From Ted.Lemon@nominum.com Tue Feb 1 04:52:24 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 22FD73A6BFF for ; Tue, 1 Feb 2011 04:52:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.595 X-Spam-Level: X-Spam-Status: No, score=-106.595 tagged_above=-999 required=5 tests=[AWL=0.004, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gIg56Ol92ewo for ; Tue, 1 Feb 2011 04:52:23 -0800 (PST) Received: from exprod7og115.obsmtp.com (exprod7og115.obsmtp.com [64.18.2.217]) by core3.amsl.com (Postfix) with ESMTP id 160E53A6BEE for ; Tue, 1 Feb 2011 04:52:22 -0800 (PST) Received: from source ([64.89.228.229]) (using TLSv1) by exprod7ob115.postini.com ([64.18.6.12]) with SMTP ID DSNKTUgCy6tOmo9hs1kVKaxsIEDZI5IYejcq@postini.com; Tue, 01 Feb 2011 04:55:40 PST Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id F227F1B82DF for ; Tue, 1 Feb 2011 04:55:38 -0800 (PST) Received: from webmail.nominum.com (webmail.nominum.com [64.89.228.50]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (Client CN "webmail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTP id D3B3D190054; Tue, 1 Feb 2011 04:55:38 -0800 (PST) Received: from vpna-148.vpn.nominum.com (64.89.227.148) by exchange-01.win.nominum.com (64.89.228.50) with Microsoft SMTP Server (TLS) id 8.2.176.0; Tue, 1 Feb 2011 04:55:38 -0800 MIME-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset="us-ascii" From: Ted Lemon In-Reply-To: Date: Tue, 1 Feb 2011 07:55:34 -0500 Content-Transfer-Encoding: quoted-printable Message-ID: References: <3E0BC533-AFF7-4E5E-A52E-BD7814FC4060@hopcount.ca> <4D472D2C.9090108@cisco.com> <6819D144-A148-41AB-BF38-A888E0950D7E@hopcount.ca> <4D476699.5060105@vpnc.org> To: Phillip Hallam-Baker X-Mailer: Apple Mail (2.1082) Cc: Paul Hoffman , dnsext@ietf.org Subject: Re: [dnsext] draft-jabley-dnsop-validator-bootstrap-00 X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 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, 01 Feb 2011 12:52:24 -0000 On Jan 31, 2011, at 11:25 PM, Phillip Hallam-Baker wrote: > I was going to reply to this post, then I read it and saw that you = cannot converse in a civil fashion. What's uncivil about calling balderdash poppycock? But it's good that you didn't reply, because Paul is right. From hallam@gmail.com Tue Feb 1 05:25:41 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 652353A6FC5; Tue, 1 Feb 2011 05:25:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.475 X-Spam-Level: X-Spam-Status: No, score=-3.475 tagged_above=-999 required=5 tests=[AWL=0.123, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 92e8cVVXccIe; Tue, 1 Feb 2011 05:25:40 -0800 (PST) Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by core3.amsl.com (Postfix) with ESMTP id C1B513A6E80; Tue, 1 Feb 2011 05:25:39 -0800 (PST) Received: by ywk9 with SMTP id 9so2824227ywk.31 for ; Tue, 01 Feb 2011 05:28:56 -0800 (PST) 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=SgiOe0GSmTUdE7Cu/YmpcjFw0pU1mjwlfZuB32imHAI=; b=MNdTkfUhZSoSP9Vv4e946eptkzsEaiXi1BZ3iBOo+aap8opO20ReNxsZj3yFZ9vjTN yeA7Hk+/Fn/WWnSDW/VzDgj6QZ3Vat0UU+clqxF4lyTZOg2+1/du4No8LYaSf7ipJkp/ /ksGeUCMdlK3PF2DZEzbDJiTECGxXrws4IIng= 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=mBxNpL0GBQSO+39AIGKjpMGSD759PYcRMUI2yh1x0/pvRfwr7SfoSw6RmypV6gOeLk XzEqUqv16ljbIGdH00mPR+Oc3VTI8rM1tL+AMi5CVL3lVhH5pscM3Ag8BhT5qUm1siHr GDeNQ1AIQgZvQDxqZzdO9OnDfr/75O5qxwipc= MIME-Version: 1.0 Received: by 10.100.134.10 with SMTP id h10mr4908603and.86.1296566936130; Tue, 01 Feb 2011 05:28:56 -0800 (PST) Received: by 10.100.109.16 with HTTP; Tue, 1 Feb 2011 05:28:56 -0800 (PST) In-Reply-To: References: Date: Tue, 1 Feb 2011 08:28:56 -0500 Message-ID: From: Phillip Hallam-Baker To: Paul Wouters Content-Type: multipart/alternative; boundary=0016e644c708a7d54a049b38839a Cc: "dnsop@ietf.org WG" , dnsext List , Knight Dave Subject: Re: [dnsext] Time vs bootstrap (was Re: draft-jabley-dnsop-validator-bootstrap-00) X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 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, 01 Feb 2011 13:25:41 -0000 --0016e644c708a7d54a049b38839a Content-Type: text/plain; charset=ISO-8859-1 On Tue, Feb 1, 2011 at 2:30 AM, Paul Wouters wrote: > On Tue, 1 Feb 2011, Brian Dickson wrote: > > This may be good enough for DNSSEC purposes. >> > > At least to then do ntp and and see that it matches our rough expectation. > Though in all, if the attacker is your controlling upstream, you are lost. > > Paul Active man in the middle is rather easier than factoring a 2048 bit RSA. With active man in the middle it is going to be possible to perform a replay attack. Checking for consistency of data is going to make a replay attack harder but not impossible. This may not matter if the device that ultimately relies on the data returned has a trustworthy time source. Otherwise you need a mechanism that provides trusted time that is secure against a replay attack. That is at minimum going to require the ability to persist a trusted time response to provide a weak form of protection but strong protection requires a challenge response mechanism and trusted time. Since ICANN does not provide trusted time, an additional trust root is going to be necessary. One issue that does come to mind is that if people are going to implement the trustworthy resolver model, it would probably be useful to be able to use the DNS resolver as a low fidelity source of trustworthy time. -- Website: http://hallambaker.com/ --0016e644c708a7d54a049b38839a Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Tue, Feb 1, 2011 at 2:30 AM, Paul Wou= ters <paul@xeler= ance.com> wrote:
On Tue, 1 Feb 2011, Brian Dickson wrote:

This may be good enough for DNSSEC purposes.

At least to then do ntp and and see that it matches our rough expectation.<= br> Though in all, if the attacker is your controlling upstream, you are lost.<= br>
Paul

Active man in the middle is rat= her easier than factoring a 2048 bit RSA.

With act= ive man in the middle it is going to be possible to perform a replay attack= .

Checking for consistency of data is going to make a rep= lay attack harder but not impossible.

This may not= matter if the device that ultimately relies on the data returned has a tru= stworthy time source.
=A0
Otherwise you need a mechanism that provides trusted ti= me that is secure against a replay attack. That is at minimum going to requ= ire the ability to persist a trusted time response to provide a weak form o= f protection but strong protection requires a challenge response mechanism = and trusted time.


Since ICANN does not provide trusted time, an addit= ional trust root is going to be necessary.

One iss= ue that does come to mind is that if people are going to implement the trus= tworthy resolver model, it would probably be useful to be able to use the D= NS resolver as a low fidelity source of trustworthy time.

--0016e644c708a7d54a049b38839a-- From hallam@gmail.com Tue Feb 1 05:41:58 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 123C63A6C00 for ; Tue, 1 Feb 2011 05:41:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.475 X-Spam-Level: X-Spam-Status: No, score=-3.475 tagged_above=-999 required=5 tests=[AWL=0.123, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ex93VIEkHDC1 for ; Tue, 1 Feb 2011 05:41:56 -0800 (PST) Received: from mail-gx0-f172.google.com (mail-gx0-f172.google.com [209.85.161.172]) by core3.amsl.com (Postfix) with ESMTP id 888B43A6D59 for ; Tue, 1 Feb 2011 05:41:40 -0800 (PST) Received: by gxk27 with SMTP id 27so2852563gxk.31 for ; Tue, 01 Feb 2011 05:44:57 -0800 (PST) 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=mTqDCXdMGVTTPqyNB5QtHkJEYpoNp6OfAVgoYw+on2s=; b=g6XWwMFpdeYB3UX6f0ugWMTggzGp1eiC9y+WhUzJjV1Idz36rGnc6OHdFIwEkRKSP3 Acym8bzx+7suYmoVoNnxh/XaHCNiPQDww/wQM2711ksuIt1YDHnivJcDMSYlT/AAvwzd 55yLcOYNuRyMC8PdUIKgYy/b+lotLuie7vHTQ= 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=dtZQ/K3+56+R07Ifx+cW+hd1m/v+vysJqOSB3do0+ndczoMDBRniHLUHgE7JyJynKy 8qVmwx0kgTvrZkrnXntCePqBdi1r3pBvZDmFrFhBPTkJ0Pqfi5JdQ7ETlMxO8iz/k8Vi MWxpyJHZnoMfeMnkaF5wbd7XlQW51JzHKbUo0= MIME-Version: 1.0 Received: by 10.100.8.9 with SMTP id 9mr4929701anh.120.1296567897286; Tue, 01 Feb 2011 05:44:57 -0800 (PST) Received: by 10.100.109.16 with HTTP; Tue, 1 Feb 2011 05:44:57 -0800 (PST) In-Reply-To: References: <3E0BC533-AFF7-4E5E-A52E-BD7814FC4060@hopcount.ca> <4D472D2C.9090108@cisco.com> <6819D144-A148-41AB-BF38-A888E0950D7E@hopcount.ca> <4D476699.5060105@vpnc.org> Date: Tue, 1 Feb 2011 08:44:57 -0500 Message-ID: From: Phillip Hallam-Baker To: Ted Lemon Content-Type: multipart/alternative; boundary=0016e6441dd8f1e8b5049b38bc0f Cc: Paul Hoffman , dnsext@ietf.org Subject: Re: [dnsext] draft-jabley-dnsop-validator-bootstrap-00 X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 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, 01 Feb 2011 13:41:58 -0000 --0016e6441dd8f1e8b5049b38bc0f Content-Type: text/plain; charset=ISO-8859-1 Given that the chairs have asked me not to avoid making personal comments it is not possible for me to respond appropriately to your post or Paul's that followed. As you both know I have professional experience and expertise in this specific area. I have been thinking about this specific problem for over two decades. You have the right to think I am wrong. But until your system has functioned in the real world for at least as long as mine you are going to have to treat me with respect. On Tue, Feb 1, 2011 at 7:55 AM, Ted Lemon wrote: > On Jan 31, 2011, at 11:25 PM, Phillip Hallam-Baker wrote: > > I was going to reply to this post, then I read it and saw that you cannot > converse in a civil fashion. > > What's uncivil about calling balderdash poppycock? > > But it's good that you didn't reply, because Paul is right. > > -- Website: http://hallambaker.com/ --0016e6441dd8f1e8b5049b38bc0f Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Given that the chairs have asked me not to avoid making personal comments i= t is not possible for me to respond appropriately to your post or Paul'= s that followed.

As you both know I have professiona= l experience and expertise in this specific area. I have been thinking abou= t this specific problem for over two decades.


You have the right to think I am wrong. = But until your system has functioned in the real world for at least as long= as mine you are going to have to treat me with respect.



On Tue, Feb 1, 201= 1 at 7:55 AM, Ted Lemon <Ted.Lemon@nominum.com> wrote:
On Jan 31, 2011, at 11:25 PM, Phillip Hallam-Baker wrote:=
> I was going to reply to this post, then I read it and saw that you can= not converse in a civil fashion.

What's uncivil about calling balderdash poppycock?

But it's good that you didn't reply, because Paul is right.




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

--0016e6441dd8f1e8b5049b38bc0f-- From ajs@shinkuro.com Tue Feb 1 06:40:17 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E981C3A6D4B for ; Tue, 1 Feb 2011 06:40:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.792 X-Spam-Level: X-Spam-Status: No, score=-101.792 tagged_above=-999 required=5 tests=[AWL=-0.433, BAYES_00=-2.599, SARE_LWSHORTT=1.24, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eafS7+GggBUf for ; Tue, 1 Feb 2011 06:40:17 -0800 (PST) Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by core3.amsl.com (Postfix) with ESMTP id 16F6A3A6CEA for ; Tue, 1 Feb 2011 06:40:17 -0800 (PST) Received: from crankycanuck.ca (external.shinkuro.com [66.92.164.104]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yitter.info (Postfix) with ESMTPSA id F3D461ECB422 for ; Tue, 1 Feb 2011 14:43:33 +0000 (UTC) Date: Tue, 1 Feb 2011 09:43:32 -0500 From: Andrew Sullivan To: dnsext@ietf.org Message-ID: <20110201144332.GD3135@shinkuro.com> References: <3E0BC533-AFF7-4E5E-A52E-BD7814FC4060@hopcount.ca> <4D472D2C.9090108@cisco.com> <6819D144-A148-41AB-BF38-A888E0950D7E@hopcount.ca> <4D476699.5060105@vpnc.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4D476699.5060105@vpnc.org> User-Agent: Mutt/1.5.18 (2008-05-17) Subject: [dnsext] Moderate one's tone, please. (was: draft-jabley-dnsop-validator-bootstrap-00) X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 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, 01 Feb 2011 14:40:18 -0000 Not to pick on Paul, but again, I'd like to suggest a moderation of tone. I understand perfectly well that there are strong views here, and I also think there is a perfectly legitimate technical dispute here. But let's go out of our collective way to keep our responses as even as possible precisely so that we can get to a satisfying conclusion for everyone. Thanks, A On Mon, Jan 31, 2011 at 05:49:13PM -0800, Paul Hoffman wrote: > On 1/31/11 4:40 PM, Phillip Hallam-Baker wrote: >> To be precise here, there is no difference in the likelihood that the >> keys will be compromised. > > Quite right. > >> The difference is that the X.509 protocol is designed to support keys >> that are persistent over long periods (decades) and DNSSEC is not. > > Poppycock. Both PKIX and DNSSEC are agnostic on how long the keys are > meant to last. Pretending that PKIX has some advantage here is nonsense. > >> In particular an X.509 self-signed certificate is an assertion that the >> key holder will maintain and use the associated private key in >> accordance with the specified practices for the specified length of time. > > Bosh. If you are talking about the "notAfter" field, it is defined as > the end of "the time interval during which the CA warrants that it will > maintain information about the status of the certificate"; that is quite > different than "maintain and use". If you are speaking of something > else, please quote from the PKIX spec. > >> You can easily find out how long Comodo or Symantec or whoever is going >> to maintain their SSL CA roots, the information is right there in the >> cert store and is irrevocable in that the CA can extend the time period >> (through recertification) but cannot reduce it. > > Balderdash. When I look in Comodo's certificate in my "cert store", I > don't see anything about how long you are going to maintain your SSL CA > root. I see something that says you will maintain *information about the > status* of the certificate; note the difference. As for "irrevocable", > that's just silly: Comodo can revoke it at any time. There is no > contract here. > >> My advice to Cisco would be to use their existing root to sign the >> published CSR for the DNS root KSK in the short term at least. > > Signing is the easy part: making their systems use that signed key is > much more difficult. That difficulty is what started this thread; > handwaving it away won't help Cisco or anyone. > >> In the longer term we are going to have to have a look at the problem at >> a higher level and work out how we are going to solve it in a scalable >> way across all the platforms that involve a root key. >> >> We are starting to make quite a little collection of industry forums >> that are doing this root key management as a sideline. > > Now everyone can rest assured: industry forums to the rescue! > _______________________________________________ > dnsext mailing list > dnsext@ietf.org > https://www.ietf.org/mailman/listinfo/dnsext -- Andrew Sullivan ajs@shinkuro.com Shinkuro, Inc. From fanf2@hermes.cam.ac.uk Tue Feb 1 08:21:51 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 47FF83A6959 for ; Tue, 1 Feb 2011 08:21:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.608 X-Spam-Level: X-Spam-Status: No, score=-4.608 tagged_above=-999 required=5 tests=[AWL=1.991, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wLBer2SBipHy for ; Tue, 1 Feb 2011 08:21:50 -0800 (PST) Received: from ppsw-50.csi.cam.ac.uk (ppsw-50.csi.cam.ac.uk [131.111.8.150]) by core3.amsl.com (Postfix) with ESMTP id E808B3A6E50 for ; Tue, 1 Feb 2011 08:21:49 -0800 (PST) X-Cam-AntiVirus: no malware found X-Cam-SpamDetails: not scanned X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ Received: from hermes-1.csi.cam.ac.uk ([131.111.8.51]:43545) by ppsw-50.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.157]:25) with esmtpa (EXTERNAL:fanf2) id 1PkJ2P-0001NL-sT (Exim 4.72) (return-path ); Tue, 01 Feb 2011 16:25:05 +0000 Received: from fanf2 (helo=localhost) by hermes-1.csi.cam.ac.uk (hermes.cam.ac.uk) with local-esmtp id 1PkJ2P-0002mE-SA (Exim 4.67) (return-path ); Tue, 01 Feb 2011 16:25:05 +0000 Date: Tue, 1 Feb 2011 16:25:05 +0000 From: Tony Finch X-X-Sender: fanf2@hermes-1.csi.cam.ac.uk To: George Barwood In-Reply-To: <1964C69C6E2043BAA45387ED557C72E2@local> Message-ID: References: <4D41D3E2.6060107@cisco.com> <82r5bxl8yo.fsf@mid.bfk.de> <1964C69C6E2043BAA45387ED557C72E2@local> User-Agent: Alpine 2.00 (LSU 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: Tony Finch Cc: dnsext@ietf.org Subject: Re: [dnsext] Historical root keys: The Large Router Vendor Speaks X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 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, 01 Feb 2011 16:21:51 -0000 On Fri, 28 Jan 2011, George Barwood wrote: > > I think it's necessary to roll the key eventually because DNSSEC > signature dates wrap, (and signatures can therefore be replayed) but > only after 136 years. There are no dates on DNS keys so I don't understand the relevance of this point. Tony. -- f.anthony.n.finch http://dotat.at/ HUMBER THAMES DOVER WIGHT PORTLAND: NORTH BACKING WEST OR NORTHWEST, 5 TO 7, DECREASING 4 OR 5, OCCASIONALLY 6 LATER IN HUMBER AND THAMES. MODERATE OR ROUGH. RAIN THEN FAIR. GOOD. From cet1@hermes.cam.ac.uk Tue Feb 1 08:46:21 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 980D83A6BFF for ; Tue, 1 Feb 2011 08:46:21 -0800 (PST) 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=[AWL=2.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SZ50i7yyOLDt for ; Tue, 1 Feb 2011 08:46:20 -0800 (PST) Received: from ppsw-41.csi.cam.ac.uk (ppsw-41.csi.cam.ac.uk [131.111.8.141]) by core3.amsl.com (Postfix) with ESMTP id AECCD3A6CCC for ; Tue, 1 Feb 2011 08:46:03 -0800 (PST) X-Cam-AntiVirus: no malware found X-Cam-SpamDetails: not scanned X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ Received: from hermes-1.csi.cam.ac.uk ([131.111.8.51]:55490) by ppsw-41.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.156]:25) with esmtpa (EXTERNAL:cet1) id 1PkJPr-000087-SN (Exim 4.72) (return-path ); Tue, 01 Feb 2011 16:49:19 +0000 Received: from prayer by hermes-1.csi.cam.ac.uk (hermes.cam.ac.uk) with local (PRAYER:cet1) id 1PkJPr-0006mk-PB (Exim 4.67) (return-path ); Tue, 01 Feb 2011 16:49:19 +0000 Received: from [131.111.11.47] by webmail.hermes.cam.ac.uk with HTTP (Prayer-1.3.3); 01 Feb 2011 16:49:19 +0000 Date: 01 Feb 2011 16:49:19 +0000 From: Chris Thompson To: Tony Finch Message-ID: In-Reply-To: References: <4D41D3E2.6060107@cisco.com> <82r5bxl8yo.fsf@mid.bfk.de> <1964C69C6E2043BAA45387ED557C72E2@local> X-Mailer: Prayer v1.3.3 Mime-Version: 1.0 Content-Type: text/plain; format=flowed; charset=ISO-8859-1 Sender: Chris Thompson Cc: dnsext@ietf.org Subject: Re: [dnsext] Historical root keys: The Large Router Vendor Speaks X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: cet1@cam.ac.uk List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Feb 2011 16:46:21 -0000 On Feb 1 2011, Tony Finch wrote: >On Fri, 28 Jan 2011, George Barwood wrote: >> >> I think it's necessary to roll the key eventually because DNSSEC >> signature dates wrap, (and signatures can therefore be replayed) but >> only after 136 years. > >There are no dates on DNS keys so I don't understand the relevance of this >point. In 2011, the root zone has an RRSIG on the DNSKEY RRset signed using the KSK, validating the current ZSK. It covers a period of a couple of weeks. In 2147, the same time_t values (mod 2^32) come round again, and this RRSIG can be replayed, if the root zone KSK has not changed. Meanwhile, this year's ZSK has been compromised - we'll be able to factorise 1024-bit moduli by then, surely? So the replay can be used to validate a compromised root zone ZSK, and we're well away to taking over the Internet :-) Of course, the likelihood of any of this stuff being around in 136 years time is ... small. -- Chris Thompson University of Cambridge Computing Service, Email: cet1@ucs.cam.ac.uk New Museums Site, Cambridge CB2 3QH, Phone: +44 1223 334715 United Kingdom. From george.barwood@blueyonder.co.uk Tue Feb 1 08:47:12 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 92B003A6C23 for ; Tue, 1 Feb 2011 08:47:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.731 X-Spam-Level: X-Spam-Status: No, score=0.731 tagged_above=-999 required=5 tests=[AWL=0.136, BAYES_00=-2.599, HELO_EQ_BLUEYON=1.4, MIME_BASE64_BLANKS=0.041, MIME_BASE64_TEXT=1.753] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D0Ost4TRBG0x for ; Tue, 1 Feb 2011 08:47:11 -0800 (PST) Received: from smtp-out3.blueyonder.co.uk (smtp-out3.blueyonder.co.uk [195.188.213.6]) by core3.amsl.com (Postfix) with ESMTP id 5C6B83A6BFF for ; Tue, 1 Feb 2011 08:47:11 -0800 (PST) Received: from [172.23.170.141] (helo=anti-virus02-08) by smtp-out3.blueyonder.co.uk with smtp (Exim 4.52) id 1PkJQx-00015h-N5; Tue, 01 Feb 2011 16:50:27 +0000 Received: from [92.238.99.235] (helo=GeorgeLaptop) by asmtp-out6.blueyonder.co.uk with smtp (Exim 4.72) (envelope-from ) id 1PkJQf-0000YX-00; Tue, 01 Feb 2011 16:50:09 +0000 Message-ID: <5AD6E9AC27744EC0BA907125654003F8@local> From: "George Barwood" To: "Tony Finch" References: <4D41D3E2.6060107@cisco.com> <82r5bxl8yo.fsf@mid.bfk.de> <1964C69C6E2043BAA45387ED557C72E2@local> Date: Tue, 1 Feb 2011 16:50:49 -0000 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.5994 Cc: dnsext@ietf.org Subject: Re: [dnsext] Historical root keys: The Large Router Vendor Speaks X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 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, 01 Feb 2011 16:47:12 -0000 DQotLS0tLSBPcmlnaW5hbCBNZXNzYWdlIC0tLS0tIA0KRnJvbTogIlRvbnkgRmluY2giIDxkb3RA ZG90YXQuYXQ+DQpUbzogIkdlb3JnZSBCYXJ3b29kIiA8Z2VvcmdlLmJhcndvb2RAYmx1ZXlvbmRl ci5jby51az4NCkNjOiA8ZG5zZXh0QGlldGYub3JnPg0KU2VudDogVHVlc2RheSwgRmVicnVhcnkg MDEsIDIwMTEgNDoyNSBQTQ0KU3ViamVjdDogUmU6IFtkbnNleHRdIEhpc3RvcmljYWwgcm9vdCBr ZXlzOiBUaGUgTGFyZ2UgUm91dGVyIFZlbmRvciBTcGVha3MNCg0KDQo+IE9uIEZyaSwgMjggSmFu IDIwMTEsIEdlb3JnZSBCYXJ3b29kIHdyb3RlOg0KPj4NCj4+IEkgdGhpbmsgaXQncyBuZWNlc3Nh cnkgdG8gcm9sbCB0aGUga2V5IGV2ZW50dWFsbHkgYmVjYXVzZSBETlNTRUMNCj4+IHNpZ25hdHVy ZSBkYXRlcyB3cmFwLCAoYW5kIHNpZ25hdHVyZXMgY2FuIHRoZXJlZm9yZSBiZSByZXBsYXllZCkg YnV0DQo+PiBvbmx5IGFmdGVyIDEzNiB5ZWFycy4NCj4gDQo+IFRoZXJlIGFyZSBubyBkYXRlcyBv biBETlMga2V5cyBzbyBJIGRvbid0IHVuZGVyc3RhbmQgdGhlIHJlbGV2YW5jZSBvZiB0aGlzDQo+ IHBvaW50Lg0KDQpPaywgd2UgYXJlIHRhbGtpbmcgYWJvdXQgcmVwbGF5IGF0dGFja3MuDQoNClRo ZSBkYXRlIGZpZWxkcyBpbiBSUlNJRyByZWNvcmRzIHdyYXAgYXJvdW5kIGFmdGVyIDEzNiB5ZWFy cywgIHNvIGFuIGF0dGFja2VyDQpjYW4gcmVwbGF5IHJlc3BvbnNlcyBmcm9tIDEzNiB5ZWFycyBh Z28gYW5kIHRoZXkgd2lsbCBiZSBhY2NlcHRlZCBhcyBjdXJyZW50LA0KaWYgbm8gS1NLIHJvbGxv dmVyIGhhcyBiZWVuIHBlcmZvcm1lZC4NCg0KVGh1cyBpbiBETlNTRUMsIHlvdSBtdXN0IHJvbGwg YW55IEtTSyBhdCBsZWFzdCBvbmNlIGV2ZXJ5IDEzNiB5ZWFycyB0byByZW1haW4gc2VjdXJlLg0K DQooIDEzNiB5ZWFycyA9IDJeMzIgc2Vjb25kcyApDQoNCkdlb3JnZQ0KDQo+IFRvbnkuDQo+IC0t IA0KPiBmLmFudGhvbnkubi5maW5jaCAgPGRvdEBkb3RhdC5hdD4gIGh0dHA6Ly9kb3RhdC5hdC8N Cj4gSFVNQkVSIFRIQU1FUyBET1ZFUiBXSUdIVCBQT1JUTEFORDogTk9SVEggQkFDS0lORyBXRVNU IE9SIE5PUlRIV0VTVCwgNSBUTyA3LA0KPiBERUNSRUFTSU5HIDQgT1IgNSwgT0NDQVNJT05BTExZ IDYgTEFURVIgSU4gSFVNQkVSIEFORCBUSEFNRVMuIE1PREVSQVRFIE9SDQo+IFJPVUdILiBSQUlO IFRIRU4gRkFJUi4gR09PRC4= From fanf2@hermes.cam.ac.uk Tue Feb 1 08:51:43 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D61043A6BFF for ; Tue, 1 Feb 2011 08:51:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.663 X-Spam-Level: X-Spam-Status: No, score=-4.663 tagged_above=-999 required=5 tests=[AWL=1.936, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C9NVb1CkQNNu for ; Tue, 1 Feb 2011 08:51:39 -0800 (PST) Received: from ppsw-52.csi.cam.ac.uk (ppsw-52.csi.cam.ac.uk [131.111.8.152]) by core3.amsl.com (Postfix) with ESMTP id 7D0A33A6C3B for ; Tue, 1 Feb 2011 08:51:39 -0800 (PST) X-Cam-AntiVirus: no malware found X-Cam-SpamDetails: not scanned X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ Received: from hermes-1.csi.cam.ac.uk ([131.111.8.51]:43488) by ppsw-52.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.159]:25) with esmtpa (EXTERNAL:fanf2) id 1PkJVH-0007Av-FX (Exim 4.72) (return-path ); Tue, 01 Feb 2011 16:54:55 +0000 Received: from fanf2 (helo=localhost) by hermes-1.csi.cam.ac.uk (hermes.cam.ac.uk) with local-esmtp id 1PkJVH-0007i2-Pu (Exim 4.67) (return-path ); Tue, 01 Feb 2011 16:54:55 +0000 Date: Tue, 1 Feb 2011 16:54:55 +0000 From: Tony Finch X-X-Sender: fanf2@hermes-1.csi.cam.ac.uk To: Chris Thompson In-Reply-To: Message-ID: References: <4D41D3E2.6060107@cisco.com> <82r5bxl8yo.fsf@mid.bfk.de> <1964C69C6E2043BAA45387ED557C72E2@local> User-Agent: Alpine 2.00 (LSU 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: Tony Finch Cc: dnsext@ietf.org Subject: Re: [dnsext] Historical root keys: The Large Router Vendor Speaks X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 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, 01 Feb 2011 16:51:43 -0000 On Tue, 1 Feb 2011, Chris Thompson wrote: > > In 2147, the same time_t values (mod 2^32) come round again, and this RRSIG > can be replayed, if the root zone KSK has not changed. Ah, of course! Thanks. Tony. -- f.anthony.n.finch http://dotat.at/ HUMBER THAMES DOVER WIGHT PORTLAND: NORTH BACKING WEST OR NORTHWEST, 5 TO 7, DECREASING 4 OR 5, OCCASIONALLY 6 LATER IN HUMBER AND THAMES. MODERATE OR ROUGH. RAIN THEN FAIR. GOOD. From hallam@gmail.com Tue Feb 1 08:57:20 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DC9CD3A6BFF for ; Tue, 1 Feb 2011 08:57:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.475 X-Spam-Level: X-Spam-Status: No, score=-3.475 tagged_above=-999 required=5 tests=[AWL=0.123, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id chkyGpizyGJS for ; Tue, 1 Feb 2011 08:57:19 -0800 (PST) Received: from mail-gx0-f172.google.com (mail-gx0-f172.google.com [209.85.161.172]) by core3.amsl.com (Postfix) with ESMTP id 95EDB3A6959 for ; Tue, 1 Feb 2011 08:57:19 -0800 (PST) Received: by gxk27 with SMTP id 27so2963838gxk.31 for ; Tue, 01 Feb 2011 09:00:36 -0800 (PST) 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=oSnIKJGwGYK2QMOE2JGXKVShkjjB+wbyn2aHkuK10Mk=; b=e7ekVqkvuUAP83YCwiqq1LwMVBuvqMb7vYlwKH6RYe/XWOHdTvO7UrPlFhfFMp8dFB 0MdhM7A/IUTVThnVQHIaiolFgaZyOaIvXyrjN4ezAaL2oHOiGfhIPjAoKa9ejrLLbGA9 Tab5090dAq+xQIUaDrMn89Znh2Tnv99RTkgkM= 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=TU5iWINHTsT9qcCNNBApj02OiZgW6LvwJ+p5YAqdR3QBqyXDDove826BLZb+77qzTE ZtUnF1MJnGJdVfLf0h+Ynk+TQwf/wlWH9kJjCVO7DngDbbKRxnnjkKivIKbtoiE65Ukc 1MtfrMHlJLRaoOVNIndzLFomo3yK3XWHjNORg= MIME-Version: 1.0 Received: by 10.100.195.12 with SMTP id s12mr5154224anf.18.1296579636335; Tue, 01 Feb 2011 09:00:36 -0800 (PST) Received: by 10.100.109.16 with HTTP; Tue, 1 Feb 2011 09:00:36 -0800 (PST) In-Reply-To: References: <4D41D3E2.6060107@cisco.com> <82r5bxl8yo.fsf@mid.bfk.de> <1964C69C6E2043BAA45387ED557C72E2@local> Date: Tue, 1 Feb 2011 12:00:36 -0500 Message-ID: From: Phillip Hallam-Baker To: cet1@cam.ac.uk Content-Type: multipart/alternative; boundary=0016e644c630a5955a049b3b784b Cc: dnsext@ietf.org Subject: Re: [dnsext] Historical root keys: The Large Router Vendor Speaks X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 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, 01 Feb 2011 16:57:21 -0000 --0016e644c630a5955a049b3b784b Content-Type: text/plain; charset=ISO-8859-1 On Tue, Feb 1, 2011 at 11:49 AM, Chris Thompson wrote: > > Of course, the likelihood of any of this stuff being around in 136 years > time > is ... small. The likelihood of us being around is small. But the system itself will almost certainly still be around. About 60% of the light fixtures in my house in the US suffer from a fairly elementary design flaw that was corrected in the European standard fixture (the Swan bayonet) over a century ago. As a result they have a tendency to work loose under vibration. The design considerations of the QWERTY keyboard have been known as long. But I am typing on one right now. Make still has a peculiar syntax glitch that the designer thought they should have fixed the day after the first release but could not because there was an installed base that objected to the change. Once this infrastructure is deployed it is going to only be possible to add. Fortunately any given piece of equipment need only need install the most recent root. So unless we expect physical equipment to have to last more than 136 years we can work fine with a system where roots are valid for 25 years and a new one is published every five years. Given that RSA1024 is about to be deprecated, this is really only an issue for RSA2048. -- Website: http://hallambaker.com/ --0016e644c630a5955a049b3b784b Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Tue, Feb 1, 2011 at 11:49 AM, Chris T= hompson <cet1@cam.ac= .uk> wrote:

Of course, the likelihood of any of this stuff being around in 136 years ti= me
is ... small.

The likelihood of us being ar= ound is small. But the system itself will almost certainly still be around.=

About 60% of the light fixtures in my house in th= e US suffer from a fairly elementary design flaw that was corrected in the = European standard fixture (the Swan bayonet) =A0over a century ago. As a re= sult they have a tendency to work loose under vibration.

The design considerations of the QWERTY keyboard have b= een known as long. But I am typing on one right now.

Make still has a peculiar syntax glitch that the designer thought they s= hould have fixed the day after the first release but could not because ther= e was an installed base that objected to the change.


Once this infrastructure is deployed it = is going to only be possible to add.=A0

Fortunate= ly any given piece of equipment need only need install the most recent root= . So unless we expect physical equipment to have to last more than 136 year= s we can work fine with a system where roots are valid for 25 years and a n= ew one is published every five years.


Given that RSA1024 is about to be deprecated,= this is really only an issue for RSA2048.

--
Webs= ite: http://hallambaker.com/
--0016e644c630a5955a049b3b784b-- From paul.hoffman@vpnc.org Tue Feb 1 09:04:24 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BC49A3A6AE5 for ; Tue, 1 Feb 2011 09:04:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.757 X-Spam-Level: X-Spam-Status: No, score=-101.757 tagged_above=-999 required=5 tests=[AWL=0.289, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rouLK00PA6gr for ; Tue, 1 Feb 2011 09:04:23 -0800 (PST) Received: from hoffman.proper.com (Hoffman.Proper.COM [207.182.41.81]) by core3.amsl.com (Postfix) with ESMTP id B70223A6CCE for ; Tue, 1 Feb 2011 09:04:23 -0800 (PST) Received: from MacBook-08.local (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 p11H7e4J030868 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Tue, 1 Feb 2011 10:07:40 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Message-ID: <4D483DDB.3020802@vpnc.org> Date: Tue, 01 Feb 2011 09:07:39 -0800 From: Paul Hoffman User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: dnsext@ietf.org References: <3E0BC533-AFF7-4E5E-A52E-BD7814FC4060@hopcount.ca> <4D472D2C.9090108@cisco.com> <6819D144-A148-41AB-BF38-A888E0950D7E@hopcount.ca> <4D476699.5060105@vpnc.org> <20110201144332.GD3135@shinkuro.com> In-Reply-To: <20110201144332.GD3135@shinkuro.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [dnsext] Moderate one's tone, please. X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 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, 01 Feb 2011 17:04:24 -0000 On 2/1/11 6:43 AM, Andrew Sullivan wrote: > Not to pick on Paul, but again, I'd like to suggest a moderation of > tone. I understand perfectly well that there are strong views here, > and I also think there is a perfectly legitimate technical dispute > here. But let's go out of our collective way to keep our responses as > even as possible precisely so that we can get to a satisfying > conclusion for everyone. Phill was making technical statements, not "views". His technical statements were wrong. I believe that saying "poppycock" and "bosh" and "balderdash" instead of repeating "this is demonstrably wrong" makes the writing more interesting, but I hear that others may not appreciate interesting writing. Note that I did quote from the relevant RFC as I did so, and Phill has not responded on the technical merits (or lack thereof) of his statements. From ajs@shinkuro.com Tue Feb 1 09:20:19 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 82F573A6C56 for ; Tue, 1 Feb 2011 09:20:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.39 X-Spam-Level: X-Spam-Status: No, score=-102.39 tagged_above=-999 required=5 tests=[AWL=0.209, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tR5u5N1OykES for ; Tue, 1 Feb 2011 09:20:18 -0800 (PST) Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by core3.amsl.com (Postfix) with ESMTP id 8C0F23A6BAE for ; Tue, 1 Feb 2011 09:20:18 -0800 (PST) Received: from crankycanuck.ca (external.shinkuro.com [66.92.164.104]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yitter.info (Postfix) with ESMTPSA id 9AB0B1ECB422 for ; Tue, 1 Feb 2011 17:23:35 +0000 (UTC) Date: Tue, 1 Feb 2011 12:23:34 -0500 From: Andrew Sullivan To: dnsext@ietf.org Message-ID: <20110201172333.GC5586@shinkuro.com> References: <3E0BC533-AFF7-4E5E-A52E-BD7814FC4060@hopcount.ca> <4D472D2C.9090108@cisco.com> <6819D144-A148-41AB-BF38-A888E0950D7E@hopcount.ca> <4D476699.5060105@vpnc.org> <20110201144332.GD3135@shinkuro.com> <4D483DDB.3020802@vpnc.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4D483DDB.3020802@vpnc.org> User-Agent: Mutt/1.5.18 (2008-05-17) Subject: Re: [dnsext] Moderate one's tone, please. X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 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, 01 Feb 2011 17:20:19 -0000 On Tue, Feb 01, 2011 at 09:07:39AM -0800, Paul Hoffman wrote: > Phill was making technical statements, not "views". Perhaps you and I have different theories about the meanings of those terms. The point I'm trying to make is just that, the more contentious the disagreement, the nastier discussions can get on mailing lists. So I'm trying to ask everyone to be even nicer than usual. > Note that I did quote from the relevant RFC as I did so, and Phill has > not responded on the technical merits (or lack thereof) of his > statements. I wish to be pefectly clear that plainly stated cases comparing one person's argument against relevant RFC(s) are not, in my opinion, to be moderated and are not personal attacks. I'm only saying that, in making an argument, one can either make that argument nicely or state things in more colourful and stinging terms; and, I'd prefer that we lean towards the former approach (particularly just now). For the same reasons, if anyone wishes to argue exclusively from appeals to authority on the basis of deployed systems, he or she will need to address the complaints that the deployed systems have something wrong with them, or else accept that such arguments will continue to be made. But we will all benefit if we try very hard to be even more civil and dispassionate than usual in discussing these matters. Thanks, A -- Andrew Sullivan ajs@shinkuro.com Shinkuro, Inc. From hallam@gmail.com Tue Feb 1 11:06:24 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DE13F3A6FC4 for ; Tue, 1 Feb 2011 11:06:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.476 X-Spam-Level: X-Spam-Status: No, score=-3.476 tagged_above=-999 required=5 tests=[AWL=0.122, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IsB3ruwQiISB for ; Tue, 1 Feb 2011 11:06:22 -0800 (PST) Received: from mail-yi0-f44.google.com (mail-yi0-f44.google.com [209.85.218.44]) by core3.amsl.com (Postfix) with ESMTP id 474F03A6FDC for ; Tue, 1 Feb 2011 11:06:22 -0800 (PST) Received: by yie19 with SMTP id 19so3001706yie.31 for ; Tue, 01 Feb 2011 11:09:39 -0800 (PST) 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=1SstoqePZxTiU3ByaXEe5myewQRMrXYXnJnmEEma1+Y=; b=a9qLKpcW8MNHA/5p7WCN6yfa0WMy4j3fNJZJ658dqr2pM78Ql7+eySYbmQOBsLeKkr cvYCXoogAh+qWS4qQmMytJlqyI90zzk+hvb2BOklppdL5eB9Y9z2PAUlJhsRJViaVlOV O4LR4xC6LTP4aE8ORbKpoO1JlD55O2XUK1HL4= 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=xnX2x1FAI9HeG/rTh5dhysojT4Aw+K7WonV40DEICbjhSuNeSaP/DLOB5TFoItlB9e nABG4HFAyjIQpaVOHHDd5dNBl3OU/t7epi59PUUFFKcRHSHMWDBrRmK2KWCmu+pv+Nhn Dpg+pWBcDC0SfIr2DbPRysy5BZYC9uT2Lnbdc= MIME-Version: 1.0 Received: by 10.100.167.5 with SMTP id p5mr3948691ane.222.1296587378797; Tue, 01 Feb 2011 11:09:38 -0800 (PST) Received: by 10.100.109.16 with HTTP; Tue, 1 Feb 2011 11:09:34 -0800 (PST) In-Reply-To: <4D483DDB.3020802@vpnc.org> References: <3E0BC533-AFF7-4E5E-A52E-BD7814FC4060@hopcount.ca> <4D472D2C.9090108@cisco.com> <6819D144-A148-41AB-BF38-A888E0950D7E@hopcount.ca> <4D476699.5060105@vpnc.org> <20110201144332.GD3135@shinkuro.com> <4D483DDB.3020802@vpnc.org> Date: Tue, 1 Feb 2011 14:09:34 -0500 Message-ID: From: Phillip Hallam-Baker To: Paul Hoffman Content-Type: multipart/alternative; boundary=0016e643465822314b049b3d4606 Cc: dnsext@ietf.org Subject: Re: [dnsext] Moderate one's tone, please. X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 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, 01 Feb 2011 19:06:25 -0000 --0016e643465822314b049b3d4606 Content-Type: text/plain; charset=ISO-8859-1 The reason I took exception to your tone Paul is that I interpreted it as implying that anyone who does not agree with you must do so from ignorance. Many people, at least ten from the DNS and PKI fields have told me that they do not see any point in participating in IETF because they find these tactics unpleasant. I know that my particular views are well founded in industry practice and experience. I have worked on this particular problem for over fifteen years. I have taught courses on how to manage offline keys. I do not think that you can truthfully claim an equivalent level of expertise. Thus for you to be using the language you do suggests that you are attempting to bully my arguments away rather than answer them as I have seen you do in other instances against other people who have subsequently decided not to have anything to do with the IETF in future. So that is the reason that I found your comments so unacceptable. On Tue, Feb 1, 2011 at 12:07 PM, Paul Hoffman wrote: > On 2/1/11 6:43 AM, Andrew Sullivan wrote: > >> Not to pick on Paul, but again, I'd like to suggest a moderation of >> tone. I understand perfectly well that there are strong views here, >> and I also think there is a perfectly legitimate technical dispute >> here. But let's go out of our collective way to keep our responses as >> even as possible precisely so that we can get to a satisfying >> conclusion for everyone. >> > > Phill was making technical statements, not "views". His technical > statements were wrong. I believe that saying "poppycock" and "bosh" and > "balderdash" instead of repeating "this is demonstrably wrong" makes the > writing more interesting, but I hear that others may not appreciate > interesting writing. > > Note that I did quote from the relevant RFC as I did so, and Phill has not > responded on the technical merits (or lack thereof) of his statements. > _______________________________________________ > dnsext mailing list > dnsext@ietf.org > https://www.ietf.org/mailman/listinfo/dnsext > -- Website: http://hallambaker.com/ --0016e643465822314b049b3d4606 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable The reason I took exception to your tone Paul is that I interpreted it as i= mplying that anyone who does not agree with you must do so from ignorance.= =A0

Many people, at least ten from the DNS and PKI field= s have told me that they do not see any point in participating in IETF beca= use they find these tactics unpleasant.

I know that my particular views are well founded in ind= ustry practice and experience. I have worked on this particular problem for= over fifteen years. I have taught courses on how to manage offline keys.= =A0

I do not think that you can truthfully claim an equival= ent level of expertise. Thus for you to be using the language you do sugges= ts that you are attempting to bully my arguments away rather than answer th= em as I have seen you do in other instances against other people who have s= ubsequently decided not to have anything to do with the IETF in future.


So that is the reason that I found your = comments so unacceptable.=A0


O= n Tue, Feb 1, 2011 at 12:07 PM, Paul Hoffman <paul.hoffman@vpnc.org> wrot= e:
On 2/1/11 6:43 AM, Andrew Sullivan wrote:
Not to pick on Paul, but again, I'd like to suggest a moderation of
tone. =A0I understand perfectly well that there are strong views here,
and I also think there is a perfectly legitimate technical dispute
here. =A0But let's go out of our collective way to keep our responses a= s
even as possible precisely so that we can get to a satisfying
conclusion for everyone.

Phill was making technical statements, not "views". His technical= statements were wrong. I believe that saying "poppycock" and &qu= ot;bosh" and "balderdash" instead of repeating "this is= demonstrably wrong" makes the writing more interesting, but I hear th= at others may not appreciate interesting writing.

Note that I did quote from the relevant RFC as I did so, and Phill has not = responded on the technical merits (or lack thereof) of his statements.
_______________________________________________
dnsext mailing list
dnsext@ietf.org = https://www.ietf.org/mailman/listinfo/dnsext



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

--0016e643465822314b049b3d4606-- From ogud@ogud.com Tue Feb 1 11:09:20 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9DD4F3A6C4F for ; Tue, 1 Feb 2011 11:09:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.562 X-Spam-Level: X-Spam-Status: No, score=-102.562 tagged_above=-999 required=5 tests=[AWL=0.037, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YcNLV-nYWxdd for ; Tue, 1 Feb 2011 11:09:17 -0800 (PST) Received: from stora.ogud.com (stora.ogud.com [66.92.146.20]) by core3.amsl.com (Postfix) with ESMTP id DD0583A6B01 for ; Tue, 1 Feb 2011 11:09:16 -0800 (PST) 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 p11JCXeW044704 for ; Tue, 1 Feb 2011 14:12:33 -0500 (EST) (envelope-from ogud@ogud.com) Message-ID: <4D485B1B.80801@ogud.com> Date: Tue, 01 Feb 2011 14:12:27 -0500 From: Olafur Gudmundsson User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-GB; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: dnsext@ietf.org References: <4D41D3E2.6060107@cisco.com> <82r5bxl8yo.fsf@mid.bfk.de> <1964C69C6E2043BAA45387ED557C72E2@local> <5AD6E9AC27744EC0BA907125654003F8@local> In-Reply-To: <5AD6E9AC27744EC0BA907125654003F8@local> 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] Historical root keys: The Large Router Vendor Speaks X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 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, 01 Feb 2011 19:09:20 -0000 On 01/02/2011 11:50 AM, George Barwood wrote: > > ----- Original Message ----- > From: "Tony Finch" > To: "George Barwood" > Cc: > Sent: Tuesday, February 01, 2011 4:25 PM > Subject: Re: [dnsext] Historical root keys: The Large Router Vendor Speaks > > >> On Fri, 28 Jan 2011, George Barwood wrote: >>> >>> I think it's necessary to roll the key eventually because DNSSEC >>> signature dates wrap, (and signatures can therefore be replayed) but >>> only after 136 years. >> >> There are no dates on DNS keys so I don't understand the relevance of this >> point. > > Ok, we are talking about replay attacks. > > The date fields in RRSIG records wrap around after 136 years, so an attacker > can replay responses from 136 years ago and they will be accepted as current, > if no KSK rollover has been performed. > > Thus in DNSSEC, you must roll any KSK at least once every 136 years to remain secure. > > ( 136 years = 2^32 seconds ) > Actually there is no explicit requirement to roll, you need signatures to be included that show the key has not changed every 34 years or so, as validators are supposed to only accept timer values that are not that far off each other (there are times I wish we had gone with at least 40 bit timer values). Olafur From paul@xelerance.com Tue Feb 1 11:11:12 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EB89B3A6FE2 for ; Tue, 1 Feb 2011 11:11:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.577 X-Spam-Level: X-Spam-Status: No, score=-2.577 tagged_above=-999 required=5 tests=[AWL=0.022, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZmZb2EWHS19M for ; Tue, 1 Feb 2011 11:11:10 -0800 (PST) Received: from newtla.xelerance.com (newtla.xelerance.com [193.110.157.143]) by core3.amsl.com (Postfix) with ESMTP id 7999E3A6EE9 for ; Tue, 1 Feb 2011 11:11:10 -0800 (PST) Received: from tla.xelerance.com (tla.xelerance.com [193.110.157.130]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by newtla.xelerance.com (Postfix) with ESMTP id A939BC4FA; Tue, 1 Feb 2011 14:14:27 -0500 (EST) Date: Tue, 1 Feb 2011 14:14:27 -0500 (EST) From: Paul Wouters To: Andrew Sullivan In-Reply-To: <20110201172333.GC5586@shinkuro.com> Message-ID: References: <3E0BC533-AFF7-4E5E-A52E-BD7814FC4060@hopcount.ca> <4D472D2C.9090108@cisco.com> <6819D144-A148-41AB-BF38-A888E0950D7E@hopcount.ca> <4D476699.5060105@vpnc.org> <20110201144332.GD3135@shinkuro.com> <4D483DDB.3020802@vpnc.org> <20110201172333.GC5586@shinkuro.com> User-Agent: Alpine 1.10 (LFD 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: dnsext@ietf.org Subject: Re: [dnsext] Moderate one's tone, please. X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 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, 01 Feb 2011 19:11:12 -0000 On Tue, 1 Feb 2011, Andrew Sullivan wrote: > For the same reasons, if anyone wishes to argue exclusively from > appeals to authority on the basis of deployed systems, he or she will > need to address the complaints that the deployed systems have > something wrong with them, or else accept that such arguments will > continue to be made. I'm not sure this parses right? Someone repeatedly stating unproven generalities based on appeal of authority (or old age of the system) is causing an effective denieal of service on the discussion forward. You're telling people need to continiously argue against these claims without merit? In that case I would like file my expenses with you :) Perhaps you meant to say "Please don't use appeal of authority in your argumentation" Paul From fanf2@hermes.cam.ac.uk Tue Feb 1 11:11:54 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A729B3A7004 for ; Tue, 1 Feb 2011 11:11:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.715 X-Spam-Level: X-Spam-Status: No, score=-4.715 tagged_above=-999 required=5 tests=[AWL=1.884, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q7pNXRWvKsue for ; Tue, 1 Feb 2011 11:11:45 -0800 (PST) Received: from ppsw-51.csi.cam.ac.uk (ppsw-51.csi.cam.ac.uk [131.111.8.151]) by core3.amsl.com (Postfix) with ESMTP id A2CFC3A6FFF for ; Tue, 1 Feb 2011 11:11:42 -0800 (PST) X-Cam-AntiVirus: no malware found X-Cam-SpamDetails: not scanned X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ Received: from hermes-1.csi.cam.ac.uk ([131.111.8.51]:35056) by ppsw-51.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.158]:25) with esmtpa (EXTERNAL:fanf2) id 1PkLgp-0005NV-Wb (Exim 4.72) (return-path ); Tue, 01 Feb 2011 19:14:59 +0000 Received: from fanf2 (helo=localhost) by hermes-1.csi.cam.ac.uk (hermes.cam.ac.uk) with local-esmtp id 1PkLgp-0001hR-32 (Exim 4.67) (return-path ); Tue, 01 Feb 2011 19:14:59 +0000 Date: Tue, 1 Feb 2011 19:14:59 +0000 From: Tony Finch X-X-Sender: fanf2@hermes-1.csi.cam.ac.uk To: Phillip Hallam-Baker In-Reply-To: Message-ID: References: <17A80F45-52CB-43F6-BD4A-3488821F6933@hopcount.ca> <3A1DEE95-8C8E-4C89-97EB-6D8F799ADE25@virtualized.org> <583A62B0-0DBF-469A-AF8A-B81DEDD1E7E2@dotat.at> <86B1D38A-C274-4335-B30E-3C5C0DF05C38@hopcount.ca> <4D45DE93.9090508@vpnc.org> <4C747F08-A9E8-46E6-AE76-0A999A16D276@hopcount.ca> User-Agent: Alpine 2.00 (LSU 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: Tony Finch Cc: dnsext@ietf.org Subject: Re: [dnsext] historal root keys for upgrade path? X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 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, 01 Feb 2011 19:11:54 -0000 On Mon, 31 Jan 2011, Phillip Hallam-Baker wrote: > > ICANN can eliminate the problem of rollovers for scheduled rolls by > announcing that it will never roll the key except in an emergency. The problem with that idea is that (per Cisco's plan) if every Internet-connected device is a validator, an emergency will break the entire Internet. You *have* to plan for root key rollovers to be normal events that can be handled without fuss. > We faced this problem in the PKI world and found that 20 year roots were a > better solution. But in the PKI world you have many trust anchors which can come and go as time passes without breaking the whole system. Tony. -- f.anthony.n.finch http://dotat.at/ HUMBER THAMES DOVER WIGHT PORTLAND: NORTH BACKING WEST OR NORTHWEST, 5 TO 7, DECREASING 4 OR 5, OCCASIONALLY 6 LATER IN HUMBER AND THAMES. MODERATE OR ROUGH. RAIN THEN FAIR. GOOD. From paul@xelerance.com Tue Feb 1 11:17:13 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 39B603A6F86 for ; Tue, 1 Feb 2011 11:17:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.577 X-Spam-Level: X-Spam-Status: No, score=-2.577 tagged_above=-999 required=5 tests=[AWL=0.022, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LffM7Q5Ug3Sx for ; Tue, 1 Feb 2011 11:17:12 -0800 (PST) Received: from newtla.xelerance.com (newtla.xelerance.com [193.110.157.143]) by core3.amsl.com (Postfix) with ESMTP id 623873A6DD5 for ; Tue, 1 Feb 2011 11:17:12 -0800 (PST) Received: from tla.xelerance.com (tla.xelerance.com [193.110.157.130]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by newtla.xelerance.com (Postfix) with ESMTP id 86266C4FA; Tue, 1 Feb 2011 14:20:29 -0500 (EST) Date: Tue, 1 Feb 2011 14:20:29 -0500 (EST) From: Paul Wouters To: Phillip Hallam-Baker In-Reply-To: Message-ID: References: <3E0BC533-AFF7-4E5E-A52E-BD7814FC4060@hopcount.ca> <4D472D2C.9090108@cisco.com> <6819D144-A148-41AB-BF38-A888E0950D7E@hopcount.ca> <4D476699.5060105@vpnc.org> <20110201144332.GD3135@shinkuro.com> <4D483DDB.3020802@vpnc.org> User-Agent: Alpine 1.10 (LFD 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: Paul Hoffman , dnsext@ietf.org Subject: Re: [dnsext] Moderate one's tone, please. X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 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, 01 Feb 2011 19:17:13 -0000 On Tue, 1 Feb 2011, Phillip Hallam-Baker wrote: > I know that my particular views are well founded in industry practice and > experience. I have worked on this particular problem for over fifteen > years. This is an example of such an appeal to authority that some people keep using, usually combined with general all-encompassing statements. > I do not think that you can truthfully claim an equivalent level of > expertise. I am reminded of your claim of 20 years of DNSSEC experience at the Toronto TASK meeting...... Paul From fanf2@hermes.cam.ac.uk Tue Feb 1 11:30:06 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 867033A6D71 for ; Tue, 1 Feb 2011 11:30:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.765 X-Spam-Level: X-Spam-Status: No, score=-4.765 tagged_above=-999 required=5 tests=[AWL=1.834, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AB+Pf8wfkkUW for ; Tue, 1 Feb 2011 11:30:04 -0800 (PST) Received: from ppsw-41.csi.cam.ac.uk (ppsw-41.csi.cam.ac.uk [131.111.8.141]) by core3.amsl.com (Postfix) with ESMTP id 78B343A6D00 for ; Tue, 1 Feb 2011 11:30:04 -0800 (PST) X-Cam-AntiVirus: no malware found X-Cam-SpamDetails: not scanned X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ Received: from hermes-1.csi.cam.ac.uk ([131.111.8.51]:57949) by ppsw-41.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.156]:25) with esmtpa (EXTERNAL:fanf2) id 1PkLyb-00019q-Rv (Exim 4.72) (return-path ); Tue, 01 Feb 2011 19:33:21 +0000 Received: from fanf2 (helo=localhost) by hermes-1.csi.cam.ac.uk (hermes.cam.ac.uk) with local-esmtp id 1PkLyb-0003ym-Kf (Exim 4.67) (return-path ); Tue, 01 Feb 2011 19:33:21 +0000 Date: Tue, 1 Feb 2011 19:33:21 +0000 From: Tony Finch X-X-Sender: fanf2@hermes-1.csi.cam.ac.uk To: Phillip Hallam-Baker In-Reply-To: Message-ID: References: <17A80F45-52CB-43F6-BD4A-3488821F6933@hopcount.ca> <3A1DEE95-8C8E-4C89-97EB-6D8F799ADE25@virtualized.org> <583A62B0-0DBF-469A-AF8A-B81DEDD1E7E2@dotat.at> <86B1D38A-C274-4335-B30E-3C5C0DF05C38@hopcount.ca> <4D45DE93.9090508@vpnc.org> <4C747F08-A9E8-46E6-AE76-0A999A16D276@hopcount.ca> User-Agent: Alpine 2.00 (LSU 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: Tony Finch Cc: Paul Hoffman , dnsext@ietf.org Subject: Re: [dnsext] historal root keys for upgrade path? X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 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, 01 Feb 2011 19:30:06 -0000 On Tue, 1 Feb 2011, Phillip Hallam-Baker wrote: > > The whole purpose of high security root key management is to ensure that > compromise is not possible without a major systemic failure. If you are doing it right, you are more likely to accidentally destroy the private key than expose it. Tony. -- f.anthony.n.finch http://dotat.at/ HUMBER THAMES DOVER WIGHT PORTLAND: NORTH BACKING WEST OR NORTHWEST, 5 TO 7, DECREASING 4 OR 5, OCCASIONALLY 6 LATER IN HUMBER AND THAMES. MODERATE OR ROUGH. RAIN THEN FAIR. GOOD. From ogud@ogud.com Tue Feb 1 11:36:33 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 11D3E3A6DE0 for ; Tue, 1 Feb 2011 11:36:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.563 X-Spam-Level: X-Spam-Status: No, score=-102.563 tagged_above=-999 required=5 tests=[AWL=0.036, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2bN827ehlm5c for ; Tue, 1 Feb 2011 11:36:32 -0800 (PST) Received: from stora.ogud.com (stora.ogud.com [66.92.146.20]) by core3.amsl.com (Postfix) with ESMTP id AD69E3A6A7A for ; Tue, 1 Feb 2011 11:36:31 -0800 (PST) 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 p11JdmLC044970 for ; Tue, 1 Feb 2011 14:39:49 -0500 (EST) (envelope-from ogud@ogud.com) Message-ID: <4D48617E.1020408@ogud.com> Date: Tue, 01 Feb 2011 14:39:42 -0500 From: Olafur Gudmundsson User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-GB; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: dnsext@ietf.org 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: [dnsext] DNSEXT progress and possible meeting at IETF-80 X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 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, 01 Feb 2011 19:36:33 -0000 At this point the chairs are not sure there is a reason to have a meeting. We have a number of work items that can be discussed on the mailing list or wait on chair action. There is one ttem that seems to have died, "Aliasing Requirements". Unless there is movement on that document we can not adopt any new aliasing proposed changes. The chairs will make a final call on meeting in about 10 days. Olafur & Andrew From paul.hoffman@vpnc.org Tue Feb 1 11:47:59 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DF2BF3A6DF4 for ; Tue, 1 Feb 2011 11:47:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.756 X-Spam-Level: X-Spam-Status: No, score=-101.756 tagged_above=-999 required=5 tests=[AWL=0.290, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Mat+BH5p80Lt for ; Tue, 1 Feb 2011 11:47:59 -0800 (PST) Received: from hoffman.proper.com (Hoffman.Proper.COM [207.182.41.81]) by core3.amsl.com (Postfix) with ESMTP id 41A233A6DEE for ; Tue, 1 Feb 2011 11:47:59 -0800 (PST) Received: from MacBook-08.local (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 p11JpF1x053135 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Tue, 1 Feb 2011 12:51:16 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Message-ID: <4D486433.9090905@vpnc.org> Date: Tue, 01 Feb 2011 11:51:15 -0800 From: Paul Hoffman User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: dnsext@ietf.org References: <3E0BC533-AFF7-4E5E-A52E-BD7814FC4060@hopcount.ca> <4D472D2C.9090108@cisco.com> <6819D144-A148-41AB-BF38-A888E0950D7E@hopcount.ca> <4D476699.5060105@vpnc.org> <20110201144332.GD3135@shinkuro.com> <4D483DDB.3020802@vpnc.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [dnsext] Moderate one's tone, please. X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 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, 01 Feb 2011 19:48:00 -0000 On 2/1/11 11:09 AM, Phillip Hallam-Baker wrote: > So that is the reason that I found your comments so unacceptable. I understand that you found my comments so unacceptable. It is still useful for you to comment on thread with technical justification for your statements. I quoted from the PKIX RFC showing, I believe, that you are factually wrong. If you can quote from that or a similar RFC showing that you are right, that would be helpful. If you can't, saying that you can't would also be helpful. From hallam@gmail.com Tue Feb 1 11:49:18 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 319A63A6D8D for ; Tue, 1 Feb 2011 11:49:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.477 X-Spam-Level: X-Spam-Status: No, score=-3.477 tagged_above=-999 required=5 tests=[AWL=0.121, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HyO5KMpd+SvA for ; Tue, 1 Feb 2011 11:49:17 -0800 (PST) Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by core3.amsl.com (Postfix) with ESMTP id CF3613A6D54 for ; Tue, 1 Feb 2011 11:49:16 -0800 (PST) Received: by ywk9 with SMTP id 9so3032766ywk.31 for ; Tue, 01 Feb 2011 11:52:34 -0800 (PST) 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=09QNHjLNHDwyK/uRqt2QrYSFqg77COxXZ6xcY9/ijSg=; b=xM0nj/u/3+SC6oz8GEonLE7GwvuilWNe7sdJhYLuECGAZaF6u0D8E1cjR0PG/8BJsv wIc/pRAz0FFq8IQm3ybHmjNco1g5lunNJGW1YNAtXsWHvz535KMaW/7EW6qMJJerWW9V sawrJElHdW7YnNidjC55xhdmF6KjwWXIGDw2M= 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=DXbX5adq5Sw0LOz2KYq/pKYH5PS5BaPVdXjQ2u2xXxl84ogjcHFgpZ6ANKRHtKPYdt +MWhOQN5U2TYMNvFF7vCDUuj4g/cUAmsTXgMsDHVW1Vb1n8BVvpwmuYh6Yd7jecdw/EE nW4wtLIcAieSWSvN4vq4TkZqGThMSnzeJaKwA= MIME-Version: 1.0 Received: by 10.100.195.12 with SMTP id s12mr5276025anf.18.1296589953206; Tue, 01 Feb 2011 11:52:33 -0800 (PST) Received: by 10.100.109.16 with HTTP; Tue, 1 Feb 2011 11:52:33 -0800 (PST) In-Reply-To: References: <3E0BC533-AFF7-4E5E-A52E-BD7814FC4060@hopcount.ca> <4D472D2C.9090108@cisco.com> <6819D144-A148-41AB-BF38-A888E0950D7E@hopcount.ca> <4D476699.5060105@vpnc.org> <20110201144332.GD3135@shinkuro.com> <4D483DDB.3020802@vpnc.org> Date: Tue, 1 Feb 2011 14:52:33 -0500 Message-ID: From: Phillip Hallam-Baker To: Paul Wouters Content-Type: multipart/alternative; boundary=0016e644c6309489d6049b3ddfc4 Cc: Paul Hoffman , dnsext@ietf.org Subject: Re: [dnsext] Moderate one's tone, please. X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 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, 01 Feb 2011 19:49:18 -0000 --0016e644c6309489d6049b3ddfc4 Content-Type: text/plain; charset=ISO-8859-1 Appeal to personal authority is entirely appropriate when defending against an attack on personal expertise. I do not believe that I claimed twenty years experience in DNSSEC, but I certainly have over twenty years experience in PKI. I discussed DNSSEC with Don in 1995. That work was itself performed in the aftermath of the collapse of the PEM root project. Given that my argument at TASK was that we had been engaged in development of DNSSEC since the incorporation date of VeriSign (1995) I am pretty sure that I gave the right date. I spoke on this issue at the second World Wide Web Conference in Chicago in 1994. On Tue, Feb 1, 2011 at 2:20 PM, Paul Wouters wrote: > On Tue, 1 Feb 2011, Phillip Hallam-Baker wrote: > > I know that my particular views are well founded in industry practice and >> experience. I have worked on this particular problem for over fifteen >> years. >> > > This is an example of such an appeal to authority that some people keep > using, usually combined with general all-encompassing statements. > > > I do not think that you can truthfully claim an equivalent level of >> expertise. >> > > I am reminded of your claim of 20 years of DNSSEC experience at the > Toronto TASK meeting...... > > Paul > -- Website: http://hallambaker.com/ --0016e644c6309489d6049b3ddfc4 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Appeal to personal authority is entirely appropriate when defending against= an attack on personal expertise.

I do not believe that = I claimed twenty years experience in DNSSEC, but I certainly have over twen= ty years experience in PKI.=A0

I discussed DNSSEC with Don in 1995. That work was itse= lf performed in the aftermath of the collapse of the PEM root project. Give= n that my argument at TASK was that we had been engaged in development of D= NSSEC since the incorporation date of VeriSign (1995) I am pretty sure that= I gave the right date.


I spoke on this issue at the second Worl= d Wide Web Conference in Chicago in 1994.


On Tue, Feb 1, 2011 at 2:20 PM, Paul Wouters <paul@xelerance.com= > wrote:
On Tue, 1 Feb 2011, Phill= ip Hallam-Baker wrote:

I know that my particular views are well founded in industry practice and experience. I have worked on this particular problem for over fifteen
years.

This is an example of such an appeal to authority that some people keep
using, usually combined with general all-encompassing statements.


I do not think that you can truthfully claim an equivalent level of
expertise.

I am reminded of your claim of 20 years of DNSSEC experience at the
Toronto TASK meeting......

Paul



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

--0016e644c6309489d6049b3ddfc4-- From hallam@gmail.com Tue Feb 1 12:14:51 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3B9783A6C81 for ; Tue, 1 Feb 2011 12:14:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.627 X-Spam-Level: X-Spam-Status: No, score=-3.627 tagged_above=-999 required=5 tests=[AWL=-0.029, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 09hEVFG6J0km for ; Tue, 1 Feb 2011 12:14:50 -0800 (PST) Received: from mail-gw0-f44.google.com (mail-gw0-f44.google.com [74.125.83.44]) by core3.amsl.com (Postfix) with ESMTP id D4BFA3A6C7C for ; Tue, 1 Feb 2011 12:14:49 -0800 (PST) Received: by gwb20 with SMTP id 20so3066348gwb.31 for ; Tue, 01 Feb 2011 12:18:07 -0800 (PST) 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=BzhbmKgdKXqgT6gsZm3qZZzhMtEmZNhWmwDyIysxObI=; b=IB+CsBQCuOiMij7yWzoW64Gw6vpUlDIM+OgdnI+tIZik2yGiTag3BpdxbkH8LjkRzV 0aMnfVVmbtyrEaTbhppHVbA1ueHNhgt5yQTj6FTb7+6JmegYWMIWd8h1y2gCZwxNHPVE +lx0m85DmK1Wb85MxL60eqLz6HF0vBPzGnDz8= 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=JgIlbf8p2L2aYWr32Ohx7/J3l3U+Xi7vuXBJwjA8nBjk6OeJVzln+XgeCeYBFFY1Ei drjvBYUaFbQAP2hWG/OGvOKUKZYwd/4SYpRm+N+5xx0EIrKb41BvCmSUmDJ3nkV6Wr1/ fo1w77T9/x2oLJHTzcvlBK2sRvNyFuD4X4jys= MIME-Version: 1.0 Received: by 10.100.48.3 with SMTP id v3mr5293606anv.154.1296591486558; Tue, 01 Feb 2011 12:18:06 -0800 (PST) Received: by 10.100.109.16 with HTTP; Tue, 1 Feb 2011 12:18:06 -0800 (PST) In-Reply-To: References: <17A80F45-52CB-43F6-BD4A-3488821F6933@hopcount.ca> <3A1DEE95-8C8E-4C89-97EB-6D8F799ADE25@virtualized.org> <583A62B0-0DBF-469A-AF8A-B81DEDD1E7E2@dotat.at> <86B1D38A-C274-4335-B30E-3C5C0DF05C38@hopcount.ca> <4D45DE93.9090508@vpnc.org> <4C747F08-A9E8-46E6-AE76-0A999A16D276@hopcount.ca> Date: Tue, 1 Feb 2011 15:18:06 -0500 Message-ID: From: Phillip Hallam-Baker To: Tony Finch Content-Type: multipart/alternative; boundary=0016e645b8c4f9a217049b3e3a81 Cc: dnsext@ietf.org Subject: Re: [dnsext] historal root keys for upgrade path? X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 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, 01 Feb 2011 20:14:51 -0000 --0016e645b8c4f9a217049b3e3a81 Content-Type: text/plain; charset=ISO-8859-1 On Tue, Feb 1, 2011 at 2:14 PM, Tony Finch wrote: > On Mon, 31 Jan 2011, Phillip Hallam-Baker wrote: > > > > ICANN can eliminate the problem of rollovers for scheduled rolls by > > announcing that it will never roll the key except in an emergency. > > The problem with that idea is that (per Cisco's plan) if every > Internet-connected device is a validator, an emergency will break the > entire Internet. You *have* to plan for root key rollovers to be normal > events that can be handled without fuss. If you want to plan effectively for an emergency you have to do much more than just roll the key. The design of commercial PKI roots has been predicated on the need to make them tamper-evident and not to eliminate the possibility of a compromise. If we ever did have to do an emergency roll we would probably need to change the whole signing scheme as well. We would at a minimum need to go for a stronger key but we might well have to go to a different algorithm. > > We faced this problem in the PKI world and found that 20 year roots were > a > > better solution. > > But in the PKI world you have many trust anchors which can come and go as > time passes without breaking the whole system. Actually the number of roots is much smaller than people imagine. In the case of Windows the ultimate root that matters is held by Microsoft and always has been. That is the root used to sign the CTL that authorizes the roots. I believe that new CTL keys are introduced from time to time. But a given root is good for the support lifetime of the product in question and in practice has been maintained beyond that point. And as certain people keep pointing out, as currently configured, each root provides a fresh opportunity to compromise the system. That is the issue CAA is designed to address. -- Website: http://hallambaker.com/ --0016e645b8c4f9a217049b3e3a81 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Tue, Feb 1, 2011 at 2:14 PM, Tony Fin= ch <dot@dotat.at&g= t; wrote:
On Mon, 31 Jan 2011, Phillip Hallam-Baker wrote:
>
> ICANN can eliminate the problem of rollovers for scheduled rolls by > announcing that it will never roll the key except in an emergency.

The problem with that idea is that (per Cisco's plan) if every Internet-connected device is a validator, an emergency will break the
entire Internet. You *have* to plan for root key rollovers to be normal
events that can be handled without fuss.

If= you want to plan effectively for an emergency you have to do much more tha= n just roll the key.

The design of commercial PKI = roots has been predicated on the need to make them tamper-evident and not t= o eliminate the possibility =A0of a compromise.

If we ever did have to do an emergency roll we would pr= obably need to change the whole signing scheme as well. We would at a minim= um need to go for a stronger key but we might well have to go to a differen= t algorithm.=A0


=A0
> We faced this problem in the PKI world and found that 20 year roots we= re a
> better solution.

But in the PKI world you have many trust anchors which can come and g= o as
time passes without breaking the whole system.

<= div>Actually the number of roots is much smaller than people imagine. In th= e case of Windows the ultimate root that matters is held by Microsoft and a= lways has been. That is the root used to sign the CTL that authorizes the r= oots.

I believe that new CTL keys are introduced from time to= time. But a given root is good for the support lifetime of the product in = question and in practice has been maintained beyond that point.=A0

And as certain people keep pointing out, as currently config= ured, each root provides a fresh opportunity to compromise the system. That= is the issue CAA is designed to address.


--
Website: http://hallambaker.com/
--0016e645b8c4f9a217049b3e3a81-- From fanf2@hermes.cam.ac.uk Tue Feb 1 12:37:24 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 458833A6C7B; Tue, 1 Feb 2011 12:37:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.812 X-Spam-Level: X-Spam-Status: No, score=-4.812 tagged_above=-999 required=5 tests=[AWL=1.787, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gjoRJ9KLCpJk; Tue, 1 Feb 2011 12:37:23 -0800 (PST) Received: from ppsw-50.csi.cam.ac.uk (ppsw-50.csi.cam.ac.uk [131.111.8.150]) by core3.amsl.com (Postfix) with ESMTP id 37F5F3A6C5E; Tue, 1 Feb 2011 12:37:23 -0800 (PST) X-Cam-AntiVirus: no malware found X-Cam-SpamDetails: not scanned X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ Received: from hermes-1.csi.cam.ac.uk ([131.111.8.51]:41539) by ppsw-50.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.157]:25) with esmtpa (EXTERNAL:fanf2) id 1PkN1P-0004ez-qT (Exim 4.72) (return-path ); Tue, 01 Feb 2011 20:40:19 +0000 Received: from fanf2 (helo=localhost) by hermes-1.csi.cam.ac.uk (hermes.cam.ac.uk) with local-esmtp id 1PkN1P-0003Bp-7z (Exim 4.67) (return-path ); Tue, 01 Feb 2011 20:40:19 +0000 Date: Tue, 1 Feb 2011 20:40:19 +0000 From: Tony Finch X-X-Sender: fanf2@hermes-1.csi.cam.ac.uk To: John Bashinski In-Reply-To: <4D472D2C.9090108@cisco.com> Message-ID: References: <3E0BC533-AFF7-4E5E-A52E-BD7814FC4060@hopcount.ca> <4D472D2C.9090108@cisco.com> User-Agent: Alpine 2.00 (LSU 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: Tony Finch Cc: "dnsop@ietf.org WG" , dnsext List , Knight Dave Subject: Re: [dnsext] draft-jabley-dnsop-validator-bootstrap-00 X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 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, 01 Feb 2011 20:37:24 -0000 On Mon, 31 Jan 2011, John Bashinski wrote: > > A validator must confirm that its local clock is sufficiently > > accurate before trust anchors can be established, and before > > processing of DNSSEC signatures can proceed. > > How? There are two possibilities here: you can't reach a time server because of some screwup, or someone is deliberately lying to you about the time. The latter for DNSSEC is a denial of service attack, and the other network comms in the bootstrap process is similarly vulnerable to DoS. I agree it is a concern but I'm not sure it needs to cause angst. Tony. -- f.anthony.n.finch http://dotat.at/ HUMBER THAMES DOVER WIGHT PORTLAND: NORTH BACKING WEST OR NORTHWEST, 5 TO 7, DECREASING 4 OR 5, OCCASIONALLY 6 LATER IN HUMBER AND THAMES. MODERATE OR ROUGH. RAIN THEN FAIR. GOOD. From fanf2@hermes.cam.ac.uk Tue Feb 1 12:44:54 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 003663A6C7A; Tue, 1 Feb 2011 12:44:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.857 X-Spam-Level: X-Spam-Status: No, score=-4.857 tagged_above=-999 required=5 tests=[AWL=1.742, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZKkG6QawcOlm; Tue, 1 Feb 2011 12:44:52 -0800 (PST) Received: from ppsw-50.csi.cam.ac.uk (ppsw-50.csi.cam.ac.uk [131.111.8.150]) by core3.amsl.com (Postfix) with ESMTP id 479683A6C5E; Tue, 1 Feb 2011 12:44:52 -0800 (PST) X-Cam-AntiVirus: no malware found X-Cam-SpamDetails: not scanned X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ Received: from hermes-1.csi.cam.ac.uk ([131.111.8.51]:45583) by ppsw-50.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.157]:25) with esmtpa (EXTERNAL:fanf2) id 1PkN8z-0006v0-sK (Exim 4.72) (return-path ); Tue, 01 Feb 2011 20:48:09 +0000 Received: from fanf2 (helo=localhost) by hermes-1.csi.cam.ac.uk (hermes.cam.ac.uk) with local-esmtp id 1PkN8z-00045E-Qi (Exim 4.67) (return-path ); Tue, 01 Feb 2011 20:48:09 +0000 Date: Tue, 1 Feb 2011 20:48:09 +0000 From: Tony Finch X-X-Sender: fanf2@hermes-1.csi.cam.ac.uk To: dnsop@ietf.org, dnsext@ietf.org Message-ID: User-Agent: Alpine 2.00 (LSU 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: Tony Finch Subject: [dnsext] bootstrapping using a quorum of witnesses X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 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, 01 Feb 2011 20:44:54 -0000 Here is a sketch of a scheme for establishing trust in the root KSK based on a group of less-trusted cryptographic "witnesses", without a single point of failure. It is designed to survive a reasonable amount of cryptographic, operational, and organizational attrition, so that it should be possible for a ten-year-old validator to successfully and securely bootstrap. Think of a fifteen-year-old root hints file, which still after all that time contains eight valid root server IP addresses: enough to bootstrap. Phillip Hallam-Baker and John Bashinski have recently hinted at something like this, though I thought up this scheme a few months ago. * Witnesses There is a group of about a dozen root trust anchor witnesses. They are selected from interested parties such as root server operators, TLD operators, DNS registries, RIRs, software and hardware vendors, etc. They have diverse software, hardware, crypto algorithms, operations, locations, politics, etc. There is no need for anyone to trust any single one of them nor to trust all of them. * Witness signatures Periodically (quarterly, perhaps) the witnesses all sign each others' public keys and the root public key(s). They also sign a digest of the previous witness signature set to form a historical link, and other metadata to associate each key with its owner. These mutual signatures form a proof that all witnesses agree that these are the current keys. * Interaction with root zone There is no coupling between the witnesses and root zone operations, except that witness signing ceremonies must be timed so that validators can reliably obtain a valid root KSK from the witness zones across a root KSK rollover. * Witness zones Each witness maintains a well-known DNS zone in which that witness publishes their copy of all historical witness signatures from all witnesses. This zone's KSK is the witness's current key. (Details of the format TBD.) * Key lifetime We do not require any very long-lived or standby keys: the only keys not in active oprerational use are historical bootstrap keys whose private parts have been destroyed. The remaining risk is that these old keys might fall to crypographic attack; however if the witnesses have reasonable key and algorithm rolling schedules and the attacks aren't catastrophic, this vulnerability will only affect validators bootsrapping of very old (compromised) data. Sufficiently diverse witnesses can also reduce this vulnerability. * Bootstrap data A validator's bootstrap data comprises a list of witness zones and their keys. This is operationally similar to the root name server hints, in that moderately stale data doesn't matter. * Staleness There are three kinds of change to the set of witness keys. - planned key and/or algorithm rollovers - deletion of a witness key - introduction of a new witness Deletion and introduction are expected to be fairly rare. (cf. root server changes.) * Rollover There is a mechanism (details TBD) to indicate in the series of witness signature sets that a witness performed a planned rollover and destroyed the old key's private part. A bootstrapping validator uses this information to update its idea of that witness's key while tracing the chain of witness signature sets. * Deletion There is a mechanism (details TBD) to indicate in the series of witness signature sets that a key was deleted because of loss or compromise or because the key's owner ceased to act as a witness for some other reason. Deletion requires agreement by the other witnesses but does not require action from the deleted witness. A bootstrapping validator does not trust any witness that it observes to have been deleted. * Introduction New witnesses can be added (again details TBD). A bootstrapping validator ignores witnesses that were not included in its bootstrap data. Validators will normally ship with an up-to-date list of witnesses. If an organization wishes to continue its role as a witness after its key has been deleted from the set (and if the other witnesses agree!), it must be re-introduced as a new witness. * Bootstrap actions A validator traces the chain of witness signature sets in a witness zone. In each signature set it verifies all the signatures of the witnesses in its bootstrap data. Witnesses' keys are updated as necessary by rollover information. Witnesses that the validator observes to have been deleted according to this zone are excluded from the entire validation process. The most recent signature set must have a quorum of valid signatures. The validator repeats this process for each witness zone until a quorum of the zones has a record of exactly the same valid chain of witness signature sets. If it fails to find a quorum it cannot bootstrap. The size of the quorum is chosen to balance security against resilience in the face of stale bootstrap data. Tony. -- f.anthony.n.finch http://dotat.at/ HUMBER THAMES DOVER WIGHT PORTLAND: NORTH BACKING WEST OR NORTHWEST, 5 TO 7, DECREASING 4 OR 5, OCCASIONALLY 6 LATER IN HUMBER AND THAMES. MODERATE OR ROUGH. RAIN THEN FAIR. GOOD. From mohta@necom830.hpcl.titech.ac.jp Tue Feb 1 12:56:24 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 51C283A6C6C for ; Tue, 1 Feb 2011 12:56:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.805 X-Spam-Level: X-Spam-Status: No, score=0.805 tagged_above=-999 required=5 tests=[AWL=0.895, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2qr53lZXB8Ww for ; Tue, 1 Feb 2011 12:56:23 -0800 (PST) Received: from necom830.hpcl.titech.ac.jp (necom830.hpcl.titech.ac.jp [131.112.32.132]) by core3.amsl.com (Postfix) with SMTP id F3ED23A6B4F for ; Tue, 1 Feb 2011 12:56:22 -0800 (PST) Received: (qmail 40730 invoked from network); 1 Feb 2011 21:05:07 -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; 1 Feb 2011 21:05:07 -0000 Message-ID: <4D487400.2070203@necom830.hpcl.titech.ac.jp> Date: Wed, 02 Feb 2011 05:58:40 +0900 From: Masataka Ohta User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; ja; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: dnsext@ietf.org References: <3E0BC533-AFF7-4E5E-A52E-BD7814FC4060@hopcount.ca> <4D472D2C.9090108@cisco.com> <6819D144-A148-41AB-BF38-A888E0950D7E@hopcount.ca> <4D476699.5060105@vpnc.org> <20110201144332.GD3135@shinkuro.com> <4D483DDB.3020802@vpnc.org> In-Reply-To: <4D483DDB.3020802@vpnc.org> Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit Subject: Re: [dnsext] Moderate one's tone, please. X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 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, 01 Feb 2011 20:56:24 -0000 Paul Hoffman wrote: > Phill was making technical statements, not "views". His technical > statements were wrong. True. But, the fundamental problem is that PKI, in general, is broken and not really securely operational. What you are seeing is desperate attempts to defend PKI by believers in. Of course, you can't expect religious statements technically correct. But, it is hard, if not impossible, to convince believers in of the technical reality, if a religion has decades of history with a lot of believers in. The believers in are well trained not to admit some technical problems and won't accept proposals to solve the problems, because they know the proposals cause other problems. Masataka Ohta From weiler@watson.org Tue Feb 1 13:29:23 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D810C3A6C75 for ; Tue, 1 Feb 2011 13:29:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.502 X-Spam-Level: X-Spam-Status: No, score=-2.502 tagged_above=-999 required=5 tests=[AWL=0.097, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U2yHQiUW4RzH for ; Tue, 1 Feb 2011 13:29:23 -0800 (PST) Received: from fledge.watson.org (fledge.watson.org [65.122.17.41]) by core3.amsl.com (Postfix) with ESMTP id D9A7D3A6C57 for ; Tue, 1 Feb 2011 13:29:22 -0800 (PST) Received: from fledge.watson.org (localhost.watson.org [127.0.0.1]) by fledge.watson.org (8.14.4/8.14.4) with ESMTP id p11LWdAn037946; Tue, 1 Feb 2011 16:32:39 -0500 (EST) (envelope-from weiler@watson.org) Received: from localhost (weiler@localhost) by fledge.watson.org (8.14.4/8.14.4/Submit) with ESMTP id p11LWcKQ037940; Tue, 1 Feb 2011 16:32:38 -0500 (EST) (envelope-from weiler@watson.org) X-Authentication-Warning: fledge.watson.org: weiler owned process doing -bs Date: Tue, 1 Feb 2011 16:32:38 -0500 (EST) From: Samuel Weiler To: Ralph Droms In-Reply-To: <2A149A97-3B0A-49AA-88CA-9741F88B9274@gmail.com> Message-ID: References: <20110117230048.26192.84056.idtracker@localhost> <2A149A97-3B0A-49AA-88CA-9741F88B9274@gmail.com> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.3 (fledge.watson.org [127.0.0.1]); Tue, 01 Feb 2011 16:32:39 -0500 (EST) Cc: dnsext@ietf.org Subject: Re: [dnsext] Fwd: Last Call: (Special-Use Domain Names) to Proposed Standard X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 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, 01 Feb 2011 21:29:23 -0000 On Mon, 17 Jan 2011, Ralph Droms wrote: > FYI; review and comment requested... ... > This document describes what it means to say that a DNS name is > reserved for special use, when reserving such a name is appropriate, > and the procedure for doing so. I observe that the document is not putting any names in the registry it is creating. Are there names that should be in the registry? If so, name them here. If not, why are creating an empty registry at this time? And I'll offer a broad "me too" to Joe Abley's comments re: the specifics of the registry. -- Sam From hallam@gmail.com Tue Feb 1 20:15:29 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 59BE83A7015; Tue, 1 Feb 2011 20:15:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.478 X-Spam-Level: X-Spam-Status: No, score=-3.478 tagged_above=-999 required=5 tests=[AWL=0.120, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Gg0oowhn5VW4; Tue, 1 Feb 2011 20:15:26 -0800 (PST) Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by core3.amsl.com (Postfix) with ESMTP id 579B93A6E88; Tue, 1 Feb 2011 20:15:26 -0800 (PST) Received: by ywk9 with SMTP id 9so3210884ywk.31 for ; Tue, 01 Feb 2011 20:18:44 -0800 (PST) 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=3Xlmbne/IlTlC0ywlzaJJ1EmAmHm4SDHY6aKD7eYTWA=; b=mxB45DVOeVmKG7oLQvy/ypaIxv80ObkkzSu/dkx3l5Y6fSM85g2hVEc84bPJjYJJNL +sLOYjvipKF9NMKma8TF9kEegmxIlqcN85YR8Bb3x6zqPo3V0gPHLlM/vSS+gQlXdx/D 1qYRLJP5R12J6upVFn9g/alTL3oU13R9WBRYY= 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=RfBtGL0OyVMmal8i0OJFdmMo8HMskQz0J59GZvbJN5cfu60UTUTVDZ521sdr3NRetz a/BDhNpPbxS+jRtAKSxqH9v2rkMqymqzzLiVeoY/1AktN2ebgmR242NaWfK7v3omI1PG YtIBPCXYQua+c/KCRcdbDv0zKTRh10J4g7GwA= MIME-Version: 1.0 Received: by 10.100.167.5 with SMTP id p5mr4302914ane.222.1296620324349; Tue, 01 Feb 2011 20:18:44 -0800 (PST) Received: by 10.100.109.16 with HTTP; Tue, 1 Feb 2011 20:18:44 -0800 (PST) In-Reply-To: References: Date: Tue, 1 Feb 2011 23:18:44 -0500 Message-ID: From: Phillip Hallam-Baker To: Tony Finch Content-Type: multipart/alternative; boundary=0016e6434658d767f1049b44f16e Cc: dnsop@ietf.org, dnsext@ietf.org Subject: Re: [dnsext] bootstrapping using a quorum of witnesses X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 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, 02 Feb 2011 04:15:29 -0000 --0016e6434658d767f1049b44f16e Content-Type: text/plain; charset=ISO-8859-1 That is along the lines of where I was thinking. It may even be possible to make it work with less organization, possibly self-assembling. So the starting point I thought of was that a Large Router Vendor (LRV) decides to use its own existing offline root key maintain signatures over the ICANN KSK. ICANN have published a CSR so it should be relatively easy to generate an X.509v3 cross certificate for the ICANN KSK. Why use X.509 here? Well because that allows us to use the code that we already have to service other equipment. It allows us to specify an expiry date for the cross certificate - I would suggest one to two years. Also it allows said LRV to avoid liability issues that I will come to in a moment. The LRV then publishes the cross certificate at a specified point in their DNS tree that is a subdomain that they have reserved for this purpose and is specific to that particular root. So this might be: root2009.lrv.biz CERT ..... blah If people are willing to write code we could achieve the same thing in pure DNSSEC. But that would require code to be written to use the existing HSM to sign DNS records. There would also be some more architectural options. This is the minimal cheap and cheerful approach. Essentially all that LRV has done is to replace the ICANN root with themselves. However they are publishing the cross cert in a public place. So what happens if Small Router Vendor now comes along and looks at this scheme and says 'hey, I can free ride on LRV's scheme'. Which originally had me thinking in terms of putting a practices statement in the certificate or possibly going so far as to assert copyright in the embedded root key. To make this scheme worthwhile is is necessary for LRV to spend an equivalent amount of care etc. in management of their root. They should be using key sharing, separation of duties etc (to see how it is done read a certain large CA's CPS that has the whole scheme explained in all the detail anyone would ever need). Then I thought that maybe the bug is a feature and that maybe hooking into LRV alone is not going to meet the needs of SRV after all. They have no more control over LRV than they have over ICANN. In fact they have rather less assurance as LRV might decide to issue a firmware update and phase out their root. So one model would be for SRV to contract to have someone manage a root for them in an outsourced model. Which is feasible, but not inexpensive. And the cumulative duplication of effort is really not worthwhile. A better model would be for there to be an established standard for this scheme and for SRV to embed multiple roots and employ a quorum scheme. The main advantage to LRV is that the concentration of risk is gone and thus the potential third party liability. They might still want to have some form of contractual arrangement with the relying party vendors. But the possibility of unilateral default is gone and with it the liability. Moreover since the LRV cannot successfully default, there is no incentive for them to attempt to do so or for someone to attempt to coerce them - unless they can coerce a quorum of roots. A second advantage to LRV is that it frequently grows by acquiring SRVs. Having them use compatible protocol approaches will ease their legacy maintenance headache. So now we have arrived at a position where LRV is doing the work but SRV is actually giving a better assurance to their customers, their equipment is can only be compromised through multiple failures while LRVs is vulnerable to a single failure. So LRV would probably end up employing the same quorum scheme, either with peers or with some number of specialist providers of outsourced crypto management. So now we have a scheme that is independent of any single point of control. The only question being the circumstances in which the signers would legitimately sign something other than the current ICANN root KSK. The point here is not that ICANN would want to default, but that it might be coerced. The practices they are using are tamper-evident, not absolutely tamper proof. If we take away the possibility that a coercion attempt would succeed, we take away the incentive for a rational person to attempt to do so. What I like about this scheme is that we can start building the technical infrastructure without having to first construct a social-political construct. It In fact I would prefer to avoid creating any such construct that might be misinterpreted as a 'New World Order' type organization. The same technical infrastructure can be used to support a quorum of one out of one to n out of m. And there is the option for the ultimate customer to choose their own quorum points. On Tue, Feb 1, 2011 at 3:48 PM, Tony Finch wrote: > Here is a sketch of a scheme for establishing trust in the root KSK based > on a group of less-trusted cryptographic "witnesses", without a single > point of failure. > > It is designed to survive a reasonable amount of cryptographic, > operational, and organizational attrition, so that it should be possible > for a ten-year-old validator to successfully and securely bootstrap. Think > of a fifteen-year-old root hints file, which still after all that time > contains eight valid root server IP addresses: enough to bootstrap. > > Phillip Hallam-Baker and John Bashinski have recently hinted at something > like this, though I thought up this scheme a few months ago. > > * Witnesses > > There is a group of about a dozen root trust anchor witnesses. They are > selected from interested parties such as root server operators, TLD > operators, DNS registries, RIRs, software and hardware vendors, etc. They > have diverse software, hardware, crypto algorithms, operations, locations, > politics, etc. There is no need for anyone to trust any single one of them > nor to trust all of them. > > * Witness signatures > > Periodically (quarterly, perhaps) the witnesses all sign each others' > public keys and the root public key(s). They also sign a digest of the > previous witness signature set to form a historical link, and other > metadata to associate each key with its owner. These mutual signatures > form a proof that all witnesses agree that these are the current keys. > > * Interaction with root zone > > There is no coupling between the witnesses and root zone operations, > except that witness signing ceremonies must be timed so that validators > can reliably obtain a valid root KSK from the witness zones across a root > KSK rollover. > > * Witness zones > > Each witness maintains a well-known DNS zone in which that witness > publishes their copy of all historical witness signatures from all > witnesses. This zone's KSK is the witness's current key. (Details of the > format TBD.) > > * Key lifetime > > We do not require any very long-lived or standby keys: the only keys not > in active oprerational use are historical bootstrap keys whose private > parts have been destroyed. The remaining risk is that these old keys might > fall to crypographic attack; however if the witnesses have reasonable key > and algorithm rolling schedules and the attacks aren't catastrophic, this > vulnerability will only affect validators bootsrapping of very old > (compromised) data. Sufficiently diverse witnesses can also reduce this > vulnerability. > > * Bootstrap data > > A validator's bootstrap data comprises a list of witness zones and their > keys. This is operationally similar to the root name server hints, in that > moderately stale data doesn't matter. > > * Staleness > > There are three kinds of change to the set of witness keys. > > - planned key and/or algorithm rollovers > > - deletion of a witness key > > - introduction of a new witness > > Deletion and introduction are expected to be fairly rare. (cf. root > server changes.) > > * Rollover > > There is a mechanism (details TBD) to indicate in the series of witness > signature sets that a witness performed a planned rollover and destroyed > the old key's private part. A bootstrapping validator uses this > information to update its idea of that witness's key while tracing the > chain of witness signature sets. > > * Deletion > > There is a mechanism (details TBD) to indicate in the series of witness > signature sets that a key was deleted because of loss or compromise or > because the key's owner ceased to act as a witness for some other reason. > Deletion requires agreement by the other witnesses but does not require > action from the deleted witness. A bootstrapping validator does not trust > any witness that it observes to have been deleted. > > * Introduction > > New witnesses can be added (again details TBD). A bootstrapping validator > ignores witnesses that were not included in its bootstrap data. Validators > will normally ship with an up-to-date list of witnesses. > > If an organization wishes to continue its role as a witness after its key > has been deleted from the set (and if the other witnesses agree!), it must > be re-introduced as a new witness. > > * Bootstrap actions > > A validator traces the chain of witness signature sets in a witness zone. > In each signature set it verifies all the signatures of the witnesses in > its bootstrap data. Witnesses' keys are updated as necessary by rollover > information. Witnesses that the validator observes to have been deleted > according to this zone are excluded from the entire validation process. > The most recent signature set must have a quorum of valid signatures. > > The validator repeats this process for each witness zone until a quorum of > the zones has a record of exactly the same valid chain of witness > signature sets. If it fails to find a quorum it cannot bootstrap. > > The size of the quorum is chosen to balance security against resilience in > the face of stale bootstrap data. > > Tony. > -- > f.anthony.n.finch http://dotat.at/ > HUMBER THAMES DOVER WIGHT PORTLAND: NORTH BACKING WEST OR NORTHWEST, 5 TO > 7, > DECREASING 4 OR 5, OCCASIONALLY 6 LATER IN HUMBER AND THAMES. MODERATE OR > ROUGH. RAIN THEN FAIR. GOOD. > _______________________________________________ > dnsext mailing list > dnsext@ietf.org > https://www.ietf.org/mailman/listinfo/dnsext > -- Website: http://hallambaker.com/ --0016e6434658d767f1049b44f16e Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable That is along the lines of where I was thinking. It may even be possible to= make it work with less organization, possibly self-assembling.


So the starting point I thought of was that a Large = Router Vendor (LRV) decides to use its own existing offline root key mainta= in signatures over the ICANN KSK.=A0

ICANN have published a CSR so it should be relatively e= asy to generate an X.509v3 cross certificate for the ICANN KSK. Why use X.5= 09 here? Well because that allows us to use the code that we already have t= o service other equipment. It allows us to specify an expiry date for the c= ross certificate - I would suggest one to two years. Also it allows said LR= V to avoid liability issues that I will come to in a moment.

The LRV then publishes the cross certificate at a speci= fied point in their DNS tree that is a subdomain that they have reserved fo= r this purpose and is specific to that particular root.

So this might be:

root2009.lrv.biz =A0CERT ..... blah

I= f people are willing to write code we could achieve the same thing in pure = DNSSEC. But that would require code to be written to use the existing HSM t= o sign DNS records. There would also be some more architectural options.=A0=


This is the minimal cheap and cheerful a= pproach. Essentially all that LRV has done is to replace the ICANN root wit= h themselves. However they are publishing the cross cert in a public place.=

So what happens if Small Router Vendor now comes along = and looks at this scheme and says 'hey, I can free ride on LRV's sc= heme'. Which originally had me thinking in terms of putting a practices= statement in the certificate or possibly going so far as to assert copyrig= ht in the embedded root key.

To make this scheme worthwhile is is necessary for LRV = to spend an equivalent amount of care etc. in management of their root. The= y should be using key sharing, separation of duties etc (to see how it is d= one read a certain large CA's CPS that has the whole scheme explained i= n all the detail anyone would ever need).


Then I thought that maybe the bug is a f= eature and that maybe hooking into LRV alone is not going to meet the needs= of SRV after all. They have no more control over LRV than they have over I= CANN. In fact they have rather less assurance as LRV might decide to issue = a firmware update and phase out their root.

So one model would be for SRV to contract to have someo= ne manage a root for them in an outsourced model. Which is feasible, but no= t inexpensive. And the cumulative duplication of effort is really not worth= while.


A better model would be for there to be = an established standard for this scheme and for SRV to embed multiple roots= and employ a quorum scheme.

The main advantage to= LRV is that the concentration of risk is gone and thus the potential third= party liability. They might still want to have some form of contractual ar= rangement with the relying party vendors. But the possibility of unilateral= default is gone and with it the liability. Moreover since the LRV cannot s= uccessfully default, there is no incentive for them to attempt to do so or = for someone to attempt to coerce them - unless they can coerce a quorum of = roots.

A second advantage to LRV is that it frequently grows b= y acquiring SRVs. Having them use compatible protocol approaches will ease = their legacy maintenance headache.


So now we have arrived at a position where LRV is doing the work but SRV is= actually giving a better assurance to their customers, their equipment is = can only be compromised through multiple failures while LRVs is vulnerable = to a single failure.

So LRV would probably end up employing the same quorum = scheme, either with peers or with some number of specialist providers of ou= tsourced crypto management.


So now = we have a scheme that is independent of any single point of control. The on= ly question being the circumstances in which the signers would legitimately= sign something other than the current ICANN root KSK.=A0

The point here is not that ICANN would want to default,= but that it might be coerced. The practices they are using are tamper-evid= ent, not absolutely tamper proof. If we take away the possibility that a co= ercion attempt would succeed, we take away the incentive for a rational per= son to attempt to do so.


What I like about this scheme is that we= can start building the technical infrastructure without having to first co= nstruct a social-political construct. It In fact I would prefer to avoid cr= eating any such construct that might be misinterpreted as a 'New World = Order' type organization.

The same technical infrastructure can be used to suppor= t a quorum of one out of one to n out of m. And there is the option for the= ultimate customer to choose their own quorum points.


On Tue, Feb 1, 2011 at 3:48 = PM, Tony Finch <dot@do= tat.at> wrote:
Here is a sketch of a scheme for establishing trust in the root KSK based on a group of less-trusted cryptographic "witnesses", without a s= ingle
point of failure.

It is designed to survive a reasonable amount of cryptographic,
operational, and organizational attrition, so that it should be possible for a ten-year-old validator to successfully and securely bootstrap. Think<= br> of a fifteen-year-old root hints file, which still after all that time
contains eight valid root server IP addresses: enough to bootstrap.

Phillip Hallam-Baker and John Bashinski have recently hinted at something like this, though I thought up this scheme a few months ago.

* Witnesses

There is a group of about a dozen root trust anchor witnesses. They are
selected from interested parties such as root server operators, TLD
operators, DNS registries, RIRs, software and hardware vendors, etc. They have diverse software, hardware, crypto algorithms, operations, locations,<= br> politics, etc. There is no need for anyone to trust any single one of them<= br> nor to trust all of them.

* Witness signatures

Periodically (quarterly, perhaps) the witnesses all sign each others' public keys and the root public key(s). They also sign a digest of the
previous witness signature set to form a historical link, and other
metadata to associate each key with its owner. These mutual signatures
form a proof that all witnesses agree that these are the current keys.

* Interaction with root zone

There is no coupling between the witnesses and root zone operations,
except that witness signing ceremonies must be timed so that validators
can reliably obtain a valid root KSK from the witness zones across a root KSK rollover.

* Witness zones

Each witness maintains a well-known DNS zone in which that witness
publishes their copy of all historical witness signatures from all
witnesses. This zone's KSK is the witness's current key. (Details o= f the
format TBD.)

* Key lifetime

We do not require any very long-lived or standby keys: the only keys not in active oprerational use are historical bootstrap keys whose private
parts have been destroyed. The remaining risk is that these old keys might<= br> fall to crypographic attack; however if the witnesses have reasonable key and algorithm rolling schedules and the attacks aren't catastrophic, th= is
vulnerability will only affect validators bootsrapping of very old
(compromised) data. Sufficiently diverse witnesses can also reduce this
vulnerability.

* Bootstrap data

A validator's bootstrap data comprises a list of witness zones and thei= r
keys. This is operationally similar to the root name server hints, in that<= br> moderately stale data doesn't matter.

* Staleness

There are three kinds of change to the set of witness keys.

=A0- planned key and/or algorithm rollovers

=A0- deletion of a witness key

=A0- introduction of a new witness

Deletion and introduction are expected to be fairly rare. (cf. root
server changes.)

* Rollover

There is a mechanism (details TBD) to indicate in the series of witness
signature sets that a witness performed a planned rollover and destroyed the old key's private part. A bootstrapping validator uses this
information to update its idea of that witness's key while tracing the<= br> chain of witness signature sets.

* Deletion

There is a mechanism (details TBD) to indicate in the series of witness
signature sets that a key was deleted because of loss or compromise or
because the key's owner ceased to act as a witness for some other reaso= n.
Deletion requires agreement by the other witnesses but does not require
action from the deleted witness. A bootstrapping validator does not trust any witness that it observes to have been deleted.

* Introduction

New witnesses can be added (again details TBD). A bootstrapping validator ignores witnesses that were not included in its bootstrap data. Validators<= br> will normally ship with an up-to-date list of witnesses.

If an organization wishes to continue its role as a witness after its key has been deleted from the set (and if the other witnesses agree!), it must<= br> be re-introduced as a new witness.

* Bootstrap actions

A validator traces the chain of witness signature sets in a witness zone. In each signature set it verifies all the signatures of the witnesses in its bootstrap data. Witnesses' keys are updated as necessary by rollove= r
information. Witnesses that the validator observes to have been deleted
according to this zone are excluded from the entire validation process.
The most recent signature set must have a quorum of valid signatures.

The validator repeats this process for each witness zone until a quorum of<= br> the zones has a record of exactly the same valid chain of witness
signature sets. If it fails to find a quorum it cannot bootstrap.

The size of the quorum is chosen to balance security against resilience in<= br> the face of stale bootstrap data.

Tony.
--
f.anthony.n.finch =A0<dot@dotat.at&g= t; =A0http://dotat.at/ HUMBER THAMES DOVER WIGHT PORTLAND: NORTH BACKING WEST OR NORTHWEST, 5 TO 7= ,
DECREASING 4 OR 5, OCCASIONALLY 6 LATER IN HUMBER AND THAMES. MODERATE OR ROUGH. RAIN THEN FAIR. GOOD.
_______________________________________________
dnsext mailing list
dnsext@ietf.org
= https://www.ietf.org/mailman/listinfo/dnsext



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

--0016e6434658d767f1049b44f16e-- From fanf2@hermes.cam.ac.uk Wed Feb 2 00:37:25 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 671C33A6E3D; Wed, 2 Feb 2011 00:37:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.157 X-Spam-Level: X-Spam-Status: No, score=-3.157 tagged_above=-999 required=5 tests=[AWL=2.046, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tNVTpqPPyDkG; Wed, 2 Feb 2011 00:36:39 -0800 (PST) Received: from ppsw-50.csi.cam.ac.uk (ppsw-50.csi.cam.ac.uk [131.111.8.150]) by core3.amsl.com (Postfix) with ESMTP id 035453A6B73; Wed, 2 Feb 2011 00:36:39 -0800 (PST) X-Cam-AntiVirus: no malware found X-Cam-SpamDetails: not scanned X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ Received: from [89.192.59.241] (port=49390 helo=[10.34.109.39]) by ppsw-50.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.157]:587) with esmtpsa (PLAIN:fanf2) (TLSv1:AES128-SHA:128) id 1PkYFp-00023U-q1 (Exim 4.72) (return-path ); Wed, 02 Feb 2011 08:39:57 +0000 References: In-Reply-To: Mime-Version: 1.0 (iPhone Mail 8C148) Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Message-Id: <8AADFCFA-240A-43ED-A479-6266DA2E63B8@dotat.at> X-Mailer: iPhone Mail (8C148) From: Tony Finch Date: Wed, 2 Feb 2011 08:38:58 +0000 To: Phillip Hallam-Baker Sender: Tony Finch Cc: "dnsop@ietf.org" , "dnsext@ietf.org" Subject: Re: [dnsext] bootstrapping using a quorum of witnesses X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 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, 02 Feb 2011 08:37:25 -0000 On 2 Feb 2011, at 04:18, Phillip Hallam-Baker wrote: >=20 I'm glad you think my sheme is reasonably plausible. I'm not sure your idea o= f a self-assembling committee of witnesses is likely to happen. It seems to m= e that more deliberate setup will be faster and more likely to succeed. But i= t requires politics which isn't my area... > So now we have a scheme that is independent of any single point of control= . The only question being the circumstances in which the signers would legit= imately sign something other than the current ICANN root KSK.=20 The same question applies to the root server operators' relationship with IC= ANN... Tony. -- f.anthony.n.finch http://dotat.at/= From jakob@kirei.se Wed Feb 2 01:34:26 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AF7893A7147 for ; Wed, 2 Feb 2011 01:34:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.199 X-Spam-Level: X-Spam-Status: No, score=-2.199 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, HELO_EQ_SE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P+-UBSQWOVuQ for ; Wed, 2 Feb 2011 01:34:25 -0800 (PST) Received: from spg.kirei.se (gomi.kirei.se [91.206.174.9]) by core3.amsl.com (Postfix) with ESMTP id DE2923A7146 for ; Wed, 2 Feb 2011 01:34:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kirei.se; s=spg20100524; h=received:subject:mime-version:content-type:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to:x-mailer; bh=MWZugShCrjM25o7HnSrDspnOUNwnX9ejiDKMW+JOpGA=; b=zJbRmtAQt9KPyZkZALP6kgC5//MWZLxOudkaXmK8ZVJwT/7bIhP1BFoDrkbsfURAMyD52rN/0zBZV 59ySQAs8oO5GQp9JvljtFajsewDUNyFvFATt8obgH6t09Fz6g+KdJaNvr2xrLYDvaGegvn5nbvBna9 dfTtlhtWP+5Anqoo= Received: from mail.kirei.se (unknown [91.206.174.10]) by spg.kirei.se (Halon Mail Gateway) with ESMTPS; Wed, 2 Feb 2011 10:37:41 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Jakob Schlyter In-Reply-To: Date: Wed, 2 Feb 2011 10:37:38 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <17A80F45-52CB-43F6-BD4A-3488821F6933@hopcount.ca> <3A1DEE95-8C8E-4C89-97EB-6D8F799ADE25@virtualized.org> <583A62B0-0DBF-469A-AF8A-B81DEDD1E7E2@dotat.at> <86B1D38A-C274-4335-B30E-3C5C0DF05C38@hopcount.ca> <4D45DE93.9090508@vpnc.org> <4C747F08-A9E8-46E6-AE76-0A999A16D276@hopcount.ca> To: Phillip Hallam-Baker X-Mailer: Apple Mail (2.1082) Cc: Paul Hoffman , dnsext@ietf.org Subject: Re: [dnsext] historal root keys for upgrade path? X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 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, 02 Feb 2011 09:34:26 -0000 On 31 jan 2011, at 20.37, Phillip Hallam-Baker wrote: > I know that it is fashionable to roll keys every so often. But in the = case of a root key it causes more problems than it solves.=20 I could not agree with you more - vanity key rollovers are not useful. jakob From jakob@kirei.se Wed Feb 2 02:03:36 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A2FBC3A712D for ; Wed, 2 Feb 2011 02:03:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.552 X-Spam-Level: X-Spam-Status: No, score=-1.552 tagged_above=-999 required=5 tests=[AWL=-0.543, BAYES_00=-2.599, HELO_EQ_SE=0.35, SARE_LWSHORTT=1.24] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z-TinVGfL5BP for ; Wed, 2 Feb 2011 02:03:35 -0800 (PST) Received: from spg.kirei.se (gomi.kirei.se [91.206.174.9]) by core3.amsl.com (Postfix) with ESMTP id 29FE33A704C for ; Wed, 2 Feb 2011 02:03:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kirei.se; s=spg20100524; h=received:subject:mime-version:content-type:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to:x-mailer; bh=cIRgNboDGOsKuC6aDtyPxMf7c4XZS6GEjOVaQ/PjIjs=; b=oVS/HnrSd2LiBYJLtrtSQQhZZK6N9jyv3YYdx90cs6l5D5n66zZwaFvaG++nFTrg+dFBS3D0uYPV4 mSDTlQ2v/OCI3KgIG2DHSQLvpPgDMtDtuYWf7NZilnWyysJ8BezTMvNM+/770wLiW8RSqRga7d67qQ oH6JLJeXQuCKrlnA= Received: from mail.kirei.se (unknown [91.206.174.10]) by spg.kirei.se (Halon Mail Gateway) with ESMTPS; Wed, 2 Feb 2011 11:06:52 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Jakob Schlyter In-Reply-To: Date: Wed, 2 Feb 2011 11:06:46 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <99E68FDB-9473-4AC7-9547-787DA5C41C72@kirei.se> References: <3E0BC533-AFF7-4E5E-A52E-BD7814FC4060@hopcount.ca> <4D472D2C.9090108@cisco.com> <6819D144-A148-41AB-BF38-A888E0950D7E@hopcount.ca> To: Phillip Hallam-Baker X-Mailer: Apple Mail (2.1082) Cc: "dnsop@ietf.org WG" , dnsext List , Dave Knight Subject: Re: [dnsext] draft-jabley-dnsop-validator-bootstrap-00 X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 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, 02 Feb 2011 10:03:36 -0000 On 1 feb 2011, at 01.40, Phillip Hallam-Baker wrote: > My advice to Cisco would be to use their existing root to sign the = published CSR for the DNS root KSK in the short term at least. That's why we (the Root DNSSEC Design Team) included a CSR as one output = from the key generation ceremony. jakob From derek@ihtfp.com Wed Feb 2 05:05:14 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D7C3A3A6EBE for ; Wed, 2 Feb 2011 05:05:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.388 X-Spam-Level: X-Spam-Status: No, score=-101.388 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_ORG=0.611, J_CHICKENPOX_13=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Sdx70nIrq9Ro for ; Wed, 2 Feb 2011 05:05:14 -0800 (PST) Received: from mail2.ihtfp.org (MAIL2.IHTFP.ORG [204.107.200.7]) by core3.amsl.com (Postfix) with ESMTP id 255003A6BE9 for ; Wed, 2 Feb 2011 05:05:13 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail2.ihtfp.org (Postfix) with ESMTP id 73969260302; Wed, 2 Feb 2011 08:08:30 -0500 (EST) Received: from mail2.ihtfp.org ([127.0.0.1]) by localhost (mail2.ihtfp.org [127.0.0.1]) (amavisd-maia, port 10024) with ESMTP id 14761-02; Wed, 2 Feb 2011 08:08:28 -0500 (EST) Received: from pgpdev.ihtfp.org (IHTFP-DHCP-100.IHTFP.ORG [192.168.248.100]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "cliodev.ihtfp.com", Issuer "IHTFP Consulting Certification Authority" (not verified)) by mail2.ihtfp.org (Postfix) with ESMTPS id 683D726029B; Wed, 2 Feb 2011 08:08:28 -0500 (EST) Received: (from warlord@localhost) by pgpdev.ihtfp.org (8.14.4/8.14.3/Submit) id p12D8P25029186; Wed, 2 Feb 2011 08:08:25 -0500 From: Derek Atkins To: Paul Wouters References: <3E0BC533-AFF7-4E5E-A52E-BD7814FC4060@hopcount.ca> <4D472D2C.9090108@cisco.com> <6819D144-A148-41AB-BF38-A888E0950D7E@hopcount.ca> <4D476699.5060105@vpnc.org> <20110201144332.GD3135@shinkuro.com> <4D483DDB.3020802@vpnc.org> Date: Wed, 02 Feb 2011 08:08:25 -0500 In-Reply-To: (Paul Wouters's message of "Tue, 1 Feb 2011 14:20:29 -0500 (EST)") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Virus-Scanned: Maia Mailguard 1.0.2a Cc: Paul Hoffman , dnsext@ietf.org Subject: Re: [dnsext] Moderate one's tone, please. X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 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, 02 Feb 2011 13:05:14 -0000 Paul Wouters writes: > On Tue, 1 Feb 2011, Phillip Hallam-Baker wrote: > >> I know that my particular views are well founded in industry practice and >> experience. I have worked on this particular problem for over fifteen >> years. > > This is an example of such an appeal to authority that some people keep > using, usually combined with general all-encompassing statements. > >> I do not think that you can truthfully claim an equivalent level of >> expertise. > > I am reminded of your claim of 20 years of DNSSEC experience at the > Toronto TASK meeting...... Not to necessarily defend Phill, but that's certainly possible. I was working on a DNSSec implementation in 1995. That was... 16 years ago. > Paul -derek -- Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory Member, MIT Student Information Processing Board (SIPB) URL: http://web.mit.edu/warlord/ PP-ASEL-IA N1NWH warlord@MIT.EDU PGP key available From fanf2@hermes.cam.ac.uk Wed Feb 2 06:03:45 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D23113A6BB1 for ; Wed, 2 Feb 2011 06:03:45 -0800 (PST) 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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aQuGoKO3io8U for ; Wed, 2 Feb 2011 06:03:44 -0800 (PST) Received: from ppsw-50.csi.cam.ac.uk (ppsw-50.csi.cam.ac.uk [131.111.8.150]) by core3.amsl.com (Postfix) with ESMTP id C97C93A6D10 for ; Wed, 2 Feb 2011 06:03:41 -0800 (PST) X-Cam-AntiVirus: no malware found X-Cam-SpamDetails: not scanned X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ Received: from hermes-1.csi.cam.ac.uk ([131.111.8.51]:48097) by ppsw-50.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.157]:25) with esmtpa (EXTERNAL:fanf2) id 1PkdMI-0002fM-ro (Exim 4.72) (return-path ); Wed, 02 Feb 2011 14:06:58 +0000 Received: from fanf2 (helo=localhost) by hermes-1.csi.cam.ac.uk (hermes.cam.ac.uk) with local-esmtp id 1PkdMI-0002BQ-LZ (Exim 4.67) (return-path ); Wed, 02 Feb 2011 14:06:58 +0000 Date: Wed, 2 Feb 2011 14:06:58 +0000 From: Tony Finch X-X-Sender: fanf2@hermes-1.csi.cam.ac.uk To: Jakob Schlyter In-Reply-To: Message-ID: References: <17A80F45-52CB-43F6-BD4A-3488821F6933@hopcount.ca> <3A1DEE95-8C8E-4C89-97EB-6D8F799ADE25@virtualized.org> <583A62B0-0DBF-469A-AF8A-B81DEDD1E7E2@dotat.at> <86B1D38A-C274-4335-B30E-3C5C0DF05C38@hopcount.ca> <4D45DE93.9090508@vpnc.org> <4C747F08-A9E8-46E6-AE76-0A999A16D276@hopcount.ca> User-Agent: Alpine 2.00 (LSU 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: Tony Finch Cc: Paul Hoffman , dnsext@ietf.org Subject: Re: [dnsext] historal root keys for upgrade path? X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 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, 02 Feb 2011 14:03:45 -0000 On Wed, 2 Feb 2011, Jakob Schlyter wrote: > > I could not agree with you more - vanity key rollovers are not useful. How else can you know that a necessary rollover will work, e.g. to upgrade the key length or algorithm or because of an emergency? Tony. -- f.anthony.n.finch http://dotat.at/ HUMBER THAMES DOVER WIGHT PORTLAND: NORTH BACKING WEST OR NORTHWEST, 5 TO 7, DECREASING 4 OR 5, OCCASIONALLY 6 LATER IN HUMBER AND THAMES. MODERATE OR ROUGH. RAIN THEN FAIR. GOOD. From jakob@kirei.se Wed Feb 2 06:29:04 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 45ECA3A6D25 for ; Wed, 2 Feb 2011 06:29:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.15 X-Spam-Level: X-Spam-Status: No, score=-2.15 tagged_above=-999 required=5 tests=[AWL=0.099, BAYES_00=-2.599, HELO_EQ_SE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wMyTRZ5EhujA for ; Wed, 2 Feb 2011 06:29:02 -0800 (PST) Received: from spg.kirei.se (gomi.kirei.se [91.206.174.9]) by core3.amsl.com (Postfix) with ESMTP id 575553A6D17 for ; Wed, 2 Feb 2011 06:29:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kirei.se; s=spg20100524; h=received:subject:mime-version:content-type:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to:x-mailer; bh=+b021FrGqzkdKxfRQfA97/fsa7m70iaYYadbmNbmxQc=; b=L/L6PchYW2FNC3Vd1KDPTmklDACohDdit9QnZAGgosw5SORPXflsRNWx88zPiExVFHQDb9/ravs8u fl0g6c8otFcT1r+IKZhON5iN/7stwOKRU+smS8lJj3et4hY8ySYVv0ucMQ3/cKgxTWki93X9L5++br zH7M6BlLGSdAzmRo= Received: from mail.kirei.se (unknown [91.206.174.10]) by spg.kirei.se (Halon Mail Gateway) with ESMTPS; Wed, 2 Feb 2011 15:32:18 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Jakob Schlyter In-Reply-To: Date: Wed, 2 Feb 2011 15:32:16 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <55D1BB6F-44E9-4D12-93F3-DD5AD219D429@kirei.se> References: <17A80F45-52CB-43F6-BD4A-3488821F6933@hopcount.ca> <3A1DEE95-8C8E-4C89-97EB-6D8F799ADE25@virtualized.org> <583A62B0-0DBF-469A-AF8A-B81DEDD1E7E2@dotat.at> <86B1D38A-C274-4335-B30E-3C5C0DF05C38@hopcount.ca> <4D45DE93.9090508@vpnc.org> <4C747F08-A9E8-46E6-AE76-0A999A16D276@hopcount.ca> To: Tony Finch X-Mailer: Apple Mail (2.1082) Cc: Paul Hoffman , dnsext@ietf.org Subject: Re: [dnsext] historal root keys for upgrade path? X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 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, 02 Feb 2011 14:29:04 -0000 On 2 feb 2011, at 15.06, Tony Finch wrote: >> I could not agree with you more - vanity key rollovers are not = useful. >=20 > How else can you know that a necessary rollover will work, e.g. to = upgrade > the key length or algorithm or because of an emergency? I'm not saying we should not test key rollovers, but testing in public = on the live Internet would, IMHO, be irresponsible. Testing should be = exercised in a closed environment, together with vendors. We don't set real buildings on fire just to make sure that the fire = brigade still operates as expected - we test and exercise them under = much better control. jakob From hallam@gmail.com Wed Feb 2 06:33:23 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C3D0E3A6D1F for ; Wed, 2 Feb 2011 06:33:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.479 X-Spam-Level: X-Spam-Status: No, score=-3.479 tagged_above=-999 required=5 tests=[AWL=0.119, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QARVrI8lZRWV for ; Wed, 2 Feb 2011 06:33:22 -0800 (PST) Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by core3.amsl.com (Postfix) with ESMTP id 6070F3A6D02 for ; Wed, 2 Feb 2011 06:33:22 -0800 (PST) Received: by gyd12 with SMTP id 12so3394gyd.31 for ; Wed, 02 Feb 2011 06:36:41 -0800 (PST) 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=5Vd70qleQM7Do3Lb60x57Yr0MuHll3Jea6XuD7gVXYc=; b=EPjlNKVOGAD5LE9jGZ0HAzKUfZ9HyUYxmNxwmACAqAkEWotpg/JVOqSwOnXRW9ii9R eaTkFvldSseCx23id7Twg3bYeyfAMviQ2NXkh6xOF9mKsxUZnvhKHMxGVfeFuNzeTC9A dAZcEZ4GOHkz1mlFfQqc70dvGzgtwUzzvRoG0= 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=d4b4xof7zFWYzniwD34x6acZeq2gomZEDzR9WR8HZrlL4YpcH3RePCig1idKMBn6NG 2IP+jTCoOi7ihHeZjM/O+QegWkgsnJx8ihXbcMWbiANX5dgbwqlq+q1cCXWNBCbkqlaR R8dfrMbW2Vi7MLnrHJj4teYCi87juTTUDIH8g= MIME-Version: 1.0 Received: by 10.100.34.1 with SMTP id h1mr6063908anh.188.1296657399869; Wed, 02 Feb 2011 06:36:39 -0800 (PST) Received: by 10.100.242.14 with HTTP; Wed, 2 Feb 2011 06:36:39 -0800 (PST) In-Reply-To: References: <17A80F45-52CB-43F6-BD4A-3488821F6933@hopcount.ca> <3A1DEE95-8C8E-4C89-97EB-6D8F799ADE25@virtualized.org> <583A62B0-0DBF-469A-AF8A-B81DEDD1E7E2@dotat.at> <86B1D38A-C274-4335-B30E-3C5C0DF05C38@hopcount.ca> <4D45DE93.9090508@vpnc.org> <4C747F08-A9E8-46E6-AE76-0A999A16D276@hopcount.ca> Date: Wed, 2 Feb 2011 09:36:39 -0500 Message-ID: From: Phillip Hallam-Baker To: Tony Finch Content-Type: multipart/alternative; boundary=0016e6465220b6f99a049b4d9332 Cc: Paul Hoffman , dnsext@ietf.org Subject: Re: [dnsext] historal root keys for upgrade path? X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 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, 02 Feb 2011 14:33:23 -0000 --0016e6465220b6f99a049b4d9332 Content-Type: text/plain; charset=ISO-8859-1 Unfortunately the ability to do a vanity key roll does not really help in emergency planning. We have many protocols that allow us to slot in new crypto but when the pragmatics of deployment are considered they just simply don't work. We are currently moving from 1024 bit RSA to 2048 and it is creating quite a few issues despite the fact that almost everything that does 1024 does 2048. The SHA-256 transition for SSL is going to be a major upheaval. MD5 to SHA1 was easy because everything supported SHA1. But only 50% of the base supports SHA-256 if that. On Wed, Feb 2, 2011 at 9:06 AM, Tony Finch wrote: > On Wed, 2 Feb 2011, Jakob Schlyter wrote: > > > > I could not agree with you more - vanity key rollovers are not useful. > > How else can you know that a necessary rollover will work, e.g. to upgrade > the key length or algorithm or because of an emergency? > > Tony. > -- > f.anthony.n.finch http://dotat.at/ > HUMBER THAMES DOVER WIGHT PORTLAND: NORTH BACKING WEST OR NORTHWEST, 5 TO > 7, > DECREASING 4 OR 5, OCCASIONALLY 6 LATER IN HUMBER AND THAMES. MODERATE OR > ROUGH. RAIN THEN FAIR. GOOD. > -- Website: http://hallambaker.com/ --0016e6465220b6f99a049b4d9332 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Unfortunately the ability to do a vanity key roll does not really help in e= mergency planning.

We have many protocols that allow us = to slot in new crypto but when the pragmatics of deployment are considered = they just simply don't work.


We are currently moving from 1024 bit RS= A to 2048 and it is creating quite a few issues despite the fact that almos= t everything that does 1024 does 2048.

The SHA-256= transition for SSL is going to be a major upheaval. MD5 to SHA1 was easy b= ecause everything supported SHA1. But only 50% of the base supports SHA-256= if that.


On Wed, Feb 2, 2011 at 9:06 AM, Ton= y Finch <dot@dotat.at<= /a>> wrote:
On Wed, 2 Feb 2011, Jakob Schlyter wrote:
>
> I could not agree with you more - vanity key rollovers are not useful.=

How else can you know that a necessary rollover will work, e.g. to up= grade
the key length or algorithm or because of an emergency?

Tony.
--
f.anthony.n.finch =A0<dot@dotat.at&g= t; =A0http://dotat.at/
HUMBER THAMES DOVER WIGHT PORTLAND:= NORTH BACKING WEST OR NORTHWEST, 5 TO 7,
DECREASING 4 OR 5, OCCASIONALLY 6 LATER IN HUMBER AND THAMES. MODERATE OR ROUGH. RAIN THEN FAIR. GOOD.



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

--0016e6465220b6f99a049b4d9332-- From fanf2@hermes.cam.ac.uk Wed Feb 2 06:35:54 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7983B3A6D1F for ; Wed, 2 Feb 2011 06:35:54 -0800 (PST) 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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lzVK2xL-mf0V for ; Wed, 2 Feb 2011 06:35:53 -0800 (PST) Received: from ppsw-51.csi.cam.ac.uk (ppsw-51.csi.cam.ac.uk [131.111.8.151]) by core3.amsl.com (Postfix) with ESMTP id 2B2E73A6C68 for ; Wed, 2 Feb 2011 06:35:53 -0800 (PST) X-Cam-AntiVirus: no malware found X-Cam-SpamDetails: not scanned X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ Received: from hermes-1.csi.cam.ac.uk ([131.111.8.51]:56057) by ppsw-51.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.158]:25) with esmtpa (EXTERNAL:fanf2) id 1PkdrS-0000gL-Wi (Exim 4.72) (return-path ); Wed, 02 Feb 2011 14:39:10 +0000 Received: from fanf2 (helo=localhost) by hermes-1.csi.cam.ac.uk (hermes.cam.ac.uk) with local-esmtp id 1PkdrS-0007CR-47 (Exim 4.67) (return-path ); Wed, 02 Feb 2011 14:39:10 +0000 Date: Wed, 2 Feb 2011 14:39:10 +0000 From: Tony Finch X-X-Sender: fanf2@hermes-1.csi.cam.ac.uk To: Jakob Schlyter In-Reply-To: <55D1BB6F-44E9-4D12-93F3-DD5AD219D429@kirei.se> Message-ID: References: <17A80F45-52CB-43F6-BD4A-3488821F6933@hopcount.ca> <3A1DEE95-8C8E-4C89-97EB-6D8F799ADE25@virtualized.org> <583A62B0-0DBF-469A-AF8A-B81DEDD1E7E2@dotat.at> <86B1D38A-C274-4335-B30E-3C5C0DF05C38@hopcount.ca> <4D45DE93.9090508@vpnc.org> <4C747F08-A9E8-46E6-AE76-0A999A16D276@hopcount.ca> <55D1BB6F-44E9-4D12-93F3-DD5AD219D429@kirei.se> User-Agent: Alpine 2.00 (LSU 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: Tony Finch Cc: Paul Hoffman , dnsext@ietf.org Subject: Re: [dnsext] historal root keys for upgrade path? X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 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, 02 Feb 2011 14:35:54 -0000 On Wed, 2 Feb 2011, Jakob Schlyter wrote: > > I'm not saying we should not test key rollovers, but testing in public > on the live Internet would, IMHO, be irresponsible. Testing should be > exercised in a closed environment, together with vendors. I was not thinking of bench testing, I was thinking of maintaining the operational readiness of all the installations out there. > We don't set real buildings on fire just to make sure that the fire > brigade still operates as expected - we test and exercise them under > much better control. We do drill non-emergency evacuations and deliberately sound operational fire alarm systems. Tony. -- f.anthony.n.finch http://dotat.at/ HUMBER THAMES DOVER WIGHT PORTLAND: NORTH BACKING WEST OR NORTHWEST, 5 TO 7, DECREASING 4 OR 5, OCCASIONALLY 6 LATER IN HUMBER AND THAMES. MODERATE OR ROUGH. RAIN THEN FAIR. GOOD. From hallam@gmail.com Wed Feb 2 08:27:22 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 37B3D3A6D31 for ; Wed, 2 Feb 2011 08:27:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.479 X-Spam-Level: X-Spam-Status: No, score=-3.479 tagged_above=-999 required=5 tests=[AWL=0.119, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Nw+57VXxYvzq for ; Wed, 2 Feb 2011 08:27:21 -0800 (PST) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by core3.amsl.com (Postfix) with ESMTP id CCC443A6CFB for ; Wed, 2 Feb 2011 08:27:20 -0800 (PST) Received: by yxt33 with SMTP id 33so74430yxt.31 for ; Wed, 02 Feb 2011 08:30:40 -0800 (PST) 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=28+jV74blm46sxF2IBnyO4sus+yOzr04AsJIu+eyOgQ=; b=ZSomzKUmf5uhHrQpDDxQlcwQt1cTcyt/Qh8CEc3Zt3mIYUvvgnTqJ1ykjVVOtNjGi1 aZRTW1gME9AFbPJYsLjjUrs/HqKGLgomhGRCHGAZKHegPDAM996/GMQJQEziChCzsgHe i1Hvk6PtYjKVSorqyv32uKGE+YbidpgE62esI= 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=mzOR2Deh0zLHWXzrmAcuAUf9D9OvwneGpXx4/GFh9PtXzc5DoRPy/q3bN2BiaL0hxG n0InMn6M9umEr3V+Tcne7FN9x+CanA1/SkwxTOcqj0/3HmR7+zPtlp9QY0P1Y7tqr9x+ LaPd2i9+QlmURsp/9hjd1pSLtoTa/HapFnEpA= MIME-Version: 1.0 Received: by 10.100.134.10 with SMTP id h10mr6054308and.86.1296664239285; Wed, 02 Feb 2011 08:30:39 -0800 (PST) Received: by 10.100.242.14 with HTTP; Wed, 2 Feb 2011 08:30:38 -0800 (PST) In-Reply-To: References: <17A80F45-52CB-43F6-BD4A-3488821F6933@hopcount.ca> <3A1DEE95-8C8E-4C89-97EB-6D8F799ADE25@virtualized.org> <583A62B0-0DBF-469A-AF8A-B81DEDD1E7E2@dotat.at> <86B1D38A-C274-4335-B30E-3C5C0DF05C38@hopcount.ca> <4D45DE93.9090508@vpnc.org> <4C747F08-A9E8-46E6-AE76-0A999A16D276@hopcount.ca> <55D1BB6F-44E9-4D12-93F3-DD5AD219D429@kirei.se> Date: Wed, 2 Feb 2011 11:30:38 -0500 Message-ID: From: Phillip Hallam-Baker To: Tony Finch Content-Type: multipart/alternative; boundary=0016e644c708602859049b4f2b9d Cc: Paul Hoffman , dnsext@ietf.org Subject: Re: [dnsext] historal root keys for upgrade path? X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 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, 02 Feb 2011 16:27:22 -0000 --0016e644c708602859049b4f2b9d Content-Type: text/plain; charset=ISO-8859-1 We have about a quarter billion names and in excess of four billion devices. By the time we get to the second roll in the 2020 time frame I would expect us to be considering about ten billion devices, most of which we would hope to have DNSSEC capability. If the cost of this firedrill is $0.10 cents per device we are talking about a billion dollar fire drill. If the cost is $10 per device we have spent $100 billion. The reason that costs accumulate in the federal government PKI is that (1) they hire contractors looking to inflate costs and (2) they have a heck of a lot of devices and small administrative cost escalates quickly. Loading up unnecessary requirements like vanity root rolls is the reason some people's X.509 PKIs became overly complex and difficult to manage. That is why we settled on using long term embedded roots in the SSL PKI. It is not an ideal situation from the crypto-perfectionist point of view, but that is not the only consideration. On Wed, Feb 2, 2011 at 9:39 AM, Tony Finch wrote: > On Wed, 2 Feb 2011, Jakob Schlyter wrote: > > > > I'm not saying we should not test key rollovers, but testing in public > > on the live Internet would, IMHO, be irresponsible. Testing should be > > exercised in a closed environment, together with vendors. > > I was not thinking of bench testing, I was thinking of maintaining > the operational readiness of all the installations out there. > > > We don't set real buildings on fire just to make sure that the fire > > brigade still operates as expected - we test and exercise them under > > much better control. > > We do drill non-emergency evacuations and deliberately sound operational > fire alarm systems. > > Tony. > -- > f.anthony.n.finch http://dotat.at/ > HUMBER THAMES DOVER WIGHT PORTLAND: NORTH BACKING WEST OR NORTHWEST, 5 TO > 7, > DECREASING 4 OR 5, OCCASIONALLY 6 LATER IN HUMBER AND THAMES. MODERATE OR > ROUGH. RAIN THEN FAIR. GOOD. > -- Website: http://hallambaker.com/ --0016e644c708602859049b4f2b9d Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable We have about a quarter billion names and in excess of four billion devices= .

By the time we get to the second roll in the 2020 time= frame I would expect us to be considering about ten billion devices, most = of which we would hope to have DNSSEC capability.


If the cost of this firedrill is $0.10 c= ents per device we are talking about a billion dollar fire drill. If the co= st is $10 per device we have spent $100 billion.

The reason that costs accumulate in the federal government PKI is that (1) = they hire contractors looking to inflate costs and (2) they have a heck of = a lot of devices and small administrative cost escalates quickly.

Loading up unnecessary requirements like vanity root ro= lls is the reason some people's X.509 PKIs became overly complex and di= fficult to manage.


That is why we s= ettled on using long term embedded roots in the SSL PKI. It is not an ideal= situation from the crypto-perfectionist point of view, but that is not the= only consideration.


On Wed, Feb 2, 2011 at 9:39 AM= , Tony Finch <dot@dota= t.at> wrote:
On Wed, 2 Feb 2011, Jakob Schlyter wrote:
>
> I'm not saying we should not test key roll= overs, but testing in public
> on the live Internet would, IMHO, be irresponsible. Testing should be<= br> > exercised in a closed environment, together with vendors.

I was not thinking of bench testing, I was thinking of maintaining the operational readiness of all the installations out there.

> We don't set real buildings on fire just to make sure that the fir= e
> brigade still operates as expected - we test and exercise them under > much better control.

We do drill non-emergency evacuations and deliberately sound operatio= nal
fire alarm systems.

Tony.
--
f.anthony.n.finch =A0<dot@dotat.at&g= t; =A0http://dotat.at/ HUMBER THAMES DOVER WIGHT PORTLAND: NORTH BACKING WEST OR NORTHWEST, 5 TO 7= ,
DECREASING 4 OR 5, OCCASIONALLY 6 LATER IN HUMBER AND THAMES. MODERATE OR ROUGH. RAIN THEN FAIR. GOOD.



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

--0016e644c708602859049b4f2b9d-- From Ted.Lemon@nominum.com Wed Feb 2 08:39:23 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 15E6E3A6D79 for ; Wed, 2 Feb 2011 08:39:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.595 X-Spam-Level: X-Spam-Status: No, score=-106.595 tagged_above=-999 required=5 tests=[AWL=0.004, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kpX9a1fKXj7m for ; Wed, 2 Feb 2011 08:39:22 -0800 (PST) Received: from exprod7og124.obsmtp.com (exprod7og124.obsmtp.com [64.18.2.26]) by core3.amsl.com (Postfix) with ESMTP id 2FC5F3A6D83 for ; Wed, 2 Feb 2011 08:39:17 -0800 (PST) Received: from source ([64.89.228.229]) (using TLSv1) by exprod7ob124.postini.com ([64.18.6.12]) with SMTP ID DSNKTUmJfQRmmhaYCDFqKg+7JWSxXNEksh4U@postini.com; Wed, 02 Feb 2011 08:42:38 PST Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id ECF771B81B5 for ; Wed, 2 Feb 2011 08:42:36 -0800 (PST) Received: from webmail.nominum.com (webmail.nominum.com [64.89.228.50]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (Client CN "webmail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id BAC14190052; Wed, 2 Feb 2011 08:42:36 -0800 (PST) (envelope-from Ted.Lemon@nominum.com) Received: from vpna-148.vpn.nominum.com (64.89.227.148) by exchange-01.win.nominum.com (64.89.228.50) with Microsoft SMTP Server (TLS) id 8.2.176.0; Wed, 2 Feb 2011 08:42:36 -0800 MIME-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset="us-ascii" From: Ted Lemon In-Reply-To: Date: Wed, 2 Feb 2011 11:42:31 -0500 Content-Transfer-Encoding: quoted-printable Message-ID: References: <17A80F45-52CB-43F6-BD4A-3488821F6933@hopcount.ca> <3A1DEE95-8C8E-4C89-97EB-6D8F799ADE25@virtualized.org> <583A62B0-0DBF-469A-AF8A-B81DEDD1E7E2@dotat.at> <86B1D38A-C274-4335-B30E-3C5C0DF05C38@hopcount.ca> <4D45DE93.9090508@vpnc.org> <4C747F08-A9E8-46E6-AE76-0A999A16D276@hopcount.ca> <55D1BB6F-44E9-4D12-93F3-DD5AD219D429@kirei.se> To: Phillip Hallam-Baker X-Mailer: Apple Mail (2.1082) Cc: Paul Hoffman , dnsext@ietf.org Subject: Re: [dnsext] historal root keys for upgrade path? X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 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, 02 Feb 2011 16:39:23 -0000 On Feb 2, 2011, at 11:30 AM, Phillip Hallam-Baker wrote: > If the cost of this firedrill is $0.10 cents per device we are talking = about a billion dollar fire drill. If the cost is $10 per device we have = spent $100 billion. There are two problems with this scare figure. First, most devices = will be online during the rollover, and will therefore handle it = automatically. The number of devices that will have to be physically = touched by an administrator will be small relative to the total number = of devices. Second, if you have ten billion devices, each of which = cost at least $50, then to the "you" we are talking about, a billion = dollars is literally pocket change. Because really you have a billion = people with all those devices, and so the cost is more like $1 per = person. Having said that, however, it is worth noting that your scare figure is = in fact valid in the event of an emergency root key rollover. So this = does argue in favor of having multiple chains of trust, so that you = still have a key you can trust even if you can't trust the root key. = Granted, having extra keys like this is also dangerous, because those = keys are also subject to compromise, but the cost per incident for such = a compromise is much lower, and the value of such a compromise is also = lower. From paul@xelerance.com Wed Feb 2 11:46:11 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5F3713A6D8E for ; Wed, 2 Feb 2011 11:46:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.577 X-Spam-Level: X-Spam-Status: No, score=-2.577 tagged_above=-999 required=5 tests=[AWL=0.022, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nHGr1fc+DhLo for ; Wed, 2 Feb 2011 11:46:10 -0800 (PST) Received: from newtla.xelerance.com (newtla.xelerance.com [193.110.157.143]) by core3.amsl.com (Postfix) with ESMTP id 75B113A6D41 for ; Wed, 2 Feb 2011 11:46:10 -0800 (PST) Received: from tla.xelerance.com (tla.xelerance.com [193.110.157.130]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by newtla.xelerance.com (Postfix) with ESMTP id 5B24AC556; Wed, 2 Feb 2011 14:49:30 -0500 (EST) Date: Wed, 2 Feb 2011 14:49:29 -0500 (EST) From: Paul Wouters To: Phillip Hallam-Baker In-Reply-To: Message-ID: References: <17A80F45-52CB-43F6-BD4A-3488821F6933@hopcount.ca> <3A1DEE95-8C8E-4C89-97EB-6D8F799ADE25@virtualized.org> <583A62B0-0DBF-469A-AF8A-B81DEDD1E7E2@dotat.at> <86B1D38A-C274-4335-B30E-3C5C0DF05C38@hopcount.ca> <4D45DE93.9090508@vpnc.org> <4C747F08-A9E8-46E6-AE76-0A999A16D276@hopcount.ca> User-Agent: Alpine 1.10 (LFD 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: Paul Hoffman , dnsext@ietf.org Subject: Re: [dnsext] historal root keys for upgrade path? X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 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, 02 Feb 2011 19:46:11 -0000 On Wed, 2 Feb 2011, Phillip Hallam-Baker wrote: > We are currently moving from 1024 bit RSA to 2048 and it is creating quite a few issues despite the fact that almost > everything that does 1024 does 2048. Can you name some of the "quite a few" issues? I'd be interested to hear them. The only one that I'm aware of is using PKIX with IKE and problems with UDP fragmentation when large PKIX blobs are sent inline with IKE. The difference between 1024 and 2048 bit keys seemed to trigger this packet size related issue. Paul From fweimer@bfk.de Fri Feb 4 04:38:37 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C115D3A691A for ; Fri, 4 Feb 2011 04:38:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.165 X-Spam-Level: X-Spam-Status: No, score=-2.165 tagged_above=-999 required=5 tests=[AWL=0.084, BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZxgyIXtj05Q2 for ; Fri, 4 Feb 2011 04:38:37 -0800 (PST) Received: from mx01.bfk.de (mx01.bfk.de [193.227.124.2]) by core3.amsl.com (Postfix) with ESMTP id CB0393A6916 for ; Fri, 4 Feb 2011 04:38:36 -0800 (PST) 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 1PlKz8-0001qj-UK; Fri, 04 Feb 2011 12:41:58 +0000 Received: by bfk.de with local id 1PlKz8-0007ro-M9; Fri, 04 Feb 2011 12:41:58 +0000 To: Samuel Weiler References: <20110117230048.26192.84056.idtracker@localhost> <2A149A97-3B0A-49AA-88CA-9741F88B9274@gmail.com> From: Florian Weimer Date: Fri, 04 Feb 2011 12:41:58 +0000 In-Reply-To: (Samuel Weiler's message of "Tue\, 1 Feb 2011 16\:32\:38 -0500 \(EST\)") Message-ID: <82hbckhsyx.fsf@mid.bfk.de> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Ralph Droms , dnsext@ietf.org Subject: Re: [dnsext] Fwd: Last Call: (Special-Use Domain Names) to Proposed Standard X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 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, 04 Feb 2011 12:38:37 -0000 * Samuel Weiler: > On Mon, 17 Jan 2011, Ralph Droms wrote: > >> FYI; review and comment requested... > ... >> This document describes what it means to say that a DNS name is >> reserved for special use, when reserving such a name is appropriate, >> and the procedure for doing so. > > I observe that the document is not putting any names in the registry > it is creating. Are there names that should be in the registry? LOCAL. If understand things correctly, it's widely used to trigger Multicast DNS resolution in combined DNS/Multicast DNS environments. --=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 bortzmeyer@nic.fr Fri Feb 4 04:50:01 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 479653A6959 for ; Fri, 4 Feb 2011 04:50:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -108.73 X-Spam-Level: X-Spam-Status: No, score=-108.73 tagged_above=-999 required=5 tests=[AWL=1.519, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id juCqClYuVIzF for ; Fri, 4 Feb 2011 04:50:00 -0800 (PST) Received: from mx2.nic.fr (mx2.nic.fr [IPv6:2001:660:3003:2::4:11]) by core3.amsl.com (Postfix) with ESMTP id 1F8ED3A6B9B for ; Fri, 4 Feb 2011 04:50:00 -0800 (PST) Received: from mx2.nic.fr (localhost [127.0.0.1]) by mx2.nic.fr (Postfix) with SMTP id 1F0701C0028; Fri, 4 Feb 2011 13:53:24 +0100 (CET) Received: from relay1.nic.fr (relay1.nic.fr [192.134.4.162]) by mx2.nic.fr (Postfix) with ESMTP id 1A7D41C0017; Fri, 4 Feb 2011 13:53:24 +0100 (CET) Received: from bortzmeyer.nic.fr (batilda.nic.fr [192.134.4.69]) by relay1.nic.fr (Postfix) with ESMTP id 0EE99568122; Fri, 4 Feb 2011 13:53:24 +0100 (CET) Date: Fri, 4 Feb 2011 13:53:24 +0100 From: Stephane Bortzmeyer To: Florian Weimer Message-ID: <20110204125324.GA11826@nic.fr> References: <20110117230048.26192.84056.idtracker@localhost> <2A149A97-3B0A-49AA-88CA-9741F88B9274@gmail.com> <82hbckhsyx.fsf@mid.bfk.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <82hbckhsyx.fsf@mid.bfk.de> X-Operating-System: Debian GNU/Linux 6.0 X-Kernel: Linux 2.6.26-2-686 i686 Organization: NIC France X-URL: http://www.nic.fr/ User-Agent: Mutt/1.5.20 (2009-06-14) Cc: dnsext@ietf.org Subject: Re: [dnsext] Last Call: (Special-Use Domain Names) to Proposed Standard X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 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, 04 Feb 2011 12:50:01 -0000 On Fri, Feb 04, 2011 at 12:41:58PM +0000, Florian Weimer wrote a message of 26 lines which said: > > I observe that the document is not putting any names in the registry > > it is creating. Are there names that should be in the registry? > > LOCAL. It is not mentioned in draft-cheshire-dnsext-special-names-01 (otherwise, I would have challenged the right of Apple to hijack TLD by unilateral decision). From fweimer@bfk.de Fri Feb 4 04:55:41 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C15983A6946 for ; Fri, 4 Feb 2011 04:55:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.167 X-Spam-Level: X-Spam-Status: No, score=-2.167 tagged_above=-999 required=5 tests=[AWL=0.082, BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aHKYftLRkMPl for ; Fri, 4 Feb 2011 04:55:39 -0800 (PST) Received: from mx01.bfk.de (mx01.bfk.de [193.227.124.2]) by core3.amsl.com (Postfix) with ESMTP id F14943A6905 for ; Fri, 4 Feb 2011 04:55:37 -0800 (PST) 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 1PlLFd-0003PR-JF; Fri, 04 Feb 2011 12:59:01 +0000 Received: by bfk.de with local id 1PlLFd-0006Sc-GL; Fri, 04 Feb 2011 12:59:01 +0000 To: Stephane Bortzmeyer References: <20110117230048.26192.84056.idtracker@localhost> <2A149A97-3B0A-49AA-88CA-9741F88B9274@gmail.com> <82hbckhsyx.fsf@mid.bfk.de> <20110204125324.GA11826@nic.fr> From: Florian Weimer Date: Fri, 04 Feb 2011 12:59:01 +0000 In-Reply-To: <20110204125324.GA11826@nic.fr> (Stephane Bortzmeyer's message of "Fri\, 4 Feb 2011 13\:53\:24 +0100") Message-ID: <82bp2shs6i.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] Last Call: (Special-Use Domain Names) to Proposed Standard X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 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, 04 Feb 2011 12:55:41 -0000 * Stephane Bortzmeyer: > On Fri, Feb 04, 2011 at 12:41:58PM +0000, > Florian Weimer wrote=20 > a message of 26 lines which said: > >> > I observe that the document is not putting any names in the registry >> > it is creating. Are there names that should be in the registry? >>=20 >> LOCAL.=20 > > It is not mentioned in draft-cheshire-dnsext-special-names-01 Wrong document? > (otherwise, I would have challenged the right of Apple to hijack TLD It's not just Apple, not even close. > by unilateral decision). IIRC, previous attempts predating Multicast DNS to reserve this name have failed. That might have been one reason why RFCs have been reluctant to mention special names. Oh, and if we cannot put LOCAL. into the registry now, I'm quite certain that the registry will always remain empty. 8-) --=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 Fri Feb 4 05:31:48 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ED9413A6B87 for ; Fri, 4 Feb 2011 05:31:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.17 X-Spam-Level: X-Spam-Status: No, score=-2.17 tagged_above=-999 required=5 tests=[AWL=0.079, BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mrRCqdc7tkwk for ; Fri, 4 Feb 2011 05:31:48 -0800 (PST) Received: from mx01.bfk.de (mx01.bfk.de [193.227.124.2]) by core3.amsl.com (Postfix) with ESMTP id 716753A6BA1 for ; Fri, 4 Feb 2011 05:31:42 -0800 (PST) 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 1PlLoU-00017A-Is; Fri, 04 Feb 2011 13:35:02 +0000 Received: by bfk.de with local id 1PlLoU-0001lS-Cs; Fri, 04 Feb 2011 13:35:02 +0000 To: Thierry Moreau References: <17A80F45-52CB-43F6-BD4A-3488821F6933@hopcount.ca> <3A1DEE95-8C8E-4C89-97EB-6D8F799ADE25@virtualized.org> <4D42F4ED.6070502@connotech.com> From: Florian Weimer Date: Fri, 04 Feb 2011 13:35:02 +0000 In-Reply-To: <4D42F4ED.6070502@connotech.com> (Thierry Moreau's message of "Fri\, 28 Jan 2011 11\:55\:09 -0500") Message-ID: <82oc6rhqih.fsf@mid.bfk.de> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: dnsext List Subject: Re: [dnsext] historal root keys for upgrade path? X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 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, 04 Feb 2011 13:31:49 -0000 * Thierry Moreau: > Note that RFC5011 could have been "practiced" (by who would you guess > ... IANA) such that the next KSK is pre-announced at T[n-1]+mu (mu is > small). If mu+epsilon reliably recover at T[n] without an implicit leap-of-faith. But that > path would have made the root DNSKEY RRset larger. I still don't understand how you can postulate the existence of distinct "crypto periods" when you tie them intimately by cryptographic means (such as RFC 5011, or Wouter's trust anchor history mechanism). --=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 jabley@hopcount.ca Fri Feb 4 05:53:56 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 74C083A6949 for ; Fri, 4 Feb 2011 05:53:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.577 X-Spam-Level: X-Spam-Status: No, score=-102.577 tagged_above=-999 required=5 tests=[AWL=0.022, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nS7UXfQyicYk for ; Fri, 4 Feb 2011 05:53:55 -0800 (PST) Received: from monster.hopcount.ca (monster.hopcount.ca [216.235.14.38]) by core3.amsl.com (Postfix) with ESMTP id BA36D3A6941 for ; Fri, 4 Feb 2011 05:53:54 -0800 (PST) Received: from [199.212.90.21] (helo=dh21.r2.owls.hopcount.ca) by monster.hopcount.ca with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.71 (FreeBSD)) (envelope-from ) id 1PlME0-0008Hm-JQ; Fri, 04 Feb 2011 14:01:25 +0000 Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Joe Abley In-Reply-To: <82hbckhsyx.fsf@mid.bfk.de> Date: Fri, 4 Feb 2011 08:57:04 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20110117230048.26192.84056.idtracker@localhost> <2A149A97-3B0A-49AA-88CA-9741F88B9274@gmail.com> <82hbckhsyx.fsf@mid.bfk.de> To: Florian Weimer X-Mailer: Apple Mail (2.1082) X-SA-Exim-Connect-IP: 199.212.90.21 X-SA-Exim-Mail-From: jabley@hopcount.ca X-SA-Exim-Scanned: No (on monster.hopcount.ca); SAEximRunCond expanded to false Cc: Samuel Weiler , Ralph Droms , dnsext@ietf.org Subject: Re: [dnsext] Fwd: Last Call: (Special-Use Domain Names) to Proposed Standard X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 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, 04 Feb 2011 13:53:56 -0000 On 2011-02-04, at 07:41, Florian Weimer wrote: > LOCAL. If understand things correctly, it's widely used to trigger > Multicast DNS resolution in combined DNS/Multicast DNS environments. In draft-jabley-reserved-domain-names-00, my initial registry was = specified as: +-------------+-----------------------------------------+-----------+ | Domain Name | Description | Reference | +-------------+-----------------------------------------+-----------+ | TEST | Recommended for use in testing of | [RFC2606] | | | current or new DNS related code | | | | | | | EXAMPLE | Recommended for use in documentation or | [RFC2606] | | | as examples | | | | | | | INVALID | Recommended for use in documentation or | [RFC2606] | | | as examples | | | | | | | LOCALHOST | Traditionally statically defined in | [RFC2606] | | | host DNS implementations as having an A | | | | record pointing to the loop back IP | | | | address, and reserved for such use | | | | | | | EXAMPLE.COM | Available for use as examples | [RFC2606] | | | | | | EXAMPLE.NET | Available for use as examples | [RFC2606] | | | | | | EXAMPLE.ORG | Available for use as examples | [RFC2606] | +-------------+-----------------------------------------+-----------+ I didn't include LOCAL because there wasn't a suitable published = document for it, and the registry I defined had registration procedures = specified as "document published with iab approval". However, if this = registry existed, I would expect that Stuart's bonjour draft would be = extended with an IANA Considerations section that specified relevant = names be added to the registry. I never submitted draft-jabley-reserved-domain-names-00 when I wrote it, = but since I've referred to it a couple of times I will now do so in case = that's of any use to anybody. I continue to think that Stuart's = discussion of the issues is valuable, but I think the registry creation = would benefit from more concise direction. Joe= From prvs=0020bc2800=namedroppers+phil@spodhuis.org Mon Feb 7 22:37:58 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 820013A6B69 for ; Mon, 7 Feb 2011 22:37:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.741 X-Spam-Level: X-Spam-Status: No, score=-0.741 tagged_above=-999 required=5 tests=[BAYES_20=-0.74, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fi-GLqcFDNfy for ; Mon, 7 Feb 2011 22:37:56 -0800 (PST) Received: from mx.spodhuis.org (smtp.spodhuis.org [IPv6:2a02:898:31:0:48:4558:736d:7470]) by core3.amsl.com (Postfix) with ESMTP id 77CB33A7018 for ; Mon, 7 Feb 2011 22:37:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=spodhuis.org; s=d200912; h=Content-Type:MIME-Version:Message-ID:Subject:To:From:Date; bh=Vz0m1A9dNFX1asEVkuQGKvCDI7a/1EUMyzyb70sNm7Y=; b=oFFFEw1xEOxLj4z1S5iTzioTbUUmZ366d1R0PEFvYov2GUuhx5+Zctjmss7dXlbeddSyiE1zVeh8d1nopKlJGS5xiNXh7NwXcTYZN5JrTT+Frlhapd9gZH6JOr5Ck+F6A9mLQdoU2hXfBOXFsL8B25SMJtaZIvdhg4qDDY+Hod0=; Received: by smtp.spodhuis.org with local id 1PmhD5-0009H3-PJ; Tue, 08 Feb 2011 06:37:59 +0000 Date: Tue, 8 Feb 2011 01:37:59 -0500 From: Phil Pennock To: dnsext@ietf.org Message-ID: <20110208063759.GA35601@redoubt.spodhuis.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Subject: [dnsext] Spec for AA in query meaning AA-only? X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 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, 08 Feb 2011 06:37:58 -0000 RFC 1035 defines AA for responses; I'm failing to find a specification which states that AA in a query means AA-only. I see +aaonly for dig. Not finding a reference. Am I missing it or is this only an informal convention? Thanks, -Phil From george.barwood@blueyonder.co.uk Tue Feb 8 00:28:20 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9FF793A704E for ; Tue, 8 Feb 2011 00:28:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.595 X-Spam-Level: X-Spam-Status: No, score=0.595 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_BLUEYON=1.4, MIME_BASE64_BLANKS=0.041, MIME_BASE64_TEXT=1.753] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ITHHWWamTQnP for ; Tue, 8 Feb 2011 00:28:20 -0800 (PST) Received: from smtp-out4.blueyonder.co.uk (smtp-out4.blueyonder.co.uk [195.188.213.7]) by core3.amsl.com (Postfix) with ESMTP id CEB6F3A7003 for ; Tue, 8 Feb 2011 00:28:19 -0800 (PST) Received: from [172.23.170.146] (helo=anti-virus03-09) by smtp-out4.blueyonder.co.uk with smtp (Exim 4.52) id 1Pmivw-0002U7-Lv; Tue, 08 Feb 2011 08:28:24 +0000 Received: from [92.238.99.235] (helo=GeorgeLaptop) by asmtp-out6.blueyonder.co.uk with smtp (Exim 4.72) (envelope-from ) id 1Pmivm-0001iJ-N9; Tue, 08 Feb 2011 08:28:14 +0000 Message-ID: <168FFF9696C5454B93C33414A29BD891@local> From: "George Barwood" To: "Phil Pennock" , References: <20110208063759.GA35601@redoubt.spodhuis.org> Date: Tue, 8 Feb 2011 08:28:20 -0000 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.5994 Subject: Re: [dnsext] Spec for AA in query meaning AA-only? X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 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, 08 Feb 2011 08:28:20 -0000 DQotLS0tLSBPcmlnaW5hbCBNZXNzYWdlIC0tLS0tIA0KRnJvbTogIlBoaWwgUGVubm9jayIgPG5h bWVkcm9wcGVycytwaGlsQHNwb2RodWlzLm9yZz4NClRvOiA8ZG5zZXh0QGlldGYub3JnPg0KU2Vu dDogVHVlc2RheSwgRmVicnVhcnkgMDgsIDIwMTEgNjozNyBBTQ0KU3ViamVjdDogW2Ruc2V4dF0g U3BlYyBmb3IgQUEgaW4gcXVlcnkgbWVhbmluZyBBQS1vbmx5Pw0KDQoNCj4gUkZDIDEwMzUgZGVm aW5lcyBBQSBmb3IgcmVzcG9uc2VzOyBJJ20gZmFpbGluZyB0byBmaW5kIGEgc3BlY2lmaWNhdGlv bg0KPiB3aGljaCBzdGF0ZXMgdGhhdCBBQSBpbiBhIHF1ZXJ5IG1lYW5zIEFBLW9ubHkuDQoNClRo ZSBtZWFuaW5nIG9mIHRoZSBBQSBmbGFnIGJpdCBpbiBhIHF1ZXJ5IGlzIG5vdCBkZWZpbmVkIGJ5 IHRoZSBzdGFuZGFyZC4NCkdlbmVyYWwgcHJpbmNpcGxlcyBkaWN0YXRlIHRoYXQgc2VuZGVycyBz aG91bGQgbGVhdmUgdGhlIGJpdCB6ZXJvLCByZWNlaXZlcnMgc2hvdWxkIGlnbm9yZSBpdC4NCg0K PiBJIHNlZSArYWFvbmx5IGZvciBkaWcuICBOb3QgZmluZGluZyBhIHJlZmVyZW5jZS4NCg0KVGhp cyBpcyBhcHBhcmVudGx5IGFuIGhpc3RvcmljIHJlbGljLiBJIHByZXN1bWUgdGhhdCBhdCBzb21l IHBvaW50IGluIHRoZSBkaXN0YW50IHBhc3Qgc29tZQ0Kc2VydmVycyBtdXN0IGhhdmUgYXNzaWdu ZWQgYSBtZWFuaW5nIHRvIEFBIGJlaW5nIHNldCBpbiBhIHF1ZXJ5Lg0KIA0KPiBBbSBJIG1pc3Np bmcgaXQgb3IgaXMgdGhpcyBvbmx5IGFuIGluZm9ybWFsIGNvbnZlbnRpb24/DQoNCkkgZG9uJ3Qg dGhpbmsgeW91IGhhdmUgbWlzc2VkIGFueXRoaW5nLg0KDQpSZWdhcmRzLA0KR2VvcmdlDQogDQo+ IFRoYW5rcywNCj4gLVBoaWwNCj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX18NCj4gZG5zZXh0IG1haWxpbmcgbGlzdA0KPiBkbnNleHRAaWV0Zi5vcmcNCj4g aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9kbnNleHQ= From bert.hubert@netherlabs.nl Tue Feb 8 01:57:48 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E19963A7019 for ; Tue, 8 Feb 2011 01:57:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.976 X-Spam-Level: X-Spam-Status: No, score=-1.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hS7elBu3fGc6 for ; Tue, 8 Feb 2011 01:57:48 -0800 (PST) Received: from xs.powerdns.com (xs.powerdns.com [IPv6:2001:888:2000:1d::2]) by core3.amsl.com (Postfix) with ESMTP id BED423A70B5 for ; Tue, 8 Feb 2011 01:57:47 -0800 (PST) Received: from mail-fx0-f44.google.com ([209.85.161.44]) by xs.powerdns.com with esmtpsa (TLS1.0:RSA_ARCFOUR_MD5:16) (Exim 4.69) (envelope-from ) id 1PmkKR-00043c-7W for dnsext@ietf.org; Tue, 08 Feb 2011 10:57:49 +0100 Received: by fxm9 with SMTP id 9so6298263fxm.31 for ; Tue, 08 Feb 2011 01:57:42 -0800 (PST) Received: by 10.223.72.6 with SMTP id k6mr15986828faj.46.1297158999118; Tue, 08 Feb 2011 01:56:39 -0800 (PST) MIME-Version: 1.0 Received: by 10.223.161.16 with HTTP; Tue, 8 Feb 2011 01:56:19 -0800 (PST) In-Reply-To: <20110208063759.GA35601@redoubt.spodhuis.org> References: <20110208063759.GA35601@redoubt.spodhuis.org> From: bert hubert Date: Tue, 8 Feb 2011 10:56:19 +0100 Message-ID: To: Phil Pennock Content-Type: multipart/alternative; boundary=20cf3054a71f5c157f049bc25d4e X-Spam_score: -3.8 X-Spam_score_int: -37 X-Spam_bar: --- X-Spam_report: Spam detection software, running on the system "xs.powerdns.com", has identified this incoming email as possible spam. The original message has been attached to this so you can view it (if it isn't spam) or label similar future email. If you have any questions, see the administrator of that system for details. Content preview: On Tue, Feb 8, 2011 at 7:37 AM, Phil Pennock wrote: > RFC 1035 defines AA for responses; I'm failing to find a specification > which states that AA in a query means AA-only. > [...] Content analysis details: (-3.8 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -1.8 ALL_TRUSTED Passed through trusted hosts only via SMTP 0.0 HTML_MESSAGE BODY: HTML included in message -2.6 BAYES_00 BODY: Bayesian spam probability is 0 to 1% [score: 0.0000] 0.6 AWL AWL: From: address is in the auto white-list Cc: dnsext@ietf.org Subject: Re: [dnsext] Spec for AA in query meaning AA-only? X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 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, 08 Feb 2011 09:57:49 -0000 --20cf3054a71f5c157f049bc25d4e Content-Type: text/plain; charset=ISO-8859-1 On Tue, Feb 8, 2011 at 7:37 AM, Phil Pennock wrote: > RFC 1035 defines AA for responses; I'm failing to find a specification > which states that AA in a query means AA-only. > I've never thought it meant that in a query. So even if this is an informal convention, it is not implemented universally, at least not in PowerDNS. Bert --20cf3054a71f5c157f049bc25d4e Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Tue, Feb 8, 2011 at 7:37 AM, Phil Pen= nock <namedroppers+phil@spodhuis.org> wrote:
RFC 1035 defines AA for responses; I'm failing to find a specification<= br> which states that AA in a query means AA-only.

I've never thought it meant that in a query. So even if this is= an informal convention, it is not implemented universally, at least not in= PowerDNS.

=A0=A0 Bert
--20cf3054a71f5c157f049bc25d4e-- From ogud@ogud.com Tue Feb 8 04:23:07 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D9EF93A6DE4 for ; Tue, 8 Feb 2011 04:23:07 -0800 (PST) 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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B7cg4m1QKrCv for ; Tue, 8 Feb 2011 04:23:07 -0800 (PST) Received: from stora.ogud.com (stora.ogud.com [66.92.146.20]) by core3.amsl.com (Postfix) with ESMTP id EDF423A6DD1 for ; Tue, 8 Feb 2011 04:23:06 -0800 (PST) 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 p18CNCDA004428 for ; Tue, 8 Feb 2011 07:23:13 -0500 (EST) (envelope-from ogud@ogud.com) Message-ID: <4D5135A8.4010709@ogud.com> Date: Tue, 08 Feb 2011 07:23:04 -0500 From: Olafur Gudmundsson User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-GB; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: dnsext@ietf.org References: <20110208063759.GA35601@redoubt.spodhuis.org> In-Reply-To: <20110208063759.GA35601@redoubt.spodhuis.org> 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] Spec for AA in query meaning AA-only? X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 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, 08 Feb 2011 12:23:08 -0000 On 08/02/2011 1:37 AM, Phil Pennock wrote: > RFC 1035 defines AA for responses; I'm failing to find a specification > which states that AA in a query means AA-only. > > I see +aaonly for dig. Not finding a reference. > > Am I missing it or is this only an informal convention? > > Thanks, > It is an artifact of an idea that Paul Vixie had many years ago to mean "Authoritative Answers Only". The idea did not gain traction with the DNS protocol community, but the experimental code is still in dig after all these years (look for aaonly in bin/dig directory. I do not think the code is in the name-server. If I recall correctly this was intended to force resolvers to go back to authoritative servers and get answer from them rather than give answer from cache. IMHO it is perfectly acceptable for a resolver to reject a query with AA bit set as "malformed". Olafur From each@isc.org Tue Feb 8 11:35:40 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E0D503A680A for ; Tue, 8 Feb 2011 11:35:40 -0800 (PST) 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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zKGI2nNcs9mI for ; Tue, 8 Feb 2011 11:35:40 -0800 (PST) Received: from mx.pao1.isc.org (mx.pao1.isc.org [IPv6:2001:4f8:0:2::2b]) by core3.amsl.com (Postfix) with ESMTP id 0414F3A682C for ; Tue, 8 Feb 2011 11:35:40 -0800 (PST) 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 43584C9435; Tue, 8 Feb 2011 19:35:39 +0000 (UTC) (envelope-from each@isc.org) Received: by bikeshed.isc.org (Postfix, from userid 10292) id 354D5216C33; Tue, 8 Feb 2011 19:35:39 +0000 (UTC) Date: Tue, 8 Feb 2011 19:35:39 +0000 From: Evan Hunt To: George Barwood Message-ID: <20110208193539.GA95484@isc.org> References: <20110208063759.GA35601@redoubt.spodhuis.org> <168FFF9696C5454B93C33414A29BD891@local> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <168FFF9696C5454B93C33414A29BD891@local> User-Agent: Mutt/1.4.2.3i Cc: dnsext@ietf.org Subject: Re: [dnsext] Spec for AA in query meaning AA-only? X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 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, 08 Feb 2011 19:35:41 -0000 > > I see +aaonly for dig. Not finding a reference. > > This is apparently an historic relic. I presume that at some point in the > distant past some servers must have assigned a meaning to AA being set in > a query. dig is a DNS debugging tool; it's capable of sending oddly-formed queries so as to find out how servers respond. Just because dig can do something doesn't mean it's a good idea. :) -- Evan Hunt -- each@isc.org Internet Systems Consortium, Inc. From wilmer@google.com Wed Feb 9 05:01:16 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A81843A69B9 for ; Wed, 9 Feb 2011 05:01:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.977 X-Spam-Level: X-Spam-Status: No, score=-105.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mGwVKeBE32Rf for ; Wed, 9 Feb 2011 05:01:15 -0800 (PST) Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by core3.amsl.com (Postfix) with ESMTP id 947393A69AB for ; Wed, 9 Feb 2011 05:01:15 -0800 (PST) Received: from kpbe13.cbf.corp.google.com (kpbe13.cbf.corp.google.com [172.25.105.77]) by smtp-out.google.com with ESMTP id p19D1OpP013466 for ; Wed, 9 Feb 2011 05:01:24 -0800 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1297256484; bh=Cv39a2LTD2sJDz83TUpccSqqSn0=; h=MIME-Version:Date:Message-ID:Subject:From:To:Cc:Content-Type; b=oiDtOA6VQeBsTBv5ln4SY34KtcOKbuNM4h3VLhqDtmkLwmzi+AXylyn655BWPtW0T jhwLl7g9eSeitXjqmOrxg== Received: from ewy8 (ewy8.prod.google.com [10.241.103.8]) by kpbe13.cbf.corp.google.com with ESMTP id p19D1MLD020741 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Wed, 9 Feb 2011 05:01:23 -0800 Received: by ewy8 with SMTP id 8so56361ewy.31 for ; Wed, 09 Feb 2011 05:01:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=domainkey-signature:mime-version:date:message-id:subject:from:to:cc :content-type; bh=0y2SKf9AEfu0FLZ9kAnNaP7IfqyqNvpooi7h83kagng=; b=jOXeqPY27lJFbtrjd/8IsHwBmZlrWvdU/N8wZcWh2RrwDaUanopSlyNE775172s62J FikGKA1+wnbl4McnCb5A== DomainKey-Signature: a=rsa-sha1; c=nofws; d=google.com; s=beta; h=mime-version:date:message-id:subject:from:to:cc:content-type; b=bvFyfHfrimg0WGG1lUZGmNMZSavfxzHWW5lRdl+don0WXYWfmcdONBJswt94OLGHrd nZ0ODIjoKmC0XH4FhWjw== MIME-Version: 1.0 Received: by 10.213.32.18 with SMTP id a18mr1698299ebd.60.1297256480896; Wed, 09 Feb 2011 05:01:20 -0800 (PST) Received: by 10.213.106.19 with HTTP; Wed, 9 Feb 2011 05:01:20 -0800 (PST) Date: Wed, 9 Feb 2011 13:01:20 +0000 Message-ID: From: Wilmer van der Gaast To: dnsext@ietf.org Content-Type: text/plain; charset=ISO-8859-1 X-System-Of-Record: true Cc: edns-client-subnet@googlegroups.com Subject: [dnsext] Uploaded: edns-client-subnet-00 X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 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, 09 Feb 2011 13:01:16 -0000 Everyone, A few days ago we uploaded a new version of the edns-client-subnet draft. It can be found at: http://tools.ietf.org/html/draft-vandergaast-edns-client-subnet-00 The version number was reset to -00 because of the rename from edns-client-ip to edns-client-subnet. Without a rename, it would've been version -02. Appendix A describes all changes made to the draft since the last version. In short: * Rewrote origination sections to clarify that normally only recursive resolvers generate edns-client-subnet options. * Discussion on whitelisting or automatically detecting if an authority supports edns-client-subnet. * More precisely specifying (optional) transitive behaviour. * Minor revisions to improve clarity and correctness w.r.t. other RFCs. Also, since the release of the last draft we have: * Added support for handling edns-client-subnet options to both our authoritative nameservers and Google Public DNS, using option code 0x50fa (not officially allocated and *not* to be used permanently). * Started a small-scale experiment of using edns-client-subnet in real life, to measure latency improvements and confirm that the idea is generally feasible. We're working with several third parties (CDNs but also resolvers) and are looking forward to hearing from anyone else interested in participating. We intend to release our findings from the experiment described above in the next months. In the meantime, comments on the new draft are welcome as always. Kind regards, Wilmer van der Gaast, Carlo Contavalli Google Sean Leach Verisign Darryl Rodden Neustar From segred@ics.forth.gr Thu Feb 10 06:12:50 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E85083A69A6 for ; Thu, 10 Feb 2011 06:12:50 -0800 (PST) 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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gLaIkVayTV0M for ; Thu, 10 Feb 2011 06:12:50 -0800 (PST) Received: from mailgate.ics.forth.gr (mailgate.ics.forth.gr [139.91.1.2]) by core3.amsl.com (Postfix) with ESMTP id BC14C3A69A4 for ; Thu, 10 Feb 2011 06:12:49 -0800 (PST) Received: from av1.ics.forth.gr (av1-in.ics.forth.gr [139.91.1.71]) by mailgate.ics.forth.gr (8.14.3/ICS-FORTH/V10-1.8-GATE) with ESMTP id p1AECvMS014902; Thu, 10 Feb 2011 16:12:59 +0200 (EET) X-AuditID: 8b5b9d47-b7c88ae0000076fe-20-4d53f269d4f9 Received: from enigma.ics.forth.gr (webmail.ics.forth.gr [139.91.1.30]) by av1.ics.forth.gr (SMTP Outbound / FORTH / ICS) with SMTP id D8.52.30462.962F35D4; Thu, 10 Feb 2011 16:12:57 +0200 (EET) Received: from Thanatos (thanatos.ics.forth.gr [139.91.88.160]) (authenticated bits=0) by enigma.ics.forth.gr (8.14.3//ICS-FORTH/V10.3.0C-EXTNULL-SSL-SASL) with ESMTP id p1AECuZq023521 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Thu, 10 Feb 2011 16:12:56 +0200 X-ICS-AUTH-INFO: Authenticated user: segred at ics.forth.gr From: "Vaggelis Segredakis" To: "'Olafur Gudmundsson'" , References: <4D48617E.1020408@ogud.com> Date: Thu, 10 Feb 2011 16:11:54 +0200 Message-ID: <3A5CD55E5CCE43F0BA44AAC89BADB866@ics.forth.gr> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <4D48617E.1020408@ogud.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5994 Thread-Index: AcvCR9TeLB7LSH/USj+/UpQz3tucSwG45DzA X-Brightmail-Tracker: AAAAAA== X-j-chkmail-Score: MSGID : 4D53F269.000 on mailgate : j-chkmail score : . : R=. U=. O=. B=0.000 -> S=0.000 X-ICS-JCHK-SCL: Ham Subject: Re: [dnsext] DNSEXT progress and possible meeting at IETF-80 X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 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, 10 Feb 2011 14:12:51 -0000 Dear Chairs, We as the Registry of [.gr] domain names are still very much interested in the Aliasing Requirements item and the development of a "xNAME" identical tree solution. We would be very happy to produce a comment of this document. If there is anyone else interested in that please feel free to contact me. Kind Regards, Vaggelis Segredakis Administrator of the .GR Top Level Domain Institute of Computer Science Foundation for Research and Technology - Hellas Tel. +30-281-0391450 Fax +30-281-0391451 Email segred@ics.forth.gr -----Original Message----- From: dnsext-bounces@ietf.org [mailto:dnsext-bounces@ietf.org] On Behalf Of Olafur Gudmundsson Sent: Tuesday, February 01, 2011 9:40 PM To: dnsext@ietf.org Subject: [dnsext] DNSEXT progress and possible meeting at IETF-80 At this point the chairs are not sure there is a reason to have a meeting. We have a number of work items that can be discussed on the mailing list or wait on chair action. There is one ttem that seems to have died, "Aliasing Requirements". Unless there is movement on that document we can not adopt any new aliasing proposed changes. The chairs will make a final call on meeting in about 10 days. Olafur & Andrew _______________________________________________ dnsext mailing list dnsext@ietf.org https://www.ietf.org/mailman/listinfo/dnsext From woolf@isc.org Thu Feb 10 18:01:23 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 965CA3A69DB for ; Thu, 10 Feb 2011 18:01:23 -0800 (PST) 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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QiBOjuM+yKPo for ; Thu, 10 Feb 2011 18:01:22 -0800 (PST) Received: from mx.ams1.isc.org (mx.ams1.isc.org [IPv6:2001:500:60::65]) by core3.amsl.com (Postfix) with ESMTP id 991FC3A69AB for ; Thu, 10 Feb 2011 18:01:22 -0800 (PST) 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 280705F98F3; Fri, 11 Feb 2011 02:01:27 +0000 (UTC) (envelope-from woolf@isc.org) Received: by bikeshed.isc.org (Postfix, from userid 10265) id 35C03216C22; Fri, 11 Feb 2011 02:01:25 +0000 (UTC) Date: Fri, 11 Feb 2011 02:01:25 +0000 From: Suzanne Woolf To: Vaggelis Segredakis Message-ID: <20110211020125.GA147@bikeshed.isc.org> References: <4D48617E.1020408@ogud.com> <3A5CD55E5CCE43F0BA44AAC89BADB866@ics.forth.gr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3A5CD55E5CCE43F0BA44AAC89BADB866@ics.forth.gr> User-Agent: Mutt/1.4.2.3i Cc: dnsext@ietf.org, 'Olafur Gudmundsson' Subject: Re: [dnsext] DNSEXT progress and possible meeting at IETF-80 X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 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, 11 Feb 2011 02:01:23 -0000 On Thu, Feb 10, 2011 at 04:11:54PM +0200, Vaggelis Segredakis wrote: > We as the Registry of [.gr] domain names are still very much interested in > the Aliasing Requirements item and the development of a "xNAME" identical > tree solution. This is good to know, as I am working on the -00 (WG item) of the identical-resolution draft; it's behind schedule but definitely not forgotten. I expect to be in Prague and would work with you (or anyone interested) there, as well as in email until then. > We would be very happy to produce a comment of this document. If there is > anyone else interested in that please feel free to contact me. This would be helpful. thanks, Suzanne From segred@ics.forth.gr Fri Feb 11 08:18:08 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3A6083A69D1 for ; Fri, 11 Feb 2011 08:18:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.599 X-Spam-Level: X-Spam-Status: No, score=-7.599 tagged_above=-999 required=5 tests=[AWL=1.000, BAYES_00=-2.599, GB_I_LETTER=-2, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HxAhe7BKbCbM for ; Fri, 11 Feb 2011 08:18:06 -0800 (PST) Received: from mailgate.ics.forth.gr (mailgate.ics.forth.gr [139.91.1.2]) by core3.amsl.com (Postfix) with ESMTP id 202173A68C0 for ; Fri, 11 Feb 2011 08:18:01 -0800 (PST) Received: from av1.ics.forth.gr (av1-in.ics.forth.gr [139.91.1.71]) by mailgate.ics.forth.gr (8.14.3/ICS-FORTH/V10-1.8-GATE) with ESMTP id p1BGI3Ba022938; Fri, 11 Feb 2011 18:18:05 +0200 (EET) X-AuditID: 8b5b9d47-b7c88ae0000076fe-a5-4d55613b8969 Received: from enigma.ics.forth.gr (webmail.ics.forth.gr [139.91.1.30]) by av1.ics.forth.gr (SMTP Outbound / FORTH / ICS) with SMTP id 60.AA.30462.B31655D4; Fri, 11 Feb 2011 18:18:03 +0200 (EET) Received: from Thanatos (thanatos.ics.forth.gr [139.91.88.160]) (authenticated bits=0) by enigma.ics.forth.gr (8.14.3//ICS-FORTH/V10.3.0C-EXTNULL-SSL-SASL) with ESMTP id p1BGI0pQ001245 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Fri, 11 Feb 2011 18:18:00 +0200 X-ICS-AUTH-INFO: Authenticated user: segred at ics.forth.gr From: "Vaggelis Segredakis" To: "'Suzanne Woolf'" References: <4D48617E.1020408@ogud.com> <3A5CD55E5CCE43F0BA44AAC89BADB866@ics.forth.gr> <20110211020125.GA147@bikeshed.isc.org> Date: Fri, 11 Feb 2011 18:17:16 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <20110211020125.GA147@bikeshed.isc.org> thread-index: AcvJj6Zv6eRl6Yc5THmRTc30Rg8bJAAcU3zg X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5994 X-Brightmail-Tracker: AAAAARdlQCA= X-j-chkmail-Score: MSGID : 4D55613B.000 on mailgate : j-chkmail score : . : R=. U=. O=. B=0.000 -> S=0.000 X-ICS-JCHK-SCL: Ham Cc: dnsext@ietf.org, 'Olafur Gudmundsson' Subject: [dnsext] draft-yao-dnsext-identical-resolution-02 comment X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 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, 11 Feb 2011 16:18:08 -0000 Dear Suzanne, Having read your analysis in the document draft-yao-dnsext-identical-resolution-02.pdf I would like to raise some points of discussion. The analysis was thorough and it explains very well the issues at hand for the registries with variant IDN registrations. Although we have been advised to create bundles or variants of domain names, their behavior was never explained as a mechanism. As the Greek registry, offering registrations in Greek characters presented the problem with the accent mark "tonos" which is used in the majority of Greek words. In capital letters however, the same words are spelled without the tonos. Their representation in the Punycode is unfortunately different and we had to match these up (make similar) for the user, otherwise the user experience of case-insensitivity would be lost. We used the DNAME mechanism with not very satisfactory results. The revision of the IDNA protocol to IDNA2008 brought forward two other issues: 1. The mapping of the upper case letters to the lower case is no longer a feature of the protocol but rather a task of the application. This way we cannot have consistent mappings since we do not know what the programmer has chosen to do with the upper case characters, especially in regards to tonos and final sigma. 2. The final sigma letter which is a representation of the small case sigma when at the end of the word and not a letter by itself is represented in the new protocol as a standalone character. This is good in a sense, since almost all male names and surnames and numerous other words end in a final sigma which was misrepresented. However -maybe you guessed it- the same words, when spelled in upper case letters do not have a final sigma but instead the normal one. Your document has also raised the issue of "confusing similar visuality" [Page 12] (Homographs) which although present in the Greek to Latin alphabet similarities was solved by regulation and was not really a problem of DNS. Our solution can be found at the address https://grweb.ics.forth.gr/homographs.jsp?lang=en. We are in favor of a solution of the BNAME type proposal. We do not intend to SHADOW the .gr zone to another one but we would really like to "make similar" a great number of IDN domain names that will have variants. This way, while a SHADOW would be helpful only to our registrants wishing to "make similar" the variants themselves we as a registry would like to provide to our registrants the easiest solution of not having to deal extensively with DNS. The registrant could just ask the registry to provide the "sameness" for the variants in the BNAME form. These are two completely different solutions and they have been asked by different people for different cases. The word "similar" or "same" is confusing but the needs presented are totally different. The SHADOW is a request by registries that have multiple TLDs in different(?) character sets and they want them to operate as one. The BNAME solution is suitable for a TLD that wants to register variants and comply with the RFC3743 idea of equivalence of labels and bundled names. I would be very happy if your issue-analysis document turns into a solution or even two, since these two are not even close, although BNAME would be a solution even for shadow TLD zones as well, if it was to be used directly in the root zone files. I hope that Olafur in his email on the 1st of February was mistaken when he declared the item "Aliasing Requirements" dead and a discussion will take place in the next DNSSEC meeting to initiate the solution procedure. Thank you for your document and I look forward to your next draft. I would be glad to assist in any way possible. Vaggelis Segredakis P.S. The http://users.isc.org/~woolf web site mentioned in the draft is not accessible. -----Original Message----- From: Suzanne Woolf [mailto:woolf@isc.org] Sent: Friday, February 11, 2011 4:01 AM To: Vaggelis Segredakis Cc: 'Olafur Gudmundsson'; dnsext@ietf.org Subject: Re: [dnsext] DNSEXT progress and possible meeting at IETF-80 On Thu, Feb 10, 2011 at 04:11:54PM +0200, Vaggelis Segredakis wrote: > We as the Registry of [.gr] domain names are still very much interested in > the Aliasing Requirements item and the development of a "xNAME" identical > tree solution. This is good to know, as I am working on the -00 (WG item) of the identical-resolution draft; it's behind schedule but definitely not forgotten. I expect to be in Prague and would work with you (or anyone interested) there, as well as in email until then. > We would be very happy to produce a comment of this document. If there is > anyone else interested in that please feel free to contact me. This would be helpful. thanks, Suzanne From woolf@isc.org Sun Feb 13 23:10:39 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0A9F03A6C7C for ; Sun, 13 Feb 2011 23:10:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.6 X-Spam-Level: X-Spam-Status: No, score=-3.6 tagged_above=-999 required=5 tests=[AWL=1.000, BAYES_00=-2.599, GB_I_LETTER=-2, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6aH76z0QH6HS for ; Sun, 13 Feb 2011 23:10:37 -0800 (PST) Received: from mx.ams1.isc.org (mx.ams1.isc.org [IPv6:2001:500:60::65]) by core3.amsl.com (Postfix) with ESMTP id 2DEAC3A6C77 for ; Sun, 13 Feb 2011 23:10:37 -0800 (PST) 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 C61EC5F98E9; Mon, 14 Feb 2011 07:10:48 +0000 (UTC) (envelope-from woolf@isc.org) Received: by bikeshed.isc.org (Postfix, from userid 10265) id 6D107216C36; Mon, 14 Feb 2011 07:10:47 +0000 (UTC) Date: Mon, 14 Feb 2011 07:10:47 +0000 From: Suzanne Woolf To: Vaggelis Segredakis Message-ID: <20110214071047.GA64679@bikeshed.isc.org> References: <4D48617E.1020408@ogud.com> <3A5CD55E5CCE43F0BA44AAC89BADB866@ics.forth.gr> <20110211020125.GA147@bikeshed.isc.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i Cc: dnsext@ietf.org, 'Olafur Gudmundsson' Subject: Re: [dnsext] draft-yao-dnsext-identical-resolution-02 comment X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 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, 14 Feb 2011 07:10:39 -0000 On Fri, Feb 11, 2011 at 06:17:16PM +0200, Vaggelis Segredakis wrote: > As the Greek registry, offering registrations in Greek characters presented > the problem with the accent mark "tonos" which is used in the majority of > Greek words. In capital letters however, the same words are spelled without > the tonos. Their representation in the Punycode is unfortunately different > and we had to match these up (make similar) for the user, otherwise the user > experience of case-insensitivity would be lost. We used the DNAME mechanism > with not very satisfactory results. The previous version of the document used your previous messages on Greek as an example of the "bundling" requirement, however I can't find any previous reference to specific problems you might have had with DNAME. Could you elaborate? > The revision of the IDNA protocol to IDNA2008 brought forward two other > issues: > 1. The mapping of the upper case letters to the lower case is no longer a > feature of the protocol but rather a task of the application. This way we > cannot have consistent mappings since we do not know what the programmer has > chosen to do with the upper case characters, especially in regards to tonos > and final sigma. This uncertainty about what the application will do with "bundled" names as far as treating them "the same" seems to be the underlying concern that motivates all the discussion we've had about adding functionality to the DNS to support the "sameness" property. However, it's also been strongly argued here that there's no way to support "aliases" in the DNS without application support, particularly without introducing inconsistencies in handling of certificates and other objects that rely on domain names. So the tension that needs to be explained in the next version of the document is between the need for providing this kind of "help" to applications, and the challenge of getting them to use it. > We are in favor of a solution of the BNAME type proposal. We do not intend > to SHADOW the .gr zone to another one but we would really like to "make > similar" a great number of IDN domain names that will have variants. This > way, while a SHADOW would be helpful only to our registrants wishing to > "make similar" the variants themselves we as a registry would like to > provide to our registrants the easiest solution of not having to deal > extensively with DNS. The registrant could just ask the registry to provide > the "sameness" for the variants in the BNAME form. The thing that worries me about this is that the registry can provide BNAMEs, but if applications don't make use of the "sameness" semantics, we haven't really gained anything.... > I hope that Olafur in his email on the 1st of February was mistaken > when he declared the item "Aliasing Requirements" dead and a > discussion will take place in the next DNSSEC meeting to initiate > the solution procedure. The requirements document is a WG item under the recent charter, and it remains my intent (as I believe Olafur knows) to make sure the document is completed as an Informational RFC in the near future. The work item isn't done until the WG has decided one way or another whether to pursue additional work on the subject, so I'll respectfully disagree with Olafur's assertion. Whether there's a meeting of DNSEXT in Prague or not, the WG version of this draft will ship soon so we can continue the discussion. best, Suzanne From segred@ics.forth.gr Mon Feb 14 07:01:21 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2C44D3A6D71 for ; Mon, 14 Feb 2011 07:01:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.966 X-Spam-Level: X-Spam-Status: No, score=-6.966 tagged_above=-999 required=5 tests=[AWL=-0.633, BAYES_00=-2.599, GB_I_LETTER=-2, J_CHICKENPOX_55=0.6, RCVD_IN_DNSWL_MED=-4, SARE_URI_EQUALS=1.666] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GBOHwBOuWrgQ for ; Mon, 14 Feb 2011 07:01:20 -0800 (PST) Received: from mailgate.ics.forth.gr (mailgate.ics.forth.gr [139.91.1.2]) by core3.amsl.com (Postfix) with ESMTP id 9CE813A6D67 for ; Mon, 14 Feb 2011 07:01:19 -0800 (PST) Received: from av1.ics.forth.gr (av1-in.ics.forth.gr [139.91.1.71]) by mailgate.ics.forth.gr (8.14.3/ICS-FORTH/V10-1.8-GATE) with ESMTP id p1EF1TZ6011986; Mon, 14 Feb 2011 17:01:31 +0200 (EET) X-AuditID: 8b5b9d47-b7c88ae0000076fe-b0-4d5943c8a189 Received: from enigma.ics.forth.gr (webmail.ics.forth.gr [139.91.1.30]) by av1.ics.forth.gr (SMTP Outbound / FORTH / ICS) with SMTP id B8.D5.30462.9C3495D4; Mon, 14 Feb 2011 17:01:29 +0200 (EET) Received: from Thanatos (thanatos.ics.forth.gr [139.91.88.160]) (authenticated bits=0) by enigma.ics.forth.gr (8.14.3//ICS-FORTH/V10.3.0C-EXTNULL-SSL-SASL) with ESMTP id p1EF1Rug026365 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Mon, 14 Feb 2011 17:01:27 +0200 X-ICS-AUTH-INFO: Authenticated user: segred at ics.forth.gr From: "Vaggelis Segredakis" To: "'Suzanne Woolf'" References: <4D48617E.1020408@ogud.com> <3A5CD55E5CCE43F0BA44AAC89BADB866@ics.forth.gr> <20110211020125.GA147@bikeshed.isc.org> <20110214071047.GA64679@bikeshed.isc.org> Date: Mon, 14 Feb 2011 17:05:02 +0200 Message-ID: <15CC617D3D244626A6B31600701E9A81@ics.forth.gr> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <20110214071047.GA64679@bikeshed.isc.org> thread-index: AcvMFluzhPD0gNuqQ5+rathPNkqPfwAP6Krg X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5994 X-Brightmail-Tracker: AAAAAA== X-j-chkmail-Score: MSGID : 4D5943C9.000 on mailgate : j-chkmail score : . : R=. U=. O=. B=0.000 -> S=0.000 X-ICS-JCHK-SCL: Ham Cc: dnsext@ietf.org, 'Olafur Gudmundsson' Subject: Re: [dnsext] draft-yao-dnsext-identical-resolution-02 comment X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 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, 14 Feb 2011 15:01:21 -0000 Dear Suzanne, >The previous version of the document used your previous messages on >Greek as an example of the "bundling" requirement, however I can't >find any previous reference to specific problems you might have had >with DNAME. Could you elaborate? We have given the DNAME option to our registrants for less hassle in setting up their DNS. Although it is OK if you just try to set www.name1.gr=www.name2.gr, unfortunately you cannot use it to send email@name1.gr and expect it to arrive to email@name2.gr because name1.gr<>name2.gr. This way, our actual assistance to the registrant is very limited and anyone choosing not to set up a zone for each name of the bundle gets limited operation for the rest of the bundle names. As I explained before, since a user expects to type a domain name with tonos or the same domain without the tonos and end up with the same result (remember, in Greek words are spelled with tonos in small case letters but without in Caps) the user experience is severely damaged when this is not happening flawlessly, as expected if the domain was in Latin. We try to find a solution to amend this issue and we came to the conclusion that a BNAME sort of solution is necessary. >However, it's also been strongly argued here that there's no way to >support "aliases" in the DNS without application support, particularly >without introducing inconsistencies in handling of certificates and >other objects that rely on domain names. So the tension that needs to >be explained in the next version of the document is between the need >for providing this kind of "help" to applications, and the challenge >of getting them to use it. I can understand that a number of issues would need to be sorted before such a solution could be used. However I believe that there is a need for it. Furthermore, there is a logical gap between CNAME and DNAME if CNAME+DNAME cannot co-exist and we do nothing to change this. >The thing that worries me about this is that the registry can provide >BNAMEs, but if applications don't make use of the "sameness" >semantics, we haven't really gained anything.... I expect it could take some time for the applications to adapt to such a solution but I keep reminding to myself that DNAME as well took some time to be deployed although it was a useful add-on to the DNS. >Whether there's a meeting of DNSEXT in Prague or not, the WG version >of this draft will ship soon so we can continue the discussion. This is very good to know :) Best, Vaggelis Segredakis From ajs@shinkuro.com Mon Feb 14 08:37:24 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 81B803A6D5C for ; Mon, 14 Feb 2011 08:37:24 -0800 (PST) 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=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BuN5gTAf5Mrg for ; Mon, 14 Feb 2011 08:37:23 -0800 (PST) Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by core3.amsl.com (Postfix) with ESMTP id 8DD553A6D4C for ; Mon, 14 Feb 2011 08:37:23 -0800 (PST) Received: from crankycanuck.ca (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 47ED91ECB41D for ; Mon, 14 Feb 2011 16:37:45 +0000 (UTC) Date: Mon, 14 Feb 2011 11:37:43 -0500 From: Andrew Sullivan To: dnsext@ietf.org Message-ID: <20110214163742.GC71863@shinkuro.com> References: <4D48617E.1020408@ogud.com> <3A5CD55E5CCE43F0BA44AAC89BADB866@ics.forth.gr> <20110211020125.GA147@bikeshed.isc.org> <20110214071047.GA64679@bikeshed.isc.org> <15CC617D3D244626A6B31600701E9A81@ics.forth.gr> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <15CC617D3D244626A6B31600701E9A81@ics.forth.gr> User-Agent: Mutt/1.5.18 (2008-05-17) Subject: Re: [dnsext] draft-yao-dnsext-identical-resolution-02 comment X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 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, 14 Feb 2011 16:37:24 -0000 On Mon, Feb 14, 2011 at 05:05:02PM +0200, Vaggelis Segredakis wrote: > I can understand that a number of issues would need to be sorted before such > a solution could be used. However I believe that there is a need for it. Speaking only for myself, this is the crux of the issue. What you're saying is that the technology is needed, but the objection that some have raised is that such a technology won't really work except in the most trivial cases. Since the trivial cases could just as easily be solved with DNAME + other records at the apex, it's hard to justify making a big change to the protocol. Now, if the suggestion is that the parent _needs to_ enforce policies in the tree underneath the parent, then we have a different argument, because DNAME on the parent side won't really work for this purpose. Speaking as co-chair but without having run this text past Olafur: in respect of having a meeting, the issue is that we've already talked about this topic a lot in meetings. We discussed it at length in Anaheim, had a special session about it in Maastricht, devoted meeting time to in Beijing, and even had an interim teleconference. But in between those events very little discussion on the topic seems to have happened. Moreover, when we do have discussion it tends to focus on existing proposals: "Do BNAME", for instance. But the problem we have is that we cannot tell whether BNAME (or any other proposal) actually addresses the particular problems people have. So either we get a clear and broadly agreed-upon statement of the problem we are trying to solve, or we don't solve the problem (because if we can't say what it is, I think that means we don't know). Best, Andrew -- Andrew Sullivan ajs@shinkuro.com Shinkuro, Inc. From woolf@isc.org Mon Feb 14 08:56:46 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 08C423A6A0F for ; Mon, 14 Feb 2011 08:56:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.1 X-Spam-Level: X-Spam-Status: No, score=-3.1 tagged_above=-999 required=5 tests=[AWL=-0.500, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JO7a69iv41Ey for ; Mon, 14 Feb 2011 08:56:45 -0800 (PST) Received: from mx.pao1.isc.org (mx.pao1.isc.org [IPv6:2001:4f8:0:2::2b]) by core3.amsl.com (Postfix) with ESMTP id 0357C3A6A57 for ; Mon, 14 Feb 2011 08:56:45 -0800 (PST) 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 B5CD2C9427; Mon, 14 Feb 2011 16:57:05 +0000 (UTC) (envelope-from woolf@isc.org) Received: by bikeshed.isc.org (Postfix, from userid 10265) id A9D76216C22; Mon, 14 Feb 2011 16:57:05 +0000 (UTC) Date: Mon, 14 Feb 2011 16:57:05 +0000 From: Suzanne Woolf To: Andrew Sullivan Message-ID: <20110214165705.GA76894@bikeshed.isc.org> References: <4D48617E.1020408@ogud.com> <3A5CD55E5CCE43F0BA44AAC89BADB866@ics.forth.gr> <20110211020125.GA147@bikeshed.isc.org> <20110214071047.GA64679@bikeshed.isc.org> <15CC617D3D244626A6B31600701E9A81@ics.forth.gr> <20110214163742.GC71863@shinkuro.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20110214163742.GC71863@shinkuro.com> User-Agent: Mutt/1.4.2.3i Cc: dnsext@ietf.org Subject: Re: [dnsext] draft-yao-dnsext-identical-resolution-02 comment X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 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, 14 Feb 2011 16:56:46 -0000 On Mon, Feb 14, 2011 at 11:37:43AM -0500, Andrew Sullivan wrote: > But in > between those events very little discussion on the topic seems to have > happened. Moreover, when we do have discussion it tends to focus on > existing proposals: "Do BNAME", for instance. But the problem we have > is that we cannot tell whether BNAME (or any other proposal) actually > addresses the particular problems people have. So either we get a > clear and broadly agreed-upon statement of the problem we are trying > to solve, or we don't solve the problem (because if we can't say what > it is, I think that means we don't know). With all due respect, I'm not sure this is the most (or at least only) useful razor for where we are at the moment. I went back and looked at the problem statement draft after being forced to put it aside for other things for some time. What I'm seeing is that it has a couple of examples, and could benefit from more, and needs to more clearly state the potential protocol issues around application awareness, special processing, etc.... But the other thing we haven't talked about much is the actual requirements for solutions. We did once (in Anaheim maybe?) but IIRC only the once. The main piece that the -00 will have that the previous individual submission versions didn't, I think now, will be the list of what we think a solution should look like....not in the protocol details of behavior, I agree we won't know those without finer details of the problems (probably plural) we're talking about....but in the sense of things like: * A solution must not break DNSSEC; * A solution must not (should not?) require client changes to be useful; * A solution must not change existing behavior of established RRtypes and protocol (which would make "fix CNAME" a non-starter); * A solution should clearly either be less work than existing techniques, or solve some specific case (such as the canonicalization of email addresses that Vaggelis mentioned) that isn't otherwise solvable, so there's some incentive for deployment.... * A solution should not be specific to the root zone; etc. best, S. From ajs@shinkuro.com Mon Feb 14 09:40:38 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2B5EA3A6D6D for ; Mon, 14 Feb 2011 09:40:38 -0800 (PST) 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=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wysa2XcCET1g for ; Mon, 14 Feb 2011 09:40:37 -0800 (PST) Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by core3.amsl.com (Postfix) with ESMTP id 4FA8A3A6C99 for ; Mon, 14 Feb 2011 09:40:37 -0800 (PST) Received: from crankycanuck.ca (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 38C401ECB41D for ; Mon, 14 Feb 2011 17:41:00 +0000 (UTC) Date: Mon, 14 Feb 2011 12:40:58 -0500 From: Andrew Sullivan To: dnsext@ietf.org Message-ID: <20110214174058.GD71863@shinkuro.com> References: <4D48617E.1020408@ogud.com> <3A5CD55E5CCE43F0BA44AAC89BADB866@ics.forth.gr> <20110211020125.GA147@bikeshed.isc.org> <20110214071047.GA64679@bikeshed.isc.org> <15CC617D3D244626A6B31600701E9A81@ics.forth.gr> <20110214163742.GC71863@shinkuro.com> <20110214165705.GA76894@bikeshed.isc.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20110214165705.GA76894@bikeshed.isc.org> User-Agent: Mutt/1.5.18 (2008-05-17) Subject: Re: [dnsext] draft-yao-dnsext-identical-resolution-02 comment X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 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, 14 Feb 2011 17:40:38 -0000 No hat On Mon, Feb 14, 2011 at 04:57:05PM +0000, Suzanne Woolf wrote: > But the other thing we haven't talked about much is the actual > requirements for solutions. We did once (in Anaheim maybe?) but IIRC > only the once. Yes, I fully agree. But what that amounts to are parameters for the trade-offs we need to make, and that _again_ requires WG discussion and so on. When the WG doesn't discuss such issues, it makes me think that it isn't that interested. That's all I meant. A -- Andrew Sullivan ajs@shinkuro.com Shinkuro, Inc. From mohta@necom830.hpcl.titech.ac.jp Mon Feb 14 15:49:36 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0A12F3A6DA0 for ; Mon, 14 Feb 2011 15:49:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.257 X-Spam-Level: X-Spam-Status: No, score=-0.257 tagged_above=-999 required=5 tests=[AWL=0.167, BAYES_00=-2.599, GB_I_LETTER=-2, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, SARE_HTML_URI_LHOST31=1.666] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wC-4XRwT86D1 for ; Mon, 14 Feb 2011 15:49:35 -0800 (PST) Received: from necom830.hpcl.titech.ac.jp (necom830.hpcl.titech.ac.jp [131.112.32.132]) by core3.amsl.com (Postfix) with SMTP id D70813A6D7C for ; Mon, 14 Feb 2011 15:49:33 -0800 (PST) Received: (qmail 84909 invoked from network); 14 Feb 2011 23:59:26 -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; 14 Feb 2011 23:59:26 -0000 Message-ID: <4D59BF48.3080705@necom830.hpcl.titech.ac.jp> Date: Tue, 15 Feb 2011 08:48:24 +0900 From: Masataka Ohta User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; ja; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: dnsext@ietf.org References: <4D48617E.1020408@ogud.com> <3A5CD55E5CCE43F0BA44AAC89BADB866@ics.forth.gr> <20110211020125.GA147@bikeshed.isc.org> In-Reply-To: Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit Subject: Re: [dnsext] draft-yao-dnsext-identical-resolution-02 comment X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 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, 14 Feb 2011 23:49:36 -0000 Vaggelis Segredakis wrote: > As the Greek registry, offering registrations in Greek characters presented > the problem with the accent mark "tonos" which is used in the majority of > Greek words. In capital letters however, the same words are spelled without > the tonos. The problem already occurs in ISO 8859/1 with 'y' with diaeresis, upper case of which is plain 'Y' without diaeresis. > Their representation in the Punycode is unfortunately different > and we had to match these up (make similar) for the user, Definitions, such as case correspondence, in Unicode are not definitions useful in the real world, which means Unicode is useless. > We used the DNAME mechanism with not very satisfactory results. Suppose you have a label: YYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYY.com You can match it with: YyYYYyYYYYYYyYYYYyYYYYyYYYyYYyYYYyYYYYYyYYyYYyYyYY.com easily because case correspondence is recognized by DNS protocol. But, if you want to do the same thing with 'y' with diaeresis, you can't do it with predefined BNAME/CNAME/DNAME, because of exponentially many aliases. However, dynamic generation of *NAME causes performance problem with secure DNS. So, you should give up localized DNS, secure DNS or have common definition on extended case insensitivity (not really defined in Unicode) between DNS servers and (security aware) clients. My recommendation is to give up both. > This way we cannot have consistent mappings since we do not know > what the programmer has chosen to do with the upper case > characters, especially in regards to tonos and final sigma. For precise definitions of extended case insensitivity, we need a formal language for extended case insensitivity description. Locale dependent case insensitivity for localized domain names requires locale information somehow supplied through DNS. Masataka Ohta From johnl@iecc.com Tue Feb 15 19:20:58 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1C2C83A6C2D for ; Tue, 15 Feb 2011 19:20:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -111.199 X-Spam-Level: X-Spam-Status: No, score=-111.199 tagged_above=-999 required=5 tests=[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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4Q2UNiNaS1cE for ; Tue, 15 Feb 2011 19:20:56 -0800 (PST) Received: from gal.iecc.com (gal.iecc.com [64.57.183.53]) by core3.amsl.com (Postfix) with ESMTP id AE22E3A6B77 for ; Tue, 15 Feb 2011 19:20:55 -0800 (PST) Received: (qmail 42053 invoked from network); 16 Feb 2011 03:21:21 -0000 Received: from mail1.iecc.com (64.57.183.56) by mail1.iecc.com with QMQP; 16 Feb 2011 03:21:21 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:subject:in-reply-to:cc:mime-version:content-type:content-transfer-encoding:vbr-info; s=a9d3.4d5b42b0.k1102; i=johnl@user.iecc.com; bh=n/8YrJuU3v7JbAnMIivIuxZtorsXMj4ejssVTOyen+8=; b=LUQBlhbJwCz137zPmoe+fHHsbgirbecDrHgIB05yRjMYWg364S0NPV6oM7yr54RGzWZXaN5O+RkzRWCtSGvIW5OqkbK6Ek5joCnHFCCq7r/fIDpU764VtotiqAntc7VKhkmW98nApKamOzIcf4MqoNtVpXUJYWc/cKQu8KoTIsA= VBR-Info: md=iecc.com; mc=all; mv=dwl.spamhaus.org Date: 16 Feb 2011 03:21:20 -0000 Message-ID: <20110216032120.43474.qmail@joyce.lan> From: John Levine To: dnsext@ietf.org In-Reply-To: <20110214165705.GA76894@bikeshed.isc.org> Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 7bit Subject: Re: [dnsext] we need help to make names the same, was draft-yao-dnsext-identical-resolution-02 comment X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 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, 16 Feb 2011 03:20:58 -0000 >* A solution must not (should not?) require client changes to be useful; To me this is the key issue. If you just want something that will return similar DNS records for all of variants of a name, the technical issues are pretty straightforward. But as has often been noted, many protocols such as HTTP and SMTP depend on the actual domain name, so nothing the DNS does to make stuff "the same" will make variants of a domain name work. Considering the number of variants that a name can have, e.g., M^N for any name with N characters that have M variants, any approach that provisions the HTTP and SMTP servers manually is likely to fail in practice, since the various lists of equivalent domains will always get out of sync. It would not be absurd to argue that the most reasonable way to solve the provisioning issues is for the SMTP and HTTP servers to ask the DNS what the canonical name for an otherwise unknown name is, so those servers are just provisioned with the canonical name and an "allow variants" flag. I'm pretty tight with the SMTP crowd, and I have no idea how such a proposal would be received, although once they understand the problem, I suspect they'd eventually agree this was the least bad option. No idea what HTTP and any other protocols that use the domain name would do, but I think it's the reasonable approach. Regards, John Levine, johnl@iecc.com, Primary Perpetrator of "The Internet for Dummies", Please consider the environment before reading this e-mail. http://jl.ly From jra@baylink.com Tue Feb 15 20:17:05 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AE4F43A6D23 for ; Tue, 15 Feb 2011 20:17:05 -0800 (PST) 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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cUnfWZw1knoj for ; Tue, 15 Feb 2011 20:17:05 -0800 (PST) Received: from hrndva-omtalb.mail.rr.com (hrndva-omtalb.mail.rr.com [71.74.56.125]) by core3.amsl.com (Postfix) with ESMTP id CC1623A6CD1 for ; Tue, 15 Feb 2011 20:17:04 -0800 (PST) X-Authority-Analysis: v=1.1 cv=dquaJDitHqzHCdqWSoZ6IgapSuTzW/4TaRYx9N9k4W8= c=1 sm=0 a=SnqA-C_CkNwA:10 a=FKkrIqjQGGEA:10 a=Xve_KQuntz4A:10 a=wPDyFdB5xvgA:10 a=IkcTkHD0fZMA:10 a=QDKGtjV+XQz2PzAlwL4sQw==:17 a=3DW5ysfuAAAA:8 a=fAb-cvdhe0lY3sdcGIIA:9 a=o1FYIOhP8hwyg9pv7Wc_EBzMREsA:4 a=QEXdDO2ut3YA:10 a=2SAumGWBsQEA:10 a=QDKGtjV+XQz2PzAlwL4sQw==:117 X-Cloudmark-Score: 0 X-Originating-IP: 24.129.180.187 Received: from [24.129.180.187] ([24.129.180.187:54887] helo=benjamin.baylink.com) by hrndva-oedge01.mail.rr.com (envelope-from ) (ecelerity 2.2.3.46 r()) with ESMTP id 1C/29-14011-BDF4B5D4; Wed, 16 Feb 2011 04:17:31 +0000 Received: from localhost (localhost.localdomain [127.0.0.1]) by benjamin.baylink.com (Postfix) with ESMTP id 491701F0012C for ; Tue, 15 Feb 2011 23:17:49 -0500 (EST) X-Virus-Scanned: amavisd-new at benjamin.baylink.com Received: from benjamin.baylink.com ([127.0.0.1]) by localhost (benjamin.baylink.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EuhQ+lF+wYgj for ; Tue, 15 Feb 2011 23:17:48 -0500 (EST) Received: from benjamin.baylink.com (benjamin.baylink.com [192.168.253.10]) by benjamin.baylink.com (Postfix) with ESMTP id 81AD81F000F0 for ; Tue, 15 Feb 2011 23:17:48 -0500 (EST) Date: Tue, 15 Feb 2011 23:17:48 -0500 (EST) From: Jay Ashworth To: dnsext@ietf.org Message-ID: <32007060.266.1297829868445.JavaMail.root@benjamin.baylink.com> In-Reply-To: <20110216032120.43474.qmail@joyce.lan> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Mailer: Zimbra 6.0.9_GA_2686 (ZimbraWebClient - FF3.0 (Linux)/6.0.9_GA_2686) Subject: Re: [dnsext] we need help to make names the same, was draft-yao-dnsext-identical-resolution-02 comment X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 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, 16 Feb 2011 04:17:05 -0000 ----- Original Message ----- > From: "John Levine" > But as has often been noted, many protocols such as HTTP and SMTP > depend on the actual domain name, so nothing the DNS does to make > stuff "the same" will make variants of a domain name work. > Considering the number of variants that a name can have, e.g., M^N for > any name with N characters that have M variants, any approach that > provisions the HTTP and SMTP servers manually is likely to fail in > practice, since the various lists of equivalent domains will always > get out of sync. And, as has been pointed out in some other venues, and which seems applicable here also, some approachs to certain things *depend on trying a DNS lookup and having it break*. I'm damned if I can remember what the canonical example was, but it fell in the general category of "please don't make this change to try to 'help' 'the web', cause you'll break *my* protocol which isn't http". Cheers, -- jra From mohta@necom830.hpcl.titech.ac.jp Tue Feb 15 21:20:34 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 753413A6CBD for ; Tue, 15 Feb 2011 21:20:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.174 X-Spam-Level: X-Spam-Status: No, score=-0.174 tagged_above=-999 required=5 tests=[AWL=-0.084, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ehFq9R7VfJnX for ; Tue, 15 Feb 2011 21:20:33 -0800 (PST) Received: from necom830.hpcl.titech.ac.jp (necom830.hpcl.titech.ac.jp [131.112.32.132]) by core3.amsl.com (Postfix) with SMTP id 708353A6B8E for ; Tue, 15 Feb 2011 21:20:33 -0800 (PST) Received: (qmail 31619 invoked from network); 16 Feb 2011 05:30:49 -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; 16 Feb 2011 05:30:49 -0000 Message-ID: <4D5B5E81.1050602@necom830.hpcl.titech.ac.jp> Date: Wed, 16 Feb 2011 14:20:01 +0900 From: Masataka Ohta User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; ja; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: dnsext@ietf.org References: <20110216032120.43474.qmail@joyce.lan> In-Reply-To: <20110216032120.43474.qmail@joyce.lan> Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit Subject: Re: [dnsext] we need help to make names the same, was draft-yao-dnsext-identical-resolution-02 comment X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 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, 16 Feb 2011 05:20:34 -0000 John Levine wrote: >> * A solution must not (should not?) require client changes to be useful; > > To me this is the key issue. So true. Clients should have remained as they were only allowing ASCII domain names. > It would not be absurd to argue that the most reasonable way to solve > the provisioning issues is for the SMTP and HTTP servers to ask the > DNS what the canonical name for an otherwise unknown name is, Are you requesting DNS hold huge database on exponentially many (millions or billions of) variations? Masataka Ohta From johnl@iecc.com Tue Feb 15 23:33:14 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8964D3A6DCC for ; Tue, 15 Feb 2011 23:33:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -111.198 X-Spam-Level: X-Spam-Status: No, score=-111.198 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HABEAS_ACCREDITED_SOI=-4.3, OBSCURED_EMAIL=0.001, RCVD_IN_BSP_TRUSTED=-4.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r+LmuAB8ck96 for ; Tue, 15 Feb 2011 23:33:13 -0800 (PST) Received: from gal.iecc.com (gal.iecc.com [64.57.183.53]) by core3.amsl.com (Postfix) with ESMTP id 2455E3A6DC6 for ; Tue, 15 Feb 2011 23:33:12 -0800 (PST) Received: (qmail 2354 invoked from network); 16 Feb 2011 07:33:39 -0000 Received: from mail1.iecc.com (64.57.183.56) by mail1.iecc.com with QMQP; 16 Feb 2011 07:33:39 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:subject:in-reply-to:cc:mime-version:content-type:content-transfer-encoding:vbr-info; s=1c54.4d5b7dd2.k1102; i=johnl@user.iecc.com; bh=z2prUk/idHclV8rDHe8uqF5WPOavXGXnxrwQ9gpCS60=; b=CNcRZygGtEr868wB/tEwh0NUwF262xTGRcLmMQpSt91LTi/C4Ox+0QxQ6+24PYrne3P9I7aGkXwHaJmbIVCbIB16AbUZBK8oHS1WwySYONmTHMucyPUlGhMwEr73tApmdBkdxHyq9RmEGQMcsnlXeeL5yQs8vbLFpbQGGmaBsv4= VBR-Info: md=iecc.com; mc=all; mv=dwl.spamhaus.org Date: 16 Feb 2011 07:33:38 -0000 Message-ID: <20110216073338.7251.qmail@joyce.lan> From: John Levine To: dnsext@ietf.org In-Reply-To: <4D5B5E81.1050602@necom830.hpcl.titech.ac.jp> Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 7bit Subject: Re: [dnsext] we need help to make names the same, was draft-yao-dnsext-identical-resolution-02 comment X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 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, 16 Feb 2011 07:33:14 -0000 >Are you requesting DNS hold huge database on exponentially many >(millions or billions of) variations? Yes, but of course that does not mean it needs millions or billions of records stored in servers. A DNS wildcard matches a very large number of names, roughly 2^(8*(63-K)) where K is the length of the name after the star, but a DNS server handles that with one pattern record and an algorithm that tells the server how to match queries with the pattern. The pattern language for encoding variant names would probably be more complex than people would like, but if we are serious that all the spellings of Greek words are equivalent, or traditional and simplified Chinese are equivalent, I don't see how anything simpler could do the job. Regards, John Levine, johnl@iecc.com, Primary Perpetrator of "The Internet for Dummies", Please consider the environment before reading this e-mail. http://jl.ly From alex@alex.org.uk Tue Feb 15 23:43:07 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 923FF3A6DD4 for ; Tue, 15 Feb 2011 23:43:07 -0800 (PST) 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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ylNtc7iFBZNX for ; Tue, 15 Feb 2011 23:43:05 -0800 (PST) Received: from mail.avalus.com (mail.avalus.com [89.16.176.221]) by core3.amsl.com (Postfix) with ESMTP id 735843A6DD9 for ; Tue, 15 Feb 2011 23:43:05 -0800 (PST) Received: from [10.93.101.159] (87-194-71-186.bethere.co.uk [87.194.71.186]) by mail.avalus.com (Postfix) with ESMTPSA id 5A7DBC5641A; Wed, 16 Feb 2011 07:43:31 +0000 (GMT) Date: Wed, 16 Feb 2011 07:43:30 +0000 From: Alex Bligh To: John Levine , dnsext@ietf.org Message-ID: In-Reply-To: <20110216073338.7251.qmail@joyce.lan> References: <20110216073338.7251.qmail@joyce.lan> 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 Subject: Re: [dnsext] we need help to make names the same, was draft-yao-dnsext-identical-resolution-02 comment X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 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, 16 Feb 2011 07:43:07 -0000 --On 16 February 2011 07:33:38 +0000 John Levine wrote: > The pattern language for encoding variant names would probably be more > complex than people would like, but if we are serious that all the > spellings of Greek words are equivalent, or traditional and simplified > Chinese are equivalent, I don't see how anything simpler could do the > job. The fact that 2 or more spellings (*) are equivalent does not necessarily mean both always need to give the same DNS results; indeed as much trailed previously, this may be undesirable. I still think this is the wrong "job" to do, so the fact this is might be simplest way of doing something undesirable is not really a positive. However, except in the cases of combinatorial explosion, manual provisioning would seem to be far simpler. (*) I think it's really about orthographic representation rather than spelling: we aren't really talking about jail.com and gaol.com, are we? -- Alex Bligh From johnl@iecc.com Wed Feb 16 00:01:56 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 284CD3A68A3 for ; Wed, 16 Feb 2011 00:01:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -111.199 X-Spam-Level: X-Spam-Status: No, score=-111.199 tagged_above=-999 required=5 tests=[AWL=0.000, 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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WF1LOvnsxUqJ for ; Wed, 16 Feb 2011 00:01:53 -0800 (PST) Received: from gal.iecc.com (gal.iecc.com [64.57.183.53]) by core3.amsl.com (Postfix) with ESMTP id 18A113A6DBC for ; Wed, 16 Feb 2011 00:01:53 -0800 (PST) Received: (qmail 11645 invoked from network); 16 Feb 2011 08:02:19 -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=2d7a.4d5b848b.k1102; i=johnl@submit.iecc.com; bh=H+425fZE0uFk4Ss4znaBrkcz/IfBYKozEv698CssJpI=; b=l6aQw/Xh7PgTUn0aVIz3GQlgpI/wfFmUZwXKIZL476Un8iQsEw9NSn/EwoLvsUiuvLHWOdx/Wit+qESvf/cJe929C9F8orI8cxfbe5a+q1C/9cHcNteJulMBtqUazimnWD28fiqoDqbtCj9gkJxkMh2ayTfHQeJIRriQ4lDUeQE= VBR-Info: md=iecc.com; mc=all; mv=dwl.spamhaus.org Received: (ofmipd johnl@64.57.183.62) with (DHE-RSA-AES256-SHA encrypted) SMTP; 16 Feb 2011 08:01:57 -0000 Date: 16 Feb 2011 00:02:15 -0800 Message-ID: From: "John R. Levine" To: "Alex Bligh" In-Reply-To: References: <20110216073338.7251.qmail@joyce.lan> 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] we need help to make names the same, was draft-yao-dnsext-identical-resolution-02 comment X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 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, 16 Feb 2011 08:01:56 -0000 > However, except in the cases of combinatorial explosion, manual > provisioning would seem to be far simpler. I think you will find that combinatorial explosion is the norm, not the exception, in cases where you want multiple names to be equivalent. Or if it's not the rule, it is common enough that any attempted solution that doesn't handle large sets of equivalent names isn't good enough to be worth doing. I also have a general dislike of any design that requires two things to be kept in sync manually, with random failures if they're not. If a set of names really is all equivalent, wouldn't it be better in the long run for people to configure the set once rather than once per server? Regards, John Levine, johnl@iecc.com, Primary Perpetrator of "The Internet for Dummies", Please consider the environment before reading this e-mail. http://jl.ly From mohta@necom830.hpcl.titech.ac.jp Wed Feb 16 00:05:19 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 808A03A6B6B for ; Wed, 16 Feb 2011 00:05:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.132 X-Spam-Level: X-Spam-Status: No, score=-0.132 tagged_above=-999 required=5 tests=[AWL=-0.042, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G4iR-E95BhjL for ; Wed, 16 Feb 2011 00:05:18 -0800 (PST) Received: from necom830.hpcl.titech.ac.jp (necom830.hpcl.titech.ac.jp [131.112.32.132]) by core3.amsl.com (Postfix) with SMTP id 7738C3A68A3 for ; Wed, 16 Feb 2011 00:05:18 -0800 (PST) Received: (qmail 36237 invoked from network); 16 Feb 2011 08:15:51 -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; 16 Feb 2011 08:15:51 -0000 Message-ID: <4D5B8529.8030509@necom830.hpcl.titech.ac.jp> Date: Wed, 16 Feb 2011 17:04:57 +0900 From: Masataka Ohta User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; ja; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: John Levine References: <20110216073338.7251.qmail@joyce.lan> In-Reply-To: <20110216073338.7251.qmail@joyce.lan> Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit Cc: dnsext@ietf.org Subject: Re: [dnsext] we need help to make names the same, was draft-yao-dnsext-identical-resolution-02 comment X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 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, 16 Feb 2011 08:05:19 -0000 John Levine wrote: > The pattern language for encoding variant names would probably be more > complex than people would like, but if we are serious that all the > spellings of Greek words are equivalent, or traditional and simplified > Chinese are equivalent, I don't see how anything simpler could do the > job. I'm happy that you seems to have reached the same conclusion as mine: : For precise definitions of extended case insensitivity, we need : a formal language for extended case insensitivity description. But, then, the issue is purely about character encoding which is better handled by clients outside of DNS. Note that people working on secure DNS (I'm not) won't welcome proposals to support yet another type of wild card. Or, if you think pattern should be locale dependent, I agree that its support must involve DNS protocol. Locale information must be supplied from DNS, at least. Masataka Ohta From alex@alex.org.uk Wed Feb 16 00:35:00 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CEDB93A6DE4 for ; Wed, 16 Feb 2011 00:35:00 -0800 (PST) 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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bmQA0F-LgJbu for ; Wed, 16 Feb 2011 00:34:59 -0800 (PST) Received: from mail.avalus.com (mail.avalus.com [89.16.176.221]) by core3.amsl.com (Postfix) with ESMTP id 0AC293A6B5F for ; Wed, 16 Feb 2011 00:34:58 -0800 (PST) Received: from [10.93.101.159] (87-194-71-186.bethere.co.uk [87.194.71.186]) by mail.avalus.com (Postfix) with ESMTPSA id 93082C5641A; Wed, 16 Feb 2011 08:35:24 +0000 (GMT) Date: Wed, 16 Feb 2011 08:35:23 +0000 From: Alex Bligh To: "John R. Levine" Message-ID: In-Reply-To: References: <20110216073338.7251.qmail@joyce.lan> 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] we need help to make names the same, was draft-yao-dnsext-identical-resolution-02 comment X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 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, 16 Feb 2011 08:35:01 -0000 --On 16 February 2011 00:02:15 -0800 "John R. Levine" wrote: > If a set of names really is all equivalent, wouldn't it be better in the > long run for people to configure the set once rather than once per server? I think we've been round this loop and determined that for most/many applications there is /still/ manual configuration (see SSL cert DN for example). An alternative would be to do this at a higher presentation layer (e.g. the search engine), and cope with the fact that despite there being >1 equivalent representation, there is a smaller number of canonical ones (perhaps one) that work. I'm not convinced alex-bligh.com and alexbligh.com are not equivalent - or for that matter alex.bligh.com; just because I get one to work, it doesn't mean the others work automatically. -- Alex Bligh From fanf2@hermes.cam.ac.uk Wed Feb 16 03:55:36 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1A7783A6CA7 for ; Wed, 16 Feb 2011 03:55:36 -0800 (PST) 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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2x6EkPug1Ljy for ; Wed, 16 Feb 2011 03:55:31 -0800 (PST) Received: from ppsw-51.csi.cam.ac.uk (ppsw-51.csi.cam.ac.uk [131.111.8.151]) by core3.amsl.com (Postfix) with ESMTP id 63E453A6E07 for ; Wed, 16 Feb 2011 03:55:31 -0800 (PST) X-Cam-AntiVirus: no malware found X-Cam-SpamDetails: not scanned X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ Received: from hermes-1.csi.cam.ac.uk ([131.111.8.51]:33740) by ppsw-51.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.158]:25) with esmtpa (EXTERNAL:fanf2) id 1PpfzB-0005MY-WL (Exim 4.72) (return-path ); Wed, 16 Feb 2011 11:55:57 +0000 Received: from fanf2 (helo=localhost) by hermes-1.csi.cam.ac.uk (hermes.cam.ac.uk) with local-esmtp id 1PpfzB-000849-0P (Exim 4.67) (return-path ); Wed, 16 Feb 2011 11:55:57 +0000 Date: Wed, 16 Feb 2011 11:55:57 +0000 From: Tony Finch X-X-Sender: fanf2@hermes-1.csi.cam.ac.uk To: John Levine In-Reply-To: <20110216032120.43474.qmail@joyce.lan> Message-ID: References: <20110216032120.43474.qmail@joyce.lan> User-Agent: Alpine 2.00 (LSU 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: Tony Finch Cc: dnsext@ietf.org Subject: Re: [dnsext] we need help to make names the same, was draft-yao-dnsext-identical-resolution-02 comment X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 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, 16 Feb 2011 11:55:36 -0000 On Wed, 16 Feb 2011, John Levine wrote: > > It would not be absurd to argue that the most reasonable way to solve > the provisioning issues is for the SMTP and HTTP servers to ask the > DNS what the canonical name for an otherwise unknown name is, so those > servers are just provisioned with the canonical name and an "allow > variants" flag. It used to be the case that SMTP servers would rewrite domains in addresses by replacing a CNAME owner with its target. See RFC 1123 section 5.2.2. This requirement no longer exists but there is still code out there that supports it. I think it would be quite reasonable to add a feature for optional cname-based canonicalization to an MTA. (You can probably do it now using Exim's configuration language, though it'll probably be a bit ugly.) There is also some HTTP server code out there that hooks into the DNS for server name canonicalization - see Apache's UseCanonicalName DNS option, which is my fault. It uses reverse DNS lookups (it was designed for IP-based virtual hosting) but I don't think it would be hard to do something similar based on CNAME records. Note that server features like this are nice to have but not absolutely necessary. Tony. -- f.anthony.n.finch http://dotat.at/ HUMBER THAMES DOVER WIGHT PORTLAND: NORTH BACKING WEST OR NORTHWEST, 5 TO 7, DECREASING 4 OR 5, OCCASIONALLY 6 LATER IN HUMBER AND THAMES. MODERATE OR ROUGH. RAIN THEN FAIR. GOOD. From mohta@necom830.hpcl.titech.ac.jp Wed Feb 16 05:22:29 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 811993A6CB8 for ; Wed, 16 Feb 2011 05:22:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.123 X-Spam-Level: X-Spam-Status: No, score=-0.123 tagged_above=-999 required=5 tests=[AWL=-0.033, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5TdVm3h2DWWD for ; Wed, 16 Feb 2011 05:22:28 -0800 (PST) Received: from necom830.hpcl.titech.ac.jp (necom830.hpcl.titech.ac.jp [131.112.32.132]) by core3.amsl.com (Postfix) with SMTP id 798BC3A6B74 for ; Wed, 16 Feb 2011 05:22:27 -0800 (PST) Received: (qmail 47658 invoked from network); 16 Feb 2011 13:32: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; 16 Feb 2011 13:32:43 -0000 Message-ID: <4D5BCF70.90104@necom830.hpcl.titech.ac.jp> Date: Wed, 16 Feb 2011 22:21:52 +0900 From: Masataka Ohta User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; ja; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: dnsext@ietf.org References: <20110216073338.7251.qmail@joyce.lan> In-Reply-To: Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit Subject: Re: [dnsext] we need help to make names the same, was draft-yao-dnsext-identical-resolution-02 comment X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 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, 16 Feb 2011 13:22:29 -0000 John R. Levine wrote: > I also have a general dislike of any design that requires two things to > be kept in sync manually, with random failures if they're not. If a set > of names really is all equivalent, wouldn't it be better in the long run > for people to configure the set once rather than once per server? Equivalence rule must run very long, maybe forever. Or, if the rule is not stable, we shouldn't start registration only to cause conflicts between registered names before and after rule changes. With the stable rule in hand, we can expect the rule configured in factory on all clients. The problem, of course, is how can we have the stable rule. Masataka Ohta From mohta@necom830.hpcl.titech.ac.jp Wed Feb 16 06:05:58 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EA81A3A6CC8 for ; Wed, 16 Feb 2011 06:05:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.118 X-Spam-Level: X-Spam-Status: No, score=-0.118 tagged_above=-999 required=5 tests=[AWL=-0.028, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KcVuKtrDJhmY for ; Wed, 16 Feb 2011 06:05:58 -0800 (PST) Received: from necom830.hpcl.titech.ac.jp (necom830.hpcl.titech.ac.jp [131.112.32.132]) by core3.amsl.com (Postfix) with SMTP id CFB3A3A6CA7 for ; Wed, 16 Feb 2011 06:05:57 -0800 (PST) Received: (qmail 49282 invoked from network); 16 Feb 2011 14:16:12 -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; 16 Feb 2011 14:16:12 -0000 Message-ID: <4D5BD99F.1010804@necom830.hpcl.titech.ac.jp> Date: Wed, 16 Feb 2011 23:05:19 +0900 From: Masataka Ohta User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; ja; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: dnsext@ietf.org References: <20110216032120.43474.qmail@joyce.lan> In-Reply-To: Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit Subject: Re: [dnsext] we need help to make names the same, was draft-yao-dnsext-identical-resolution-02 comment X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 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, 16 Feb 2011 14:05:59 -0000 Tony Finch wrote: > I think it would be quite reasonable to add a feature > for optional cname-based canonicalization to an MTA. It does not address the exponential explosions. Worse, it requires CNAME target canonicalized, which practically means canonicalization by hand. Masataka Ohta From segred@ics.forth.gr Wed Feb 16 06:38:16 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C431C3A6D1B for ; Wed, 16 Feb 2011 06:38:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.43 X-Spam-Level: X-Spam-Status: No, score=-6.43 tagged_above=-999 required=5 tests=[AWL=-0.747, BAYES_00=-2.599, J_CHICKENPOX_43=0.6, OBSCURED_EMAIL=0.001, RCVD_IN_DNSWL_MED=-4, SARE_MILLIONSOF=0.315] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QyeTGQoLxquQ for ; Wed, 16 Feb 2011 06:38:15 -0800 (PST) Received: from mailgate.ics.forth.gr (mailgate.ics.forth.gr [139.91.1.2]) by core3.amsl.com (Postfix) with ESMTP id AB3293A6E41 for ; Wed, 16 Feb 2011 06:38:14 -0800 (PST) Received: from av1.ics.forth.gr (av1-in.ics.forth.gr [139.91.1.71]) by mailgate.ics.forth.gr (8.14.3/ICS-FORTH/V10-1.8-GATE) with ESMTP id p1GEcZQs005043; Wed, 16 Feb 2011 16:38:37 +0200 (EET) X-AuditID: 8b5b9d47-b7c88ae0000076fe-1a-4d5be16b8de9 Received: from enigma.ics.forth.gr (webmail.ics.forth.gr [139.91.1.30]) by av1.ics.forth.gr (SMTP Outbound / FORTH / ICS) with SMTP id F2.B0.30462.B61EB5D4; Wed, 16 Feb 2011 16:38:35 +0200 (EET) Received: from Thanatos (thanatos.ics.forth.gr [139.91.88.160]) (authenticated bits=0) by enigma.ics.forth.gr (8.14.3//ICS-FORTH/V10.3.0C-EXTNULL-SSL-SASL) with ESMTP id p1GEcWfg021371 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Wed, 16 Feb 2011 16:38:34 +0200 X-ICS-AUTH-INFO: Authenticated user: segred at ics.forth.gr From: "Vaggelis Segredakis" To: "'John Levine'" , References: <4D5B5E81.1050602@necom830.hpcl.titech.ac.jp> <20110216073338.7251.qmail@joyce.lan> Date: Wed, 16 Feb 2011 16:37:13 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <20110216073338.7251.qmail@joyce.lan> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5994 Thread-Index: AcvNq+SvJtqrypE5REiZwh7oDao8lQAN4MiQ X-Brightmail-Tracker: AAAAAA== X-j-chkmail-Score: MSGID : 4D5BE16B.000 on mailgate : j-chkmail score : . : R=. U=. O=. B=0.000 -> S=0.000 X-ICS-JCHK-SCL: Ham Subject: Re: [dnsext] we need help to make names the same, was draft-yao-dnsext-identical-resolution-02 comment X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 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, 16 Feb 2011 14:38:16 -0000 John, Please do not misunderstand the issue here. We did not ask for a wildcard in DNS, we did not ask for millions of domain names to become one bundle. We did however ask for the user's choice of registered domain names, the names he thinks represent better the word he chose for registration to act as a bundle. The number of these domain names varies from two (or four if a final sigma is present) to some tens of domains, not millions and certainly not billions. The names are specific, not names with star-substituted characters; just handpicked domain names by the user that should point to the same services since one user will type them this way while the next user will type them in an alternative form. We did not say anything about a pattern to match domain names that look the same in a language. We asked for a DNS rr that will allow two, three, four, or tens of chosen domain names to act as if they were interchangeable in all the branches of the domain name tree, starting from the top. They could be perfectly normal Latin domain names that point to the same services and the administrator decides to administer them as one. Kind Regards, Vaggelis Segredakis -----Original Message----- From: dnsext-bounces@ietf.org [mailto:dnsext-bounces@ietf.org] On Behalf Of John Levine Sent: Wednesday, February 16, 2011 9:34 AM To: dnsext@ietf.org Subject: Re: [dnsext] we need help to make names the same,was draft-yao-dnsext-identical-resolution-02 comment >Are you requesting DNS hold huge database on exponentially many >(millions or billions of) variations? Yes, but of course that does not mean it needs millions or billions of records stored in servers. A DNS wildcard matches a very large number of names, roughly 2^(8*(63-K)) where K is the length of the name after the star, but a DNS server handles that with one pattern record and an algorithm that tells the server how to match queries with the pattern. The pattern language for encoding variant names would probably be more complex than people would like, but if we are serious that all the spellings of Greek words are equivalent, or traditional and simplified Chinese are equivalent, I don't see how anything simpler could do the job. Regards, John Levine, johnl@iecc.com, Primary Perpetrator of "The Internet for Dummies", Please consider the environment before reading this e-mail. http://jl.ly _______________________________________________ dnsext mailing list dnsext@ietf.org https://www.ietf.org/mailman/listinfo/dnsext From ajs@shinkuro.com Wed Feb 16 08:58:57 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5F9043A6C9F for ; Wed, 16 Feb 2011 08:58:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.442 X-Spam-Level: X-Spam-Status: No, score=-102.442 tagged_above=-999 required=5 tests=[AWL=-0.158, BAYES_00=-2.599, SARE_MILLIONSOF=0.315, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C7F9vbV65jo0 for ; Wed, 16 Feb 2011 08:58:56 -0800 (PST) Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by core3.amsl.com (Postfix) with ESMTP id 226033A6C8F for ; Wed, 16 Feb 2011 08:58:56 -0800 (PST) Received: from crankycanuck.ca (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 A6EC01ECB420 for ; Wed, 16 Feb 2011 16:59:23 +0000 (UTC) Date: Wed, 16 Feb 2011 11:59:21 -0500 From: Andrew Sullivan To: dnsext@ietf.org Message-ID: <20110216165921.GW96213@shinkuro.com> References: <4D5B5E81.1050602@necom830.hpcl.titech.ac.jp> <20110216073338.7251.qmail@joyce.lan> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.18 (2008-05-17) Subject: Re: [dnsext] we need help to make names the same, was draft-yao-dnsext-identical-resolution-02 comment X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 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, 16 Feb 2011 16:58:57 -0000 On Wed, Feb 16, 2011 at 04:37:13PM +0200, Vaggelis Segredakis wrote: > John, > > Please do not misunderstand the issue here. We did not ask for a wildcard in > DNS, we did not ask for millions of domain names to become one bundle. > > We did however ask for the user's choice of registered domain names, the > names he thinks represent better the word he chose for registration to act > as a bundle. As a matter of _protocol_, however, what you asked for devolves to "more than two". Once we're at that point, the size of the set doesn't really matter except for the question of where the trade-off will be for performance reasons. Moreover, you're not the only one asking. This is certainly not a WG devoted to solving the problem of how to make things easier for the .gr registry. Whatever we do has to be a significant improvement for many different kinds of uses, or it's not worth changing the protocol, even if that means you lose. Sorry. A -- Andrew Sullivan ajs@shinkuro.com Shinkuro, Inc. From ajs@shinkuro.com Wed Feb 16 09:14:06 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1759D3A6EA3 for ; Wed, 16 Feb 2011 09:14:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.589 X-Spam-Level: X-Spam-Status: No, score=-102.589 tagged_above=-999 required=5 tests=[AWL=0.010, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WVsCBcJYdBJX for ; Wed, 16 Feb 2011 09:14:04 -0800 (PST) Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by core3.amsl.com (Postfix) with ESMTP id 89C4B3A6E16 for ; Wed, 16 Feb 2011 09:14:04 -0800 (PST) Received: from crankycanuck.ca (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 C4C5E1ECB420 for ; Wed, 16 Feb 2011 17:14:32 +0000 (UTC) Date: Wed, 16 Feb 2011 12:14:30 -0500 From: Andrew Sullivan To: dnsext@ietf.org Message-ID: <20110216171430.GX96213@shinkuro.com> References: <20110216073338.7251.qmail@joyce.lan> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.18 (2008-05-17) Subject: Re: [dnsext] we need help to make names the same, was draft-yao-dnsext-identical-resolution-02 comment X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 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, 16 Feb 2011 17:14:06 -0000 On Wed, Feb 16, 2011 at 07:43:30AM +0000, Alex Bligh wrote: > (*) I think it's really about orthographic representation rather than > spelling: we aren't really talking about jail.com and gaol.com, are > we? As co-chair but without having discussed with Olafur: We are talking about whatever zone administrators want to be equivalent, I think. This absolutely is not, no way, the DNS and Linguistic Harmony Extenions Working Group. We are not well enough versed in the linguistic differences between two different spellings "in English" and the two scripts that are used to write Chinese for us to begin to make decisions on the basis of that sort of distinction. No hat: One of the possibilities I think could come of the requirements assessment is that something new is needed: the desires that people have for locale-sensitive representations in the naming system on the Internet perhaps simply cannot be accommodated in the actual DNS as it is deployed and can realistically be modified. This amounts to saying, "We are at the end of incremental improvements of this sort for the DNS, and if people want new features, they have to go invent DNSng." That is a legitimate possible answer if we look very hard at the problems we are trying to solve, even if we don't like it. This is why I, at least, have been adamant that we need a problem statement before we start trying to solve the problem. It would be a bad thing to add a bunch of complications that don't actually address the real problems. This is also why I have been so unhappy that we have attracted little interest from the applications area crowd, who will have to use anything we end up delivering. If we can't tell whether what we are talking about looks like a real problem to (say) web browser writers, how will we know whether what we propose to do is going to have any effect? A -- Andrew Sullivan ajs@shinkuro.com Shinkuro, Inc. From lconroy@insensate.co.uk Wed Feb 16 09:23:09 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 01AB73A6D60 for ; Wed, 16 Feb 2011 09:23:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.442 X-Spam-Level: X-Spam-Status: No, score=-2.442 tagged_above=-999 required=5 tests=[AWL=-0.158, BAYES_00=-2.599, SARE_MILLIONSOF=0.315] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Rn-+BOjfciNc for ; Wed, 16 Feb 2011 09:23:08 -0800 (PST) Received: from insensate.co.uk (ghost.insensate.co.uk [213.152.49.121]) by core3.amsl.com (Postfix) with ESMTP id 7F7493A6CB7 for ; Wed, 16 Feb 2011 09:23:07 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by insensate.co.uk (Postfix) with ESMTP id BB871171BBF; Wed, 16 Feb 2011 17:23:34 +0000 (GMT) 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 T+aocgeqJX6g; Wed, 16 Feb 2011 17:23:33 +0000 (GMT) Received: from [127.0.0.1] (localhost [127.0.0.1]) by insensate.co.uk (Postfix) with ESMTP id BB1EC171BB4; Wed, 16 Feb 2011 17:23:33 +0000 (GMT) Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Lawrence Conroy In-Reply-To: <20110216165921.GW96213@shinkuro.com> Date: Wed, 16 Feb 2011 17:23:33 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: <3B90ED2E-980D-4B01-889F-447D66D0B58D@insensate.co.uk> References: <4D5B5E81.1050602@necom830.hpcl.titech.ac.jp> <20110216073338.7251.qmail@joyce.lan> <20110216165921.GW96213@shinkuro.com> To: Andrew Sullivan X-Mailer: Apple Mail (2.1082) Cc: dnsext@ietf.org Subject: Re: [dnsext] we need help to make names the same, was draft-yao-dnsext-identical-resolution-02 comment X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 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, 16 Feb 2011 17:23:09 -0000 On 16 Feb 2011, at 16:59, Andrew Sullivan wrote: > On Wed, Feb 16, 2011 at 04:37:13PM +0200, Vaggelis Segredakis wrote: >> John, >>=20 >> Please do not misunderstand the issue here. We did not ask for a = wildcard in >> DNS, we did not ask for millions of domain names to become one = bundle. >>=20 >> We did however ask for the user's choice of registered domain names, = the >> names he thinks represent better the word he chose for registration = to act >> as a bundle. >=20 > As a matter of _protocol_, however, what you asked for devolves to > "more than two". Once we're at that point, the size of the set > doesn't really matter except for the question of where the trade-off > will be for performance reasons. >=20 > Moreover, you're not the only one asking. This is certainly not a WG > devoted to solving the problem of how to make things easier for the > .gr registry. Whatever we do has to be a significant improvement for > many different kinds of uses, or it's not worth changing the protocol, > even if that means you lose. Sorry. >=20 > A To which I reply: In principle, universal solutions trump narrow solutions that cover = fewer use cases. BUT ... So far, this thread has touched on/drifted towards VERY difficult = problems, with alleged combinatorial explosions and other evils. Vaggelis seemed to suggest that those allegations might not be important = in practice. Almost all registries will have rules on bundling and mapping. Thus one = may not need to "solve for infinity" to reach a solution that covers many or even = most cases. His comment appeared reasonable (to me :), in rebutting allegations of = impossibility. If I can count the number of "shadows" with my fingers, that seems to ME = to be a tad different from millions of potential domains. The requirements capture is running apace. It seemed that some were = starting to claim that the (quantum superposed) kitchen sink needed to be in there as = well. We need to know what this is trying to solve, but I'd be surprised if = DNSng (or some LDAP-based oracle) is needed, just to meet the real registry issues = already mentioned. all the best, Lawrence From alex@alex.org.uk Wed Feb 16 09:29:26 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 288A73A6EAA for ; Wed, 16 Feb 2011 09:29:24 -0800 (PST) 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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xBGjfpwazcip for ; Wed, 16 Feb 2011 09:29:20 -0800 (PST) Received: from mail.avalus.com (mail.avalus.com [89.16.176.221]) by core3.amsl.com (Postfix) with ESMTP id AFA3F3A6C6E for ; Wed, 16 Feb 2011 09:29:19 -0800 (PST) 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 AEEE8C5641A; Wed, 16 Feb 2011 17:29:46 +0000 (GMT) Date: Wed, 16 Feb 2011 17:29:46 +0000 From: Alex Bligh To: Andrew Sullivan , dnsext@ietf.org Message-ID: <19E41B4714C510B9EF65CBFF@Ximines.local> In-Reply-To: <20110216171430.GX96213@shinkuro.com> References: <20110216073338.7251.qmail@joyce.lan> <20110216171430.GX96213@shinkuro.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 Subject: Re: [dnsext] we need help to make names the same, was draft-yao-dnsext-identical-resolution-02 comment X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 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, 16 Feb 2011 17:29:26 -0000 --On 16 February 2011 12:14:30 -0500 Andrew Sullivan wrote: > On Wed, Feb 16, 2011 at 07:43:30AM +0000, Alex Bligh wrote: >> (*) I think it's really about orthographic representation rather than >> spelling: we aren't really talking about jail.com and gaol.com, are >> we? > > As co-chair but without having discussed with Olafur: We are talking > about whatever zone administrators want to be equivalent, I think. Yes. You are quite correct. What I meant to say was treating this as equivalencies in "spelling" misses the point; most of the use cases now are about orthographic representation (I think). However *if* we solve this, we need, as you say, to solve the general equivalence problem, as ... > We are not well enough versed in the > linguistic differences between two different spellings "in English" > and the two scripts that are used to write Chinese for us to begin to > make decisions on the basis of that sort of distinction. +1 > This is why I, at least, have been adamant that we need a problem > statement before we start trying to solve the problem. It would be a > bad thing to add a bunch of complications that don't actually address > the real problems. I'm not sure I follow that. If we don't understand the existing known potential users (Chinese, Greek etc.), how can we pretend to understand the requirements of users we don't know? Surely, the /only/ logical thing to do is to solve "the general case", where an arbitrary number of sets of labels each are equivalent inside that set. > This is also why I have been so unhappy that we > have attracted little interest from the applications area crowd, who > will have to use anything we end up delivering. If we can't tell > whether what we are talking about looks like a real problem to (say) > web browser writers, how will we know whether what we propose to do is > going to have any effect? +1 -- Alex Bligh From nweaver@icsi.berkeley.edu Wed Feb 16 09:39:06 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3EDE03A6D59 for ; Wed, 16 Feb 2011 09:39:06 -0800 (PST) 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_55=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LLm5CPi5tAbA for ; Wed, 16 Feb 2011 09:39:05 -0800 (PST) Received: from taffy.ICSI.Berkeley.EDU (taffy.ICSI.Berkeley.EDU [192.150.187.26]) by core3.amsl.com (Postfix) with ESMTP id 6E6233A6C9F for ; Wed, 16 Feb 2011 09:39:05 -0800 (PST) Received: from gala.icsi.berkeley.edu (gala.ICSI.Berkeley.EDU [192.150.186.168]) (Authenticated sender: nweaver) by taffy.ICSI.Berkeley.EDU (Postfix) with ESMTP id 511ED36A405; Wed, 16 Feb 2011 09:39:34 -0800 (PST) References: <4D5B5E81.1050602@necom830.hpcl.titech.ac.jp> <20110216073338.7251.qmail@joyce.lan> <20110216165921.GW96213@shinkuro.com> <3B90ED2E-980D-4B01-889F-447D66D0B58D@insensate.co.uk> In-Reply-To: <3B90ED2E-980D-4B01-889F-447D66D0B58D@insensate.co.uk> Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii Message-Id: <5171BE80-37A7-4665-983F-AD06C048F39F@icsi.berkeley.edu> Content-Transfer-Encoding: quoted-printable From: Nicholas Weaver Date: Wed, 16 Feb 2011 09:39:33 -0800 To: Lawrence Conroy X-Mailer: Apple Mail (2.1082) Cc: dnsext@ietf.org Subject: Re: [dnsext] we need help to make names the same, was draft-yao-dnsext-identical-resolution-02 comment X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 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, 16 Feb 2011 17:39:06 -0000 On Feb 16, 2011, at 9:23 AM, Lawrence Conroy wrote: >=20 > To which I reply: > In principle, universal solutions trump narrow solutions that cover = fewer use cases. > BUT ... > So far, this thread has touched on/drifted towards VERY difficult = problems, with > alleged combinatorial explosions and other evils. >=20 > Vaggelis seemed to suggest that those allegations might not be = important in practice. > Almost all registries will have rules on bundling and mapping. Thus = one may not need > to "solve for infinity" to reach a solution that covers many or even = most cases. > His comment appeared reasonable (to me :), in rebutting allegations of = impossibility. One stupid observation: Combinatorial explosion, if the protocol is = done right, should not be a problem even in the 'solve for near = infinity' case: The effect on resolvers/caches is effectively nonexistent: they only = need to store the actual instances queried for. The effect on authorities is harder, but still not that hard IF the = authority can dynamically generate the needed translations on the fly. Thus the CNAME+DNAME style of aliasing should one finally be settled on = (x.y -> r.s AND *.x.y -> *.r.s) is a sufficient mechanism if the = authorities who want the combinatorial explosion case can use code to = synthesize (x'.y' -> r.s) plus the associated RRSIGs on the fly. Thus I'll argue that any solution SHOULD support the 'solve for = infinity' case. There is no real reason not to. From ajs@shinkuro.com Wed Feb 16 09:39:46 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B18433A6EC4 for ; Wed, 16 Feb 2011 09:39:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.432 X-Spam-Level: X-Spam-Status: No, score=-102.432 tagged_above=-999 required=5 tests=[AWL=-0.148, BAYES_00=-2.599, SARE_MILLIONSOF=0.315, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dUTb95bbWTmi for ; Wed, 16 Feb 2011 09:39:46 -0800 (PST) Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by core3.amsl.com (Postfix) with ESMTP id D8BBA3A6E6B for ; Wed, 16 Feb 2011 09:39:45 -0800 (PST) Received: from crankycanuck.ca (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 0C7E11ECB420 for ; Wed, 16 Feb 2011 17:40:13 +0000 (UTC) Date: Wed, 16 Feb 2011 12:40:12 -0500 From: Andrew Sullivan To: dnsext@ietf.org Message-ID: <20110216174011.GZ96213@shinkuro.com> References: <4D5B5E81.1050602@necom830.hpcl.titech.ac.jp> <20110216073338.7251.qmail@joyce.lan> <20110216165921.GW96213@shinkuro.com> <3B90ED2E-980D-4B01-889F-447D66D0B58D@insensate.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3B90ED2E-980D-4B01-889F-447D66D0B58D@insensate.co.uk> User-Agent: Mutt/1.5.18 (2008-05-17) Subject: Re: [dnsext] we need help to make names the same, was draft-yao-dnsext-identical-resolution-02 comment X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 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, 16 Feb 2011 17:39:47 -0000 On Wed, Feb 16, 2011 at 05:23:33PM +0000, Lawrence Conroy wrote: > Almost all registries will have rules on bundling and mapping. I just want to be clear what you mean by "registries" there. Remember that, formally, every zone cut comes with a registry responsible for it. If what you mean is "big TLD registries", then I'll concede the point. But we're not the DNS Extensions for TLDs WG. We're responsible for the protocol all the way down. I fully agree that we're not required to solve _every_ case: we can't. But we do have to solve enough of a problem to really make a difference. This is why the SMTP and web server issues are such a big deal. If we solve the problem that you only have to maintain one tree in the DNS, and everything else "just works", that is a completely meaningless victory if you nevertheless have to maintain all your SMTP and web servers by hand and keep them up to date about the aliases. The work to keep the DNS in sync here is trivial compared to everything else. > If I can count the number of "shadows" with my fingers, that seems to ME to be a tad > different from millions of potential domains. So how many shadows is the right number? The final sigma case is trivial. But the tonos case is not; it requires a large number of alternatives. We heard "tens of alternatives". But of course, that's tens of alternatives _in every level_. If you have four levels deep and 10 each, then that's 40 possible alternatives for one FQDN. A -- Andrew Sullivan ajs@shinkuro.com Shinkuro, Inc. From johnl@iecc.com Wed Feb 16 09:43:52 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7B41C3A6ECB for ; Wed, 16 Feb 2011 09:43:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -111.199 X-Spam-Level: X-Spam-Status: No, score=-111.199 tagged_above=-999 required=5 tests=[AWL=0.000, 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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0KorINAe180z for ; Wed, 16 Feb 2011 09:43:51 -0800 (PST) Received: from gal.iecc.com (gal.iecc.com [64.57.183.53]) by core3.amsl.com (Postfix) with ESMTP id 071F23A6EC7 for ; Wed, 16 Feb 2011 09:43:50 -0800 (PST) Received: (qmail 548 invoked from network); 16 Feb 2011 17:44:18 -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=223.4d5c0cf2.k1102; i=johnl@submit.iecc.com; bh=MdScmUt4Zu3l2htZZYvJsqQrRzkXLQqu/UR9I1WINS4=; b=GRFEwo1pm3klvS9cBHovyv6Jxfj8GdMYGlyCdX25zoyaZKBrVIbuJaunl9OTTybZJt7uKUm+NxoIbXi2L1uv2rJI7WMkKOtJO3Uqlz9N9XgMqQAL0lONWD21f1rYbSFD9OdwU/xu4TQWkkVDtpT1/SHNf9yAxPTDd4lDYWKfGO8= VBR-Info: md=iecc.com; mc=all; mv=dwl.spamhaus.org Received: (ofmipd johnl@64.57.183.62) with (DHE-RSA-AES256-SHA encrypted) SMTP; 16 Feb 2011 17:43:56 -0000 Date: 16 Feb 2011 09:44:16 -0800 Message-ID: From: "John R. Levine" To: "Alex Bligh" In-Reply-To: References: <20110216073338.7251.qmail@joyce.lan> 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] we need help to make names the same, was draft-yao-dnsext-identical-resolution-02 comment X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 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, 16 Feb 2011 17:43:52 -0000 >> If a set of names really is all equivalent, wouldn't it be better in the >> long run for people to configure the set once rather than once per server? > > I think we've been round this loop and determined that for most/many > applications there is /still/ manual configuration (see SSL cert DN > for example). If we're serious about names being equivalent, browsers should be able to take the name in an SSL cert, and check in the DNS to see if it's equivalent to the name it's using. If we believe in DNSSEC this shouldn't be a security issue. Yes, this is a lot more work than some DNS tweak that makes everything work, but if the DNS tweak existed, we would already have found it. Regards, John Levine, johnl@iecc.com, Primary Perpetrator of "The Internet for Dummies", Please consider the environment before reading this e-mail. http://jl.ly From johnl@iecc.com Wed Feb 16 09:56:39 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F01FC3A6EDF for ; Wed, 16 Feb 2011 09:56:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.899 X-Spam-Level: X-Spam-Status: No, score=-110.899 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, HABEAS_ACCREDITED_SOI=-4.3, J_CHICKENPOX_43=0.6, RCVD_IN_BSP_TRUSTED=-4.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OWp8pngV-e8T for ; Wed, 16 Feb 2011 09:56:38 -0800 (PST) Received: from gal.iecc.com (gal.iecc.com [64.57.183.53]) by core3.amsl.com (Postfix) with ESMTP id 94BBC3A6EDE for ; Wed, 16 Feb 2011 09:56:38 -0800 (PST) Received: (qmail 4856 invoked from network); 16 Feb 2011 17:57:05 -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=12f7.4d5c0ff1.k1102; i=johnl@submit.iecc.com; bh=V2hRHf6F2d5XS1K9X5GcN3NfD4tAwoqRx78Ut7Jz8eo=; b=WD/KV9vQw39MqeJt5+xFtiknL2wC/eY7R2dHsIfkcctt1JuSZIcoFa3QhwvhpRtgq1cdc2FKMewF2uWRohmYGyzNp34ioaeFTHLAtKdrTrm5ZYxfGgjFGR94o9qN18RJ9r3ZdI3OS8ljWuRTN3jklORz1Zrlsj+TH+FhueQ3CIM= VBR-Info: md=iecc.com; mc=all; mv=dwl.spamhaus.org Received: (ofmipd johnl@64.57.183.62) with (DHE-RSA-AES256-SHA encrypted) SMTP; 16 Feb 2011 17:56:43 -0000 Date: 16 Feb 2011 09:57:03 -0800 Message-ID: From: "John R. Levine" To: "Vaggelis Segredakis" In-Reply-To: References: <4D5B5E81.1050602@necom830.hpcl.titech.ac.jp> <20110216073338.7251.qmail@joyce.lan> 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] we need help to make names the same, was draft-yao-dnsext-identical-resolution-02 comment X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 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, 16 Feb 2011 17:56:40 -0000 > The number of these domain names varies from two (or four if a final sigma > is present) to some tens of domains, not millions and certainly not > billions. Well, yes, but that's in one component. If someone has a name A.B.C.gr, where each of A B C has ten variants, now there's a thousand equivalent names. I would think that a design that handled the variants in C but not in A and B is not worth implementing. If you only care about C, you can do that with bundling, have the registry assign all variants of a requested name to the registrant, and let the registrant deal with making them the same, by copies of the zone. It's not particularly elegant, but it requires no changes to existing protocol and the software is not very complicated. > We asked for a DNS rr that will allow two, three, four, or tens of > chosen domain names to act as if they were interchangeable in all the > branches of the domain name tree, starting from the top. They could be > perfectly normal Latin domain names that point to the same services and > the administrator decides to administer them as one. Except that, as often noted, if the servers they point to don't have some way to discover that the names are intended to be equivalent, the services won't work. The assumptions so far seem to be either that the services are something like telnet that doesn't care what its name is, or that they'll be manually provisioned, which seems unlikely to work except in the tiniest cases. Regards, John Levine, johnl@iecc.com, Primary Perpetrator of "The Internet for Dummies", Please consider the environment before reading this e-mail. http://jl.ly From mohta@necom830.hpcl.titech.ac.jp Wed Feb 16 13:02:40 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5EF723A6D2A for ; Wed, 16 Feb 2011 13:02:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.109 X-Spam-Level: X-Spam-Status: No, score=-0.109 tagged_above=-999 required=5 tests=[AWL=-0.019, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tZ6zhsCBJD13 for ; Wed, 16 Feb 2011 13:02:39 -0800 (PST) Received: from necom830.hpcl.titech.ac.jp (necom830.hpcl.titech.ac.jp [131.112.32.132]) by core3.amsl.com (Postfix) with SMTP id 2EB393A6CBA for ; Wed, 16 Feb 2011 13:02:39 -0800 (PST) Received: (qmail 64152 invoked from network); 16 Feb 2011 21:13: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; 16 Feb 2011 21:13:23 -0000 Message-ID: <4D5C3B53.8080909@necom830.hpcl.titech.ac.jp> Date: Thu, 17 Feb 2011 06:02:11 +0900 From: Masataka Ohta User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; ja; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: dnsext@ietf.org References: <4D5B5E81.1050602@necom830.hpcl.titech.ac.jp> <20110216073338.7251.qmail@joyce.lan> In-Reply-To: Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit Subject: Re: [dnsext] we need help to make names the same, was draft-yao-dnsext-identical-resolution-02 comment X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 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, 16 Feb 2011 21:02:40 -0000 Vaggelis Segredakis wrote: > We did however ask for the user's choice of registered domain names, How many names the user can choose? 10? 100? or 1000000? > The number of these domain names varies from two See examples of possible meaningful combinations of upper and lower cases. my-domain.com my-Domain.com My-domain.com My-Domain.com MY-DOMAIN.com or, some user may think even more meaningful my-DOMAIN.com My-DOMAIN.com MY-domain.com MY-Domain.com > (or four if a final sigma is present) How much will it be with the Greek equivalent of above examples? > to some tens of domains, not millions and certainly not > billions. How can you forbid a user who purchased "my-domain.com" want to have control over: mY-DoMaIn.com ? > They could be > perfectly normal Latin domain names that point to the same services mY-DoMaIn.com is a perfectly normal Latin domain name. > and the > administrator decides to administer them as one. Administrator of which? Registry or the user? Masataka Ohta From marka@isc.org Wed Feb 16 13:29:29 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8F3323A6CB0 for ; Wed, 16 Feb 2011 13:29:29 -0800 (PST) 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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NpWmYJVlwEyt for ; Wed, 16 Feb 2011 13:29:26 -0800 (PST) Received: from mx.ams1.isc.org (mx.ams1.isc.org [IPv6:2001:500:60::65]) by core3.amsl.com (Postfix) with ESMTP id 37EB53A6CBA for ; Wed, 16 Feb 2011 13:29:26 -0800 (PST) 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 2D4125F983B; Wed, 16 Feb 2011 21:29:37 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (drugs.dv.isc.org [IPv6:2001:470:1f00:820:ea06:88ff:fef3:4f9c]) (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 D880B216C22; Wed, 16 Feb 2011 21:29:34 +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 57D64A3F344; Thu, 17 Feb 2011 08:29:30 +1100 (EST) To: Tony Finch From: Mark Andrews References: <20110216032120.43474.qmail@joyce.lan> In-reply-to: Your message of "Wed, 16 Feb 2011 11:55:57 -0000." Date: Thu, 17 Feb 2011 08:29:30 +1100 Message-Id: <20110216212930.57D64A3F344@drugs.dv.isc.org> Cc: John Levine , dnsext@ietf.org Subject: Re: [dnsext] we need help to make names the same, was draft-yao-dnsext-identical-resolution-02 comment X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 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, 16 Feb 2011 21:29:29 -0000 In message , Tony Fi nch writes: > On Wed, 16 Feb 2011, John Levine wrote: > > > > It would not be absurd to argue that the most reasonable way to solve > > the provisioning issues is for the SMTP and HTTP servers to ask the > > DNS what the canonical name for an otherwise unknown name is, so those > > servers are just provisioned with the canonical name and an "allow > > variants" flag. > > It used to be the case that SMTP servers would rewrite domains in > addresses by replacing a CNAME owner with its target. See RFC 1123 section > 5.2.2. This requirement no longer exists but there is still code out there > that supports it. I think it would be quite reasonable to add a feature > for optional cname-based canonicalization to an MTA. (You can probably do > it now using Exim's configuration language, though it'll probably be a bit > ugly.) > > There is also some HTTP server code out there that hooks into the DNS for > server name canonicalization - see Apache's UseCanonicalName DNS option, > which is my fault. It uses reverse DNS lookups (it was designed for > IP-based virtual hosting) but I don't think it would be hard to do > something similar based on CNAME records. > > Note that server features like this are nice to have but not absolutely > necessary. HTTP abuses CNAME. If HTTP clients where following the design principles behind CNAME then the HTTP request would be re-written when a CNAME was seen. Instead they ignored the CNAME and as a result effectively treated it like a single MX record which is wrong and has caused problems all along. When we actually want to use CNAMEs for what they are designed to be used for we find HTTP has hijacked them. There still isn't a formal RFC for SRV with HTTP. > Tony. > -- > f.anthony.n.finch http://dotat.at/ > HUMBER THAMES DOVER WIGHT PORTLAND: NORTH BACKING WEST OR NORTHWEST, 5 TO 7, > DECREASING 4 OR 5, OCCASIONALLY 6 LATER IN HUMBER AND THAMES. MODERATE OR > ROUGH. RAIN THEN FAIR. GOOD. > _______________________________________________ > 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 Wed Feb 16 18:36:45 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 434A83A6DB2 for ; Wed, 16 Feb 2011 18:36:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.442 X-Spam-Level: X-Spam-Status: No, score=-2.442 tagged_above=-999 required=5 tests=[AWL=-0.158, BAYES_00=-2.599, SARE_MILLIONSOF=0.315] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NLONj2dY5YfE for ; Wed, 16 Feb 2011 18:36:44 -0800 (PST) Received: from mx.ams1.isc.org (mx.ams1.isc.org [IPv6:2001:500:60::65]) by core3.amsl.com (Postfix) with ESMTP id 3D4A63A6CE5 for ; Wed, 16 Feb 2011 18:36:44 -0800 (PST) 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 2486D5F98F3; Thu, 17 Feb 2011 02:36:58 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (drugs.dv.isc.org [IPv6:2001:470:1f00:820:ea06:88ff:fef3:4f9c]) (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 B45D2216C1E; Thu, 17 Feb 2011 02:36: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 DB105A41C29; Thu, 17 Feb 2011 13:36:45 +1100 (EST) To: Andrew Sullivan From: Mark Andrews References: <4D5B5E81.1050602@necom830.hpcl.titech.ac.jp> <20110216073338.7251.qmail@joyce.lan> <20110216165921.GW96213@shinkuro.com> <3B90ED2E-980D-4B01-889F-447D66D0B58D@insensate.co.uk><20110216174011.GZ96213@shinkuro.com> In-reply-to: Your message of "Wed, 16 Feb 2011 12:40:12 CDT." <20110216174011.GZ96213@shinkuro.com> Date: Thu, 17 Feb 2011 13:36:45 +1100 Message-Id: <20110217023645.DB105A41C29@drugs.dv.isc.org> Cc: dnsext@ietf.org Subject: Re: [dnsext] we need help to make names the same, was draft-yao-dnsext-identical-resolution-02 comment X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 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, 17 Feb 2011 02:36:45 -0000 In message <20110216174011.GZ96213@shinkuro.com>, Andrew Sullivan writes: > On Wed, Feb 16, 2011 at 05:23:33PM +0000, Lawrence Conroy wrote: > > > Almost all registries will have rules on bundling and mapping. > > I just want to be clear what you mean by "registries" there. Remember > that, formally, every zone cut comes with a registry responsible for > it. > > If what you mean is "big TLD registries", then I'll concede the point. > But we're not the DNS Extensions for TLDs WG. We're responsible for > the protocol all the way down. > > I fully agree that we're not required to solve _every_ case: we can't. > But we do have to solve enough of a problem to really make a > difference. > > This is why the SMTP and web server issues are such a big deal. If we > solve the problem that you only have to maintain one tree in the DNS, > and everything else "just works", that is a completely meaningless > victory if you nevertheless have to maintain all your SMTP and web > servers by hand and keep them up to date about the aliases. The work > to keep the DNS in sync here is trivial compared to everything else. > > > If I can count the number of "shadows" with my fingers, that seems to ME to > be a tad > > different from millions of potential domains. > > So how many shadows is the right number? The final sigma case is > trivial. But the tonos case is not; it requires a large number of > alternatives. We heard "tens of alternatives". But of course, that's > tens of alternatives _in every level_. If you have four levels deep > and 10 each, then that's 40 possible alternatives for one FQDN. Does one have to support mixed tonos? With and without rather than on a per character basis? I don't know as I don't write Greek. > A > > -- > Andrew Sullivan > ajs@shinkuro.com > Shinkuro, Inc. > _______________________________________________ > 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 Wed Feb 16 18:50:45 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 12A2D3A6EEB for ; Wed, 16 Feb 2011 18:50:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.567 X-Spam-Level: X-Spam-Status: No, score=-2.567 tagged_above=-999 required=5 tests=[AWL=0.032, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ucZT3LpAHnOV for ; Wed, 16 Feb 2011 18:50:43 -0800 (PST) Received: from mx.ams1.isc.org (mx.ams1.isc.org [IPv6:2001:500:60::65]) by core3.amsl.com (Postfix) with ESMTP id 865183A6E8D for ; Wed, 16 Feb 2011 18:50:43 -0800 (PST) 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 93A4A5F98F3; Thu, 17 Feb 2011 02:50:56 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (drugs.dv.isc.org [IPv6:2001:470:1f00:820:ea06:88ff:fef3:4f9c]) (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 3F0D0216C1E; Thu, 17 Feb 2011 02:50:54 +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 3DF1DA41D18; Thu, 17 Feb 2011 13:50:52 +1100 (EST) To: "John R. Levine" From: Mark Andrews References: <4D5B5E81.1050602@necom830.hpcl.titech.ac.jp> <20110216073338.7251.qmail@joyce.lan> In-reply-to: Your message of "16 Feb 2011 09:57:03 -0800." Date: Thu, 17 Feb 2011 13:50:52 +1100 Message-Id: <20110217025052.3DF1DA41D18@drugs.dv.isc.org> Cc: dnsext@ietf.org Subject: Re: [dnsext] we need help to make names the same, was draft-yao-dnsext-identical-resolution-02 comment X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 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, 17 Feb 2011 02:50:45 -0000 In message , "John R. Levine" wr ites: > > The number of these domain names varies from two (or four if a final sigma > > is present) to some tens of domains, not millions and certainly not > > billions. > > Well, yes, but that's in one component. If someone has a name A.B.C.gr, > where each of A B C has ten variants, now there's a thousand equivalent > names. I would think that a design that handled the variants in C but not > in A and B is not worth implementing. > > If you only care about C, you can do that with bundling, have the registry > assign all variants of a requested name to the registrant, and let the > registrant deal with making them the same, by copies of the zone. It's > not particularly elegant, but it requires no changes to existing protocol > and the software is not very complicated. > > > We asked for a DNS rr that will allow two, three, four, or tens of > > chosen domain names to act as if they were interchangeable in all the > > branches of the domain name tree, starting from the top. They could be > > perfectly normal Latin domain names that point to the same services and > > the administrator decides to administer them as one. > > Except that, as often noted, if the servers they point to don't have some > way to discover that the names are intended to be equivalent, the services > won't work. The assumptions so far seem to be either that the services > are something like telnet that doesn't care what its name is, or that > they'll be manually provisioned, which seems unlikely to work except in > the tiniest cases. This is where if CNAME's were being properly handled you wouldn't have a issue. Give the service the indirection support and aliasing support. HTTP uses the alias record for indirection which is just wrong. > Regards, > John Levine, johnl@iecc.com, Primary Perpetrator of "The Internet for Dummies > ", > Please consider the environment before reading this e-mail. http://jl.ly > _______________________________________________ > 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 dougb@dougbarton.us Wed Feb 16 21:04:32 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2FAD63A6CAB for ; Wed, 16 Feb 2011 21:04:32 -0800 (PST) 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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dx5OCFogafYo for ; Wed, 16 Feb 2011 21:04:31 -0800 (PST) Received: from mail2.fluidhosting.com (mx22.fluidhosting.com [204.14.89.5]) by core3.amsl.com (Postfix) with ESMTP id C4D673A6C4E for ; Wed, 16 Feb 2011 21:04:29 -0800 (PST) Received: (qmail 24882 invoked by uid 399); 17 Feb 2011 05:04:56 -0000 Received: from router.ka9q.net (HELO doug-optiplex.ka9q.net) (dougb@dougbarton.us@75.60.237.91) by mail2.fluidhosting.com with ESMTPAM; 17 Feb 2011 05:04:56 -0000 X-Originating-IP: 75.60.237.91 X-Sender: dougb@dougbarton.us Message-ID: <4D5CAC77.2050301@dougbarton.us> Date: Wed, 16 Feb 2011 21:04:55 -0800 From: Doug Barton Organization: http://SupersetSolutions.com/ User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.13) Gecko/20110129 Thunderbird/3.1.7 MIME-Version: 1.0 To: Jay Ashworth References: <32007060.266.1297829868445.JavaMail.root@benjamin.baylink.com> In-Reply-To: <32007060.266.1297829868445.JavaMail.root@benjamin.baylink.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: Re: [dnsext] we need help to make names the same, was draft-yao-dnsext-identical-resolution-02 comment X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 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, 17 Feb 2011 05:04:32 -0000 On 02/15/2011 20:17, Jay Ashworth wrote: > And, as has been pointed out in some other venues, and which seems > applicable here also, some approachs to certain things *depend on trying > a DNS lookup and having it break*. I'm damned if I can remember what > the canonical example was, but it fell in the general category of > "please don't make this change to try to 'help' 'the web', cause you'll > break*my* protocol which isn't http". It would be really great if we could find a pointer to that discussion, since some of us are still working on trying to solve the problem and would prefer not to make things worse. :) Meanwhile I'm concerned about what seems to be a thread of "We can't work to solve the DNS part of this problem because solving the DNS part won't solve the whole problem." *If* we can solve the DNS part of the problem now there are solutions available now for all the other problems that people have mentioned so far, even if they are potentially onerous (such as acquiring SSL certs for all variants, etc.). But without a solution for the DNS part of the problem it's going to be awfully hard to move forward in the other areas. 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 johnl@iecc.com Wed Feb 16 22:00:42 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 56A143A6CDC for ; Wed, 16 Feb 2011 22:00:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -111.139 X-Spam-Level: X-Spam-Status: No, score=-111.139 tagged_above=-999 required=5 tests=[AWL=0.060, 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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yDwUikjFlRJX for ; Wed, 16 Feb 2011 22:00:39 -0800 (PST) Received: from gal.iecc.com (gal.iecc.com [64.57.183.53]) by core3.amsl.com (Postfix) with ESMTP id BD5133A6CDB for ; Wed, 16 Feb 2011 22:00:38 -0800 (PST) Received: (qmail 74501 invoked from network); 17 Feb 2011 06:01:06 -0000 Received: from mail1.iecc.com (64.57.183.56) by mail1.iecc.com with QMQP; 17 Feb 2011 06:01:06 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:subject:in-reply-to:cc:mime-version:content-type:content-transfer-encoding:vbr-info; s=b7c3.4d5cb9a2.k1102; i=johnl@user.iecc.com; bh=A1mlOZ4SBc2x3ji91U0fveBa6gQchAl4z24Ivi+XAPg=; b=dTPWYV6jizULgdJhysO1jv6XP2Qmel9NFmmRB/ZHcv0wKbaaOd/I5YMABlBjSWl+zo/rPjZXIkQ1CBaJCK2We5+zHzM53nfrNM7xgJFOYjXaItd50jgsHai8uwB3Gu2WPU1oL8ZkkIa85eR8qMRTLFOFtSLREPOfdvBMoRllSLk= VBR-Info: md=iecc.com; mc=all; mv=dwl.spamhaus.org Date: 17 Feb 2011 06:01:05 -0000 Message-ID: <20110217060105.47042.qmail@joyce.lan> From: John Levine To: dnsext@ietf.org In-Reply-To: <4D5CAC77.2050301@dougbarton.us> Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 7bit Subject: Re: [dnsext] we need help to make names the same, was draft-yao-dnsext-identical-resolution-02 comment X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 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, 17 Feb 2011 06:00:42 -0000 >Meanwhile I'm concerned about what seems to be a thread of "We can't >work to solve the DNS part of this problem because solving the DNS part >won't solve the whole problem." I'm more concerned that whatever approach we adopt makes it possible for applications to configure themselves automatically using the info in the DNS. Most likely people will configure manually until the pain of doing so gets great enough that it's worth the hassle to implement autoconfiguration for HTTP, SMTP et al., but we owe it to them to make the autoconfig possible when they're ready to bite the bullet. Mark is more or less right that CNAMEs do what you want, although they don't deal with A.B.C where each of A, B, and C have variant forms. Regards, John Levine, johnl@iecc.com, Primary Perpetrator of "The Internet for Dummies", Please consider the environment before reading this e-mail. http://jl.ly From marka@isc.org Wed Feb 16 22:14:42 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 89E713A6D31 for ; Wed, 16 Feb 2011 22:14:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.573 X-Spam-Level: X-Spam-Status: No, score=-2.573 tagged_above=-999 required=5 tests=[AWL=0.026, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SOxBITsV9LiX for ; Wed, 16 Feb 2011 22:14:41 -0800 (PST) Received: from mx.ams1.isc.org (mx.ams1.isc.org [IPv6:2001:500:60::65]) by core3.amsl.com (Postfix) with ESMTP id 1C5363A6D0A for ; Wed, 16 Feb 2011 22:14:41 -0800 (PST) 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 4D9855F9891; Thu, 17 Feb 2011 06:14:55 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (drugs.dv.isc.org [IPv6:2001:470:1f00:820:ea06:88ff:fef3:4f9c]) (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 32C22216C1E; Thu, 17 Feb 2011 06:14:54 +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 AAF71A45C08; Thu, 17 Feb 2011 17:14:45 +1100 (EST) To: Doug Barton From: Mark Andrews References: <32007060.266.1297829868445.JavaMail.root@benjamin.baylink.com><4D5CAC77.2050301@dougbarton.us> In-reply-to: Your message of "Wed, 16 Feb 2011 21:04:55 -0800." <4D5CAC77.2050301@dougbarton.us> Date: Thu, 17 Feb 2011 17:14:45 +1100 Message-Id: <20110217061445.AAF71A45C08@drugs.dv.isc.org> Cc: dnsext@ietf.org Subject: Re: [dnsext] we need help to make names the same, was draft-yao-dnsext-identical-resolution-02 comment X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 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, 17 Feb 2011 06:14:42 -0000 In message <4D5CAC77.2050301@dougbarton.us>, Doug Barton writes: > On 02/15/2011 20:17, Jay Ashworth wrote: > > And, as has been pointed out in some other venues, and which seems > > applicable here also, some approachs to certain things *depend on trying > > a DNS lookup and having it break*. I'm damned if I can remember what > > the canonical example was, but it fell in the general category of > > "please don't make this change to try to 'help' 'the web', cause you'll > > break*my* protocol which isn't http". > > It would be really great if we could find a pointer to that discussion, > since some of us are still working on trying to solve the problem and > would prefer not to make things worse. :) The classic case is the email typo. It fails immediately with NXDOMAIN but has to wait for the MTA to timeout the connects with "helpful" address records. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From segred@ics.forth.gr Wed Feb 16 23:37:14 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 16AA03A6D56 for ; Wed, 16 Feb 2011 23:37:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.401 X-Spam-Level: X-Spam-Status: No, score=-6.401 tagged_above=-999 required=5 tests=[AWL=-0.402, BAYES_00=-2.599, J_CHICKENPOX_43=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TzgkMiTVh8Ry for ; Wed, 16 Feb 2011 23:37:12 -0800 (PST) Received: from mailgate.ics.forth.gr (mailgate.ics.forth.gr [139.91.1.2]) by core3.amsl.com (Postfix) with ESMTP id 321EF3A6CE6 for ; Wed, 16 Feb 2011 23:37:11 -0800 (PST) Received: from av1.ics.forth.gr (av1-in.ics.forth.gr [139.91.1.71]) by mailgate.ics.forth.gr (8.14.3/ICS-FORTH/V10-1.8-GATE) with ESMTP id p1H7bXrH010843; Thu, 17 Feb 2011 09:37:35 +0200 (EET) X-AuditID: 8b5b9d47-b7c88ae0000076fe-cf-4d5cd03c9ab4 Received: from enigma.ics.forth.gr (webmail.ics.forth.gr [139.91.1.30]) by av1.ics.forth.gr (SMTP Outbound / FORTH / ICS) with SMTP id 7F.E3.30462.C30DC5D4; Thu, 17 Feb 2011 09:37:32 +0200 (EET) Received: from Thanatos (thanatos.ics.forth.gr [139.91.88.160]) (authenticated bits=0) by enigma.ics.forth.gr (8.14.3//ICS-FORTH/V10.3.0C-EXTNULL-SSL-SASL) with ESMTP id p1H7bVac021719 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Thu, 17 Feb 2011 09:37:32 +0200 X-ICS-AUTH-INFO: Authenticated user: segred at ics.forth.gr From: "Vaggelis Segredakis" To: "'John R. Levine'" References: <4D5B5E81.1050602@necom830.hpcl.titech.ac.jp> <20110216073338.7251.qmail@joyce.lan> Date: Thu, 17 Feb 2011 09:36:13 +0200 Message-ID: <25C1FE09988043CCAA0DDC5CD6CE3DC9@ics.forth.gr> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: AcvOAvN1eo1iwWgYQOqeos8BTzrR2QAb9HKw X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5994 In-Reply-To: X-Brightmail-Tracker: AAAAAA== X-j-chkmail-Score: MSGID : 4D5CD03D.000 on mailgate : j-chkmail score : . : R=. U=. O=. B=0.000 -> S=0.000 X-ICS-JCHK-SCL: Ham Cc: dnsext@ietf.org Subject: Re: [dnsext] we need help to make names the same, was draft-yao-dnsext-identical-resolution-02 comment X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 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, 17 Feb 2011 07:37:14 -0000 Dear John, >If you only care about C, you can do that with bundling, have the registry >assign all variants of a requested name to the registrant, and let the >registrant deal with making them the same, by copies of the zone. It's >not particularly elegant, but it requires no changes to existing protocol >and the software is not very complicated. I guess you know we are the Registry of [.gr] domain names. If we are asking for a different solution than simple bundling and letting the registrant deal with the issue this should mean something about bundling, right? When an issue is so common that all your IDN registrants have to register bundles and "deal with making them the same", it appears to be a good thing if the registry can assist on such an issue. The registrants have not asked for IDNA2003 or IDNA2008 to be implemented as they were, protocols with shortcomings. However, since the IDNA protocols are well in use by now, a BNAME type solution could make life easier for the average user. >Except that, as often noted, if the servers they point to don't have some >way to discover that the names are intended to be equivalent, the services >won't work. The assumptions so far seem to be either that the services >are something like telnet that doesn't care what its name is, or that >they'll be manually provisioned, which seems unlikely to work except in >the tiniest cases. My guess is that when the solution is available, many services will benefit from it and use it. Kind Regards, Vaggelis Segredakis From segred@ics.forth.gr Thu Feb 17 00:22:52 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C24E63A6D23 for ; Thu, 17 Feb 2011 00:22:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.321 X-Spam-Level: X-Spam-Status: No, score=-6.321 tagged_above=-999 required=5 tests=[AWL=-0.322, BAYES_00=-2.599, J_CHICKENPOX_43=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H8vMt4xD7cHH for ; Thu, 17 Feb 2011 00:22:51 -0800 (PST) Received: from mailgate.ics.forth.gr (mailgate.ics.forth.gr [139.91.1.2]) by core3.amsl.com (Postfix) with ESMTP id 746D83A6C68 for ; Thu, 17 Feb 2011 00:22:51 -0800 (PST) Received: from av1.ics.forth.gr (av1-in.ics.forth.gr [139.91.1.71]) by mailgate.ics.forth.gr (8.14.3/ICS-FORTH/V10-1.8-GATE) with ESMTP id p1H8NIvu012833; Thu, 17 Feb 2011 10:23:20 +0200 (EET) X-AuditID: 8b5b9d47-b7c88ae0000076fe-77-4d5cdaf6f973 Received: from enigma.ics.forth.gr (webmail.ics.forth.gr [139.91.1.30]) by av1.ics.forth.gr (SMTP Outbound / FORTH / ICS) with SMTP id DF.14.30462.6FADC5D4; Thu, 17 Feb 2011 10:23:18 +0200 (EET) Received: from Thanatos (thanatos.ics.forth.gr [139.91.88.160]) (authenticated bits=0) by enigma.ics.forth.gr (8.14.3//ICS-FORTH/V10.3.0C-EXTNULL-SSL-SASL) with ESMTP id p1H8NHGP024750 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Thu, 17 Feb 2011 10:23:18 +0200 X-ICS-AUTH-INFO: Authenticated user: segred at ics.forth.gr From: "Vaggelis Segredakis" To: "'Andrew Sullivan'" , References: <4D5B5E81.1050602@necom830.hpcl.titech.ac.jp><20110216073338.7251.qmail@joyce.lan> <20110216165921.GW96213@shinkuro.com> Date: Thu, 17 Feb 2011 10:21:58 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: AcvN+unn/LH/mu7hS/KxZmhVNpRMygAfCmaA X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5994 In-Reply-To: <20110216165921.GW96213@shinkuro.com> X-Brightmail-Tracker: AAAAAA== X-j-chkmail-Score: MSGID : 4D5CDAF6.000 on mailgate : j-chkmail score : . : R=. U=. O=. B=0.000 -> S=0.000 X-ICS-JCHK-SCL: Ham Subject: Re: [dnsext] we need help to make names the same, was draft-yao-dnsext-identical-resolution-02 comment X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 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, 17 Feb 2011 08:22:52 -0000 Dear Andrew, >As a matter of _protocol_, however, what you asked for devolves to >"more than two". Once we're at that point, the size of the set >doesn't really matter except for the question of where the trade-off >will be for performance reasons. That is OK, as long as it provides a solution. However, what you say above does not imply necessarily the use of "wildcards", right? It is a different thing to use wildcards in the DNS protocol and completely different to ask for a group of FQDNs to be the "same". >Moreover, you're not the only one asking. This is certainly not a WG >devoted to solving the problem of how to make things easier for the >.gr registry. Whatever we do has to be a significant improvement for >many different kinds of uses, or it's not worth changing the protocol, >even if that means you lose. Sorry. Andrew, you have been crystal-clear in many occasions that we shouldn't expect a solution just for .gr domain names and we are not expecting something like that. However, if we do not bring our experience along with others in this discussion then we discuss solutions that are not applicable to the real problem. You do not need to be sorry; you are the chair of the group and somedays somebody loses; the chair will have the task to announce it. However, up to that specific point of time please be impartial because I have the feeling you would prefer this discussion to end as soon as possible and that is not just. Kind Regards, Vaggelis Segredakis From segred@ics.forth.gr Thu Feb 17 00:35:04 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4A96E3A6ABF for ; Thu, 17 Feb 2011 00:35:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.267 X-Spam-Level: X-Spam-Status: No, score=-7.267 tagged_above=-999 required=5 tests=[AWL=0.732, BAYES_00=-2.599, GB_I_LETTER=-2, J_CHICKENPOX_43=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qYEWYfgqwRFV for ; Thu, 17 Feb 2011 00:35:03 -0800 (PST) Received: from mailgate.ics.forth.gr (mailgate.ics.forth.gr [139.91.1.2]) by core3.amsl.com (Postfix) with ESMTP id 76CB83A6C7D for ; Thu, 17 Feb 2011 00:35:02 -0800 (PST) Received: from av1.ics.forth.gr (av1-in.ics.forth.gr [139.91.1.71]) by mailgate.ics.forth.gr (8.14.3/ICS-FORTH/V10-1.8-GATE) with ESMTP id p1H8ZTia013390; Thu, 17 Feb 2011 10:35:31 +0200 (EET) X-AuditID: 8b5b9d47-b7c88ae0000076fe-e6-4d5cddd1c950 Received: from enigma.ics.forth.gr (webmail.ics.forth.gr [139.91.1.30]) by av1.ics.forth.gr (SMTP Outbound / FORTH / ICS) with SMTP id 8C.24.30462.1DDDC5D4; Thu, 17 Feb 2011 10:35:29 +0200 (EET) Received: from Thanatos (thanatos.ics.forth.gr [139.91.88.160]) (authenticated bits=0) by enigma.ics.forth.gr (8.14.3//ICS-FORTH/V10.3.0C-EXTNULL-SSL-SASL) with ESMTP id p1H8ZTkK025580 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Thu, 17 Feb 2011 10:35:29 +0200 X-ICS-AUTH-INFO: Authenticated user: segred at ics.forth.gr From: "Vaggelis Segredakis" To: "'Mark Andrews'" , "'Andrew Sullivan'" References: <4D5B5E81.1050602@necom830.hpcl.titech.ac.jp><20110216073338.7251.qmail@joyce.lan><20110216165921.GW96213@shinkuro.com><3B90ED2E-980D-4B01-889F-447D66D0B58D@insensate.co.uk><20110216174011.GZ96213@shinkuro.com> <20110217023645.DB105A41C29@drugs.dv.isc.org> Date: Thu, 17 Feb 2011 10:34:10 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: AcvOS6XRA7gdovOeSteq3EY+RWobvwAMCgjg X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5994 In-Reply-To: <20110217023645.DB105A41C29@drugs.dv.isc.org> X-Brightmail-Tracker: AAAAARdxlnE= X-j-chkmail-Score: MSGID : 4D5CDDD1.000 on mailgate : j-chkmail score : . : R=. U=. O=. B=0.000 -> S=0.000 X-ICS-JCHK-SCL: Ham Cc: dnsext@ietf.org Subject: Re: [dnsext] we need help to make names the same, was draft-yao-dnsext-identical-resolution-02 comment X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 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, 17 Feb 2011 08:35:04 -0000 Dear Mark, >Does one have to support mixed tonos? With and without rather than >on a per character basis? I don't know as I don't write Greek. Most users will never ask for all possible positions of a tonos in a word to be registered as domain names, since there is usually a cost related to the registration. As a registry we provide them with the domain with tonos in their chosen position and the domain without it without extra cost. So, for every IDN registration they get two domain names. For every domain containing a final sigma they might get four domains per registration. Sometimes they decide to register a few more for the usual mistypings. Nobody to this date has ever requested all the possible domains of the bundle to be registered, since although domain names are not words the users usually like them to have a meaning. If they are meaningless variations of the original domain they are not too interesting as a product. If on the other hand you would like to register ancient Greek words then different accent styles would come into the game. A good xNAME solution however is not dependant in the PUNYCODE form, this is beyond the scope of this discussion. The xNAME solution should be one to make Latin domain trees equal. The xn-- part is no more significant than any other letter. Kind Regards, Vaggelis Segredakis From segred@ics.forth.gr Thu Feb 17 00:48:35 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9C4873A6C6A for ; Thu, 17 Feb 2011 00:48:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.072 X-Spam-Level: X-Spam-Status: No, score=-7.072 tagged_above=-999 required=5 tests=[AWL=0.327, BAYES_00=-2.599, GB_I_LETTER=-2, J_CHICKENPOX_55=0.6, J_CHICKENPOX_56=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zhG1zpOrfkPA for ; Thu, 17 Feb 2011 00:48:34 -0800 (PST) Received: from mailgate.ics.forth.gr (mailgate.ics.forth.gr [139.91.1.2]) by core3.amsl.com (Postfix) with ESMTP id 205603A68A3 for ; Thu, 17 Feb 2011 00:48:33 -0800 (PST) Received: from av1.ics.forth.gr (av1-in.ics.forth.gr [139.91.1.71]) by mailgate.ics.forth.gr (8.14.3/ICS-FORTH/V10-1.8-GATE) with ESMTP id p1H8n09B013926; Thu, 17 Feb 2011 10:49:02 +0200 (EET) X-AuditID: 8b5b9d47-b7c88ae0000076fe-54-4d5ce0fc783e Received: from enigma.ics.forth.gr (webmail.ics.forth.gr [139.91.1.30]) by av1.ics.forth.gr (SMTP Outbound / FORTH / ICS) with SMTP id 48.34.30462.CF0EC5D4; Thu, 17 Feb 2011 10:49:00 +0200 (EET) Received: from Thanatos (thanatos.ics.forth.gr [139.91.88.160]) (authenticated bits=0) by enigma.ics.forth.gr (8.14.3//ICS-FORTH/V10.3.0C-EXTNULL-SSL-SASL) with ESMTP id p1H8mxX8026483 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Thu, 17 Feb 2011 10:49:00 +0200 X-ICS-AUTH-INFO: Authenticated user: segred at ics.forth.gr From: "Vaggelis Segredakis" To: "'Masataka Ohta'" , References: <4D5B5E81.1050602@necom830.hpcl.titech.ac.jp> <20110216073338.7251.qmail@joyce.lan> <4D5C3B53.8080909@necom830.hpcl.titech.ac.jp> Date: Thu, 17 Feb 2011 10:47:41 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: AcvOHPeuhLCEvaXxQ1u/A0+NQHg9YwAYIqRg X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5994 In-Reply-To: <4D5C3B53.8080909@necom830.hpcl.titech.ac.jp> X-Brightmail-Tracker: AAAAAA== X-j-chkmail-Score: MSGID : 4D5CE0FC.000 on mailgate : j-chkmail score : . : R=. U=. O=. B=0.000 -> S=0.000 X-ICS-JCHK-SCL: Ham Subject: Re: [dnsext] we need help to make names the same, was draft-yao-dnsext-identical-resolution-02 comment X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 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, 17 Feb 2011 08:48:35 -0000 -----Original Message----- From: dnsext-bounces@ietf.org [mailto:dnsext-bounces@ietf.org] On Behalf Of Masataka Ohta Sent: Wednesday, February 16, 2011 11:02 PM To: dnsext@ietf.org Subject: Re: [dnsext] we need help to make names the same, was draft-yao-dnsext-identical-resolution-02 comment >Vaggelis Segredakis wrote: >> We did however ask for the user's choice of registered domain names, >How many names the user can choose? 10? 100? or 1000000? Usually they get two to four names. There is no real limit though. Not all domain names create huge bundles and even if they do, how many would a user choose to pay for and for what benefit? >> The number of these domain names varies from two >See examples of possible meaningful combinations of upper and >lower cases. my-domain.com my-Domain.com My-domain.com My-Domain.com MY-DOMAIN.com >or, some user may think even more meaningful my-DOMAIN.com My-DOMAIN.com MY-domain.com MY-Domain.com Your examples are not valid, they are the same domain name. The upper case to lower case conversion does not produce different domain names, even in IDN. However, if you have a letter with tonos there, the user would type this word in capital letters without tonos and this would be a different name in PUNYCODE. >> (or four if a final sigma is present) >How much will it be with the Greek equivalent of above examples? Usually there is only one position for the tonos in each word. Different position is different word or mistyping. So, you get one domain name with the tonos, one without. If the domain name had a final sigma, one domain with tonos+normal sigma, one without tonos+normal sigma, one with tonos+final sigma, one without tonos+final sigma (total four). If you have a two word domain or more, you have to multiply these combinations. >> to some tens of domains, not millions and certainly not >> billions. >How can you forbid a user who purchased "my-domain.com" want to >have control over: > mY-DoMaIn.com As mentioned before, they are the same. >> They could be >> perfectly normal Latin domain names that point to the same services > mY-DoMaIn.com >is a perfectly normal Latin domain name. I agree :-) >> and the >> administrator decides to administer them as one. >Administrator of which? Registry or the user? The administrator/user of the domain name, not the registry. Kind Regards, Vaggelis Segredakis From fanf2@hermes.cam.ac.uk Thu Feb 17 02:51:54 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EE9C73A6D69 for ; Thu, 17 Feb 2011 02:51:53 -0800 (PST) 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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DmUiDx7kRU1n for ; Thu, 17 Feb 2011 02:51:52 -0800 (PST) Received: from ppsw-50.csi.cam.ac.uk (ppsw-50.csi.cam.ac.uk [131.111.8.150]) by core3.amsl.com (Postfix) with ESMTP id 81CB23A6D2C for ; Thu, 17 Feb 2011 02:51:52 -0800 (PST) X-Cam-AntiVirus: no malware found X-Cam-SpamDetails: not scanned X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ Received: from hermes-1.csi.cam.ac.uk ([131.111.8.51]:55908) by ppsw-50.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.157]:25) with esmtpa (EXTERNAL:fanf2) id 1Pq1T8-0001mO-rh (Exim 4.72) (return-path ); Thu, 17 Feb 2011 10:52:18 +0000 Received: from fanf2 (helo=localhost) by hermes-1.csi.cam.ac.uk (hermes.cam.ac.uk) with local-esmtp id 1Pq1T8-0002vO-KO (Exim 4.67) (return-path ); Thu, 17 Feb 2011 10:52:18 +0000 Date: Thu, 17 Feb 2011 10:52:18 +0000 From: Tony Finch X-X-Sender: fanf2@hermes-1.csi.cam.ac.uk To: Mark Andrews In-Reply-To: <20110217025052.3DF1DA41D18@drugs.dv.isc.org> Message-ID: References: <4D5B5E81.1050602@necom830.hpcl.titech.ac.jp> <20110216073338.7251.qmail@joyce.lan> <20110217025052.3DF1DA41D18@drugs.dv.isc.org> User-Agent: Alpine 2.00 (LSU 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: Tony Finch Cc: "John R. Levine" , dnsext@ietf.org Subject: Re: [dnsext] we need help to make names the same, was draft-yao-dnsext-identical-resolution-02 comment X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 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, 17 Feb 2011 10:51:54 -0000 On Thu, 17 Feb 2011, Mark Andrews wrote: > > This is where if CNAME's were being properly handled you wouldn't have a > issue. Give the service the indirection support and aliasing support. > HTTP uses the alias record for indirection which is just wrong. It's worth noting that email moved away from doing client-side CNAME-based redirection. But you are right that it is better to have protocol support. SMTP has vestigial client redirects (251 and 551 server responses), though no-one ever implemented them. Many sites like to rewrite message headers to canonicalize email addresses based on some idea of friendliness e.g. fanf2@cam.ac.uk -> Tony.Finch@ucs.cam.ac.uk. I generally think this is pointless since (in the absence of 251 and 551 support) it doesn't have any useful effect on the address books of people who are using the non-canonical aliases. However since email is mostly open-loop, the complexity of a site's aliases don't need to be exposed to their correspondents. XMPP presence handling is a more awkward example: last time I looked the protocol doesn't have a way to redirect a presence subscription request from one JID to another (e.g. from an alias to the JID where you actually advertise your presence). The only way to handle aliases is on the client side as a multiplicity of separate accounts. It matters much more to your IM buddies that they know the JID(s) you currently use. Tony. -- f.anthony.n.finch http://dotat.at/ Viking, North Utsire, South Utsire, Northeast Forties: Easterly or southeasterly 5 to 7, decreasing 4 at times in North Utsire and Viking. Rough or very rough, but moderate in North Utsire. Rain or snow. Moderate or poor. From mohta@necom830.hpcl.titech.ac.jp Thu Feb 17 04:17:04 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CF2DE3A6DA0 for ; Thu, 17 Feb 2011 04:17:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.107 X-Spam-Level: X-Spam-Status: No, score=-0.107 tagged_above=-999 required=5 tests=[AWL=-0.017, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id huQwZTHKP337 for ; Thu, 17 Feb 2011 04:17:04 -0800 (PST) Received: from necom830.hpcl.titech.ac.jp (necom830.hpcl.titech.ac.jp [131.112.32.132]) by core3.amsl.com (Postfix) with SMTP id 9A8483A6D92 for ; Thu, 17 Feb 2011 04:17:03 -0800 (PST) Received: (qmail 84977 invoked from network); 17 Feb 2011 12:27:38 -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 Feb 2011 12:27:38 -0000 Message-ID: <4D5D119A.1070103@necom830.hpcl.titech.ac.jp> Date: Thu, 17 Feb 2011 21:16:26 +0900 From: Masataka Ohta User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; ja; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: dnsext@ietf.org References: <4D5B5E81.1050602@necom830.hpcl.titech.ac.jp><20110216073338.7251.qmail@joyce.lan><20110216165921.GW96213@shinkuro.com><3B90ED2E-980D-4B01-889F-447D66D0B58D@insensate.co.uk><20110216174011.GZ96213@shinkuro.com> <20110217023645.DB105A41C29@drugs.dv.isc.org> In-Reply-To: Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit Subject: Re: [dnsext] we need help to make names the same, was draft-yao-dnsext-identical-resolution-02 comment X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 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, 17 Feb 2011 12:17:04 -0000 Vaggelis Segredakis wrote: > As a registry we provide them with the domain with tonos in > their chosen position and the domain without it without > extra cost. So, for every IDN registration they get two domain > names. Then, from the beginning, there is no problem of you at all, even though you thought there were. Let your clients synchronize their domains. > For every domain containing a final > sigma they might get four domains per registration. If your clients will pay for the additional four domains, there is no problem. The problem, however, is that its not fair. > If they are meaningless variations of the original domain they are > not too interesting as a product. Just say "iPod". Masataka Ohta From Niall.oReilly@ucd.ie Thu Feb 17 04:35:37 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2EF463A6DF6 for ; Thu, 17 Feb 2011 04:35:37 -0800 (PST) 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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Jth5E-saL4b0 for ; Thu, 17 Feb 2011 04:35:36 -0800 (PST) Received: from smtp.ucd.ie (mgmtirp1.ucd.ie [137.43.231.111]) by core3.amsl.com (Postfix) with ESMTP id 0B00A3A6DF1 for ; Thu, 17 Feb 2011 04:35:35 -0800 (PST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AnQIAIekXE3BAaiL/2dsb2JhbACCPqNcc7t7hV4Ejz4 X-IronPort-AV: E=Sophos;i="4.60,486,1291593600"; d="scan'208";a="2652897" Received: from dhcp-c101a88b.ucd.ie ([193.1.168.139]) by smtp.ucd.ie with ESMTP/TLS/AES128-SHA; 17 Feb 2011 12:36:05 +0000 Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Niall O'Reilly In-Reply-To: Date: Thu, 17 Feb 2011 12:36:05 +0000 Content-Transfer-Encoding: 7bit Message-Id: <1FBC914F-F502-4233-AC6C-E7A37728C103@ucd.ie> References: <4D5B5E81.1050602@necom830.hpcl.titech.ac.jp> <20110216073338.7251.qmail@joyce.lan> <4D5C3B53.8080909@necom830.hpcl.titech.ac.jp> To: Vaggelis Segredakis X-Mailer: Apple Mail (2.1082) Cc: dnsext@ietf.org Subject: Re: [dnsext] we need help to make names the same, was draft-yao-dnsext-identical-resolution-02 comment X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 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, 17 Feb 2011 12:35:37 -0000 On 17 Feb 2011, at 08:47, Vaggelis Segredakis wrote: > Usually they get two to four names. There is no real limit though. Not all > domain names create huge bundles and even if they do, how many would a user > choose to pay for and for what benefit? Is that to say that the typicl registrant gets 2-4 names from the .GR registry, and may then add further multiplicity further down the hierarchy, depending on requirements and resources? Thanks for confirming and/or clarifying. VBR Niall O'Reilly From mayer@gis.net Thu Feb 17 05:38:17 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4637F3A6C8B for ; Thu, 17 Feb 2011 05:38:17 -0800 (PST) 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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7VS+VK+yDDdK for ; Thu, 17 Feb 2011 05:38:16 -0800 (PST) Received: from mail1.ntp.org (mail1.ntp.org [IPv6:2001:4f8:fff7:1::5]) by core3.amsl.com (Postfix) with ESMTP id 19ED83A6CC3 for ; Thu, 17 Feb 2011 05:38:15 -0800 (PST) Received: from [198.22.153.9] (helo=[10.60.111.90]) by mail1.ntp.org with esmtpsa (TLSv1:CAMELLIA256-SHA:256) (Exim 4.72 (FreeBSD)) (envelope-from ) id 1Pq43q-0003q6-UJ; Thu, 17 Feb 2011 13:38:34 +0000 Message-ID: <4D5D24F3.70206@gis.net> Date: Thu, 17 Feb 2011 08:38:59 -0500 From: Danny Mayer User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: Mark Andrews References: <20110216032120.43474.qmail@joyce.lan> <20110216212930.57D64A3F344@drugs.dv.isc.org> In-Reply-To: <20110216212930.57D64A3F344@drugs.dv.isc.org> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-SA-Exim-Connect-IP: 198.22.153.9 X-SA-Exim-Rcpt-To: marka@isc.org, dot@dotat.at, johnl@iecc.com, dnsext@ietf.org X-SA-Exim-Mail-From: mayer@gis.net X-SA-Exim-Version: 4.2 X-SA-Exim-Scanned: Yes (on mail1.ntp.org) Cc: John Levine , dnsext@ietf.org Subject: Re: [dnsext] we need help to make names the same, was draft-yao-dnsext-identical-resolution-02 comment X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: mayer@gis.net List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Feb 2011 13:38:17 -0000 On 2/16/2011 4:29 PM, Mark Andrews wrote: > > In message , Tony Fi > nch writes: >> On Wed, 16 Feb 2011, John Levine wrote: >>> >>> It would not be absurd to argue that the most reasonable way to solve >>> the provisioning issues is for the SMTP and HTTP servers to ask the >>> DNS what the canonical name for an otherwise unknown name is, so those >>> servers are just provisioned with the canonical name and an "allow >>> variants" flag. >> >> It used to be the case that SMTP servers would rewrite domains in >> addresses by replacing a CNAME owner with its target. See RFC 1123 section >> 5.2.2. This requirement no longer exists but there is still code out there >> that supports it. I think it would be quite reasonable to add a feature >> for optional cname-based canonicalization to an MTA. (You can probably do >> it now using Exim's configuration language, though it'll probably be a bit >> ugly.) >> >> There is also some HTTP server code out there that hooks into the DNS for >> server name canonicalization - see Apache's UseCanonicalName DNS option, >> which is my fault. It uses reverse DNS lookups (it was designed for >> IP-based virtual hosting) but I don't think it would be hard to do >> something similar based on CNAME records. >> >> Note that server features like this are nice to have but not absolutely >> necessary. > > HTTP abuses CNAME. If HTTP clients where following the design > principles behind CNAME then the HTTP request would be re-written > when a CNAME was seen. Instead they ignored the CNAME and as a > result effectively treated it like a single MX record which is wrong > and has caused problems all along. > > When we actually want to use CNAMEs for what they are designed to > be used for we find HTTP has hijacked them. > > There still isn't a formal RFC for SRV with HTTP. Even if there were I'm not convinced that it would be useful since there is no way on the RHS to specify the path. It can give you a name, a port, a weight and a priority but no path. There was a proposal for a URL RR but I cannot find it right now and I don't think the wg is considering it, at least it's not on the document list. Danny From segred@ics.forth.gr Thu Feb 17 05:57:38 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E45913A6CB8 for ; Thu, 17 Feb 2011 05:57:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.713 X-Spam-Level: X-Spam-Status: No, score=-6.713 tagged_above=-999 required=5 tests=[AWL=-0.114, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ytU-HFGhc5bV for ; Thu, 17 Feb 2011 05:57:38 -0800 (PST) Received: from mailgate.ics.forth.gr (mailgate.ics.forth.gr [139.91.1.2]) by core3.amsl.com (Postfix) with ESMTP id B06983A6CAC for ; Thu, 17 Feb 2011 05:57:37 -0800 (PST) Received: from av1.ics.forth.gr (av1-in.ics.forth.gr [139.91.1.71]) by mailgate.ics.forth.gr (8.14.3/ICS-FORTH/V10-1.8-GATE) with ESMTP id p1HDw58w029031; Thu, 17 Feb 2011 15:58:07 +0200 (EET) X-AuditID: 8b5b9d47-b7c88ae0000076fe-27-4d5d296dcd19 Received: from enigma.ics.forth.gr (webmail.ics.forth.gr [139.91.1.30]) by av1.ics.forth.gr (SMTP Outbound / FORTH / ICS) with SMTP id D6.06.30462.D692D5D4; Thu, 17 Feb 2011 15:58:05 +0200 (EET) Received: from Thanatos (thanatos.ics.forth.gr [139.91.88.160]) (authenticated bits=0) by enigma.ics.forth.gr (8.14.3//ICS-FORTH/V10.3.0C-EXTNULL-SSL-SASL) with ESMTP id p1HDw4jp015686 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Thu, 17 Feb 2011 15:58:05 +0200 X-ICS-AUTH-INFO: Authenticated user: segred at ics.forth.gr From: "Vaggelis Segredakis" To: "'Niall O'Reilly'" References: <4D5B5E81.1050602@necom830.hpcl.titech.ac.jp> <20110216073338.7251.qmail@joyce.lan> <4D5C3B53.8080909@necom830.hpcl.titech.ac.jp> <1FBC914F-F502-4233-AC6C-E7A37728C103@ucd.ie> Date: Thu, 17 Feb 2011 15:56:45 +0200 Message-ID: <18FF623708594B2C999BAB0DD4044936@ics.forth.gr> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: AcvOn0VrKiWYKkI6RSSig3hQ2DyzbQACjE+w X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5994 In-Reply-To: <1FBC914F-F502-4233-AC6C-E7A37728C103@ucd.ie> X-Brightmail-Tracker: AAAAAA== X-j-chkmail-Score: MSGID : 4D5D296D.000 on mailgate : j-chkmail score : . : R=. U=. O=. B=0.000 -> S=0.000 X-ICS-JCHK-SCL: Ham Cc: dnsext@ietf.org Subject: Re: [dnsext] we need help to make names the same, was draft-yao-dnsext-identical-resolution-02 comment X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 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, 17 Feb 2011 13:57:39 -0000 In the present time the registrant gets two IDN domain names, one with tonos and the same without. The IDNA2008 protocol is not yet implemented in the registry and the final sigma is not a different character. It will soon be and we have to discuss with our registrars and registrants what the fee scheme will be then, since the domains with final sigma will need four variants to cover the most usual typing types. To these domain bundles, they can add variants (different tonos positions of the original name) and homographs (names in Latin that look exactly like or very similar to the Greek character domain name). This should be considered the top level of the bundle-tree. Down below, many similar things can happen but they do not happen in our zone file. If you provide the registrant the possibility to set up just a "main" zone and xNAME the rest, the administration will be much easier and cheaper. Best, Vaggelis Segredakis -----Original Message----- From: Niall O'Reilly [mailto:Niall.oReilly@ucd.ie] Sent: Thursday, February 17, 2011 2:36 PM To: Vaggelis Segredakis Cc: dnsext@ietf.org Subject: Re: [dnsext] we need help to make names the same, was draft-yao-dnsext-identical-resolution-02 comment On 17 Feb 2011, at 08:47, Vaggelis Segredakis wrote: > Usually they get two to four names. There is no real limit though. Not all > domain names create huge bundles and even if they do, how many would a user > choose to pay for and for what benefit? Is that to say that the typicl registrant gets 2-4 names from the .GR registry, and may then add further multiplicity further down the hierarchy, depending on requirements and resources? Thanks for confirming and/or clarifying. VBR Niall O'Reilly From segred@ics.forth.gr Thu Feb 17 06:07:48 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 16CA93A6D16 for ; Thu, 17 Feb 2011 06:07:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.7 X-Spam-Level: X-Spam-Status: No, score=-6.7 tagged_above=-999 required=5 tests=[AWL=-0.101, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aMcP9lrjaN-G for ; Thu, 17 Feb 2011 06:07:47 -0800 (PST) Received: from mailgate.ics.forth.gr (mailgate.ics.forth.gr [139.91.1.2]) by core3.amsl.com (Postfix) with ESMTP id 8FCFB3A6D12 for ; Thu, 17 Feb 2011 06:07:46 -0800 (PST) Received: from av1.ics.forth.gr (av1-in.ics.forth.gr [139.91.1.71]) by mailgate.ics.forth.gr (8.14.3/ICS-FORTH/V10-1.8-GATE) with ESMTP id p1HE8Ege029533; Thu, 17 Feb 2011 16:08:16 +0200 (EET) X-AuditID: 8b5b9d47-b7c88ae0000076fe-95-4d5d2bce38e9 Received: from enigma.ics.forth.gr (webmail.ics.forth.gr [139.91.1.30]) by av1.ics.forth.gr (SMTP Outbound / FORTH / ICS) with SMTP id C3.16.30462.ECB2D5D4; Thu, 17 Feb 2011 16:08:14 +0200 (EET) Received: from Thanatos (thanatos.ics.forth.gr [139.91.88.160]) (authenticated bits=0) by enigma.ics.forth.gr (8.14.3//ICS-FORTH/V10.3.0C-EXTNULL-SSL-SASL) with ESMTP id p1HE8D0r016395 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Thu, 17 Feb 2011 16:08:13 +0200 X-ICS-AUTH-INFO: Authenticated user: segred at ics.forth.gr From: "Vaggelis Segredakis" To: "'Masataka Ohta'" , References: <4D5B5E81.1050602@necom830.hpcl.titech.ac.jp><20110216073338.7251.qmail@joyce.lan><20110216165921.GW96213@shinkuro.com><3B90ED2E-980D-4B01-889F-447D66D0B58D@insensate.co.uk><20110216174011.GZ96213@shinkuro.com> <20110217023645.DB105A41C29@drugs.dv.isc.org> <4D5D119A.1070103@necom830.hpcl.titech.ac.jp> Date: Thu, 17 Feb 2011 16:06:53 +0200 Message-ID: <884B191B5A40421D8B9F9933FA41CF6B@ics.forth.gr> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: AcvOnLi/SjwacliXQRW5Zx9mx4VfFwADhY0A X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5994 In-Reply-To: <4D5D119A.1070103@necom830.hpcl.titech.ac.jp> X-Brightmail-Tracker: AAAAAA== X-j-chkmail-Score: MSGID : 4D5D2BCE.000 on mailgate : j-chkmail score : . : R=. U=. O=. B=0.000 -> S=0.000 X-ICS-JCHK-SCL: Ham Subject: Re: [dnsext] we need help to make names the same, was draft-yao-dnsext-identical-resolution-02 comment X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 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, 17 Feb 2011 14:07:48 -0000 >Let your clients synchronize their domains. That would be the easiest thing to do. However, we want to support the users to have a good experience when using their IDN domain names and not condemn the ones that choose an IDN over a Latin name to setup everything two-three-four times. Then there is the extra cost for these setups. I believe you are familiar with the term Local Internet Community. We respect our users need to use IDNs for the Greek characters and we want to support in the best possible way this IDN community to expand in equal terms to the Latin domain names. For this, we try to remove this handicap that is present in the IDNA protocol for the non-latin users. Best, Vaggelis Segredakis -----Original Message----- From: dnsext-bounces@ietf.org [mailto:dnsext-bounces@ietf.org] On Behalf Of Masataka Ohta Sent: Thursday, February 17, 2011 2:16 PM To: dnsext@ietf.org Subject: Re: [dnsext] we need help to make names the same, was draft-yao-dnsext-identical-resolution-02 comment Vaggelis Segredakis wrote: > As a registry we provide them with the domain with tonos in > their chosen position and the domain without it without > extra cost. So, for every IDN registration they get two domain > names. Then, from the beginning, there is no problem of you at all, even though you thought there were. Let your clients synchronize their domains. > For every domain containing a final > sigma they might get four domains per registration. If your clients will pay for the additional four domains, there is no problem. The problem, however, is that its not fair. > If they are meaningless variations of the original domain they are > not too interesting as a product. Just say "iPod". Masataka Ohta _______________________________________________ dnsext mailing list dnsext@ietf.org https://www.ietf.org/mailman/listinfo/dnsext From jra@baylink.com Thu Feb 17 06:30:27 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CF52E3A6CBB for ; Thu, 17 Feb 2011 06:30:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.167 X-Spam-Level: X-Spam-Status: No, score=-2.167 tagged_above=-999 required=5 tests=[AWL=-0.433, BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, RDNS_DYNAMIC=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gvDUaFD3GyKZ for ; Thu, 17 Feb 2011 06:30:27 -0800 (PST) Received: from benjamin.baylink.com (rrcs-24-129-180-187.se.biz.rr.com [24.129.180.187]) by core3.amsl.com (Postfix) with ESMTP id 105953A6D1A for ; Thu, 17 Feb 2011 06:30:26 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by benjamin.baylink.com (Postfix) with ESMTP id 632141F0014E for ; Thu, 17 Feb 2011 09:23:21 -0500 (EST) X-Virus-Scanned: amavisd-new at benjamin.baylink.com Received: from benjamin.baylink.com ([127.0.0.1]) by localhost (benjamin.baylink.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4oFXQxMRrvG1 for ; Thu, 17 Feb 2011 09:23:20 -0500 (EST) Received: by benjamin.baylink.com (Postfix, from userid 501) id 2E3AF1F0014C; Thu, 17 Feb 2011 09:25:23 -0500 (EST) Received: from localhost (localhost.localdomain [127.0.0.1]) by benjamin.baylink.com (Postfix) with ESMTP id 0A29A1F00168 for ; Thu, 17 Feb 2011 09:20:23 -0500 (EST) X-Virus-Scanned: amavisd-new at benjamin.baylink.com Received: from benjamin.baylink.com ([127.0.0.1]) by localhost (benjamin.baylink.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c9JMH9IaI6QF for ; Thu, 17 Feb 2011 09:20:21 -0500 (EST) Received: by benjamin.baylink.com (Postfix, from userid 501) id 9EA051F0016A; Thu, 17 Feb 2011 09:30:06 -0500 (EST) Received: from localhost (localhost.localdomain [127.0.0.1]) by benjamin.baylink.com (Postfix) with ESMTP id 89CB11F00166 for ; Thu, 17 Feb 2011 01:17:03 -0500 (EST) X-Virus-Scanned: amavisd-new at benjamin.baylink.com Received: from benjamin.baylink.com ([127.0.0.1]) by localhost (benjamin.baylink.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m7cHkAX0pJuM for ; Thu, 17 Feb 2011 01:17:02 -0500 (EST) Received: from benjamin.baylink.com (benjamin.baylink.com [192.168.253.10]) by benjamin.baylink.com (Postfix) with ESMTP id DF3481F00121 for ; Thu, 17 Feb 2011 01:17:02 -0500 (EST) Date: Thu, 17 Feb 2011 01:17:02 -0500 (EST) From: Jay Ashworth To: dnsext@ietf.org Message-ID: <20184417.522.1297923422851.JavaMail.root@benjamin.baylink.com> In-Reply-To: <4D5CAC77.2050301@dougbarton.us> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [65.34.93.30] X-Mailer: Zimbra 6.0.9_GA_2686 (ZimbraWebClient - FF3.0 (Linux)/6.0.9_GA_2686) Subject: Re: [dnsext] we need help to make names the same, was draft-yao-dnsext-identical-resolution-02 comment X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 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, 17 Feb 2011 14:30:27 -0000 ----- Original Message ----- > From: "Doug Barton" > Subject: Re: [dnsext] we need help to make names the same, was draft-yao-dnsext-identical-resolution-02 comment > On 02/15/2011 20:17, Jay Ashworth wrote: > > And, as has been pointed out in some other venues, and which seems > > applicable here also, some approachs to certain things *depend on > > trying a DNS lookup and having it break*. I'm damned if I can remember what > > the canonical example was, but it fell in the general category of > > "please don't make this change to try to 'help' 'the web', cause > > you'll break*my* protocol which isn't http". > > It would be really great if we could find a pointer to that discussion, > since some of us are still working on trying to solve the problem and > would prefer not to make things worse. :) Well, clearly it was some thread I was involved in, and it was either on namedroppers (which this is the child of, right?) or NANOG, and it was in the context, I think, of Unicode more generally than I18N names (which is the present context, right? I wandered in late). And I'm pretty sure I Told You So. :-) I'll see if I can either locate it in someone's archives or remember what it was; the argument -- that whatever machination someone was trying to apply to DNS that would make DNS work better would break lots of other protocols -- was not mine; I was merely kibitzing, as I so often do. Cheers, -- jra From jra@baylink.com Thu Feb 17 06:30:28 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3D75C3A6CBB for ; Thu, 17 Feb 2011 06:30:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.95 X-Spam-Level: X-Spam-Status: No, score=-1.95 tagged_above=-999 required=5 tests=[AWL=-0.216, BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, RDNS_DYNAMIC=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uJJvOM4t5tTr for ; Thu, 17 Feb 2011 06:30:27 -0800 (PST) Received: from benjamin.baylink.com (rrcs-24-129-180-187.se.biz.rr.com [24.129.180.187]) by core3.amsl.com (Postfix) with ESMTP id 331B13A6DFF for ; Thu, 17 Feb 2011 06:30:26 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by benjamin.baylink.com (Postfix) with ESMTP id 110BA1F00157 for ; Thu, 17 Feb 2011 09:23:19 -0500 (EST) X-Virus-Scanned: amavisd-new at benjamin.baylink.com Received: from benjamin.baylink.com ([127.0.0.1]) by localhost (benjamin.baylink.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jBFevahs+Kx2 for ; Thu, 17 Feb 2011 09:23:18 -0500 (EST) Received: by benjamin.baylink.com (Postfix, from userid 501) id 000BE1F00166; Thu, 17 Feb 2011 09:25:22 -0500 (EST) Received: from localhost (localhost.localdomain [127.0.0.1]) by benjamin.baylink.com (Postfix) with ESMTP id E17E61F0016E for ; Thu, 17 Feb 2011 09:20:21 -0500 (EST) X-Virus-Scanned: amavisd-new at benjamin.baylink.com Received: from benjamin.baylink.com ([127.0.0.1]) by localhost (benjamin.baylink.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QsVdSQSix+X0 for ; Thu, 17 Feb 2011 09:20:21 -0500 (EST) Received: by benjamin.baylink.com (Postfix, from userid 501) id 8D1961F00168; Thu, 17 Feb 2011 09:54:55 -0500 (EST) Received: from localhost (localhost.localdomain [127.0.0.1]) by benjamin.baylink.com (Postfix) with ESMTP id 7DADF1F0016D for ; Thu, 17 Feb 2011 01:43:09 -0500 (EST) X-Virus-Scanned: amavisd-new at benjamin.baylink.com Received: from benjamin.baylink.com ([127.0.0.1]) by localhost (benjamin.baylink.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BXbBWYpyToO1 for ; Thu, 17 Feb 2011 01:43:08 -0500 (EST) Received: from benjamin.baylink.com (benjamin.baylink.com [192.168.253.10]) by benjamin.baylink.com (Postfix) with ESMTP id 657DC1F00121 for ; Thu, 17 Feb 2011 01:43:08 -0500 (EST) Date: Thu, 17 Feb 2011 01:43:08 -0500 (EST) From: Jay Ashworth To: dnsext@ietf.org Message-ID: <9578464.528.1297924988343.JavaMail.root@benjamin.baylink.com> In-Reply-To: <20110217061445.AAF71A45C08@drugs.dv.isc.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [65.34.93.30] X-Mailer: Zimbra 6.0.9_GA_2686 (ZimbraWebClient - FF3.0 (Linux)/6.0.9_GA_2686) Subject: Re: [dnsext] we need help to make names the same, was draft-yao-dnsext-identical-resolution-02 comment X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 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, 17 Feb 2011 14:30:28 -0000 ----- Original Message ----- > From: "Mark Andrews" > > It would be really great if we could find a pointer to that > > discussion, > > since some of us are still working on trying to solve the problem > > and > > would prefer not to make things worse. :) > > The classic case is the email typo. It fails immediately with > NXDOMAIN but has to wait for the MTA to timeout the connects with > "helpful" address records. Yeah, but I don't think that was it. I wanna say I think it might have been 3LD wildcards to the webserver name, actually, but I'm gonna have to hunt. I can characterize it pretty cleanly, though, as "DNS being configured to lie to querents to make one popular thing work at the expense of making other less common but important things *impossible* (not just slow)". On reflection, it might have been on the Linux Gazette mailing list, too; another place I can check. Cheers, -- jra From ajs@shinkuro.com Thu Feb 17 10:18:35 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EF8503A6D6C for ; Thu, 17 Feb 2011 10:18:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.285 X-Spam-Level: X-Spam-Status: No, score=-102.285 tagged_above=-999 required=5 tests=[AWL=-0.286, BAYES_00=-2.599, J_CHICKENPOX_43=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nuP1CaEzcASd for ; Thu, 17 Feb 2011 10:18:35 -0800 (PST) Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by core3.amsl.com (Postfix) with ESMTP id 4625C3A6D60 for ; Thu, 17 Feb 2011 10:18:35 -0800 (PST) Received: from crankycanuck.ca (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 88FFB1ECB420 for ; Thu, 17 Feb 2011 18:19:05 +0000 (UTC) Date: Thu, 17 Feb 2011 13:19:03 -0500 From: Andrew Sullivan To: dnsext@ietf.org Message-ID: <20110217181903.GF46793@shinkuro.com> References: <20110216165921.GW96213@shinkuro.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.18 (2008-05-17) Subject: Re: [dnsext] we need help to make names the same, was draft-yao-dnsext-identical-resolution-02 comment X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 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, 17 Feb 2011 18:18:36 -0000 No hat. On Thu, Feb 17, 2011 at 10:21:58AM +0200, Vaggelis Segredakis wrote: > That is OK, as long as it provides a solution. However, what you say above > does not imply necessarily the use of "wildcards", right? It is a different > thing to use wildcards in the DNS protocol and completely different to ask > for a group of FQDNs to be the "same". Well, yes, except that we actually already have wildcards. We don't have these other mechanisms. > However, if we do not bring our experience along with > others in this discussion then we discuss solutions that are not applicable > to the real problem. We fully agree here. > somebody loses; the chair will have the task to announce it. However, up to > that specific point of time please be impartial because I have the feeling > you would prefer this discussion to end as soon as possible and that is not > just. I do want the discussion to end as soon as possible, but only in the following sense: I want us to drive towards a conclusion and, if we're going to do something, to do it. We have been in the phase of talking about maybe doing something for a year (or depending on how you count, more), now, and we need to nail down exactly what the problems are, figure out whether we have something useful we can do about them, and then move ahead with doing those things if so. We are supposed to be a working group, after all, not a talk shop. A -- Andrew Sullivan ajs@shinkuro.com Shinkuro, Inc. From wilmer@google.com Thu Feb 17 12:26:15 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 992623A6ABD for ; Thu, 17 Feb 2011 12:26:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.977 X-Spam-Level: X-Spam-Status: No, score=-105.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ihfh1U0PgwoP for ; Thu, 17 Feb 2011 12:26:14 -0800 (PST) Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by core3.amsl.com (Postfix) with ESMTP id 7A06E3A6A00 for ; Thu, 17 Feb 2011 12:26:13 -0800 (PST) Received: from hpaq14.eem.corp.google.com (hpaq14.eem.corp.google.com [172.25.149.14]) by smtp-out.google.com with ESMTP id p1HKQiKG008373 for ; Thu, 17 Feb 2011 12:26:45 -0800 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1297974405; bh=KDza7UZhQA1YRqm+4jzvckyAeD4=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type; b=wgzUuS71OiiLHCjZ0R2fX+dxzxAbfWLyZzpZXWEuYDm3Lt9KhYtZGBI0ZrqzKzdWs WP9ekDxEglJ4dtlgQgxZg== Received: from ewy6 (ewy6.prod.google.com [10.241.103.6]) by hpaq14.eem.corp.google.com with ESMTP id p1HKQESU022642 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Thu, 17 Feb 2011 12:26:43 -0800 Received: by ewy6 with SMTP id 6so1197989ewy.12 for ; Thu, 17 Feb 2011 12:26:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=cg2pdsOcSL/UiS6yGELISCZFb4++erhhcbIx1VC5Lak=; b=C3hSRwntwCDqGNAXiPBl64bbyTfXqgWDfiks3xfTM4hiK+KG8LbvsK46I3ZsJNY1Rt vJQCsAAABt3WfFaOBSpA== DomainKey-Signature: a=rsa-sha1; c=nofws; d=google.com; s=beta; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=Rb5BI6B3FK3BonyFPBewOi+vt91iKlGuAXzwYM1qHQMsPqmLUEaiB9hAXPmfBBHfY1 YH2QD5+syJDtMScvP0Tg== MIME-Version: 1.0 Received: by 10.213.3.20 with SMTP id 20mr2807176ebl.5.1297974400456; Thu, 17 Feb 2011 12:26:40 -0800 (PST) Received: by 10.213.14.139 with HTTP; Thu, 17 Feb 2011 12:26:40 -0800 (PST) In-Reply-To: References: Date: Thu, 17 Feb 2011 20:26:40 +0000 Message-ID: From: Wilmer van der Gaast To: dnsext@ietf.org Content-Type: text/plain; charset=ISO-8859-1 X-System-Of-Record: true Cc: edns-client-subnet@googlegroups.com Subject: Re: [dnsext] Uploaded: edns-client-subnet-00 X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 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, 17 Feb 2011 20:26:15 -0000 On 9 February 2011 13:01, Wilmer van der Gaast wrote: > Also, since the release of the last draft we have: > > * Added support for handling edns-client-subnet options to both our > authoritative nameservers and Google Public DNS, using option code > 0x50fa (not officially allocated and *not* to be used permanently). > * Started a small-scale experiment of using edns-client-subnet in real > life, to measure latency improvements and confirm that the idea is > generally feasible. We're working with several third parties (CDNs but > also resolvers) and are looking forward to hearing from anyone else > interested in participating. > Addition to this: * Wrote a patch against BIND's dig utility that adds a +client= flag to send edns-client-subnet options, useful to test and debug implementations. The patch can be downloaded from http://wilmer.gaa.st/edns-client-subnet/. Regards, -- Wilmer van der Gaast, Traffic SRE/Google Public DNS team. Google Ireland. From fneves@registro.br Thu Feb 17 15:16:09 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BBA503A6CC3 for ; Thu, 17 Feb 2011 15:16:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.446 X-Spam-Level: X-Spam-Status: No, score=-0.446 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FRT_BELOW2=2.154, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wPKX6INBaTqL for ; Thu, 17 Feb 2011 15:16:08 -0800 (PST) Received: from clone.registro.br (clone.registro.br [IPv6:2001:12ff:0:2::4]) by core3.amsl.com (Postfix) with ESMTP id 0621D3A6CEC for ; Thu, 17 Feb 2011 15:16:08 -0800 (PST) Received: by clone.registro.br (Postfix, from userid 1000) id 5BF06E0457; Thu, 17 Feb 2011 21:16:38 -0200 (BRST) Date: Thu, 17 Feb 2011 21:16:38 -0200 From: Frederico A C Neves To: dnsext@ietf.org Message-ID: <20110217231638.GA42567@registro.br> References: <20110127134320.GC91248@registro.br> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20110127134320.GC91248@registro.br> Cc: iana-prot-param@iana.org Subject: Re: [dnsext] URI RRTYPE review - Result [IANA #376037] X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 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, 17 Feb 2011 23:16:09 -0000 Dear Colleagues, This message ends the review process for the URI RRTYPE, according to my judgment it meets both requirements of section 3.1.1 and none of section 3.1.2 of RFC5395 and should be accepted. Best Regards, Frederico Neves On Thu, Jan 27, 2011 at 11:43:20AM -0200, Frederico A C Neves wrote: > Dear Colleagues, > > Bellow is a resubmission of a completed template requesting a new > RRTYPE assignment under the procedures of RFC5395. > > This message starts a 3 weeks period for an expert-review of the DNS > RRTYPE parameter allocation for URI specified in > http://tools.ietf.org/html/draft-faltstrom-uri-05 > > If you have any new comments regarding this request that have not yet > being made at the thread starting with message > http://www.ietf.org/mail-archive/web/dnsext/current/msg08956.html , > please post them here before Feb 17th 18:00 UTC > > Best Regards, > Frederico Neves > > --begin 5395 template URI-- > A. Submission Date: > > May 23, 2009 > > B. Submission Type: > > [X] New RRTYPE > [ ] Modification to existing RRTYPE > > C. Contact Information for submitter: > > Name: Patrik Faltstrom > Email Address: paf@cisco.com > International telephone number: +46-8-6859131 > Other contact handles: > (Note: This information will be publicly posted.) > > D. Motivation for the new RRTYPE application? > > There is no easy way to get from a domain name to a URI. Some > mechanisms exists via use of the NAPTR [RFC3403] resource > record. That implies quite complicated rules that are > simplified via the S-NAPTR [RFC3958] specification. But, the > ability to directly look up a URI still exists. This > specification uses a prefix based naming mechanism originated in > the definition of the SRV [RFC2782] resource record, and the > RDATA is a URI, encoded as one text field. > > See also Section 1 in draft-faltstrom-uri-05.txt. > > E. Description of the proposed RR type. > > The format of the URI resource record is as follows: > > > Ownername TTL Class URI Priority Weight Target > > > The URI RR has service information encoded in its ownername. In > order to encode the service for a specific owner name one uses > service parameters. Valid service parameters used are either > Enumservice Registrations registered by IANA, or prefixes used > for the SRV resource record. > > The wire format of the RDATA is as follows: > > > 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Priority | Weight | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > / / > / Target / > / / > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > F. What existing RRTYPE or RRTYPEs come closest to filling that > need and why are they unsatisfactory? > > The RRTYPE that come closest is the NAPTR resource record. It > is for example used in the DDDS and S-NAPTR algorithms. The > main problem with the NAPTR is that selection of what record (or > records) one is interested in is based on data stored in the > RDATA portion of the NAPTR resource record. This, as explained > in RFC 5507 [RFC5507], is not optimal for DNS lookups. Further, > most applications using NAPTR resource records uses regular > expression based rewrite rules for creation of the URI, and that > has shown be complicated to implement. > > The second closest RRTYPE is the SRV record that given a > prefixed based naming just like is suggested for the URI > resource record, one get back a port number and domain name. > This can also be used for creation of a URI, but, only URIs > without path components. > > G. What mnemonic is requested for the new RRTYPE (optional)? > > URI > > H. Does the requested RRTYPE make use of any existing IANA Registry > or require the creation of a new IANA sub-registry in DNS > Parameters? > > Yes, partially. > > One of the mechanisms to select a service is to use the > Enumservice Registry managed by IANA. Another is to use > services and protocols used for SRV records. > > I. Does the proposal require/expect any changes in DNS servers/ > resolvers that prevent the new type from being processed as an > unknown RRTYPE (see [RFC3597])? > > No > > J. Comments: > > None > --end 5395 template URI-- > _______________________________________________ > dnsext mailing list > dnsext@ietf.org > https://www.ietf.org/mailman/listinfo/dnsext From marka@isc.org Thu Feb 17 15:17:04 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8ABBB3A6CEC for ; Thu, 17 Feb 2011 15:17:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.579 X-Spam-Level: X-Spam-Status: No, score=-2.579 tagged_above=-999 required=5 tests=[AWL=0.020, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A7ELBEPfZjn5 for ; Thu, 17 Feb 2011 15:17:03 -0800 (PST) Received: from mx.pao1.isc.org (mx.pao1.isc.org [IPv6:2001:4f8:0:2::2b]) by core3.amsl.com (Postfix) with ESMTP id AD7A43A6CC3 for ; Thu, 17 Feb 2011 15:17:03 -0800 (PST) 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 553A2C9429; Thu, 17 Feb 2011 23:17:25 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (drugs.dv.isc.org [IPv6:2001:470:1f00:820:ea06:88ff:fef3:4f9c]) (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 E1973216C1E; Thu, 17 Feb 2011 23:17: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 1FCF3A49096; Fri, 18 Feb 2011 10:17:20 +1100 (EST) To: mayer@gis.net From: Mark Andrews References: <20110216032120.43474.qmail@joyce.lan> <20110216212930.57D64A3F344@drugs.dv.isc.org><4D5D24F3.70206@gis.net> In-reply-to: Your message of "Thu, 17 Feb 2011 08:38:59 CDT." <4D5D24F3.70206@gis.net> Date: Fri, 18 Feb 2011 10:17:20 +1100 Message-Id: <20110217231720.1FCF3A49096@drugs.dv.isc.org> Cc: John Levine , dnsext@ietf.org Subject: Re: [dnsext] we need help to make names the same, was draft-yao-dnsext-identical-resolution-02 comment X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 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, 17 Feb 2011 23:17:04 -0000 In message <4D5D24F3.70206@gis.net>, Danny Mayer writes: > Even if there were I'm not convinced that it would be useful since there > is no way on the RHS to specify the path. It can give you a name, a > port, a weight and a priority but no path. There was a proposal for a > URL RR but I cannot find it right now and I don't think the wg is > considering it, at least it's not on the document list. > > Danny Which can be dealt with entirely at the HTTP/S layer. People are using CNAME for site -> hosting server this include "www.example.net CNAME example.net". We need to support site alias -> site { -> hosting server } CNAME NEW-TYPE Additionally people are too lazy to add records for each virtual service in the DNS so they use "* CNAME server" which makes using SRV hard as it requires prepended labels. To prevent breaking existing clients that use CNAME like NEW-TYPE client would look for NEW-TYPE and only re-write the URL there is a CNAME and a NEW-TYPE returned. The CNAME would be replace by NEW-TYPE + addresses records to help with the transition. This is very much like the introduction of MX records. At some point you stop putting in address records. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From mayer@gis.net Thu Feb 17 19:18:48 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 589123A6DA1 for ; Thu, 17 Feb 2011 19:18:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, WEIRD_PORT=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ieX-dIgigPXN for ; Thu, 17 Feb 2011 19:18:47 -0800 (PST) Received: from mail1.ntp.org (mail1.ntp.org [IPv6:2001:4f8:fff7:1::5]) by core3.amsl.com (Postfix) with ESMTP id 6BFDE3A6D72 for ; Thu, 17 Feb 2011 19:18:47 -0800 (PST) Received: from cust-63-209-235-31.bos-dynamic.gis.net ([63.209.235.31] helo=[10.10.10.101]) by mail1.ntp.org with esmtpsa (TLSv1:CAMELLIA256-SHA:256) (Exim 4.72 (FreeBSD)) (envelope-from ) id 1PqGs1-000HtG-Ca; Fri, 18 Feb 2011 03:19:12 +0000 Message-ID: <4D5DE54C.5010104@gis.net> Date: Thu, 17 Feb 2011 22:19:40 -0500 From: Danny Mayer User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: Mark Andrews References: <20110216032120.43474.qmail@joyce.lan> <20110216212930.57D64A3F344@drugs.dv.isc.org><4D5D24F3.70206@gis.net> <20110217231720.1FCF3A49096@drugs.dv.isc.org> In-Reply-To: <20110217231720.1FCF3A49096@drugs.dv.isc.org> X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-SA-Exim-Connect-IP: 63.209.235.31 X-SA-Exim-Rcpt-To: marka@isc.org, dot@dotat.at, johnl@iecc.com, dnsext@ietf.org X-SA-Exim-Mail-From: mayer@gis.net X-SA-Exim-Version: 4.2 X-SA-Exim-Scanned: Yes (on mail1.ntp.org) Cc: John Levine , dnsext@ietf.org Subject: Re: [dnsext] we need help to make names the same, was draft-yao-dnsext-identical-resolution-02 comment X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: mayer@gis.net List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Feb 2011 03:18:48 -0000 On 2/17/2011 6:17 PM, Mark Andrews wrote: > In message <4D5D24F3.70206@gis.net>, Danny Mayer writes: >> Even if there were I'm not convinced that it would be useful since there >> is no way on the RHS to specify the path. It can give you a name, a >> port, a weight and a priority but no path. There was a proposal for a >> URL RR but I cannot find it right now and I don't think the wg is >> considering it, at least it's not on the document list. >> >> Danny > > Which can be dealt with entirely at the HTTP/S layer. > Not for the purpose I'm looking to use it. For the particular purpose the SOAP Servlet path needs to be different from the regular login URL and there is no way to express that. It needs to be like an SRV record so that the particular SOAP service can be located. > People are using CNAME for > > site -> hosting server > > this include "www.example.net CNAME example.net". > > We need to support > > site alias -> site { -> hosting server } > > CNAME NEW-TYPE > > Additionally people are too lazy to add records for each virtual > service in the DNS so they use "* CNAME server" which makes using > SRV hard as it requires prepended labels. > > To prevent breaking existing clients that use CNAME like NEW-TYPE > client would look for NEW-TYPE and only re-write the URL there is > a CNAME and a NEW-TYPE returned. > > The CNAME would be replace by NEW-TYPE + addresses records to > help with the transition. > > This is very much like the introduction of MX records. At > some point you stop putting in address records. Maybe you can give an example of how to get to the following URL for a SOAP Service and a regular login otherwise for the same host and port number. http://ws.example.net:5678/Ws/SOAPServlet for SOAP Service and continue to allow regular http access to the URL http://ws.example.net/Ws/Servlet for people who need to just login. This is a real example BTW and the current implementation stores the SOAP service URL locally. If I could figure out a way of using SRV records I would. Danny From marka@isc.org Thu Feb 17 19:47:21 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D27833A6C24 for ; Thu, 17 Feb 2011 19:47:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.581 X-Spam-Level: X-Spam-Status: No, score=-2.581 tagged_above=-999 required=5 tests=[AWL=0.017, BAYES_00=-2.599, WEIRD_PORT=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ftle+NPudzYY for ; Thu, 17 Feb 2011 19:47:21 -0800 (PST) Received: from mx.pao1.isc.org (mx.pao1.isc.org [IPv6:2001:4f8:0:2::2b]) by core3.amsl.com (Postfix) with ESMTP id 9C51F3A6C21 for ; Thu, 17 Feb 2011 19:47:20 -0800 (PST) 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 8C7E8C941E; Fri, 18 Feb 2011 03:47:42 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (drugs.dv.isc.org [IPv6:2001:470:1f00:820:ea06:88ff:fef3:4f9c]) (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 1A0AA216C1E; Fri, 18 Feb 2011 03:47: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 9B601A4D098; Fri, 18 Feb 2011 14:47:37 +1100 (EST) To: mayer@gis.net From: Mark Andrews References: <20110216032120.43474.qmail@joyce.lan> <20110216212930.57D64A3F344@drugs.dv.isc.org><4D5D24F3.70206@gis.net> <20110217231720.1FCF3A49096@drugs.dv.isc.org><4D5DE54C.5010104@gis.net> In-reply-to: Your message of "Thu, 17 Feb 2011 22:19:40 CDT." <4D5DE54C.5010104@gis.net> Date: Fri, 18 Feb 2011 14:47:37 +1100 Message-Id: <20110218034737.9B601A4D098@drugs.dv.isc.org> Cc: John Levine , dnsext@ietf.org Subject: Re: [dnsext] we need help to make names the same, was draft-yao-dnsext-identical-resolution-02 comment X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 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, 18 Feb 2011 03:47:21 -0000 In message <4D5DE54C.5010104@gis.net>, Danny Mayer writes: > On 2/17/2011 6:17 PM, Mark Andrews wrote: > > In message <4D5D24F3.70206@gis.net>, Danny Mayer writes: > >> Even if there were I'm not convinced that it would be useful since there > >> is no way on the RHS to specify the path. It can give you a name, a > >> port, a weight and a priority but no path. There was a proposal for a > >> URL RR but I cannot find it right now and I don't think the wg is > >> considering it, at least it's not on the document list. > >> > >> Danny > > > > Which can be dealt with entirely at the HTTP/S layer. > > > > Not for the purpose I'm looking to use it. For the particular purpose > the SOAP Servlet path needs to be different from the regular login URL > and there is no way to express that. It needs to be like an SRV record > so that the particular SOAP service can be located. > > > People are using CNAME for > > > > site -> hosting server > > > > this include "www.example.net CNAME example.net". > > > > We need to support > > > > site alias -> site { -> hosting server } > > > > CNAME NEW-TYPE > > > > Additionally people are too lazy to add records for each virtual > > service in the DNS so they use "* CNAME server" which makes using > > SRV hard as it requires prepended labels. > > > > To prevent breaking existing clients that use CNAME like NEW-TYPE > > client would look for NEW-TYPE and only re-write the URL there is > > a CNAME and a NEW-TYPE returned. > > > > The CNAME would be replace by NEW-TYPE + addresses records to > > help with the transition. > > > > This is very much like the introduction of MX records. At > > some point you stop putting in address records. > > Maybe you can give an example of how to get to the following URL for a > SOAP Service and a regular login otherwise for the same host and port > number. > > http://ws.example.net:5678/Ws/SOAPServlet for SOAP Service and continue > to allow regular http access to the URL http://ws.example.net/Ws/Servlet > for people who need to just login. This is a real example BTW and the > current implementation stores the SOAP service URL locally. If I could > figure out a way of using SRV records I would. It helps to use the right scheme (RFC3288). It should be "soap.beep://ws.example.net:5678/Ws/SOAPServlet" not "http://ws.example.net:5678/Ws/SOAPServlet". The client can then make appropriate DNS lookups. _soap_beep._tcp.ws.example.net SRV .... > Danny -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From mayer@gis.net Thu Feb 17 20:05:28 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C197F3A6C26 for ; Thu, 17 Feb 2011 20:05:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, WEIRD_PORT=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iph76Vfnl0nO for ; Thu, 17 Feb 2011 20:05:28 -0800 (PST) Received: from mail1.ntp.org (mail1.ntp.org [IPv6:2001:4f8:fff7:1::5]) by core3.amsl.com (Postfix) with ESMTP id C762D3A6C24 for ; Thu, 17 Feb 2011 20:05:27 -0800 (PST) Received: from cust-63-209-235-31.bos-dynamic.gis.net ([63.209.235.31] helo=[10.10.10.101]) by mail1.ntp.org with esmtpsa (TLSv1:CAMELLIA256-SHA:256) (Exim 4.72 (FreeBSD)) (envelope-from ) id 1PqHbE-000LOC-My; Fri, 18 Feb 2011 04:05:55 +0000 Message-ID: <4D5DF040.6030404@gis.net> Date: Thu, 17 Feb 2011 23:06:24 -0500 From: Danny Mayer User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: Mark Andrews References: <20110216032120.43474.qmail@joyce.lan> <20110216212930.57D64A3F344@drugs.dv.isc.org><4D5D24F3.70206@gis.net> <20110217231720.1FCF3A49096@drugs.dv.isc.org><4D5DE54C.5010104@gis.net> <20110218034737.9B601A4D098@drugs.dv.isc.org> In-Reply-To: <20110218034737.9B601A4D098@drugs.dv.isc.org> X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-SA-Exim-Connect-IP: 63.209.235.31 X-SA-Exim-Rcpt-To: marka@isc.org, dot@dotat.at, johnl@iecc.com, dnsext@ietf.org X-SA-Exim-Mail-From: mayer@gis.net X-SA-Exim-Version: 4.2 X-SA-Exim-Scanned: Yes (on mail1.ntp.org) Cc: John Levine , dnsext@ietf.org Subject: Re: [dnsext] we need help to make names the same, was draft-yao-dnsext-identical-resolution-02 comment X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: mayer@gis.net List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Feb 2011 04:05:28 -0000 On 2/17/2011 10:47 PM, Mark Andrews wrote: > In message <4D5DE54C.5010104@gis.net>, Danny Mayer writes: >> On 2/17/2011 6:17 PM, Mark Andrews wrote: >>> In message <4D5D24F3.70206@gis.net>, Danny Mayer writes: >>>> Even if there were I'm not convinced that it would be useful since there >>>> is no way on the RHS to specify the path. It can give you a name, a >>>> port, a weight and a priority but no path. There was a proposal for a >>>> URL RR but I cannot find it right now and I don't think the wg is >>>> considering it, at least it's not on the document list. >>>> >>>> Danny >>> >>> Which can be dealt with entirely at the HTTP/S layer. >>> >> >> Not for the purpose I'm looking to use it. For the particular purpose >> the SOAP Servlet path needs to be different from the regular login URL >> and there is no way to express that. It needs to be like an SRV record >> so that the particular SOAP service can be located. >> >>> People are using CNAME for >>> >>> site -> hosting server >>> >>> this include "www.example.net CNAME example.net". >>> >>> We need to support >>> >>> site alias -> site { -> hosting server } >>> >>> CNAME NEW-TYPE >>> >>> Additionally people are too lazy to add records for each virtual >>> service in the DNS so they use "* CNAME server" which makes using >>> SRV hard as it requires prepended labels. >>> >>> To prevent breaking existing clients that use CNAME like NEW-TYPE >>> client would look for NEW-TYPE and only re-write the URL there is >>> a CNAME and a NEW-TYPE returned. >>> >>> The CNAME would be replace by NEW-TYPE + addresses records to >>> help with the transition. >>> >>> This is very much like the introduction of MX records. At >>> some point you stop putting in address records. >> >> Maybe you can give an example of how to get to the following URL for a >> SOAP Service and a regular login otherwise for the same host and port >> number. >> >> http://ws.example.net:5678/Ws/SOAPServlet for SOAP Service and continue >> to allow regular http access to the URL http://ws.example.net/Ws/Servlet >> for people who need to just login. This is a real example BTW and the >> current implementation stores the SOAP service URL locally. If I could >> figure out a way of using SRV records I would. > > It helps to use the right scheme (RFC3288). It should be > "soap.beep://ws.example.net:5678/Ws/SOAPServlet" not > "http://ws.example.net:5678/Ws/SOAPServlet". > > The client can then make appropriate DNS lookups. > > _soap_beep._tcp.ws.example.net SRV .... I don't care about the transport piece since that's on the LHS. It's the path that cannot be specified here. Where do I go to get the /Ws/SOAPServlet part? The path is going to be different for each site. I'd love to use SRV records particularly as Brian W implemented a Java DNS library (dnsjava from xbill) that supports SRV records. Danny From marka@isc.org Thu Feb 17 20:32:07 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A51AB3A6D33 for ; Thu, 17 Feb 2011 20:32:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.583 X-Spam-Level: X-Spam-Status: No, score=-2.583 tagged_above=-999 required=5 tests=[AWL=0.015, BAYES_00=-2.599, WEIRD_PORT=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Wh-yG+16QF+u for ; Thu, 17 Feb 2011 20:32:06 -0800 (PST) Received: from mx.ams1.isc.org (mx.ams1.isc.org [IPv6:2001:500:60::65]) by core3.amsl.com (Postfix) with ESMTP id 63C0B3A6C24 for ; Thu, 17 Feb 2011 20:32:06 -0800 (PST) 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 E3ECE5F98EA; Fri, 18 Feb 2011 04:32:17 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (drugs.dv.isc.org [IPv6:2001:470:1f00:820:ea06:88ff:fef3:4f9c]) (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 87E36216C22; Fri, 18 Feb 2011 04:32:10 +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 AB350A4D593; Fri, 18 Feb 2011 15:32:00 +1100 (EST) To: mayer@gis.net From: Mark Andrews References: <20110216032120.43474.qmail@joyce.lan> <20110216212930.57D64A3F344@drugs.dv.isc.org><4D5D24F3.70206@gis.net> <20110217231720.1FCF3A49096@drugs.dv.isc.org><4D5DE54C.5010104@gis.net> <20110218034737.9B601A4D098@drugs.dv.isc.org> <4D5DF040.6030404@gis.net> In-reply-to: Your message of "Thu, 17 Feb 2011 23:06:24 CDT." <4D5DF040.6030404@gis.net> Date: Fri, 18 Feb 2011 15:32:00 +1100 Message-Id: <20110218043200.AB350A4D593@drugs.dv.isc.org> Cc: John Levine , dnsext@ietf.org Subject: Re: [dnsext] we need help to make names the same, was draft-yao-dnsext-identical-resolution-02 comment X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 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, 18 Feb 2011 04:32:07 -0000 In message <4D5DF040.6030404@gis.net>, Danny Mayer writes: > On 2/17/2011 10:47 PM, Mark Andrews wrote: > > In message <4D5DE54C.5010104@gis.net>, Danny Mayer writes: > >> On 2/17/2011 6:17 PM, Mark Andrews wrote: > >>> In message <4D5D24F3.70206@gis.net>, Danny Mayer writes: > >>>> Even if there were I'm not convinced that it would be useful since there > >>>> is no way on the RHS to specify the path. It can give you a name, a > >>>> port, a weight and a priority but no path. There was a proposal for a > >>>> URL RR but I cannot find it right now and I don't think the wg is > >>>> considering it, at least it's not on the document list. > >>>> > >>>> Danny > >>> > >>> Which can be dealt with entirely at the HTTP/S layer. > >>> > >> > >> Not for the purpose I'm looking to use it. For the particular purpose > >> the SOAP Servlet path needs to be different from the regular login URL > >> and there is no way to express that. It needs to be like an SRV record > >> so that the particular SOAP service can be located. > >> > >>> People are using CNAME for > >>> > >>> site -> hosting server > >>> > >>> this include "www.example.net CNAME example.net". > >>> > >>> We need to support > >>> > >>> site alias -> site { -> hosting server } > >>> > >>> CNAME NEW-TYPE > >>> > >>> Additionally people are too lazy to add records for each virtual > >>> service in the DNS so they use "* CNAME server" which makes using > >>> SRV hard as it requires prepended labels. > >>> > >>> To prevent breaking existing clients that use CNAME like NEW-TYPE > >>> client would look for NEW-TYPE and only re-write the URL there is > >>> a CNAME and a NEW-TYPE returned. > >>> > >>> The CNAME would be replace by NEW-TYPE + addresses records to > >>> help with the transition. > >>> > >>> This is very much like the introduction of MX records. At > >>> some point you stop putting in address records. > >> > >> Maybe you can give an example of how to get to the following URL for a > >> SOAP Service and a regular login otherwise for the same host and port > >> number. > >> > >> http://ws.example.net:5678/Ws/SOAPServlet for SOAP Service and continue > >> to allow regular http access to the URL http://ws.example.net/Ws/Servlet > >> for people who need to just login. This is a real example BTW and the > >> current implementation stores the SOAP service URL locally. If I could > >> figure out a way of using SRV records I would. > > > > It helps to use the right scheme (RFC3288). It should be > > "soap.beep://ws.example.net:5678/Ws/SOAPServlet" not > > "http://ws.example.net:5678/Ws/SOAPServlet". > > > > The client can then make appropriate DNS lookups. > > > > _soap_beep._tcp.ws.example.net SRV .... > > > I don't care about the transport piece since that's on the LHS. It's the > path that cannot be specified here. Where do I go to get the > /Ws/SOAPServlet part? The path is going to be different for each site. > I'd love to use SRV records particularly as Brian W implemented a Java > DNS library (dnsjava from xbill) that supports SRV records. That's the job of NAPTR records. > Danny -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From brian.peter.dickson@gmail.com Thu Feb 17 21:48:50 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EDAC73A69D0 for ; Thu, 17 Feb 2011 21:48:50 -0800 (PST) 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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ap6iPGb87GrL for ; Thu, 17 Feb 2011 21:48:42 -0800 (PST) Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by core3.amsl.com (Postfix) with ESMTP id EDBCA3A6AA7 for ; Thu, 17 Feb 2011 21:48:41 -0800 (PST) Received: by fxm9 with SMTP id 9so3560028fxm.31 for ; Thu, 17 Feb 2011 21:49:14 -0800 (PST) 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=1/jwOIMWSLGIkHMZfIx4qlDepnHC10lkWO/OgDbzOak=; b=M+WMrIoZhWJ53FeRpRK4YA5H77G8pXcaQ1PpfzwD+p0SAEAlUER/Mt2zeTzNCfDw3v IM644xE8ypvIbLY/4GIFpXcill/jGxy+HDowO/FUZ+yRk4blKFVLej3EdCpE0a/uKIuz lMKhuHYPsrEirmRrfk7jO4JFxcWBKJr8XDipE= 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=BxM2Q7JepthE/WsilZFdsT29/hKB6HTAzciHh2peZlRnyvJVeiUwdwWiB0SEZoBypn GPPuVK6B2QnxVGj3nteJeCFJdnTj9yjgQ72j7sJ4pwCGSb2Sjzdcswi9nC1kHtJ3AqN+ KMYGteqRoqIjxGee8xUJ4lwuGFVXB0PIaPHdE= MIME-Version: 1.0 Received: by 10.223.73.202 with SMTP id r10mr413211faj.133.1298008140951; Thu, 17 Feb 2011 21:49:00 -0800 (PST) Received: by 10.223.107.132 with HTTP; Thu, 17 Feb 2011 21:49:00 -0800 (PST) In-Reply-To: <20110217231720.1FCF3A49096@drugs.dv.isc.org> References: <20110216032120.43474.qmail@joyce.lan> <20110216212930.57D64A3F344@drugs.dv.isc.org> <4D5D24F3.70206@gis.net> <20110217231720.1FCF3A49096@drugs.dv.isc.org> Date: Thu, 17 Feb 2011 21:49:00 -0800 Message-ID: From: Brian Dickson To: Mark Andrews Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: John Levine , dnsext@ietf.org Subject: Re: [dnsext] we need help to make names the same, was draft-yao-dnsext-identical-resolution-02 comment X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 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, 18 Feb 2011 05:48:51 -0000 I think there definitely needs to be a new combination of things: RRTYPE, semantics, and API. Overloading CNAME, while attractive, is likely to cause problems. It is also limited by what CNAME permits for RDATA. Consider a generic example, where there may be multiple equivalences at multiple locations of a FQDN A.B.C.example.gr (say). Say we have A1,A2,A3, and A4 that are all meant to be "the same", and we want the "official" (canonical) name used to be A1. Similarly, B1 for B2/B3/B4, C1 for C2/C3/C4. It would be both cumbersome, and bloated, to have to put all combinations into DNS as CNAMEs. It would also be limiting to put other requirements onto how the zone structure was built (such as requiring delegations/zone cuts). Lets consider two aspects of the naming issue. First, is the "same resolution" problem - having all combinations An.Bn.Cn.example.gr resolve identically (such as with A records). (We can leave that for another day, to discuss how to do that.) Second, is having all such combinations advise the client what the "canonical" name should be, i.e. A1.B1.C1.example.gr. Having these two handled orthogonally, means there are two distinct problems. It also means that the second problem is effectively "opt-in"; it doesn't break anything that doesn't explicitly query for it or understand it. It doesn't change the semantics of existing DNS stuff. Adding a new API, call it "dns_canonicalize()", lets things that care, look up FQDNs, and get back "canonical FQDNs". Ideally, the results of "gethostbyname(FQDN)" and "gethostbyname(dns_canonicalize(FQDN))" would return the same values, but I don't think it should be a strict requirement, rather a "principal of least surprise" recommendation to zone operators. The new RRTYPE could be, for example, CLABEL. A CLABEL's RDATA would be either a "label", i.e. relative domain name, or an FQDN (ending with a "." to anchor it at the root.) So, in our example, A3.B2.C3.example.gr could be a CLABEL of "A1", meaning only the left-most label has a "canonical" preferred label. And B2.C3.example.gr could have a CLABEL of "B1", and C3.example.gr could have a CLABEL of "C1". The resolver implementing "dns_canonicalize" would start with the FQDN, and work right-to-left (top down), looking for CLABELs at each node. Any time a CLABEL is found, rewriting is done, either relative (current label), or absolute (everything to the right). So, "dns_canonicalize("A3.B2.C3.example.gr")" would proceed as: A3.B2.C3.example.gr (no CLABEL at gr) A3.B2.C3.example.gr (no CLABEL at example.gr) A3.B2.C1.example.gr (CLABEL at C3 -> C1) A3.B1.C1.example.gr (CLABEL at B2 -> B1) A1.B1.C1.example.gr (CLABEL at A3 -> A1). The extra code in a web browser would be taking what the user typed in the address bar, apply (dns_canonicalize), and use the resulting name as the correct name to open the http (or whatever) connection to the server found at the corresponding A (or AAAA) record (or whatever else gets used in figuring out where to go and what to do). I think this has good scaling properties, doesn't break anything, and is likely to be useful to those who need it. It doesn't matter if 97% of the DNS namespace doesn't have any CLABELs, IMHO, as long as the mechanism has adequate support at both the DNS protocol and the application layers. Brian P.S. Perhaps CLABELs could be included in the additional section, if QTYPE !=3D CLABEL, to reduce delays, server load, etc. (?) On Thu, Feb 17, 2011 at 3:17 PM, Mark Andrews wrote: > > In message <4D5D24F3.70206@gis.net>, Danny Mayer writes: >> Even if there were I'm not convinced that it would be useful since there >> is no way on the RHS to specify the path. It can give you a name, a >> port, a weight and a priority but no path. There was a proposal for a >> URL RR but I cannot find it right now and I don't think the wg is >> considering it, at least it's not on the document list. >> >> Danny > > Which can be dealt with entirely at the HTTP/S layer. > > People are using CNAME for > > =A0 =A0 =A0 =A0site -> hosting server > > this include "www.example.net CNAME example.net". > > We need to support > > =A0 =A0 =A0 =A0site alias -> site { -> hosting server } > > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 CNAME =A0 =A0NEW-TYPE > > Additionally people are too lazy to add records for each virtual > service in the DNS so they use "* CNAME server" which makes using > SRV hard as it requires prepended labels. > > To prevent breaking existing clients that use CNAME like NEW-TYPE > client would look for NEW-TYPE and only re-write the URL there is > a CNAME and a NEW-TYPE returned. > > The CNAME would be replace by NEW-TYPE + addresses records to > help with the transition. > > This is very much like the introduction of MX records. =A0At > some point you stop putting in address records. > > Mark > -- > Mark Andrews, ISC > 1 Seymour St., Dundas Valley, NSW 2117, Australia > PHONE: +61 2 9871 4742 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 INTERNET: marka@is= c.org > _______________________________________________ > dnsext mailing list > dnsext@ietf.org > https://www.ietf.org/mailman/listinfo/dnsext > From mohta@necom830.hpcl.titech.ac.jp Thu Feb 17 21:51:42 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3D5D03A6AA9 for ; Thu, 17 Feb 2011 21:51:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.104 X-Spam-Level: X-Spam-Status: No, score=-0.104 tagged_above=-999 required=5 tests=[AWL=-0.014, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SMQOQLCNgbyM for ; Thu, 17 Feb 2011 21:51:41 -0800 (PST) Received: from necom830.hpcl.titech.ac.jp (necom830.hpcl.titech.ac.jp [131.112.32.132]) by core3.amsl.com (Postfix) with SMTP id 09B773A69D0 for ; Thu, 17 Feb 2011 21:51:40 -0800 (PST) Received: (qmail 10083 invoked from network); 18 Feb 2011 06:02:53 -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 Feb 2011 06:02:53 -0000 Message-ID: <4D5E08E4.8060106@necom830.hpcl.titech.ac.jp> Date: Fri, 18 Feb 2011 14:51:32 +0900 From: Masataka Ohta User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; ja; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: dnsext@ietf.org References: <20110216032120.43474.qmail@joyce.lan> <20110216212930.57D64A3F344@drugs.dv.isc.org><4D5D24F3.70206@gis.net> <20110217231720.1FCF3A49096@drugs.dv.isc.org> In-Reply-To: <20110217231720.1FCF3A49096@drugs.dv.isc.org> Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit Subject: [dnsext] SRV and wildcard CNAME X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 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, 18 Feb 2011 05:51:42 -0000 Mark Andrews wrote: > this include "www.example.net CNAME example.net". That's a problem. But... > Additionally people are too lazy to add records for each virtual > service in the DNS so they use "* CNAME server" which makes using > SRV hard as it requires prepended labels. Doesn't it mean: *.example.com CNAME srv.example.com srv.example.com SRV Priority Weight Port Target works as: _http._tcp.www.example.com SRV Priority Weight Port Target ? Masataka Ohta From paf@cisco.com Thu Feb 17 22:32:14 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 82F5C3A6D35 for ; Thu, 17 Feb 2011 22:32:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.298 X-Spam-Level: X-Spam-Status: No, score=-10.298 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-8, WEIRD_PORT=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CptklAHufsT0 for ; Thu, 17 Feb 2011 22:32:08 -0800 (PST) Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by core3.amsl.com (Postfix) with ESMTP id BCDAF3A68DD for ; Thu, 17 Feb 2011 22:32:08 -0800 (PST) Authentication-Results: sj-iport-4.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAC+hXU1AaMHG/2dsb2JhbACmIHOgd5sxhV4EjBA X-IronPort-AV: E=Sophos;i="4.62,185,1297036800"; d="scan'208";a="261791906" Received: from syd-core-1.cisco.com ([64.104.193.198]) by sj-iport-4.cisco.com with ESMTP; 18 Feb 2011 06:32:40 +0000 Received: from dhcp-10-61-107-153.cisco.com (dhcp-10-61-107-153.cisco.com [10.61.107.153]) by syd-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id p1I6Wadt007237; Fri, 18 Feb 2011 06:32:37 GMT Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: =?iso-8859-1?Q?Patrik_F=E4ltstr=F6m?= In-Reply-To: <20110217231720.1FCF3A49096@drugs.dv.isc.org> Date: Fri, 18 Feb 2011 07:32:36 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20110216032120.43474.qmail@joyce.lan> <20110216212930.57D64A3F344@drugs.dv.isc.org><4D5D24F3.70206@gis.net> <20110217231720.1FCF3A49096@drugs.dv.isc.org> To: Mark Andrews X-Mailer: Apple Mail (2.1082) Cc: John Levine , dnsext@ietf.org Subject: Re: [dnsext] we need help to make names the same, was draft-yao-dnsext-identical-resolution-02 comment X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 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, 18 Feb 2011 06:32:14 -0000 On 18 feb 2011, at 00.17, Mark Andrews wrote: > We need to support=20 >=20 > site alias -> site { -> hosting server } >=20 > CNAME NEW-TYPE I just saw an acceptance of the by me suggested URI RR-Type, and this is = one of the usages I was thinking of, although it was not a "main goal". For example: _http._tcp.example.com. URI 1 1 http://example.hostingcompany.com/ _https._tcp.example.com. URI 1 1 https://example.hostingcompany.com:444/ Etc... Patrik From johnl@iecc.com Thu Feb 17 22:46:17 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D2EBB3A6D10 for ; Thu, 17 Feb 2011 22:46:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.77 X-Spam-Level: X-Spam-Status: No, score=-110.77 tagged_above=-999 required=5 tests=[AWL=0.299, BAYES_00=-2.599, HABEAS_ACCREDITED_SOI=-4.3, RCVD_IN_BSP_TRUSTED=-4.3, SARE_RMML_Stock10=0.13, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sla+JsrwRoMj for ; Thu, 17 Feb 2011 22:46:15 -0800 (PST) Received: from gal.iecc.com (gal.iecc.com [64.57.183.53]) by core3.amsl.com (Postfix) with ESMTP id 1BE283A6CDA for ; Thu, 17 Feb 2011 22:46:15 -0800 (PST) Received: (qmail 55354 invoked from network); 18 Feb 2011 06:46:47 -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=d839.4d5e15d7.k1102; i=johnl@submit.iecc.com; bh=ZzQtAraCPNP1El/QqInUfRJUQaVllgEEOxAjGcB24A4=; b=CtcSiXzTR6DVzoImmG01D2HB+vtyGSWN0nSARucHYwFFo/VLAoLTweN+qc4nypCMRnLbNKvorlwLP/9Guaxm6I1ri7PV2zcHrIgOyVTXhmlLa3qXM/vZ+aRMduv9Hi5FDz+4NXWwJkx40lo4EhzxWyHsgHk/DjoFrDOEnD9Nomo= VBR-Info: md=iecc.com; mc=all; mv=dwl.spamhaus.org Received: (ofmipd johnl@64.57.183.62) with (DHE-RSA-AES256-SHA encrypted) SMTP; 18 Feb 2011 06:46:25 -0000 Date: 18 Feb 2011 01:46:46 -0500 Message-ID: From: "John R. Levine" To: "Brian Dickson" In-Reply-To: References: <20110216032120.43474.qmail@joyce.lan> <20110216212930.57D64A3F344@drugs.dv.isc.org> <4D5D24F3.70206@gis.net> <20110217231720.1FCF3A49096@drugs.dv.isc.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 Cc: dnsext@ietf.org Subject: Re: [dnsext] we need help to make names the same, was draft-yao-dnsext-identical-resolution-02 comment X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 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, 18 Feb 2011 06:46:18 -0000 > Say we have A1,A2,A3, and A4 that are all meant to be "the same", and > we want the "official" (canonical) name used to be A1. > Similarly, B1 for B2/B3/B4, C1 for C2/C3/C4. > > It would be both cumbersome, and bloated, to have to put all > combinations into DNS as CNAMEs. > It would also be limiting to put other requirements onto how the zone > structure was built (such as requiring delegations/zone cuts). I went back and reviewed the BNAME proposal on the plane this afternoon. Somewhat to my surprise, it looks to me like it's a plausible technical approach to "the same" if (and this is a big IF) we can get buy-in from the relevant application groups that BNAMEs mean variant spellings of the same web site/mail domain/whatever, rather than whatever CNAME means in practice now. If you do a BNAME resolution, the result should come back with a synthesized CNAME along with all the BNAME records the client can use to see that it was BNAMEs that did it. Regards, John Levine, johnl@iecc.com, Primary Perpetrator of "The Internet for Dummies", Please consider the environment before reading this e-mail. http://jl.ly From mohta@necom830.hpcl.titech.ac.jp Thu Feb 17 22:52:14 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1D0A53A6D4F for ; Thu, 17 Feb 2011 22:52:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.102 X-Spam-Level: X-Spam-Status: No, score=-0.102 tagged_above=-999 required=5 tests=[AWL=-0.013, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, WEIRD_PORT=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1XGPQXnArwug for ; Thu, 17 Feb 2011 22:52:12 -0800 (PST) Received: from necom830.hpcl.titech.ac.jp (necom830.hpcl.titech.ac.jp [131.112.32.132]) by core3.amsl.com (Postfix) with SMTP id A94663A6D46 for ; Thu, 17 Feb 2011 22:52:11 -0800 (PST) Received: (qmail 11511 invoked from network); 18 Feb 2011 07:03:12 -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 Feb 2011 07:03:12 -0000 Message-ID: <4D5E1704.4030905@necom830.hpcl.titech.ac.jp> Date: Fri, 18 Feb 2011 15:51:48 +0900 From: Masataka Ohta User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; ja; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: dnsext@ietf.org References: <20110216032120.43474.qmail@joyce.lan> <20110216212930.57D64A3F344@drugs.dv.isc.org><4D5D24F3.70206@gis.net> <20110217231720.1FCF3A49096@drugs.dv.isc.org> In-Reply-To: Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit Subject: Re: [dnsext] we need help to make names the same, was draft-yao-dnsext-identical-resolution-02 comment X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 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, 18 Feb 2011 06:52:14 -0000 wrote: > I just saw an acceptance of the by me suggested URI RR-Type, and > this is one of the usages I was thinking of, although it was > not a "main goal". > > For example: > > _http._tcp.example.com. URI 1 1 http://example.hostingcompany.com/ > _https._tcp.example.com. URI 1 1 https://example.hostingcompany.com:444/ Isn't an original request "http://example.com/filename" converted to "http://example.hostingcompany.com/" by URIs? Masataka Ohta From paf@cisco.com Thu Feb 17 22:52:20 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6A05C3A6CDA for ; Thu, 17 Feb 2011 22:52:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.222 X-Spam-Level: X-Spam-Status: No, score=-9.222 tagged_above=-999 required=5 tests=[AWL=-1.077, BAYES_00=-2.599, FRT_BELOW2=2.154, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7YJIxf54Mnhp for ; Thu, 17 Feb 2011 22:52:14 -0800 (PST) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id 2C0373A6D46 for ; Thu, 17 Feb 2011 22:52:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=paf@cisco.com; l=5351; q=dns/txt; s=amsiport01001; t=1298011967; x=1299221567; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=2OReXxO+HqtnnejqCBhcJ+Kyt02PJnR8Q+uz2wp2DFk=; b=r6iS2wXIch6VtYr6EVio6aP5pdzx+EgSe58u1xd9Piam0PPp6DPtcS5B /HpWWnp54sQDf3lR7398EP5m/bjHru4hfiDrtsoIr8nvMzGYjKBi/bouO W+O8jrBT/j9176y/yGnPopWOv1yrqQ47QidOPSjmjFE0ELFOcmu3mG/rf Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqEEALqlXU2Q/khLgWdsb2JhbACmIBUBARYiJKETmziFXgSMEQ X-IronPort-AV: E=Sophos;i="4.62,185,1297036800"; d="scan'208";a="76642920" Received: from ams-core-2.cisco.com ([144.254.72.75]) by ams-iport-1.cisco.com with ESMTP; 18 Feb 2011 06:52:46 +0000 Received: from dhcp-10-61-107-153.cisco.com (dhcp-10-61-107-153.cisco.com [10.61.107.153]) by ams-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p1I6qjRY020146; Fri, 18 Feb 2011 06:52:46 GMT Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: =?iso-8859-1?Q?Patrik_F=E4ltstr=F6m?= In-Reply-To: <20110217231638.GA42567@registro.br> Date: Fri, 18 Feb 2011 07:52:44 +0100 Content-Transfer-Encoding: 7bit Message-Id: <7DB7A6CF-8071-4404-AD65-DB424E32CE18@cisco.com> References: <20110127134320.GC91248@registro.br> <20110217231638.GA42567@registro.br> To: Frederico A C Neves X-Mailer: Apple Mail (2.1082) Cc: iana-prot-param@iana.org, dnsext@ietf.org Subject: Re: [dnsext] URI RRTYPE review - Result [IANA #376037] X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 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, 18 Feb 2011 06:52:20 -0000 Thanks for your work Fred! Patrik On 18 feb 2011, at 00.16, Frederico A C Neves wrote: > Dear Colleagues, > > This message ends the review process for the URI RRTYPE, according to > my judgment it meets both requirements of section 3.1.1 and none of > section 3.1.2 of RFC5395 and should be accepted. > > Best Regards, > Frederico Neves > > On Thu, Jan 27, 2011 at 11:43:20AM -0200, Frederico A C Neves wrote: >> Dear Colleagues, >> >> Bellow is a resubmission of a completed template requesting a new >> RRTYPE assignment under the procedures of RFC5395. >> >> This message starts a 3 weeks period for an expert-review of the DNS >> RRTYPE parameter allocation for URI specified in >> http://tools.ietf.org/html/draft-faltstrom-uri-05 >> >> If you have any new comments regarding this request that have not yet >> being made at the thread starting with message >> http://www.ietf.org/mail-archive/web/dnsext/current/msg08956.html , >> please post them here before Feb 17th 18:00 UTC >> >> Best Regards, >> Frederico Neves >> >> --begin 5395 template URI-- >> A. Submission Date: >> >> May 23, 2009 >> >> B. Submission Type: >> >> [X] New RRTYPE >> [ ] Modification to existing RRTYPE >> >> C. Contact Information for submitter: >> >> Name: Patrik Faltstrom >> Email Address: paf@cisco.com >> International telephone number: +46-8-6859131 >> Other contact handles: >> (Note: This information will be publicly posted.) >> >> D. Motivation for the new RRTYPE application? >> >> There is no easy way to get from a domain name to a URI. Some >> mechanisms exists via use of the NAPTR [RFC3403] resource >> record. That implies quite complicated rules that are >> simplified via the S-NAPTR [RFC3958] specification. But, the >> ability to directly look up a URI still exists. This >> specification uses a prefix based naming mechanism originated in >> the definition of the SRV [RFC2782] resource record, and the >> RDATA is a URI, encoded as one text field. >> >> See also Section 1 in draft-faltstrom-uri-05.txt. >> >> E. Description of the proposed RR type. >> >> The format of the URI resource record is as follows: >> >> >> Ownername TTL Class URI Priority Weight Target >> >> >> The URI RR has service information encoded in its ownername. In >> order to encode the service for a specific owner name one uses >> service parameters. Valid service parameters used are either >> Enumservice Registrations registered by IANA, or prefixes used >> for the SRV resource record. >> >> The wire format of the RDATA is as follows: >> >> >> 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 >> 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | Priority | Weight | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> / / >> / Target / >> / / >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> >> >> F. What existing RRTYPE or RRTYPEs come closest to filling that >> need and why are they unsatisfactory? >> >> The RRTYPE that come closest is the NAPTR resource record. It >> is for example used in the DDDS and S-NAPTR algorithms. The >> main problem with the NAPTR is that selection of what record (or >> records) one is interested in is based on data stored in the >> RDATA portion of the NAPTR resource record. This, as explained >> in RFC 5507 [RFC5507], is not optimal for DNS lookups. Further, >> most applications using NAPTR resource records uses regular >> expression based rewrite rules for creation of the URI, and that >> has shown be complicated to implement. >> >> The second closest RRTYPE is the SRV record that given a >> prefixed based naming just like is suggested for the URI >> resource record, one get back a port number and domain name. >> This can also be used for creation of a URI, but, only URIs >> without path components. >> >> G. What mnemonic is requested for the new RRTYPE (optional)? >> >> URI >> >> H. Does the requested RRTYPE make use of any existing IANA Registry >> or require the creation of a new IANA sub-registry in DNS >> Parameters? >> >> Yes, partially. >> >> One of the mechanisms to select a service is to use the >> Enumservice Registry managed by IANA. Another is to use >> services and protocols used for SRV records. >> >> I. Does the proposal require/expect any changes in DNS servers/ >> resolvers that prevent the new type from being processed as an >> unknown RRTYPE (see [RFC3597])? >> >> No >> >> J. Comments: >> >> None >> --end 5395 template URI-- >> _______________________________________________ >> dnsext mailing list >> dnsext@ietf.org >> https://www.ietf.org/mailman/listinfo/dnsext From paf@cisco.com Thu Feb 17 23:18:31 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D0CD53A69D0 for ; Thu, 17 Feb 2011 23:18:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.939 X-Spam-Level: X-Spam-Status: No, score=-9.939 tagged_above=-999 required=5 tests=[AWL=0.359, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-8, WEIRD_PORT=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aTmfMf3ew1L0 for ; Thu, 17 Feb 2011 23:18:30 -0800 (PST) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id 925BE3A6CE5 for ; Thu, 17 Feb 2011 23:18:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=paf@cisco.com; l=964; q=dns/txt; s=amsiport01001; t=1298013544; x=1299223144; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=Uc5Jp8hioHyrkWVD5dIEjEyNw9Z8v785IZN5DVkmP+I=; b=ACkzo22TvINav1KDlkHpk7tb9t+h+Lcr3Lo7HsnchCQrqs3Bc6hu+kEa X7NJIe2vNdjZ2Zc/DBfi1cnHNWJtNeacEv70jW89GsvijUJ87/xVCLU6E Lx8Q+G8cwfEJmNqF0XzlBIb76OAjsAGwJSZfUjQ1QI6sNbS7p7cKOZ+tI o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqEEAKqsXU2Q/khLgWdsb2JhbACmIBUBARYiJKBumzeFXgSMEYwE X-IronPort-AV: E=Sophos;i="4.62,185,1297036800"; d="scan'208";a="76645105" Received: from ams-core-2.cisco.com ([144.254.72.75]) by ams-iport-1.cisco.com with ESMTP; 18 Feb 2011 07:18:55 +0000 Received: from dhcp-10-61-107-153.cisco.com (dhcp-10-61-107-153.cisco.com [10.61.107.153]) by ams-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p1I7ItSg025491; Fri, 18 Feb 2011 07:18:55 GMT Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: =?iso-8859-1?Q?Patrik_F=E4ltstr=F6m?= In-Reply-To: <4D5E1704.4030905@necom830.hpcl.titech.ac.jp> Date: Fri, 18 Feb 2011 08:18:54 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20110216032120.43474.qmail@joyce.lan> <20110216212930.57D64A3F344@drugs.dv.isc.org><4D5D24F3.70206@gis.net> <20110217231720.1FCF3A49096@drugs.dv.isc.org> <4D5E1704.4030905@necom830.hpcl.titech.ac.jp> To: Masataka Ohta X-Mailer: Apple Mail (2.1082) Cc: dnsext@ietf.org Subject: Re: [dnsext] we need help to make names the same, was draft-yao-dnsext-identical-resolution-02 comment X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 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, 18 Feb 2011 07:18:31 -0000 On 18 feb 2011, at 07.51, Masataka Ohta wrote: > wrote: >=20 >> I just saw an acceptance of the by me suggested URI RR-Type, and >> this is one of the usages I was thinking of, although it was >> not a "main goal". >>=20 >> For example: >>=20 >> _http._tcp.example.com. URI 1 1 http://example.hostingcompany.com/ >> _https._tcp.example.com. URI 1 1 = https://example.hostingcompany.com:444/ >=20 > Isn't an original request "http://example.com/filename" converted > to "http://example.hostingcompany.com/" by URIs? Or maybe to http://example.hostingcompany.com/filename? And then the next question is of course what DN to compare with in the = SSL cert? And then the question is whether SRV RR should be used for = example.hostingcompany.com? I.e. what I see this discussion is boiling down to is that what I think = we need is a document that clearly describe one as "simple" thing as = "how to resolve a HTTP URI". Patrik From mohta@necom830.hpcl.titech.ac.jp Thu Feb 17 23:55:49 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4F1EF3A6E81 for ; Thu, 17 Feb 2011 23:55:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.102 X-Spam-Level: X-Spam-Status: No, score=-0.102 tagged_above=-999 required=5 tests=[AWL=-0.012, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6pj2JvYWh7rR for ; Thu, 17 Feb 2011 23:55:48 -0800 (PST) Received: from necom830.hpcl.titech.ac.jp (necom830.hpcl.titech.ac.jp [131.112.32.132]) by core3.amsl.com (Postfix) with SMTP id 521A23A6DB5 for ; Thu, 17 Feb 2011 23:55:48 -0800 (PST) Received: (qmail 12543 invoked from network); 18 Feb 2011 08:06:52 -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 Feb 2011 08:06:52 -0000 Message-ID: <4D5E25EC.6000100@necom830.hpcl.titech.ac.jp> Date: Fri, 18 Feb 2011 16:55:24 +0900 From: Masataka Ohta User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; ja; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: paf@cisco.com References: <20110216032120.43474.qmail@joyce.lan> <20110216212930.57D64A3F344@drugs.dv.isc.org><4D5D24F3.70206@gis.net> <20110217231720.1FCF3A49096@drugs.dv.isc.org> <4D5E1704.4030905@necom830.hpcl.titech.ac.jp> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: dnsext@ietf.org Subject: Re: [dnsext] we need help to make names the same, was draft-yao-dnsext-identical-resolution-02 comment X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 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, 18 Feb 2011 07:55:49 -0000 wrote: >> Isn't an original request "http://example.com/filename" converted >> to "http://example.hostingcompany.com/" by URIs? > > Or maybe to http://example.hostingcompany.com/filename? "Or"??? Which is specified in your draft? > And then the question is whether SRV RR should be used for > example.hostingcompany.com? The original request "http://example.com/filename" will cause SRV look up of "_http._tcp.example.com" and port numbers and targets are obtained. As RFC2782 says: Priority The priority of this target host. A client MUST attempt to contact the target host with the lowest-numbered priority it can reach; "target host"s are "contacted", which means no recursive SRV look up will occur. SRV is for hostname in URL just as MX is for domain name in e-mail address. Masataka Ohta From mayer@ntp.org Thu Feb 17 19:28:51 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0CA043A6DC3 for ; Thu, 17 Feb 2011 19:28:51 -0800 (PST) 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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eGzaw3RkNc7W for ; Thu, 17 Feb 2011 19:28:50 -0800 (PST) Received: from mail1.ntp.org (mail1.ntp.org [IPv6:2001:4f8:fff7:1::5]) by core3.amsl.com (Postfix) with ESMTP id 174453A6DA1 for ; Thu, 17 Feb 2011 19:28:49 -0800 (PST) Received: from cust-63-209-235-31.bos-dynamic.gis.net ([63.209.235.31] helo=[10.10.10.101]) by mail1.ntp.org with esmtpsa (TLSv1:CAMELLIA256-SHA:256) (Exim 4.72 (FreeBSD)) (envelope-from ) id 1PqH1k-000Hw9-AW; Fri, 18 Feb 2011 03:29:14 +0000 Message-ID: <4D5DE7A7.1010103@ntp.org> Date: Thu, 17 Feb 2011 22:29:43 -0500 From: Danny Mayer Organization: NTP User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: mayer@gis.net References: <20110216032120.43474.qmail@joyce.lan> <20110216212930.57D64A3F344@drugs.dv.isc.org><4D5D24F3.70206@gis.net> <20110217231720.1FCF3A49096@drugs.dv.isc.org> <4D5DE54C.5010104@gis.net> In-Reply-To: <4D5DE54C.5010104@gis.net> X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-SA-Exim-Connect-IP: 63.209.235.31 X-SA-Exim-Rcpt-To: mayer@gis.net, marka@isc.org, johnl@iecc.com, dnsext@ietf.org X-SA-Exim-Mail-From: mayer@ntp.org X-SA-Exim-Version: 4.2 X-SA-Exim-Scanned: Yes (on mail1.ntp.org) X-Mailman-Approved-At: Fri, 18 Feb 2011 04:46:58 -0800 Cc: John Levine , dnsext@ietf.org Subject: Re: [dnsext] we need help to make names the same, was draft-yao-dnsext-identical-resolution-02 comment X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: mayer@ntp.org List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Feb 2011 03:28:51 -0000 On 2/17/2011 10:19 PM, Danny Mayer wrote: > On 2/17/2011 6:17 PM, Mark Andrews wrote: >> In message <4D5D24F3.70206@gis.net>, Danny Mayer writes: >>> Even if there were I'm not convinced that it would be useful since there >>> is no way on the RHS to specify the path. It can give you a name, a >>> port, a weight and a priority but no path. There was a proposal for a >>> URL RR but I cannot find it right now and I don't think the wg is >>> considering it, at least it's not on the document list. >>> >>> Danny >> >> Which can be dealt with entirely at the HTTP/S layer. >> > > Not for the purpose I'm looking to use it. For the particular purpose > the SOAP Servlet path needs to be different from the regular login URL > and there is no way to express that. It needs to be like an SRV record > so that the particular SOAP service can be located. > Looks like the URI proposal from Patrik Falstrom fits the bill. Of course it will be years before it is implemented and deployed. I just saw the review message from Frederico right after yours. Danny From woolf@isc.org Fri Feb 18 06:36:23 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 012433A6DC6 for ; Fri, 18 Feb 2011 06:36:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.933 X-Spam-Level: X-Spam-Status: No, score=-2.933 tagged_above=-999 required=5 tests=[AWL=-0.333, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0Mjfkoe8ocU3 for ; Fri, 18 Feb 2011 06:36:22 -0800 (PST) Received: from mx.pao1.isc.org (mx.pao1.isc.org [IPv6:2001:4f8:0:2::2b]) by core3.amsl.com (Postfix) with ESMTP id ECC2E3A6CF2 for ; Fri, 18 Feb 2011 06:36:21 -0800 (PST) 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 D8294C9429; Fri, 18 Feb 2011 14:36:53 +0000 (UTC) (envelope-from woolf@isc.org) Received: by bikeshed.isc.org (Postfix, from userid 10265) id CDE67216C22; Fri, 18 Feb 2011 14:36:53 +0000 (UTC) Date: Fri, 18 Feb 2011 14:36:53 +0000 From: Suzanne Woolf To: Andrew Sullivan Message-ID: <20110218143653.GC84482@bikeshed.isc.org> References: <4D5B5E81.1050602@necom830.hpcl.titech.ac.jp> <20110216073338.7251.qmail@joyce.lan> <20110216165921.GW96213@shinkuro.com> <3B90ED2E-980D-4B01-889F-447D66D0B58D@insensate.co.uk> <20110216174011.GZ96213@shinkuro.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20110216174011.GZ96213@shinkuro.com> User-Agent: Mutt/1.4.2.3i Cc: dnsext@ietf.org Subject: Re: [dnsext] we need help to make names the same, was draft-yao-dnsext-identical-resolution-02 comment X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 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, 18 Feb 2011 14:36:23 -0000 On Wed, Feb 16, 2011 at 12:40:12PM -0500, Andrew Sullivan wrote: > This is why the SMTP and web server issues are such a big deal. If we > solve the problem that you only have to maintain one tree in the DNS, > and everything else "just works", that is a completely meaningless > victory if you nevertheless have to maintain all your SMTP and web > servers by hand and keep them up to date about the aliases. The work > to keep the DNS in sync here is trivial compared to everything else. Re-reading almost all of the history all at once, this strikes me as the emerging key point: we started with registry issues, where scalability of provisioning was the driver for opening the discussion. But it's not clear that we can help registry operators with benefit also to applciations writers, or to network operators (Alex's comment about protocol perversions that rely on DNS lookups to fail in order to frame a query that wlil succeed, which are always with us but which we should hardly be encouraging). I'm comfortable with the assertion that making life easier for registry operators isn't worth doing if it makes life harder for applications writers, at least for purposes of argument in the draft. But: might helping registry operators (i.e., people who run authority-side servers) without helping anyone else be worth the effort? I haven't reviewed the draft lately but clones, IIRC, are based on server-side synthesis of "the same RR you would have gotten if the aliased zones were fully enumerated". Useful enough? I *think* Andrew's text above says no, we can't reasonably help registry operators if we leave applications with the same problem they have now (knowing for themselves that string $x needs to map to string $y). But rather than argue with something he may not have actually said, I'm looking for further comments on this point. thanks, Suzanne From ajs@shinkuro.com Fri Feb 18 07:11:39 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B371A3A6F16 for ; Fri, 18 Feb 2011 07:11:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.572 X-Spam-Level: X-Spam-Status: No, score=-102.572 tagged_above=-999 required=5 tests=[AWL=0.027, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QAfHD-ZtpZdV for ; Fri, 18 Feb 2011 07:11:38 -0800 (PST) Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by core3.amsl.com (Postfix) with ESMTP id BE00D3A6DFD for ; Fri, 18 Feb 2011 07:11:38 -0800 (PST) Received: from crankycanuck.ca (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 AD9301ECB420 for ; Fri, 18 Feb 2011 15:12:11 +0000 (UTC) Date: Fri, 18 Feb 2011 10:12:09 -0500 From: Andrew Sullivan To: dnsext@ietf.org Message-ID: <20110218151209.GF66684@shinkuro.com> References: <4D5B5E81.1050602@necom830.hpcl.titech.ac.jp> <20110216073338.7251.qmail@joyce.lan> <20110216165921.GW96213@shinkuro.com> <3B90ED2E-980D-4B01-889F-447D66D0B58D@insensate.co.uk> <20110216174011.GZ96213@shinkuro.com> <20110218143653.GC84482@bikeshed.isc.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20110218143653.GC84482@bikeshed.isc.org> User-Agent: Mutt/1.5.18 (2008-05-17) Subject: Re: [dnsext] we need help to make names the same, was draft-yao-dnsext-identical-resolution-02 comment X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 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, 18 Feb 2011 15:11:39 -0000 no hat On Fri, Feb 18, 2011 at 02:36:53PM +0000, Suzanne Woolf wrote: > I *think* Andrew's text above says no, we can't reasonably help > registry operators if we leave applications with the same problem they > have now (knowing for themselves that string $x needs to map to string > $y). But rather than argue with something he may not have actually > said, I'm looking for further comments on this point. That wasn't really what I was trying to say, so I guess I better clarify. I'm trying to keep in mind two things at once. On the one hand, we have a narrow issue about the DNS and provisioning. And the idea is that we need to make it easier to say "When you encounter alias {A[1], A[2]. . .A[n]} for some value of n, then that is mostly functionally equivalent to encountering FQDN F." This isn't really that big a deal, and we have at least two complimentary proposals on how to do it. There are some tricks in stating exactly what "mostly" and "functionally equivalent" mean, but I think this isn't that hard. But if we think about this in the larger sense, we have to confront the reason why people want the above. It is surely not just that people want to have more ways to write the same name. It is rather that naive users on the Internet will try to use such "alternative spelling" names, and we want to help the operators of sites that are the target of such attempted use to make their lives easier. Therefore, if we deliver an answer that makes it trivial to add all these additional ways of referring to "the same host" or "the same resource" or something like that, we cannot simply ignore the potential issues for how the addressed services are going to manage this plethora of names. This is in fact exactly why I am so concerned that we have not attracted broad-based attention from the applications community: we need to hear from them, if we mess up, "Hey, DNS weenies! You just made my life impossible." For if we do that, we will have failed in the real goal of this work. Consider that the mail admins and the web admins could be completely different parts of the organization in a large enterprise (they were in a university where I worked). BNAME could have an effect on the mail admin even if it were just added to help the web admin. These are practical consequences of a big change in the DNS protocol, and we have to think about them in the case of adding new aliasing features. (This is not the same as what happens when you do it with provisioning: those admins already have to understand their provisioning and the deployed applications already have rules for those cases.) This is why I think just solving the provisioning case, without at least some way for the applications to know what to do, is not enough. I have been very intrigued by the idea of having two-way pointers, so that if you are a mail server and you're coming up, you can look up your name and learn how else you might be called. But nobody has offered a proposal for how to do that nicely, and we haven't heard from actual application people about whether that's useful or totally silly. (Note I'm not bashing "application people" and I appreciate, very much, the active involvement of those who have relevant experience and have been expressing opinions. But those people are here extremely notable for their rarity.) A -- Andrew Sullivan ajs@shinkuro.com Shinkuro, Inc. From vixie@isc.org Fri Feb 18 08:26:43 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9977D3A6C8D for ; Fri, 18 Feb 2011 08:26:43 -0800 (PST) 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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mMIk7EJDrI0K for ; Fri, 18 Feb 2011 08:26:42 -0800 (PST) Received: from nsa.vix.com (unknown [IPv6:2001:4f8:3:bb:230:48ff:fe5a:2f38]) by core3.amsl.com (Postfix) with ESMTP id 8C8753A6CA1 for ; Fri, 18 Feb 2011 08:26:42 -0800 (PST) Received: from nsa.vix.com (localhost [127.0.0.1]) by nsa.vix.com (Postfix) with ESMTP id 736AEA1059 for ; Fri, 18 Feb 2011 16:27:13 +0000 (UTC) (envelope-from vixie@isc.org) From: Paul Vixie To: dnsext@ietf.org In-Reply-To: Your message of "Fri, 18 Feb 2011 14:36:53 GMT." <20110218143653.GC84482@bikeshed.isc.org> References: <4D5B5E81.1050602@necom830.hpcl.titech.ac.jp> <20110216073338.7251.qmail@joyce.lan> <20110216165921.GW96213@shinkuro.com> <3B90ED2E-980D-4B01-889F-447D66D0B58D@insensate.co.uk> <20110216174011.GZ96213@shinkuro.com> <20110218143653.GC84482@bikeshed.isc.org> X-Mailer: MH-E 8.2; nmh 1.2; XEmacs 21.4 (patch 22) Date: Fri, 18 Feb 2011 16:27:13 +0000 Message-ID: <10710.1298046433@nsa.vix.com> Subject: Re: [dnsext] we need help to make names the same, was draft-yao-dnsext-identical-resolution-02 comment X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 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, 18 Feb 2011 16:26:43 -0000 > Date: Fri, 18 Feb 2011 14:36:53 +0000 > From: Suzanne Woolf > ... > I *think* Andrew's text above says no, we can't reasonably help > registry operators if we leave applications with the same problem they > have now (knowing for themselves that string $x needs to map to string > $y). But rather than argue with something he may not have actually > said, I'm looking for further comments on this point. registry operators (and those who govern) asked about name sameness and it's fair to answer them with a cost-benefit analysis, such as: "1. dns provides aliases but these are application-visible and many protocols forbid their use, for example MX -> alias -> {A|AAAA} so these may not be suitable for your proposed use. "2. services are name-aware, so any dns sameness whether based on existing alias technology or on some imaginable new technology would still require service config changes, for example to postfix and apache configs on all servers which were going to become multinamed. even if we add new dns technology to support some kind of automation in that area, it will still require a global upgrade of server side technology, and the failure mode for clients contacting non-upgraded servers could be unpredictable/unsettling. so, adding new sameness will have a high cost and a long tail. "3. some existing dns data elements are harmonized around the idea of a "canonical name" (for example, {A|AAAA} and PTR) and applications often enforce this. the dns and all applications would have to be changed to either remove assumptions about canonical names, or to change the definition of a canonical name from a scalar to a vector. this has the same high costs and long tail as described for #2 above. "please choose a tradeoff and give us appropriate marching orders. thanks." From fneves@registro.br Fri Feb 18 13:34:24 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C91B03A6AAE for ; Fri, 18 Feb 2011 13:34:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.446 X-Spam-Level: X-Spam-Status: No, score=-0.446 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FRT_BELOW2=2.154, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y6WOPOTg9HFD for ; Fri, 18 Feb 2011 13:34:23 -0800 (PST) Received: from clone.registro.br (clone.registro.br [IPv6:2001:12ff:0:2::4]) by core3.amsl.com (Postfix) with ESMTP id 719E83A6EA5 for ; Fri, 18 Feb 2011 13:34:23 -0800 (PST) Received: by clone.registro.br (Postfix, from userid 1000) id 35F7DE04AC; Fri, 18 Feb 2011 19:34:53 -0200 (BRST) Date: Fri, 18 Feb 2011 19:34:53 -0200 From: Frederico A C Neves To: dnsext@ietf.org Message-ID: <20110218213453.GB96163@registro.br> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Subject: [dnsext] CAA RRTYPE review - Comments period end Mar 11th X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 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, 18 Feb 2011 21:34:24 -0000 Dear Colleagues, Bellow is a completed template requesting a new RRTYPE assignment under the procedures of RFC5395. This message starts a 3 weeks period for an expert-review of the DNS RRTYPE parameter allocation for CAA specified in http://tools.ietf.org/html/draft-hallambaker-donotissue-02 IANA #412190 If you have comments regarding this request please post them here before Mar 11th 18:00 UTC. Best Regards, Frederico Neves --begin 5395 template CAA-- A. Submission Date: 3 Dec 2010 B. Submission Type: [X] New RRTYPE [ ] Modification to existing RRTYPE C. Contact Information for submitter: Name: Phillip Hallam-Baker Email Address: phill@hallambaker.com International telephone number: +1 617 395 4123 Other contact handles: (Note: This information will be publicly posted.) D. Motivation for the new RRTYPE application? Please keep this part at a high level to inform the Expert and reviewers about uses of the RRTYPE. Remember most reviewers will be DNS experts that may have limited knowledge of your application space. The Certification Authority Authorization (CAA) DNS Resource Record allows a DNS domain name holder to specify the certificate signing certificate(s) authorized to issue certificates for that domain. CAA resource records allow a public Certification Authority to implement additional controls to reduce the risk of unintended certificate mis- issue. And is designed to be extensible in order to support related concerns including enforcement of issue restriction in applications. E. Description of the proposed RR type. This description can be provided in-line in the template, as an attachment, or with a publicly available URL: A detailed specification is posted is given in draft-hallambaker-donotissue: https://datatracker.ietf.org/doc/draft-hallambaker-donotissue/ F. What existing RRTYPE or RRTYPEs come closest to filling that need and why are they unsatisfactory? The only current means by which this information can be expressed in the DNS is via a TXT record which is not differentiated for this purpose. The approach here addfresses purposes that are clearly outside the purpose of the CERT record and similar 'keys-in-DNS' approaches. G. What mnemonic is requested for the new RRTYPE (optional)? Note: This can be left blank and the mnemonic decided after the template is accepted. The proposed mnemonic is CAA standing for Certification Authority Authorization. H. Does the requested RRTYPE make use of any existing IANA Registry or require the creation of a new IANA sub-registry in DNS Parameters? If so, please indicate which registry is to be used or created. If a new sub-registry is needed, specify the allocation policy for it and its initial contents. Also include what the modification procedures will be. Yes, the following registry assignment is requested. 5.2. Certification Authority Authorization Properties IANA [is requested to create] the Certification Authority Authorization Properties registry with the following initial values: Meaning Reference ----------- ----------------------------------------------- --------- path Authorization Entry by Signature Path [RFCXXXX] policy Authorization Entry by Certificate Policy [RFCXXXX] Addition of tag identifiers requires a public specification and expert review as set out in RFC5395 [RFC5395] Note that information carried in this record addresses application layer concerns. As such it is highly desirable to employ a tag-value approach to attribute specification than the code-value approach that is employed at lower layers in the stack. I. Does the proposal require/expect any changes in DNS servers/resolvers that prevent the new type from being processed as an unknown RRTYPE (see [RFC3597])? No. J. Comments: While the CAA proposal made in the accompanying Internet Draft represents a complete technical proposal, development of a full CAA standard will require further work that cannot be begun until a DNS RR assignment is made. In particular the CAA proposal MAY be proposed as the basis of future minimum issue guidelines for Domain Validated Certificates published by CA-Browser Forum. It is hard to see how such a proposal could be made without first obtaining significant experience of enforcing CAA issue restrictions. The CAA proposal MAY also be relevant to ongoing work in the IETF Applications area (WEBSEC) and the security area (TLS, IPSEC, Proposed KIDNS). Given the large number of moving parts, the proposal has been crafted with the intention of minimizing the number of dependencies in the system. --end 5395 template CAA-- From dougb@dougbarton.us Fri Feb 18 14:08:45 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4F0283A6DE8 for ; Fri, 18 Feb 2011 14:08:45 -0800 (PST) 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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SfTWau7N7es0 for ; Fri, 18 Feb 2011 14:08:43 -0800 (PST) Received: from mail2.fluidhosting.com (mx22.fluidhosting.com [204.14.89.5]) by core3.amsl.com (Postfix) with ESMTP id ABD263A6D7F for ; Fri, 18 Feb 2011 14:08:43 -0800 (PST) Received: (qmail 20801 invoked by uid 399); 18 Feb 2011 22:09:15 -0000 Received: from router.ka9q.net (HELO doug-optiplex.ka9q.net) (dougb@dougbarton.us@75.60.237.91) by mail2.fluidhosting.com with ESMTPAM; 18 Feb 2011 22:09:15 -0000 X-Originating-IP: 75.60.237.91 X-Sender: dougb@dougbarton.us Message-ID: <4D5EEE09.4080405@dougbarton.us> Date: Fri, 18 Feb 2011 14:09:13 -0800 From: Doug Barton Organization: http://SupersetSolutions.com/ User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.13) Gecko/20110129 Thunderbird/3.1.7 MIME-Version: 1.0 To: Andrew Sullivan References: <4D5B5E81.1050602@necom830.hpcl.titech.ac.jp> <20110216073338.7251.qmail@joyce.lan> <20110216165921.GW96213@shinkuro.com> <3B90ED2E-980D-4B01-889F-447D66D0B58D@insensate.co.uk> <20110216174011.GZ96213@shinkuro.com> <20110218143653.GC84482@bikeshed.isc.org> <20110218151209.GF66684@shinkuro.com> In-Reply-To: <20110218151209.GF66684@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: Re: [dnsext] we need help to make names the same, was draft-yao-dnsext-identical-resolution-02 comment X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 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, 18 Feb 2011 22:08:45 -0000 On 02/18/2011 07:12, Andrew Sullivan wrote: > no hat > > On Fri, Feb 18, 2011 at 02:36:53PM +0000, Suzanne Woolf wrote: >> I *think* Andrew's text above says no, we can't reasonably help >> registry operators if we leave applications with the same problem they >> have now (knowing for themselves that string $x needs to map to string >> $y). But rather than argue with something he may not have actually >> said, I'm looking for further comments on this point. > > That wasn't really what I was trying to say, so I guess I better clarify. I think what you have here is very clear, at least it helped me understand your concern quite a bit better. > I'm trying to keep in mind two things at once. > > On the one hand, we have a narrow issue about the DNS and > provisioning. And the idea is that we need to make it easier to say > "When you encounter alias {A[1], A[2]. . .A[n]} for some value of n, > then that is mostly functionally equivalent to encountering FQDN F." > This isn't really that big a deal, and we have at least two > complimentary proposals on how to do it. There are some tricks in > stating exactly what "mostly" and "functionally equivalent" mean, but > I think this isn't that hard. > > But if we think about this in the larger sense, we have to confront > the reason why people want the above. It is surely not just that > people want to have more ways to write the same name. It is rather > that naive users on the Internet will try to use such "alternative > spelling" names, and we want to help the operators of sites that are > the target of such attempted use to make their lives easier. > > Therefore, if we deliver an answer that makes it trivial to add all > these additional ways of referring to "the same host" or "the same > resource" or something like that, we cannot simply ignore the > potential issues for how the addressed services are going to manage > this plethora of names. This is in fact exactly why I am so concerned > that we have not attracted broad-based attention from the applications > community: we need to hear from them, if we mess up, "Hey, DNS > weenies! You just made my life impossible." For if we do that, we > will have failed in the real goal of this work. Agreed up to here. > Consider that the mail admins and the web admins could be completely > different parts of the organization in a large enterprise (they were > in a university where I worked). BNAME could have an effect on the > mail admin even if it were just added to help the web admin. These > are practical consequences of a big change in the DNS protocol, and we > have to think about them in the case of adding new aliasing features. > (This is not the same as what happens when you do it with > provisioning: those admins already have to understand their > provisioning and the deployed applications already have rules for > those cases.) Two comments ... First, just because we provide one or more solutions doesn't mean that the registrants of the preferred names will chose to use them. What generally happens with variants now is that either the registry assigns them to the registrant by default, or they are given the option to register them at an additional cost. At that point (for the most part) they also have the option of whether to delegate the variants or not. So IDN registrants are already dealing with these questions, we're just giving them a different set of tools with which to deal with them. > This is why I think just solving the provisioning case, without at > least some way for the applications to know what to do, is not enough. > > I have been very intrigued by the idea of having two-way pointers, so > that if you are a mail server and you're coming up, you can look up > your name and learn how else you might be called. But nobody has > offered a proposal for how to do that nicely, and we haven't heard > from actual application people about whether that's useful or totally > silly. Personally I think that's a really interesting idea, and I will try to work it into my CLONE draft (which I am aiming to have complete before the -00 deadline on March 7). For CLONE the design is that if a CLONE-aware resolver sends a query for a name that is actually a CLONE it gets the fact that it's a CLONE back in the ADDITIONAL section, so it's not impossible to believe that application developers could use that information. What it sounds like may be useful is an additional RR (maybe CLONES) that asks the authority the question you posed above, "What other names are related to this one?" I can think of a couple of complications with that, not the least of which is that if the qname is one of the CLONEs, how do you represent the preferred label in the response (always list it first maybe)? The other problem that comes immediately to mind is what to do when you have multiple labels in a hostname and more than one of them has CLONEs. (Return all the possible variants is likely the correct answer, but depending on user creativity that could get unwieldy.) But back to your original concern, I agree that we don't want to solve one part of the problem in a way that makes other parts of the problem harder (or impossible) to solve. But I think that we have to be careful not to throw our hands up too early, particularly before we've even tried to engage the people who are already dealing with these same issues we're discussing in theory. The common case (at least as far as the IDN issues go) is likely to be a small enough number of variants that the registrants will be perfectly capable of manually configuring the relevant software for all of them. And for those that don't wish to do that they can simply choose to not provision the variants at the registry, just like they do now. hth, 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@shinkuro.com Fri Feb 18 14:29:20 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 335E43A6AAE for ; Fri, 18 Feb 2011 14:29:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.577 X-Spam-Level: X-Spam-Status: No, score=-102.577 tagged_above=-999 required=5 tests=[AWL=0.022, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9JH36jbJdndS for ; Fri, 18 Feb 2011 14:29:18 -0800 (PST) Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by core3.amsl.com (Postfix) with ESMTP id 3D37C3A6DFD for ; Fri, 18 Feb 2011 14:29:18 -0800 (PST) Received: from crankycanuck.ca (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 16EE61ECB420 for ; Fri, 18 Feb 2011 22:29:52 +0000 (UTC) Date: Fri, 18 Feb 2011 17:29:50 -0500 From: Andrew Sullivan To: dnsext@ietf.org Message-ID: <20110218222950.GL74065@shinkuro.com> References: <4D5B5E81.1050602@necom830.hpcl.titech.ac.jp> <20110216073338.7251.qmail@joyce.lan> <20110216165921.GW96213@shinkuro.com> <3B90ED2E-980D-4B01-889F-447D66D0B58D@insensate.co.uk> <20110216174011.GZ96213@shinkuro.com> <20110218143653.GC84482@bikeshed.isc.org> <20110218151209.GF66684@shinkuro.com> <4D5EEE09.4080405@dougbarton.us> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4D5EEE09.4080405@dougbarton.us> User-Agent: Mutt/1.5.18 (2008-05-17) Subject: Re: [dnsext] we need help to make names the same, was draft-yao-dnsext-identical-resolution-02 comment X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 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, 18 Feb 2011 22:29:20 -0000 On Fri, Feb 18, 2011 at 02:09:13PM -0800, Doug Barton wrote: > Two comments ... First, just because we provide one or more solutions > doesn't mean that the registrants of the preferred names will chose to > use them. What generally happens with variants now is that either the > registry assigns them to the registrant by default, or they are given > the option to register them at an additional cost. At that point (for > the most part) they also have the option of whether to delegate the > variants or not. So IDN registrants are already dealing with these > questions, we're just giving them a different set of tools with which to > deal with them. Well, yes and no. Consider one of the favoured strategies in this area: BNAME. The reason some people are unhappy with DNAME is because a DNAME at the parent side causes problems for (for instance) using email at the DNAMEd domain. The natural use of BNAME, then, would be on the parent side (never mind whether it will work for email anyway, for now). Now, today, people tend not to put DNAME on the parent side because it doesn't redirect the name itself. But if we create this tool, it allows the parent side of the delegation effectively to _require_ that two names both be active; or at least, to force the child side of the delegation to handle the traffic from both "spellings". So if you want to run your mailserver at example.com, and your parent decides that you ought also to handle otherexample.com, you're going to get that traffic even if you don't want it. And this, of course, carries up the tree. That's a tool with potentially significant changes to the operational environment in which we have lived so far, and I don't want us to forget it. > harder (or impossible) to solve. But I think that we have to be careful > not to throw our hands up too early, particularly before we've even > tried to engage the people who are already dealing with these same > issues we're discussing in theory. Yes. I would keep at least a studied silence if I were throwing up my hands. I'm not trying to be argumentative for its own sake. I just want us to expose as many things as early as possible, while we're still working out what the problems are. I'd hate to learn all of this in another year. A -- Andrew Sullivan ajs@shinkuro.com Shinkuro, Inc. From dougb@dougbarton.us Fri Feb 18 14:48:12 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9EF603A6E7D for ; Fri, 18 Feb 2011 14:48:12 -0800 (PST) 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=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FDFF8X+Z3occ for ; Fri, 18 Feb 2011 14:48:11 -0800 (PST) Received: from mail2.fluidhosting.com (mx22.fluidhosting.com [204.14.89.5]) by core3.amsl.com (Postfix) with ESMTP id 0CB823A6E55 for ; Fri, 18 Feb 2011 14:48:10 -0800 (PST) Received: (qmail 1845 invoked by uid 399); 18 Feb 2011 22:48:45 -0000 Received: from router.ka9q.net (HELO doug-optiplex.ka9q.net) (dougb@dougbarton.us@75.60.237.91) by mail2.fluidhosting.com with ESMTPAM; 18 Feb 2011 22:48:45 -0000 X-Originating-IP: 75.60.237.91 X-Sender: dougb@dougbarton.us Message-ID: <4D5EF74C.9080603@dougbarton.us> Date: Fri, 18 Feb 2011 14:48:44 -0800 From: Doug Barton Organization: http://SupersetSolutions.com/ User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.13) Gecko/20110129 Thunderbird/3.1.7 MIME-Version: 1.0 To: dnsext@ietf.org References: <4D5B5E81.1050602@necom830.hpcl.titech.ac.jp> <20110216073338.7251.qmail@joyce.lan> <20110216165921.GW96213@shinkuro.com> <3B90ED2E-980D-4B01-889F-447D66D0B58D@insensate.co.uk> <20110216174011.GZ96213@shinkuro.com> <20110218143653.GC84482@bikeshed.isc.org> <20110218151209.GF66684@shinkuro.com> <4D5EEE09.4080405@dougbarton.us> <20110218222950.GL74065@shinkuro.com> In-Reply-To: <20110218222950.GL74065@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 Subject: Re: [dnsext] we need help to make names the same, was draft-yao-dnsext-identical-resolution-02 comment X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 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, 18 Feb 2011 22:48:12 -0000 On 02/18/2011 14:29, Andrew Sullivan wrote: > Now, today, people tend not to put DNAME on the parent side because it > doesn't redirect the name itself. But if we create this tool, it > allows the parent side of the delegation effectively to _require_ that > two names both be active; or at least, to force the child side of the > delegation to handle the traffic from both "spellings". Sure, that's possible. But I think it's very, very unlikely. As I said in my previous post registries today are giving registrants the option of whether to delegate the variants, I don't see this changing if we give them a new tool to use. > So if you want to run your mailserver at example.com, and your parent > decides that you ought also to handle otherexample.com, you're going > to get that traffic even if you don't want it. And this, of course, > carries up the tree. Ok, but even if this happens (which I think is unlikely), so what? If the mail server is not configured to handle otherexample the person sending mail there will get a bounce. That's only slightly more aggravating than having it not resolve at all. 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 marka@isc.org Fri Feb 18 15:04:42 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 840203A6DA8 for ; Fri, 18 Feb 2011 15:04:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.585 X-Spam-Level: X-Spam-Status: No, score=-2.585 tagged_above=-999 required=5 tests=[AWL=0.014, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wxNCiuov6ASp for ; Fri, 18 Feb 2011 15:04:35 -0800 (PST) Received: from mx.pao1.isc.org (mx.pao1.isc.org [IPv6:2001:4f8:0:2::2b]) by core3.amsl.com (Postfix) with ESMTP id 906A03A6D71 for ; Fri, 18 Feb 2011 15:04:34 -0800 (PST) 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 68052C9423; Fri, 18 Feb 2011 23:04:59 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (c211-30-172-21.carlnfd1.nsw.optusnet.com.au [211.30.172.21]) (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 A1C65216C1E; Fri, 18 Feb 2011 23:04:58 +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 0EBCBA5028E; Sat, 19 Feb 2011 10:04:56 +1100 (EST) To: Andrew Sullivan From: Mark Andrews References: <4D5B5E81.1050602@necom830.hpcl.titech.ac.jp> <20110216073338.7251.qmail@joyce.lan> <20110216165921.GW96213@shinkuro.com> <3B90ED2E-980D-4B01-889F-447D66D0B58D@insensate.co.uk> <20110216174011.GZ96213@shinkuro.com> <20110218143653.GC84482@bikeshed.isc.org> <20110218151209.GF66684@shinkuro.com> <4D5EEE09.4080405@dougbarton.us> <20110218222950.GL74065@shinkuro.com> In-reply-to: Your message of "Fri, 18 Feb 2011 17:29:50 CDT." <20110218222950.GL74065@shinkuro.com> Date: Sat, 19 Feb 2011 10:04:55 +1100 Message-Id: <20110218230456.0EBCBA5028E@drugs.dv.isc.org> Cc: dnsext@ietf.org Subject: Re: [dnsext] we need help to make names the same, was draft-yao-dnsext-identical-resolution-02 comment X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 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, 18 Feb 2011 23:04:42 -0000 In message <20110218222950.GL74065@shinkuro.com>, Andrew Sullivan writes: > On Fri, Feb 18, 2011 at 02:09:13PM -0800, Doug Barton wrote: > > > Two comments ... First, just because we provide one or more solutions > > doesn't mean that the registrants of the preferred names will chose to > > use them. What generally happens with variants now is that either the > > registry assigns them to the registrant by default, or they are given > > the option to register them at an additional cost. At that point (for > > the most part) they also have the option of whether to delegate the > > variants or not. So IDN registrants are already dealing with these > > questions, we're just giving them a different set of tools with which to > > deal with them. > > Well, yes and no. Consider one of the favoured strategies in this > area: BNAME. > > The reason some people are unhappy with DNAME is because a DNAME at > the parent side causes problems for (for instance) using email at the > DNAMEd domain. The natural use of BNAME, then, would be on the parent > side (never mind whether it will work for email anyway, for now). > > Now, today, people tend not to put DNAME on the parent side because it > doesn't redirect the name itself. But if we create this tool, it > allows the parent side of the delegation effectively to _require_ that > two names both be active; or at least, to force the child side of the > delegation to handle the traffic from both "spellings". > > So if you want to run your mailserver at example.com, and your parent > decides that you ought also to handle otherexample.com, you're going > to get that traffic even if you don't want it. And this, of course, > carries up the tree. This is where SMTP is now stupid. 822 (821?) required the sender to rewrite in CNAME. If you want multiple mail domains use a MX record. I suspect that a lot of this was driven because HTTP does have the equivalent of MX and rather than fix the real problem SMTP was stuffed up. > That's a tool with potentially significant changes to the operational > environment in which we have lived so far, and I don't want us to > forget it. > > > harder (or impossible) to solve. But I think that we have to be careful > > not to throw our hands up too early, particularly before we've even > > tried to engage the people who are already dealing with these same > > issues we're discussing in theory. > > Yes. I would keep at least a studied silence if I were throwing up my > hands. I'm not trying to be argumentative for its own sake. I just > want us to expose as many things as early as possible, while we're > still working out what the problems are. I'd hate to learn all of > this in another year. > > A > > -- > Andrew Sullivan > ajs@shinkuro.com > Shinkuro, Inc. > _______________________________________________ > 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 ajs@shinkuro.com Fri Feb 18 15:08:34 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 374063A6DA8 for ; Fri, 18 Feb 2011 15:08:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.578 X-Spam-Level: X-Spam-Status: No, score=-102.578 tagged_above=-999 required=5 tests=[AWL=0.021, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3puxoNqwuVk7 for ; Fri, 18 Feb 2011 15:08:33 -0800 (PST) Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by core3.amsl.com (Postfix) with ESMTP id 76AF83A6D3E for ; Fri, 18 Feb 2011 15:08:33 -0800 (PST) Received: from crankycanuck.ca (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 AAC741ECB420 for ; Fri, 18 Feb 2011 23:09:07 +0000 (UTC) Date: Fri, 18 Feb 2011 18:09:06 -0500 From: Andrew Sullivan To: dnsext@ietf.org Message-ID: <20110218230905.GN74065@shinkuro.com> References: <20110216073338.7251.qmail@joyce.lan> <20110216165921.GW96213@shinkuro.com> <3B90ED2E-980D-4B01-889F-447D66D0B58D@insensate.co.uk> <20110216174011.GZ96213@shinkuro.com> <20110218143653.GC84482@bikeshed.isc.org> <20110218151209.GF66684@shinkuro.com> <4D5EEE09.4080405@dougbarton.us> <20110218222950.GL74065@shinkuro.com> <4D5EF74C.9080603@dougbarton.us> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4D5EF74C.9080603@dougbarton.us> User-Agent: Mutt/1.5.18 (2008-05-17) Subject: Re: [dnsext] we need help to make names the same, was draft-yao-dnsext-identical-resolution-02 comment X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 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, 18 Feb 2011 23:08:34 -0000 On Fri, Feb 18, 2011 at 02:48:44PM -0800, Doug Barton wrote: > Sure, that's possible. But I think it's very, very unlikely. As I said > in my previous post registries today are giving registrants the option > of whether to delegate the variants, I don't see this changing if we > give them a new tool to use. I've asked before, and I'll ask again now: what do you mean by "registries"? Remember that we are _not_ talking only about the top level. It is certainly true that the commercial environment today concentrates most of the commercial relationships and delegations at the top level, and it is also true that most delegations below the top level are friendly and co-operative. But I'm simply not willing to say, glibly, "The future will resemble the past," in this area. For instance, we are today in a commercial environment where the scope for expansion of the top level is very large, and there is little reason to believe that all of those new operators are going to do exactly the same thing as everyone else already has been doing. We need to design this protocol change for cases we can plausibly imagine, not just what we happen to have seen. A -- Andrew Sullivan ajs@shinkuro.com Shinkuro, Inc. From dougb@dougbarton.us Fri Feb 18 15:45:59 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C612C3A6EC8 for ; Fri, 18 Feb 2011 15:45:59 -0800 (PST) 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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wQzA7pFinPiN for ; Fri, 18 Feb 2011 15:45:58 -0800 (PST) Received: from mail2.fluidhosting.com (mx22.fluidhosting.com [204.14.89.5]) by core3.amsl.com (Postfix) with ESMTP id 63DF13A6D6F for ; Fri, 18 Feb 2011 15:45:58 -0800 (PST) Received: (qmail 19330 invoked by uid 399); 18 Feb 2011 23:46:31 -0000 Received: from router.ka9q.net (HELO doug-optiplex.ka9q.net) (dougb@dougbarton.us@75.60.237.91) by mail2.fluidhosting.com with ESMTPAM; 18 Feb 2011 23:46:31 -0000 X-Originating-IP: 75.60.237.91 X-Sender: dougb@dougbarton.us Message-ID: <4D5F04D5.7000901@dougbarton.us> Date: Fri, 18 Feb 2011 15:46:29 -0800 From: Doug Barton Organization: http://SupersetSolutions.com/ User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.13) Gecko/20110129 Thunderbird/3.1.7 MIME-Version: 1.0 To: dnsext@ietf.org References: <20110216073338.7251.qmail@joyce.lan> <20110216165921.GW96213@shinkuro.com> <3B90ED2E-980D-4B01-889F-447D66D0B58D@insensate.co.uk> <20110216174011.GZ96213@shinkuro.com> <20110218143653.GC84482@bikeshed.isc.org> <20110218151209.GF66684@shinkuro.com> <4D5EEE09.4080405@dougbarton.us> <20110218222950.GL74065@shinkuro.com> <4D5EF74C.9080603@dougbarton.us> <20110218230905.GN74065@shinkuro.com> In-Reply-To: <20110218230905.GN74065@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 Subject: Re: [dnsext] we need help to make names the same, was draft-yao-dnsext-identical-resolution-02 comment X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 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, 18 Feb 2011 23:45:59 -0000 On 02/18/2011 15:09, Andrew Sullivan wrote: > On Fri, Feb 18, 2011 at 02:48:44PM -0800, Doug Barton wrote: > >> Sure, that's possible. But I think it's very, very unlikely. As I said >> in my previous post registries today are giving registrants the option >> of whether to delegate the variants, I don't see this changing if we >> give them a new tool to use. > > I've asked before, and I'll ask again now: what do you mean by > "registries"? Remember that we are _not_ talking only about the top > level. Define "top." :) If you're talking about organizations registering new Top Level Domains with ICANN then the behavior regarding variants will be defined by mutual agreement so we don't have to worry there. If you're talking about how the TLD registries handle this issue with their registrants this behavior will also be defined in advance so the registrant will know what they are getting themselves into. > It is certainly true that the commercial environment today > concentrates most of the commercial relationships and delegations at > the top level, and it is also true that most delegations below the top > level are friendly and co-operative. > > But I'm simply not willing to say, glibly, "The future will resemble > the past," in this area. For instance, we are today in a commercial > environment where the scope for expansion of the top level is very > large, and there is little reason to believe that all of those new > operators are going to do exactly the same thing as everyone else > already has been doing. We need to design this protocol change for > cases we can plausibly imagine, not just what we happen to have seen. The key word there being "plausibly." I don't foresee a scenario where TLD registries will "force" activating variants (whether by delegation, or some other solution we provide) on their registrants without warning. 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 ebw@abenaki.wabanaki.net Fri Feb 18 18:12:05 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C87A83A6E6C for ; Fri, 18 Feb 2011 18:12:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.49 X-Spam-Level: X-Spam-Status: No, score=-1.49 tagged_above=-999 required=5 tests=[AWL=1.110, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SHSubmZ8OrJI for ; Fri, 18 Feb 2011 18:12:05 -0800 (PST) Received: from abenaki.wabanaki.net (abenaki.wabanaki.net [65.99.1.133]) by core3.amsl.com (Postfix) with ESMTP id D10EA3A6E23 for ; Fri, 18 Feb 2011 18:12:04 -0800 (PST) Received: from limpet.local (cpe-67-255-5-237.twcny.res.rr.com [67.255.5.237]) by abenaki.wabanaki.net (8.14.4/8.14.4) with ESMTP id p1J0RGeJ078371 for ; Fri, 18 Feb 2011 19:27:17 -0500 (EST) (envelope-from ebw@abenaki.wabanaki.net) Message-ID: <4D5F270F.20401@abenaki.wabanaki.net> Date: Fri, 18 Feb 2011 21:12:31 -0500 From: Eric Brunner-Williams Organization: wampumpeag User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: dnsext@ietf.org References: <20110216073338.7251.qmail@joyce.lan> <20110216165921.GW96213@shinkuro.com> <3B90ED2E-980D-4B01-889F-447D66D0B58D@insensate.co.uk> <20110216174011.GZ96213@shinkuro.com> <20110218143653.GC84482@bikeshed.isc.org> <20110218151209.GF66684@shinkuro.com> <4D5EEE09.4080405@dougbarton.us> <20110218222950.GL74065@shinkuro.com> <4D5EF74C.9080603@dougbarton.us> <20110218230905.GN74065@shinkuro.com> In-Reply-To: <20110218230905.GN74065@shinkuro.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [dnsext] we need help to make names the same, was draft-yao-dnsext-identical-resolution-02 comment X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 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, 19 Feb 2011 02:12:05 -0000 On 2/18/11 6:09 PM, Andrew Sullivan wrote: > ... > It is certainly true that the commercial environment today > concentrates most of the commercial relationships and delegations at > the top level, and it is also true that most delegations below the top > level are friendly and co-operative. agree. a CNOBI (com/net/org/biz/info) "feature" is fine, if, like GMO corn and soy, appropriately labeled. it is not a general (generic is a word that leads too often back to CNOBI) property of the hierarchical system. > But I'm simply not willing to say, glibly, "The future will resemble > the past," in this area. For instance, we are today in a commercial > environment... i wish the word "commercial" was paired with "and non-commercial" to somehow suggest that the mercantilism at ICANN is not universally embraced or of infinite duration. > ... where the scope for expansion of the top level is very > large, and there is little reason to believe that all of those new > operators are going to do exactly the same thing as everyone else > already has been doing. +1, though there is a dot-bomb equivalent accumulation of ambition to replicate the failed competition policy experiment of 2000 and capture more than a cosmetic (and trademark subsidized) fragment of the .com market, and an accumulation of ambition to replicate the successful communitarian policy experiment of 2004, without trademark subsidy, pioneered by Fundacio PuntCat. what we really don't know (to paraphrase a man who really should be a guest of the government) is what will happen outside of the copy-.com and copy-.cat trajectories. > ... We need to design this protocol change for > cases we can plausibly imagine, not just what we happen to have seen. err, well, yes in principle, and no in practice. that is, a series of pick-according-to-taste-or-belief{blunders, errors, accidents, acts of genius} has lead to some specific use cases. han sc/tc. greek tonos. failing to solve leads to unintended consequences. -e From marka@isc.org Sat Feb 19 13:07:01 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7B2493A6FC2 for ; Sat, 19 Feb 2011 13:07:01 -0800 (PST) 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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1oGQ6FhaFILk for ; Sat, 19 Feb 2011 13:07:00 -0800 (PST) Received: from mx.ams1.isc.org (mx.ams1.isc.org [IPv6:2001:500:60::65]) by core3.amsl.com (Postfix) with ESMTP id 1A7343A6F18 for ; Sat, 19 Feb 2011 13:07:00 -0800 (PST) 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 211305F9865 for ; Sat, 19 Feb 2011 21:07:22 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (drugs.dv.isc.org [IPv6:2001:470:1f00:820:ea06:88ff:fef3:4f9c]) (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 2495A216C1E for ; Sat, 19 Feb 2011 21:07:20 +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 72943A5602B for ; Sun, 20 Feb 2011 08:07:16 +1100 (EST) To: dnsext@ietf.org From: Mark Andrews Date: Sun, 20 Feb 2011 08:07:15 +1100 Message-Id: <20110219210716.72943A5602B@drugs.dv.isc.org> Subject: [dnsext] Failure to add glue MUST cause TC to be set. X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 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, 19 Feb 2011 21:07:01 -0000 Below is a example of why TC should be set when glue cannot be added to the answer. We need to make it clear that adding address records here (RFC 1034, Section 4.3.2, step 3b) is not optional unlike step 6 where they are optional. b. If a match would take us out of the authoritative data, we have a referral. This happens when we encounter a node with NS RRs marking cuts along the bottom of a zone. Copy the NS RRs for the subzone into the authority section of the reply. Put whatever addresses are available into the additional section, using glue RRs if the addresses are not available from authoritative data or the cache. Go to step 4. Mark ; <<>> DiG 9.6.0-APPLE-P2 <<>> +norec +dnssec +bufsize=512 @b.gov-servers.net vwall1a.nyc.gov ; (1 server found) ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 13052 ;; flags: qr; QUERY: 1, ANSWER: 0, AUTHORITY: 6, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 1472 ;; QUESTION SECTION: ;vwall1a.nyc.gov. IN A ;; AUTHORITY SECTION: nyc.gov. 86400 IN NS vwall1a.nyc.gov. nyc.gov. 86400 IN NS vwall2a.nyc.gov. nyc.gov. 86400 IN NS vwall3a.nyc.gov. nyc.gov. 86400 IN NS vwall4a.nyc.gov. rq2651faaj4nen6tfis8ju5005qccn8j.gov. 86400 IN NSEC3 1 0 8 4C44934802D3 RQDJO8PKJ2LEUMC30SGU45DDI643G497 NS rq2651faaj4nen6tfis8ju5005qccn8j.gov. 86400 IN RRSIG NSEC3 7 2 86400 20110224160026 20110219160026 47602 gov. ZL6YdI7AOtcv5Vfs9cjOZkj6tld5+K4UfDjD2BV4ToBQQ4jhD6HS102P p2TGBP90RdjSLGpGw5OHt9ZxjCPzjWjcoM5V5PiWoGhXrmdgahfmVENE cRH9gsxJhlonz+vIfXlFTeCLgn5d3D5WxjURdGKfDK5j35JvDKb0kQ+8 CwZNXGeopE+01fgiTbIMvSqXCpXlXY/RD+fAbfuh+5e05jdIbj/53/9+ gQOHTXYd3T9jCOxrFOONuznzyvpRODJ3Sga/P+DvWzgUrVZSOKYEsAAi COTbtyCqDhfBIyNB9MxPry4oN0uet46zTjIqhvRg4JjPnfC9WFAEGDTK uolyNw== ;; Query time: 187 msec ;; SERVER: 209.112.123.30#53(209.112.123.30) ;; WHEN: Sun Feb 20 07:39:46 2011 ;; MSG SIZE rcvd: 510 -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From vixie@isc.org Sat Feb 19 13:19:52 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 11FCE3A6FC6 for ; Sat, 19 Feb 2011 13:19:52 -0800 (PST) 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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U7cUikck4yPj for ; Sat, 19 Feb 2011 13:19:51 -0800 (PST) Received: from nsa.vix.com (unknown [IPv6:2001:4f8:3:bb:230:48ff:fe5a:2f38]) by core3.amsl.com (Postfix) with ESMTP id 2BAAE3A6FBE for ; Sat, 19 Feb 2011 13:19:51 -0800 (PST) Received: from nsa.vix.com (localhost [127.0.0.1]) by nsa.vix.com (Postfix) with ESMTP id B21F8A1055 for ; Sat, 19 Feb 2011 21:20:25 +0000 (UTC) (envelope-from vixie@isc.org) From: Paul Vixie To: dnsext@ietf.org In-Reply-To: Your message of "Sun, 20 Feb 2011 08:07:15 +1100." <20110219210716.72943A5602B@drugs.dv.isc.org> References: <20110219210716.72943A5602B@drugs.dv.isc.org> X-Mailer: MH-E 8.2; nmh 1.2; XEmacs 21.4 (patch 22) Date: Sat, 19 Feb 2011 21:20:25 +0000 Message-ID: <11263.1298150425@nsa.vix.com> Subject: Re: [dnsext] Failure to add glue MUST cause TC to be set. X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 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, 19 Feb 2011 21:19:52 -0000 we also need to require that the parent zone contain the addresses of child glue, since otherwise the parent authority must also be recursive which is something i think we're trying to move away from. re: > We need to make it clear that adding address records here (RFC 1034, > Section 4.3.2, step 3b) is not optional unlike step 6 where they are > optional. > > b. If a match would take us out of the authoritative data, > we have a referral. This happens when we encounter a > node with NS RRs marking cuts along the bottom of a > zone. > > Copy the NS RRs for the subzone into the authority > section of the reply. Put whatever addresses are > available into the additional section, using glue RRs > if the addresses are not available from authoritative > data or the cache. Go to step 4. From hallam@gmail.com Sat Feb 19 17:17:41 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0736B3A7051 for ; Sat, 19 Feb 2011 17:17:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.537 X-Spam-Level: X-Spam-Status: No, score=-3.537 tagged_above=-999 required=5 tests=[AWL=0.061, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yxuNyG1kfuSZ for ; Sat, 19 Feb 2011 17:17:40 -0800 (PST) Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by core3.amsl.com (Postfix) with ESMTP id CF0F63A6A6E for ; Sat, 19 Feb 2011 17:17:39 -0800 (PST) Received: by iwl42 with SMTP id 42so1732349iwl.31 for ; Sat, 19 Feb 2011 17:18:17 -0800 (PST) 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=u/WMtHgzec8GmeDW6/Q2VR7LYtBOdF6gp8ibHDQDJDA=; b=jcKaLNbmcEPFrYpGPGlDDzsPJa7rl0HN1n2zxT1Csr2JaYMKm7evj82/9VkVQOU0xj RTcBVMYw8TyY8rL8fXNk3DJ7OhRYrk1LXGmTe161fo7hROmZ5HxIZRmM+2JjqrdrFIqp olXiftOn833E6joaGKpXl7TLrOOA2vZdI+H80= 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=sCLFoHYVPYgie9Rw0IVHAetgkdp5sHVaM3E/A0Npb4dcKWShQuAbolaAoVphgFDhb+ BbXW8iCl02Mm+mmS58XSURrR9/MZg3fF0nt240II84CmCsCiU4yvZpotAcLQLrmPygxP QdHtK5LSXNRb9u17BiGPHWt0IWiOOA3L86JNQ= MIME-Version: 1.0 Received: by 10.42.4.1 with SMTP id 1mr2982186icq.370.1298164697406; Sat, 19 Feb 2011 17:18:17 -0800 (PST) Received: by 10.42.215.140 with HTTP; Sat, 19 Feb 2011 17:18:17 -0800 (PST) In-Reply-To: <4D5E08E4.8060106@necom830.hpcl.titech.ac.jp> References: <20110216032120.43474.qmail@joyce.lan> <20110216212930.57D64A3F344@drugs.dv.isc.org> <4D5D24F3.70206@gis.net> <20110217231720.1FCF3A49096@drugs.dv.isc.org> <4D5E08E4.8060106@necom830.hpcl.titech.ac.jp> Date: Sat, 19 Feb 2011 17:18:17 -0800 Message-ID: From: Phillip Hallam-Baker To: Masataka Ohta Content-Type: multipart/alternative; boundary=0016e68f67d8a61fb5049cac85ca Cc: dnsext@ietf.org Subject: Re: [dnsext] SRV and wildcard CNAME X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 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, 20 Feb 2011 01:17:41 -0000 --0016e68f67d8a61fb5049cac85ca Content-Type: text/plain; charset=ISO-8859-1 It does indeed. And worse, it works for _null._random.example.com SRV... And other non existent protocols. There is a way to fix the issue. Instead of resolving in a single step, a two step resolution is performed. The first step being for an unprefixed name. This will result in either 'not found' or a canonical name being returned. The prefix is applied to the canonical name in the second phase. On Thu, Feb 17, 2011 at 9:51 PM, Masataka Ohta < mohta@necom830.hpcl.titech.ac.jp> wrote: > Mark Andrews wrote: > > > this include "www.example.net CNAME example.net". > > That's a problem. But... > > > Additionally people are too lazy to add records for each virtual > > service in the DNS so they use "* CNAME server" which makes using > > SRV hard as it requires prepended labels. > > Doesn't it mean: > > *.example.com CNAME srv.example.com > srv.example.com SRV Priority Weight Port Target > > works as: > > _http._tcp.www.example.com SRV Priority Weight Port Target > > ? > Masataka Ohta > _______________________________________________ > dnsext mailing list > dnsext@ietf.org > https://www.ietf.org/mailman/listinfo/dnsext > -- Website: http://hallambaker.com/ --0016e68f67d8a61fb5049cac85ca Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable It does indeed.=A0And worse, it works for=A0

_null._random.example.com =A0SRV...

And other non existent protocols.

There is a way to fix the issue. Instead of resolving in a single step, a = two step resolution is performed. The first step being for an unprefixed na= me. This will result in either 'not found' or a canonical name bein= g returned. The prefix is applied to the canonical name in the second phase= .


On Thu, Feb 17, 2011 at 9:51 PM, Ma= sataka Ohta <mohta@necom830.hpcl.titech.ac.jp> wrote:
Mark Andrews wrote:

> this include "www.example.net CNAME example.net".

That's a problem. But...

> Additionally people are too lazy to add records for each virtual
> service in the DNS so they use "* CNAME server" which makes = using
> SRV hard as it requires prepended labels.

Doesn't it mean:

=A0 =A0 =A0 =A0*.example.= com =A0 =A0CNAME s= rv.example.com
=A0 =A0 =A0 =A0srv.ex= ample.com =A0SRV =A0 Priority Weight Port Target

works as:

=A0 =A0 =A0 =A0_http._tcp.www.example.com SRV =A0Priority Weight Port Target

?
=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/

--0016e68f67d8a61fb5049cac85ca-- From bmanning@karoshi.com Sat Feb 19 23:29:52 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7C3393A6CB6 for ; Sat, 19 Feb 2011 23:29:52 -0800 (PST) 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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cNcb-0ynxFJu for ; Sat, 19 Feb 2011 23:29:51 -0800 (PST) Received: from vacation.karoshi.com (vacation.karoshi.com [198.32.6.68]) by core3.amsl.com (Postfix) with ESMTP id 80A323A6CD1 for ; Sat, 19 Feb 2011 23:29:46 -0800 (PST) Received: from karoshi.com (localhost.localdomain [127.0.0.1]) by vacation.karoshi.com (8.12.8/8.12.8) with ESMTP id p1K7TV7s003517; Sun, 20 Feb 2011 07:29:48 GMT Received: (from bmanning@localhost) by karoshi.com (8.12.8/8.12.8/Submit) id p1K7TLsv003516; Sun, 20 Feb 2011 07:29:21 GMT Date: Sun, 20 Feb 2011 07:29:16 +0000 From: bmanning@vacation.karoshi.com To: Paul Vixie Message-ID: <20110220072916.GA3505@vacation.karoshi.com.> References: <20110219210716.72943A5602B@drugs.dv.isc.org> <11263.1298150425@nsa.vix.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <11263.1298150425@nsa.vix.com> User-Agent: Mutt/1.4.1i Cc: dnsext@ietf.org Subject: Re: [dnsext] Failure to add glue MUST cause TC to be set. X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 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, 20 Feb 2011 07:29:52 -0000 doesn't that cause some tension - two zones being authoritative for the same data? and i'm not fully convinced that stripping out recursion is a n'cessy evil. --bill On Sat, Feb 19, 2011 at 09:20:25PM +0000, Paul Vixie wrote: > we also need to require that the parent zone contain the addresses of > child glue, since otherwise the parent authority must also be recursive > which is something i think we're trying to move away from. > > re: > > > We need to make it clear that adding address records here (RFC 1034, > > Section 4.3.2, step 3b) is not optional unlike step 6 where they are > > optional. > > > > b. If a match would take us out of the authoritative data, > > we have a referral. This happens when we encounter a > > node with NS RRs marking cuts along the bottom of a > > zone. > > > > Copy the NS RRs for the subzone into the authority > > section of the reply. Put whatever addresses are > > available into the additional section, using glue RRs > > if the addresses are not available from authoritative > > data or the cache. Go to step 4. > _______________________________________________ > dnsext mailing list > dnsext@ietf.org > https://www.ietf.org/mailman/listinfo/dnsext From jra@baylink.com Sun Feb 20 08:14:35 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3C3423A6FF3 for ; Sun, 20 Feb 2011 08:14:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.878 X-Spam-Level: X-Spam-Status: No, score=-1.878 tagged_above=-999 required=5 tests=[AWL=-0.144, BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, RDNS_DYNAMIC=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3pv0PEgh4jM1 for ; Sun, 20 Feb 2011 08:14:34 -0800 (PST) Received: from benjamin.baylink.com (rrcs-24-129-180-187.se.biz.rr.com [24.129.180.187]) by core3.amsl.com (Postfix) with ESMTP id 90AC53A6FF2 for ; Sun, 20 Feb 2011 08:14:34 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by benjamin.baylink.com (Postfix) with ESMTP id D418E1F0012D for ; Sun, 20 Feb 2011 11:15:24 -0500 (EST) X-Virus-Scanned: amavisd-new at benjamin.baylink.com Received: from benjamin.baylink.com ([127.0.0.1]) by localhost (benjamin.baylink.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 859Ofat3DNXr for ; Sun, 20 Feb 2011 11:15:24 -0500 (EST) Received: from benjamin.baylink.com (benjamin.baylink.com [192.168.253.10]) by benjamin.baylink.com (Postfix) with ESMTP id 099361F00121 for ; Sun, 20 Feb 2011 11:15:24 -0500 (EST) Date: Sun, 20 Feb 2011 11:15:24 -0500 (EST) From: Jay Ashworth To: dnsext@ietf.org Message-ID: <33409067.626.1298218524005.JavaMail.root@benjamin.baylink.com> In-Reply-To: <4D5EEE09.4080405@dougbarton.us> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [65.34.93.30] X-Mailer: Zimbra 6.0.9_GA_2686 (ZimbraWebClient - FF3.0 (Linux)/6.0.9_GA_2686) Subject: Re: [dnsext] we need help to make names the same, was draft-yao-dnsext-identical-resolution-02 comment X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 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, 20 Feb 2011 16:14:35 -0000 ----- Original Message ----- > From: "Doug Barton" > But back to your original concern, I agree that we don't want to solve > one part of the problem in a way that makes other parts of the problem > harder (or impossible) to solve. Or, even worse, "which causes new heretofore unexperienced problems for completely unrelated items and services." Remember always that important principle: "The Internet is the only human endeavour in which a single character typographical error in a file on a server *on the other side of the planet* can cause your entire network to come crashing to the ground." I think I've got that right. :-) Can't remember who said it though. Some BGP-speaker, almost certainly. Cheers, -- jra From hallam@gmail.com Sun Feb 20 10:04:25 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9A6DE3A6EED for ; Sun, 20 Feb 2011 10:04:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.54 X-Spam-Level: X-Spam-Status: No, score=-3.54 tagged_above=-999 required=5 tests=[AWL=0.058, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LON4KhxotxGo for ; Sun, 20 Feb 2011 10:04:24 -0800 (PST) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by core3.amsl.com (Postfix) with ESMTP id 7CDF73A6D04 for ; Sun, 20 Feb 2011 10:04:24 -0800 (PST) Received: by iym1 with SMTP id 1so5615515iym.31 for ; Sun, 20 Feb 2011 10:05:03 -0800 (PST) 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=bXO/OvAD3NUNz9bcPyIr5Ya6zc2wtGHqg+yfilv2ikU=; b=MTEjmSdO6sbpPbjElj+xevb3TEFMG5mQEIsHUO/iILQ8Qj3RUFEnLwB+8V1BxPdkuQ cTAlFhpjGIcryt+h6A3kjvh6yZGMkVnWVokqvPU49MZuEfxibuBh/VT5PWOOAc+JleD7 xsWrDOmpAlqz6qsXejyYvBge16l5AS2HlWBqc= 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=aDt+QYLkoFhPjyUTlf09TOjpMk1g75DuQSWqzoJFWDgW7FEmNFbyFfPR1+mOkyuBMe Oty/yL/h/74xCFqpMdfFS0lyV6ZzdEk2SjAjIloKWqHSoDvCYOsp3rgD3W1GIAMY/bJ5 f5aGN3Ck5AKSjtF2rua7PrNuLTgcHj4hEKBwE= MIME-Version: 1.0 Received: by 10.42.218.3 with SMTP id ho3mr734416icb.437.1298225102901; Sun, 20 Feb 2011 10:05:02 -0800 (PST) Received: by 10.42.215.140 with HTTP; Sun, 20 Feb 2011 10:05:02 -0800 (PST) In-Reply-To: <20110218043200.AB350A4D593@drugs.dv.isc.org> References: <20110216032120.43474.qmail@joyce.lan> <20110216212930.57D64A3F344@drugs.dv.isc.org> <4D5D24F3.70206@gis.net> <20110217231720.1FCF3A49096@drugs.dv.isc.org> <4D5DE54C.5010104@gis.net> <20110218034737.9B601A4D098@drugs.dv.isc.org> <4D5DF040.6030404@gis.net> <20110218043200.AB350A4D593@drugs.dv.isc.org> Date: Sun, 20 Feb 2011 10:05:02 -0800 Message-ID: From: Phillip Hallam-Baker To: Mark Andrews Content-Type: multipart/alternative; boundary=20cf3054a05b18d418049cba96c9 Cc: John Levine , dnsext@ietf.org Subject: Re: [dnsext] we need help to make names the same, was draft-yao-dnsext-identical-resolution-02 comment X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 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, 20 Feb 2011 18:04:25 -0000 --20cf3054a05b18d418049cba96c9 Content-Type: text/plain; charset=ISO-8859-1 On Thu, Feb 17, 2011 at 8:32 PM, Mark Andrews wrote: > > > I don't care about the transport piece since that's on the LHS. It's the > > path that cannot be specified here. Where do I go to get the > > /Ws/SOAPServlet part? The path is going to be different for each site. > > I'd love to use SRV records particularly as Brian W implemented a Java > > DNS library (dnsjava from xbill) that supports SRV records. > > That's the job of NAPTR records. > > > Danny > No, the purpose of NAPTR records was to provide a scheme for 'resolving' URNs. Using NAPTR for any other purpose is a terrible idea. They have regular expressions and that is tantamount to being a Turing complete scheme. Why not put javascript in the DNS while we are at it? Trying to use NAPTR here results in records whose effects cannot be predicted by machines and thus prevent automation of administrative processes. -- Website: http://hallambaker.com/ --20cf3054a05b18d418049cba96c9 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Thu, Feb 17, 2011 at 8:32 PM, Mark An= drews <marka@isc.org<= /a>> wrote:

> I don't care about the transport piece since that's on the LHS= . It's the
> path that cannot be specified here. Where do I go to get the
> /Ws/SOAPServlet part? The path is going to be different for each site.=
> I'd love to use SRV records particularly as Brian W implemented a = Java
> DNS library (dnsjava from xbill) that supports SRV records.

That's the job of NAPTR records.

> Danny

No, the purpose of NAP= TR records was to provide a scheme for 'resolving' URNs.=A0

Using NAPTR for any other purpose is a terrible ide= a. They have regular expressions and that is tantamount to being a Turing c= omplete scheme. Why not put javascript in the DNS while we are at it?

Trying to use NAPTR here results in records whose effec= ts cannot be predicted by machines and thus prevent automation of administr= ative processes.


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

--20cf3054a05b18d418049cba96c9-- From fanf2@hermes.cam.ac.uk Sun Feb 20 10:48:41 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C24A23A6F4C for ; Sun, 20 Feb 2011 10:48:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.202 X-Spam-Level: X-Spam-Status: No, score=-5.202 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4zzyLQbb9+ds for ; Sun, 20 Feb 2011 10:48:39 -0800 (PST) Received: from ppsw-51.csi.cam.ac.uk (ppsw-51.csi.cam.ac.uk [131.111.8.151]) by core3.amsl.com (Postfix) with ESMTP id F152C3A6F5C for ; Sun, 20 Feb 2011 10:48:38 -0800 (PST) X-Cam-AntiVirus: no malware found X-Cam-SpamDetails: not scanned X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ Received: from 69.91.125.91.rb4.adsl.brightview.com ([91.125.91.69]:50456 helo=[192.168.0.5]) by ppsw-51.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.158]:587) with esmtpsa (PLAIN:fanf2) (TLSv1:AES128-SHA:128) id 1PrELL-00068g-ZQ (Exim 4.72) (return-path ); Sun, 20 Feb 2011 18:49:16 +0000 References: <20110219210716.72943A5602B@drugs.dv.isc.org> <11263.1298150425@nsa.vix.com> <20110220072916.GA3505@vacation.karoshi.com.> In-Reply-To: <20110220072916.GA3505@vacation.karoshi.com.> Mime-Version: 1.0 (iPhone Mail 8C148) Content-Transfer-Encoding: 7bit Content-Type: multipart/alternative; boundary=Apple-Mail-1--54523982 Message-Id: <30899A4A-833B-42EF-9850-AFEE8B8DBE02@dotat.at> X-Mailer: iPhone Mail (8C148) From: Tony Finch Date: Sun, 20 Feb 2011 18:48:57 +0000 To: "bmanning@vacation.karoshi.com" Sender: Tony Finch Cc: "dnsext@ietf.org" Subject: Re: [dnsext] Failure to add glue MUST cause TC to be set. X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 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, 20 Feb 2011 18:48:42 -0000 --Apple-Mail-1--54523982 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On 20 Feb 2011, at 07:29, bmanning@vacation.karoshi.com wrote: >=20 > doesn't that cause some tension - two zones being authoritative for the > same data?=20 No, because a parent zone is not authoritative for NS and glue address recor= ds at and below a delegation point. Tony. -- f.anthony.n.finch http://dotat.at/= --Apple-Mail-1--54523982 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
On 20 Feb 2011, at 07:29, bmanning@vacation.karoshi.com wrote:

doesn't that cause some tension - two zones being authoritative f= or the
same data? 
=

No, because a parent zone is not authorit= ative for NS and glue address records at and below a delegation point.

Tony.
--
f.anthony.n.finch  <dot@dotat.at>  = http://dotat.at/
= --Apple-Mail-1--54523982-- From fanf2@hermes.cam.ac.uk Sun Feb 20 11:08:39 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2C2863A6D3C for ; Sun, 20 Feb 2011 11:08:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.203 X-Spam-Level: X-Spam-Status: No, score=-5.203 tagged_above=-999 required=5 tests=[AWL=0.001, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xfruNlTa4n2V for ; Sun, 20 Feb 2011 11:08:38 -0800 (PST) Received: from ppsw-41.csi.cam.ac.uk (ppsw-41.csi.cam.ac.uk [131.111.8.141]) by core3.amsl.com (Postfix) with ESMTP id 2EFC33A6D2B for ; Sun, 20 Feb 2011 11:08:38 -0800 (PST) X-Cam-AntiVirus: no malware found X-Cam-SpamDetails: not scanned X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ Received: from 69.91.125.91.rb4.adsl.brightview.com ([91.125.91.69]:50489 helo=[192.168.0.5]) by ppsw-41.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.156]:587) with esmtpsa (PLAIN:fanf2) (TLSv1:AES128-SHA:128) id 1PrEed-0001bO-RE (Exim 4.72) (return-path ); Sun, 20 Feb 2011 19:09:11 +0000 References: <4D5B5E81.1050602@necom830.hpcl.titech.ac.jp> <20110216073338.7251.qmail@joyce.lan> <20110216165921.GW96213@shinkuro.com> <3B90ED2E-980D-4B01-889F-447D66D0B58D@insensate.co.uk> <20110216174011.GZ96213@shinkuro.com> <20110218143653.GC84482@bikeshed.isc.org> <20110218151209.GF66684@shinkuro.com> <4D5EEE09.4080405@dougbarton.us> <20110218222950.GL74065@shinkuro.com> <20110218230456.0EBCBA5028E@drugs.dv.isc.org> In-Reply-To: <20110218230456.0EBCBA5028E@drugs.dv.isc.org> Mime-Version: 1.0 (iPhone Mail 8C148) Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Message-Id: <6A094DEB-AFBA-4251-8FEE-04D0F546B426@dotat.at> X-Mailer: iPhone Mail (8C148) From: Tony Finch Date: Sun, 20 Feb 2011 19:08:51 +0000 To: Mark Andrews Sender: Tony Finch Cc: "dnsext@ietf.org" Subject: Re: [dnsext] we need help to make names the same, was draft-yao-dnsext-identical-resolution-02 comment X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 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, 20 Feb 2011 19:08:39 -0000 On 18 Feb 2011, at 23:04, Mark Andrews wrote: >=20 > This is where SMTP is now stupid. 822 (821?) required the sender > to rewrite in CNAME. I think the reason for removing this feature is that it allows third parties= to play silly games, inventing new aliases that will deliver mail to people= without their consent. Tony. -- f.anthony.n.finch http://dotat.at/= From george.barwood@blueyonder.co.uk Sun Feb 20 11:12:12 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2A9CD3A6F76 for ; Sun, 20 Feb 2011 11:12:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.595 X-Spam-Level: X-Spam-Status: No, score=0.595 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_BLUEYON=1.4, MIME_BASE64_BLANKS=0.041, MIME_BASE64_TEXT=1.753] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vM7WSSqaOxkm for ; Sun, 20 Feb 2011 11:12:11 -0800 (PST) Received: from smtp-out3.blueyonder.co.uk (smtp-out3.blueyonder.co.uk [195.188.213.6]) by core3.amsl.com (Postfix) with ESMTP id 253E23A6F79 for ; Sun, 20 Feb 2011 11:12:11 -0800 (PST) Received: from [172.23.170.147] (helo=anti-virus03-10) by smtp-out3.blueyonder.co.uk with smtp (Exim 4.52) id 1PrEi9-0005M2-M0; Sun, 20 Feb 2011 19:12:49 +0000 Received: from [92.238.99.235] (helo=GeorgeLaptop) by asmtp-out4.blueyonder.co.uk with smtp (Exim 4.72) (envelope-from ) id 1PrEi8-00088Z-Ok; Sun, 20 Feb 2011 19:12:48 +0000 Message-ID: From: "George Barwood" To: , "Mark Andrews" References: <20110219210716.72943A5602B@drugs.dv.isc.org> Date: Sun, 20 Feb 2011 19:13:06 -0000 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.5994 Subject: Re: [dnsext] Failure to add glue MUST cause TC to be set. X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 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, 20 Feb 2011 19:12:12 -0000 DQotLS0tLSBPcmlnaW5hbCBNZXNzYWdlIC0tLS0tIA0KRnJvbTogIk1hcmsgQW5kcmV3cyIgPG1h cmthQGlzYy5vcmc+DQpUbzogPGRuc2V4dEBpZXRmLm9yZz4NClNlbnQ6IFNhdHVyZGF5LCBGZWJy dWFyeSAxOSwgMjAxMSA5OjA3IFBNDQpTdWJqZWN0OiBbZG5zZXh0XSBGYWlsdXJlIHRvIGFkZCBn bHVlIE1VU1QgY2F1c2UgVEMgdG8gYmUgc2V0Lg0KDQoNCj4gDQo+IEJlbG93IGlzIGEgZXhhbXBs ZSBvZiB3aHkgVEMgc2hvdWxkIGJlIHNldCB3aGVuIGdsdWUgY2Fubm90IGJlIGFkZGVkDQo+IHRv IHRoZSBhbnN3ZXIuDQo+IA0KPiBbLi5dDQoNCkFncmVlZCwgYnV0IHdoZXJlIGV4YWN0bHkgc2hv dWxkIHRoZSBsaW5lIGJlIGRyYXduPw0KDQpJZiBvbWl0dGluZyBhbnkgZ2x1ZSBsZWFkcyB0byB0 cnVuY2F0aW9uLCB0aGVuIG1hbnkgKG5vbi1ETlNTRUMpIHJlZmVycmFscyBvdmVyIFVEUCB3aWxs IGhhdmUgVEMgc2V0LiBlLmcuIA0KDQpkaWcgZm9vLmNvbSBAYS5yb290LXNlcnZlcnMubmV0DQoN CklzIHRoYXQgc2Vuc2libGU/IEhvdyBtdWNoIGdsdWUgaXMgZW5vdWdoPw0KDQpHZW9yZ2UNCg0K PiBNYXJrDQo= From blblack@gmail.com Sun Feb 20 12:14:15 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 93A213A6CCA for ; Sun, 20 Feb 2011 12:14:15 -0800 (PST) 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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Fdj7qPmNbMSX for ; Sun, 20 Feb 2011 12:14:14 -0800 (PST) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by core3.amsl.com (Postfix) with ESMTP id 0340A3A6CFB for ; Sun, 20 Feb 2011 12:14:13 -0800 (PST) Received: by yxd39 with SMTP id 39so611652yxd.31 for ; Sun, 20 Feb 2011 12:14:53 -0800 (PST) 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=WMR+zIaDmXYQs8hzbObglgKhwcdp/eqcQQMwKwmdolA=; b=XDUfP4G9WjwB9ogej7IcEr2pK7gSBkICem/soEhHwfCLVvoyxZ3nzGmzPBykotNO0n gFhKD18dcjjgoLMc+UcJznygUhM84q6IRVyxawSxavNkkGqbrWjGPxu0WkiOSfDD4R5I lElBqsIgKNtmHUKlffgRPtB61pRVP1vQqPhyQ= 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=twp+1dapWESK+X4T7PfiGmlLE4oVqYU1NVhBd/WdwngRBfYewwatK4E/Gin0T4Ngus bMCdOnK3ZUV+AZHFblv3aJv3OPN1LL4OHb+7fJqTdihIejjes78fLZqYDmp6od2eJDdK E1sVnzCiPD4l5D4X7fHzzNLRsZfT0nLMHep2k= MIME-Version: 1.0 Received: by 10.100.58.14 with SMTP id g14mr38882ana.199.1298232892150; Sun, 20 Feb 2011 12:14:52 -0800 (PST) Received: by 10.101.68.7 with HTTP; Sun, 20 Feb 2011 12:14:52 -0800 (PST) In-Reply-To: <30899A4A-833B-42EF-9850-AFEE8B8DBE02@dotat.at> References: <20110219210716.72943A5602B@drugs.dv.isc.org> <11263.1298150425@nsa.vix.com> <20110220072916.GA3505@vacation.karoshi.com.> <30899A4A-833B-42EF-9850-AFEE8B8DBE02@dotat.at> Date: Sun, 20 Feb 2011 14:14:52 -0600 Message-ID: From: Brandon Black To: Tony Finch Content-Type: text/plain; charset=UTF-8 Cc: "bmanning@vacation.karoshi.com" , "dnsext@ietf.org" Subject: Re: [dnsext] Failure to add glue MUST cause TC to be set. X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 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, 20 Feb 2011 20:14:15 -0000 On Sun, Feb 20, 2011 at 12:48 PM, Tony Finch wrote: > On 20 Feb 2011, at 07:29, bmanning@vacation.karoshi.com wrote: > > doesn't that cause some tension - two zones being authoritative for the > same data? > > No, because a parent zone is not authoritative for NS and glue address > records at and below a delegation point. Isn't this really a matter of semantics? The parent zone is authoritative for everything beneath itself, even if it choses to use that power of authority to give a delegation response. e.g. the .com servers are authoritative for www.example.com, but they choose to delegate that answer to the NS for example.com. If example.com's nameservers are in-bailiwick (e.g. ns1.example.com) there's no conflict here and the parent can (and in fact, must) provide authoritative glue. If example.com's nameservers are somewhere underneath .org, there's not much point in providing the glue, as a secure resolver wouldn't believe you anyways. From marka@isc.org Sun Feb 20 12:43:06 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4A3123A6C68 for ; Sun, 20 Feb 2011 12:43:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.523 X-Spam-Level: X-Spam-Status: No, score=-2.523 tagged_above=-999 required=5 tests=[AWL=0.076, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x0tVLAur5Pfl for ; Sun, 20 Feb 2011 12:43:05 -0800 (PST) Received: from mx.pao1.isc.org (mx.pao1.isc.org [IPv6:2001:4f8:0:2::2b]) by core3.amsl.com (Postfix) with ESMTP id 198423A6D2B for ; Sun, 20 Feb 2011 12:43:05 -0800 (PST) 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 5EDE9C9423; Sun, 20 Feb 2011 20:43:31 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (c211-30-172-21.carlnfd1.nsw.optusnet.com.au [211.30.172.21]) (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 23233216C1E; Sun, 20 Feb 2011 20:43:31 +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 C1F83A6526F; Mon, 21 Feb 2011 07:31:56 +1100 (EST) To: "George Barwood" From: Mark Andrews References: <20110219210716.72943A5602B@drugs.dv.isc.org> In-reply-to: Your message of "Sun, 20 Feb 2011 19:13:06 -0000." Date: Mon, 21 Feb 2011 07:31:56 +1100 Message-Id: <20110220203156.C1F83A6526F@drugs.dv.isc.org> Cc: dnsext@ietf.org Subject: Re: [dnsext] Failure to add glue MUST cause TC to be set. X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 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, 20 Feb 2011 20:43:06 -0000 In message , "George Barwood" writes: > ----- Original Message ----- > From: "Mark Andrews" > To: > Sent: Saturday, February 19, 2011 9:07 PM > Subject: [dnsext] Failure to add glue MUST cause TC to be set. > > > Below is a example of why TC should be set when glue cannot be added > > to the answer. > > > > [..] > > Agreed, but where exactly should the line be drawn? What line? If the glue doesn't fit then the referral is not complete. > If omitting any glue leads to truncation, then many (non-DNSSEC) referrals > over UDP will have TC set. e.g. > > dig foo.com @a.root-servers.net Yes. > Is that sensible? Yes. > How much glue is enough? Depends on the delegation. The only safe answer is all you have. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From jim@rfc1035.com Sun Feb 20 12:43:41 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F076B3A6E02 for ; Sun, 20 Feb 2011 12:43:40 -0800 (PST) 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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Yf6MNErGMzNN for ; Sun, 20 Feb 2011 12:43:40 -0800 (PST) Received: from hutch.rfc1035.com (hutch.rfc1035.com [195.54.233.70]) by core3.amsl.com (Postfix) with ESMTP id 104163A6DDA for ; Sun, 20 Feb 2011 12:43:40 -0800 (PST) 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 D546315420A1; Sun, 20 Feb 2011 20:44:16 +0000 (GMT) Message-Id: From: Jim Reid To: Brandon Black In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Sun, 20 Feb 2011 20:44:16 +0000 References: <20110219210716.72943A5602B@drugs.dv.isc.org> <11263.1298150425@nsa.vix.com> <20110220072916.GA3505@vacation.karoshi.com.> <30899A4A-833B-42EF-9850-AFEE8B8DBE02@dotat.at> X-Mailer: Apple Mail (2.936) Cc: "bmanning@vacation.karoshi.com" , "dnsext@ietf.org" Subject: [dnsext] zone cut semantics X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 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, 20 Feb 2011 20:43:41 -0000 On 20 Feb 2011, at 20:14, Brandon Black wrote: > Isn't this really a matter of semantics? Yes: zone cut semantics, not language semantics. > The parent zone is > authoritative for everything beneath itself, even if it choses to use > that power of authority to give a delegation response. e.g. the .com > servers are authoritative for www.example.com, but they choose to > delegate that answer to the NS for example.com. Nope. Query the .com name servers for the NS records for example.com. They correctly return a non-authoritative answer. It's only the name servers for example.com that are authoritative for example.com and will authoritatively answer that query. In other words, it's the child that's responsible for the zone's authoritative NS RRset, not the parent. Which is how things should be when you consider what delegation actually means: crossing an administrative boundary from one authority to another. Please think again about what you posted. The inference of what you say is that the root servers are authoritative for everything. That's clearly not true. From george.barwood@blueyonder.co.uk Sun Feb 20 12:57:56 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C5C1D3A6C68 for ; Sun, 20 Feb 2011 12:57:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.895 X-Spam-Level: X-Spam-Status: No, score=0.895 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, HELO_EQ_BLUEYON=1.4, J_CHICKENPOX_55=0.6, MIME_BASE64_BLANKS=0.041, MIME_BASE64_TEXT=1.753] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NqusCO7a4PHN for ; Sun, 20 Feb 2011 12:57:55 -0800 (PST) Received: from smtp-out4.blueyonder.co.uk (smtp-out4.blueyonder.co.uk [195.188.213.7]) by core3.amsl.com (Postfix) with ESMTP id 70BC73A6CFC for ; Sun, 20 Feb 2011 12:57:55 -0800 (PST) Received: from [172.23.170.146] (helo=anti-virus03-09) by smtp-out4.blueyonder.co.uk with smtp (Exim 4.52) id 1PrGMQ-0003AM-Uv; Sun, 20 Feb 2011 20:58:30 +0000 Received: from [92.238.99.235] (helo=GeorgeLaptop) by asmtp-out5.blueyonder.co.uk with smtp (Exim 4.72) (envelope-from ) id 1PrGMO-0003rq-0o; Sun, 20 Feb 2011 20:58:28 +0000 Message-ID: <3764325DE7FA4B2F9B77387EBD15EAF8@local> From: "George Barwood" To: "Mark Andrews" References: <20110219210716.72943A5602B@drugs.dv.isc.org> <20110220203156.C1F83A6526F@drugs.dv.isc.org> Date: Sun, 20 Feb 2011 20:59:19 -0000 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.5994 Cc: dnsext@ietf.org Subject: Re: [dnsext] Failure to add glue MUST cause TC to be set. X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 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, 20 Feb 2011 20:57:57 -0000 DQotLS0tLSBPcmlnaW5hbCBNZXNzYWdlIC0tLS0tIA0KRnJvbTogIk1hcmsgQW5kcmV3cyIgPG1h cmthQGlzYy5vcmc+DQpUbzogIkdlb3JnZSBCYXJ3b29kIiA8Z2VvcmdlLmJhcndvb2RAYmx1ZXlv bmRlci5jby51az4NCkNjOiA8ZG5zZXh0QGlldGYub3JnPg0KU2VudDogU3VuZGF5LCBGZWJydWFy eSAyMCwgMjAxMSA4OjMxIFBNDQpTdWJqZWN0OiBSZTogW2Ruc2V4dF0gRmFpbHVyZSB0byBhZGQg Z2x1ZSBNVVNUIGNhdXNlIFRDIHRvIGJlIHNldC4NCg0KDQo+IA0KPiBJbiBtZXNzYWdlIDxBMDI1 NTJDQkJGMkI0MkY1QkE5MUQ2RTRFQzIzRjMxREBsb2NhbD4sICJHZW9yZ2UgQmFyd29vZCIgd3Jp dGVzOg0KPj4gLS0tLS0gT3JpZ2luYWwgTWVzc2FnZSAtLS0tLSANCj4+IEZyb206ICJNYXJrIEFu ZHJld3MiIDxtYXJrYUBpc2Mub3JnPg0KPj4gVG86IDxkbnNleHRAaWV0Zi5vcmc+DQo+PiBTZW50 OiBTYXR1cmRheSwgRmVicnVhcnkgMTksIDIwMTEgOTowNyBQTQ0KPj4gU3ViamVjdDogW2Ruc2V4 dF0gRmFpbHVyZSB0byBhZGQgZ2x1ZSBNVVNUIGNhdXNlIFRDIHRvIGJlIHNldC4NCj4+IA0KPj4g PiBCZWxvdyBpcyBhIGV4YW1wbGUgb2Ygd2h5IFRDIHNob3VsZCBiZSBzZXQgd2hlbiBnbHVlIGNh bm5vdCBiZSBhZGRlZA0KPj4gPiB0byB0aGUgYW5zd2VyLg0KPj4gPiANCj4+ID4gWy4uXQ0KPj4g DQo+PiBBZ3JlZWQsIGJ1dCB3aGVyZSBleGFjdGx5IHNob3VsZCB0aGUgbGluZSBiZSBkcmF3bj8N Cj4gDQo+IFdoYXQgbGluZT8gIElmIHRoZSBnbHVlIGRvZXNuJ3QgZml0IHRoZW4gdGhlIHJlZmVy cmFsIGlzIG5vdCBjb21wbGV0ZS4NCj4gDQo+PiBJZiBvbWl0dGluZyBhbnkgZ2x1ZSBsZWFkcyB0 byB0cnVuY2F0aW9uLCB0aGVuIG1hbnkgKG5vbi1ETlNTRUMpIHJlZmVycmFscw0KPj4gb3ZlciBV RFAgd2lsbCBoYXZlIFRDIHNldC4gZS5nLiANCj4+IA0KPj4gZGlnIGZvby5jb20gQGEucm9vdC1z ZXJ2ZXJzLm5ldA0KPiANCj4gWWVzLg0KPiANCj4+IElzIHRoYXQgc2Vuc2libGU/DQo+IA0KPiBZ ZXMuDQo+IA0KPj4gSG93IG11Y2ggZ2x1ZSBpcyBlbm91Z2g/DQo+IA0KPiBEZXBlbmRzIG9uIHRo ZSBkZWxlZ2F0aW9uLiAgVGhlIG9ubHkgc2FmZSBhbnN3ZXIgaXMgYWxsIHlvdSBoYXZlLg0KDQpP bmUgc3VnZ2VzdGlvbiB0aGF0IG1pZ2h0IHdvcmsgaXMgdGhhdCBnbHVlIHdoaWNoIG1hdGNocyBR TkFNRStRVFlQRSBNVVNUIGJlIGluY2x1ZGVkLA0KYnV0IG90aGVyIGdsdWUgY2FuIGJlIG9taXR0 ZWQuDQoNClNvIGFuIGV4YW1wbGUgbWlnaHQgYmUgKCBhbGwgcXVlcmllcyBkaXJlY3RlZCB0byBy b290IHNlcnZlcnMgKQ0KRmlyc3QgcXVlcnkgW3d3dy5mb28ubmV0LiBBXQ0KRmlyc3QgcmVmZXJy YWwgcmVzcG9uc2UgW25ldCBOUyBhLmd0bGQtc2VydmVycy5uZXRdICAobWlzc2luZyBnbHVlKQ0K U2Vjb25kIHF1ZXJ5IFthLmd0bGQtc2VydmVycy5uZXQgQV0NClNlY29uZCByZWZlcnJhbCByZXNw b25zZSBbbmV0IE5TIGEuZ3RsZC1zZXJ2ZXJzLm5ldF0gd2l0aCBnbHVlIGZvciBbYS5ndGxkLXNl cnZlcnMubmV0IEFdIG9ubHkuDQoNClRoaXMgYXNzdW1lcyB0aGF0IGEgcmVzb2x2ZXIgd2lsbCBz ZW5kIGFuIGV4cGxpY2l0IHF1ZXJ5IGZvciBtaXNzaW5nIGdsdWUuDQpUaGF0IHNlZW1zIHBsYXVz aWJsZSwgYmVjYXVzZSByZXNvbHZlcnMgYWxyZWFkeSBoYXZlIHRvIGNvcGUgd2l0aCBub3QgYWxs IGdsdWUgYmVpbmcgcHJlc2VudC4NCg0KR2VvcmdlDQoNCj4gTWFyaw0KPiANCj4gLS0gDQo+IE1h cmsgQW5kcmV3cywgSVNDDQo+IDEgU2V5bW91ciBTdC4sIER1bmRhcyBWYWxsZXksIE5TVyAyMTE3 LCBBdXN0cmFsaWENCj4gUEhPTkU6ICs2MSAyIDk4NzEgNDc0MiAgICAgICAgICAgICAgICAgSU5U RVJORVQ6IG1hcmthQGlzYy5vcmc= From marka@isc.org Sun Feb 20 13:07:39 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5B68D3A6CFE for ; Sun, 20 Feb 2011 13:07:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.228 X-Spam-Level: X-Spam-Status: No, score=-2.228 tagged_above=-999 required=5 tests=[AWL=-0.229, BAYES_00=-2.599, J_CHICKENPOX_55=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Pb3-Ge3mcgSS for ; Sun, 20 Feb 2011 13:07:38 -0800 (PST) Received: from mx.ams1.isc.org (mx.ams1.isc.org [IPv6:2001:500:60::65]) by core3.amsl.com (Postfix) with ESMTP id 2E5E93A6C68 for ; Sun, 20 Feb 2011 13:07:38 -0800 (PST) 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 B5FD75F985D; Sun, 20 Feb 2011 21:08:02 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (c211-30-172-21.carlnfd1.nsw.optusnet.com.au [211.30.172.21]) (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 A36E7216C1E; Sun, 20 Feb 2011 21:08:00 +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 81B93A65431; Mon, 21 Feb 2011 08:07:58 +1100 (EST) To: "George Barwood" From: Mark Andrews References: <20110219210716.72943A5602B@drugs.dv.isc.org> <20110220203156.C1F83A6526F@drugs.dv.isc.org><3764325DE7FA4B2F9B77387EBD15EAF8@local> In-reply-to: Your message of "Sun, 20 Feb 2011 20:59:19 -0000." <3764325DE7FA4B2F9B77387EBD15EAF8@local> Date: Mon, 21 Feb 2011 08:07:58 +1100 Message-Id: <20110220210758.81B93A65431@drugs.dv.isc.org> Cc: dnsext@ietf.org Subject: Re: [dnsext] Failure to add glue MUST cause TC to be set. X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 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, 20 Feb 2011 21:07:39 -0000 In message <3764325DE7FA4B2F9B77387EBD15EAF8@local>, "George Barwood" writes: > >> ----- Original Message ----- > >> From: "Mark Andrews" > >> To: > >> Sent: Saturday, February 19, 2011 9:07 PM > >> Subject: [dnsext] Failure to add glue MUST cause TC to be set. > >> > >> > Below is a example of why TC should be set when glue cannot be added > >> > to the answer. > >> > > >> > [..] > >> > >> Agreed, but where exactly should the line be drawn? > > > > What line? If the glue doesn't fit then the referral is not complete. > > > >> If omitting any glue leads to truncation, then many (non-DNSSEC) referrals > >> over UDP will have TC set. e.g. > >> > >> dig foo.com @a.root-servers.net > > > > Yes. > > > >> Is that sensible? > > > > Yes. > > > >> How much glue is enough? > > > > Depends on the delegation. The only safe answer is all you have. > > One suggestion that might work is that glue which matchs QNAME+QTYPE MUST > be included, but other glue can be omitted. This does not work in all cases where glue needs to be returned. Zone A.net is served by servers in B.net. Zone B.net is served by servers in A.net. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From blblack@gmail.com Sun Feb 20 13:14:36 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8F36B3A6DDA for ; Sun, 20 Feb 2011 13:14:36 -0800 (PST) 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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I83Fk6PClKie for ; Sun, 20 Feb 2011 13:14:35 -0800 (PST) Received: from mail-gx0-f172.google.com (mail-gx0-f172.google.com [209.85.161.172]) by core3.amsl.com (Postfix) with ESMTP id BB4463A6C68 for ; Sun, 20 Feb 2011 13:14:35 -0800 (PST) Received: by gxk5 with SMTP id 5so505630gxk.31 for ; Sun, 20 Feb 2011 13:15:15 -0800 (PST) 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=wxJZDMXw/5Tv0U0j8QthyR+A2PcpruRddKnnenYnj+0=; b=JPp1q9gdUDfjwNDY68mZPeuMvqnf7UylZ7XHX/Js3hh4o9H0yyG/FCKS+E5vv8C6pL U5Qj9g30RR7KorDkAlckABGdt+EpmeyWHho7H/KkLrVOPPKWX7YEpHGDj0Yd0GVNJ+GQ RT3QId40VAZLT2cc6LmXtocGBZcwzazVsSxYw= 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=c/8osQJ9GN2yR+PbuVImMpP7XWohXLAIGGruJ+6ETEy6DXGhrdcI1oYnjWYai5aTat GGWCVO1wDhEj3e+5DaRqQ8rQtfMQnepvQYgz5VZHZx/d06038uHT6r7EQYsLaqWHn51b oQfjPqPa73/E7cYWVAU15ESJKLB/zAOsvVd10= MIME-Version: 1.0 Received: by 10.100.58.14 with SMTP id g14mr57595ana.199.1298236515279; Sun, 20 Feb 2011 13:15:15 -0800 (PST) Received: by 10.101.68.7 with HTTP; Sun, 20 Feb 2011 13:15:15 -0800 (PST) In-Reply-To: <20110220210758.81B93A65431@drugs.dv.isc.org> References: <20110219210716.72943A5602B@drugs.dv.isc.org> <20110220203156.C1F83A6526F@drugs.dv.isc.org> <3764325DE7FA4B2F9B77387EBD15EAF8@local> <20110220210758.81B93A65431@drugs.dv.isc.org> Date: Sun, 20 Feb 2011 15:15:15 -0600 Message-ID: From: Brandon Black To: Mark Andrews Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: dnsext@ietf.org Subject: Re: [dnsext] Failure to add glue MUST cause TC to be set. X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 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, 20 Feb 2011 21:14:36 -0000 On Sun, Feb 20, 2011 at 3:07 PM, Mark Andrews wrote: > Zone A.net is served by servers in B.net. =C2=A0Zone B.net is served by > servers in A.net. That should never really work reliably though, right? A resolver would have to have security flaws to ever find answers in either zone, unless by chance A.net. and B.net. shared at least a single nameserver delegated from the net. servers, and that nameserver returned the applicable cross-zone glue, and the resolver was smart enough to realize its own caches entries for the A.net and B.net nameservers referred to the same single server to trust the suspicious cross-zone glue from. This seems like a special case that would hardly be worth optimizing a resolver to handle though, and authoritative servers certainly can't *expect* those kinds of smarts in order for their zones to function at all. From george.barwood@blueyonder.co.uk Sun Feb 20 13:29:04 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9BD593A6E08 for ; Sun, 20 Feb 2011 13:29:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.995 X-Spam-Level: X-Spam-Status: No, score=0.995 tagged_above=-999 required=5 tests=[AWL=-0.200, BAYES_00=-2.599, HELO_EQ_BLUEYON=1.4, J_CHICKENPOX_55=0.6, MIME_BASE64_BLANKS=0.041, MIME_BASE64_TEXT=1.753] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Yx7nUhK-MyiM for ; Sun, 20 Feb 2011 13:29:03 -0800 (PST) Received: from smtp-out4.blueyonder.co.uk (smtp-out4.blueyonder.co.uk [195.188.213.7]) by core3.amsl.com (Postfix) with ESMTP id CBE773A6C68 for ; Sun, 20 Feb 2011 13:29:02 -0800 (PST) Received: from [172.23.170.147] (helo=anti-virus03-10) by smtp-out4.blueyonder.co.uk with smtp (Exim 4.52) id 1PrGqb-00044e-IZ; Sun, 20 Feb 2011 21:29:41 +0000 Received: from [92.238.99.235] (helo=GeorgeLaptop) by asmtp-out2.blueyonder.co.uk with smtp (Exim 4.72) (envelope-from ) id 1PrGqH-0007rD-0n; Sun, 20 Feb 2011 21:29:21 +0000 Message-ID: <3D9B2A0D15F84DC6822FCF0FC6F8F214@local> From: "George Barwood" To: "Mark Andrews" References: <20110219210716.72943A5602B@drugs.dv.isc.org> <20110220203156.C1F83A6526F@drugs.dv.isc.org><3764325DE7FA4B2F9B77387EBD15EAF8@local> <20110220210758.81B93A65431@drugs.dv.isc.org> Date: Sun, 20 Feb 2011 21:30:15 -0000 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.5994 Cc: dnsext@ietf.org Subject: Re: [dnsext] Failure to add glue MUST cause TC to be set. X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 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, 20 Feb 2011 21:29:04 -0000 DQotLS0tLSBPcmlnaW5hbCBNZXNzYWdlIC0tLS0tIA0KRnJvbTogIk1hcmsgQW5kcmV3cyIgPG1h cmthQGlzYy5vcmc+DQpUbzogIkdlb3JnZSBCYXJ3b29kIiA8Z2VvcmdlLmJhcndvb2RAYmx1ZXlv bmRlci5jby51az4NCkNjOiA8ZG5zZXh0QGlldGYub3JnPg0KU2VudDogU3VuZGF5LCBGZWJydWFy eSAyMCwgMjAxMSA5OjA3IFBNDQpTdWJqZWN0OiBSZTogW2Ruc2V4dF0gRmFpbHVyZSB0byBhZGQg Z2x1ZSBNVVNUIGNhdXNlIFRDIHRvIGJlIHNldC4NCg0KDQo+IA0KPiBJbiBtZXNzYWdlIDwzNzY0 MzI1REU3RkE0QjJGOUI3NzM4N0VCRDE1RUFGOEBsb2NhbD4sICJHZW9yZ2UgQmFyd29vZCIgd3Jp dGVzOg0KPj4gPj4gLS0tLS0gT3JpZ2luYWwgTWVzc2FnZSAtLS0tLSANCj4+ID4+IEZyb206ICJN YXJrIEFuZHJld3MiIDxtYXJrYUBpc2Mub3JnPg0KPj4gPj4gVG86IDxkbnNleHRAaWV0Zi5vcmc+ DQo+PiA+PiBTZW50OiBTYXR1cmRheSwgRmVicnVhcnkgMTksIDIwMTEgOTowNyBQTQ0KPj4gPj4g U3ViamVjdDogW2Ruc2V4dF0gRmFpbHVyZSB0byBhZGQgZ2x1ZSBNVVNUIGNhdXNlIFRDIHRvIGJl IHNldC4NCj4+ID4+IA0KPj4gPj4gPiBCZWxvdyBpcyBhIGV4YW1wbGUgb2Ygd2h5IFRDIHNob3Vs ZCBiZSBzZXQgd2hlbiBnbHVlIGNhbm5vdCBiZSBhZGRlZA0KPj4gPj4gPiB0byB0aGUgYW5zd2Vy Lg0KPj4gPj4gPiANCj4+ID4+ID4gWy4uXQ0KPj4gPj4gDQo+PiA+PiBBZ3JlZWQsIGJ1dCB3aGVy ZSBleGFjdGx5IHNob3VsZCB0aGUgbGluZSBiZSBkcmF3bj8NCj4+ID4gDQo+PiA+IFdoYXQgbGlu ZT8gIElmIHRoZSBnbHVlIGRvZXNuJ3QgZml0IHRoZW4gdGhlIHJlZmVycmFsIGlzIG5vdCBjb21w bGV0ZS4NCj4+ID4gDQo+PiA+PiBJZiBvbWl0dGluZyBhbnkgZ2x1ZSBsZWFkcyB0byB0cnVuY2F0 aW9uLCB0aGVuIG1hbnkgKG5vbi1ETlNTRUMpIHJlZmVycmFscw0KPj4gPj4gb3ZlciBVRFAgd2ls bCBoYXZlIFRDIHNldC4gZS5nLiANCj4+ID4+IA0KPj4gPj4gZGlnIGZvby5jb20gQGEucm9vdC1z ZXJ2ZXJzLm5ldA0KPj4gPiANCj4+ID4gWWVzLg0KPj4gPiANCj4+ID4+IElzIHRoYXQgc2Vuc2li bGU/DQo+PiA+IA0KPj4gPiBZZXMuDQo+PiA+IA0KPj4gPj4gSG93IG11Y2ggZ2x1ZSBpcyBlbm91 Z2g/DQo+PiA+IA0KPj4gPiBEZXBlbmRzIG9uIHRoZSBkZWxlZ2F0aW9uLiAgVGhlIG9ubHkgc2Fm ZSBhbnN3ZXIgaXMgYWxsIHlvdSBoYXZlLg0KPj4gDQo+PiBPbmUgc3VnZ2VzdGlvbiB0aGF0IG1p Z2h0IHdvcmsgaXMgdGhhdCBnbHVlIHdoaWNoIG1hdGNocyBRTkFNRStRVFlQRSBNVVNUDQo+PiBi ZSBpbmNsdWRlZCwgYnV0IG90aGVyIGdsdWUgY2FuIGJlIG9taXR0ZWQuDQo+IA0KPiBUaGlzIGRv ZXMgbm90IHdvcmsgaW4gYWxsIGNhc2VzIHdoZXJlIGdsdWUgbmVlZHMgdG8gYmUgcmV0dXJuZWQu DQo+IA0KPiBab25lIEEubmV0IGlzIHNlcnZlZCBieSBzZXJ2ZXJzIGluIEIubmV0LiAgWm9uZSBC Lm5ldCBpcyBzZXJ2ZWQgYnkNCj4gc2VydmVycyBpbiBBLm5ldC4NCg0KU28gc29tZXRoaW5nIGxp a2UNCg0KDQpCdXQgbm90aGluZyB3aWxsIHdvcmsgaW4gdGhhdCBjYXNlIC0gaWYgeW91IG1ha2Ug YSByZWN1cnNpdmUgbG9vcCBsaWtlIHRoaXMsIHRoZW4gdGhlcmUgaXMgbm8gZ2x1ZQ0KKCB0aGUg bmFtZSBzZXJ2ZXIgbmFtZXMgYXJlIG5vdCAiYmVsb3ciIHRoZSBjdXQgKSBhbmQgeW91IGhhdmUg aGFkIGl0IHJlZ2FyZGxlc3MuIA0KDQpUaGF0J3MgYSBtaXMtY29uZmlndXJhdGlvbiwgbm90IGEg Y291bnRlci1leGFtcGxlLg0KDQpHZW9yZ2UNCg0KPiBNYXJrDQo+IC0tIA0KPiBNYXJrIEFuZHJl d3MsIElTQw0KPiAxIFNleW1vdXIgU3QuLCBEdW5kYXMgVmFsbGV5LCBOU1cgMjExNywgQXVzdHJh bGlhDQo+IFBIT05FOiArNjEgMiA5ODcxIDQ3NDIgICAgICAgICAgICAgICAgIElOVEVSTkVUOiBt YXJrYUBpc2Mub3Jn From marka@isc.org Sun Feb 20 14:47:49 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1032A3A6F30 for ; Sun, 20 Feb 2011 14:47:49 -0800 (PST) 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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B-SdssKXuZd3 for ; Sun, 20 Feb 2011 14:47:48 -0800 (PST) Received: from mx.ams1.isc.org (mx.ams1.isc.org [IPv6:2001:500:60::65]) by core3.amsl.com (Postfix) with ESMTP id 7B0473A6CD6 for ; Sun, 20 Feb 2011 14:47:22 -0800 (PST) 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 7F7AE5F985D; Sun, 20 Feb 2011 22:47:46 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (drugs.dv.isc.org [IPv6:2001:470:1f00:820:ea06:88ff:fef3:4f9c]) (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 55DDC216C1E; Sun, 20 Feb 2011 22:47:44 +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 2ED73A65B39; Mon, 21 Feb 2011 09:47:41 +1100 (EST) To: Brandon Black From: Mark Andrews References: <20110219210716.72943A5602B@drugs.dv.isc.org> <20110220203156.C1F83A6526F@drugs.dv.isc.org> <3764325DE7FA4B2F9B77387EBD15EAF8@local> <20110220210758.81B93A65431@drugs.dv.isc.org> In-reply-to: Your message of "Sun, 20 Feb 2011 15:15:15 MDT." Date: Mon, 21 Feb 2011 09:47:41 +1100 Message-Id: <20110220224741.2ED73A65B39@drugs.dv.isc.org> Cc: dnsext@ietf.org Subject: Re: [dnsext] Failure to add glue MUST cause TC to be set. X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 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, 20 Feb 2011 22:47:49 -0000 In message , Bran don Black writes: > On Sun, Feb 20, 2011 at 3:07 PM, Mark Andrews wrote: > > Zone A.net is served by servers in B.net. =C2=A0Zone B.net is served by > > servers in A.net. > > That should never really work reliably though, right? No. It works perfectly reliably provided you follow RFC 1034. > A resolver > would have to have security flaws to ever find answers in either zone, > unless by chance A.net. and B.net. shared at least a single nameserver > delegated from the net. servers, and that nameserver returned the > applicable cross-zone glue, and the resolver was smart enough to > realize its own caches entries for the A.net and B.net nameservers > referred to the same single server to trust the suspicious cross-zone > glue from. Your trusting the parent to supply glue for names beneath it. You *have* to trust the parent when it gives you this information. These names are all within the baliwick of the parent. > This seems like a special case that would hardly be worth optimizing a > resolver to handle though, and authoritative servers certainly can't > *expect* those kinds of smarts in order for their zones to function at > all. Firstly, such delegations exist today. Secondly you are not optimising for it. You are just returning glue that your child zone administrators have added. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From marka@isc.org Sun Feb 20 14:57:48 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 69DF13A6D21 for ; Sun, 20 Feb 2011 14:57:48 -0800 (PST) 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, J_CHICKENPOX_55=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V3GL9zKq0jOv for ; Sun, 20 Feb 2011 14:57:47 -0800 (PST) Received: from mx.pao1.isc.org (mx.pao1.isc.org [IPv6:2001:4f8:0:2::2b]) by core3.amsl.com (Postfix) with ESMTP id C9CFC3A6CD6 for ; Sun, 20 Feb 2011 14:57:46 -0800 (PST) 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 8B2DDC9421; Sun, 20 Feb 2011 22:58:13 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (drugs.dv.isc.org [IPv6:2001:470:1f00:820:ea06:88ff:fef3:4f9c]) (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 1FF97216C1E; Sun, 20 Feb 2011 22:58:13 +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 1F68CA65BFC; Mon, 21 Feb 2011 09:58:11 +1100 (EST) To: "George Barwood" From: Mark Andrews References: <20110219210716.72943A5602B@drugs.dv.isc.org> <20110220203156.C1F83A6526F@drugs.dv.isc.org><3764325DE7FA4B2F9B77387EBD15EAF8@local> <20110220210758.81B93A65431@drugs.dv.isc.org><3D9B2A0D15F84DC6822FCF0FC6F8F214@local> In-reply-to: Your message of "Sun, 20 Feb 2011 21:30:15 -0000." <3D9B2A0D15F84DC6822FCF0FC6F8F214@local> Date: Mon, 21 Feb 2011 09:58:11 +1100 Message-Id: <20110220225811.1F68CA65BFC@drugs.dv.isc.org> Cc: dnsext@ietf.org Subject: Re: [dnsext] Failure to add glue MUST cause TC to be set. X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 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, 20 Feb 2011 22:57:48 -0000 In message <3D9B2A0D15F84DC6822FCF0FC6F8F214@local>, "George Barwood" writes: > > ----- Original Message ----- > From: "Mark Andrews" > To: "George Barwood" > Cc: > Sent: Sunday, February 20, 2011 9:07 PM > Subject: Re: [dnsext] Failure to add glue MUST cause TC to be set. > > > > > > In message <3764325DE7FA4B2F9B77387EBD15EAF8@local>, "George Barwood" writes: > >> >> ----- Original Message ----- > >> >> From: "Mark Andrews" > >> >> To: > >> >> Sent: Saturday, February 19, 2011 9:07 PM > >> >> Subject: [dnsext] Failure to add glue MUST cause TC to be set. > >> >> > >> >> > Below is a example of why TC should be set when glue cannot be added > >> >> > to the answer. > >> >> > > >> >> > [..] > >> >> > >> >> Agreed, but where exactly should the line be drawn? > >> > > >> > What line? If the glue doesn't fit then the referral is not complete. > >> > > >> >> If omitting any glue leads to truncation, then many (non-DNSSEC) referrals > >> >> over UDP will have TC set. e.g. > >> >> > >> >> dig foo.com @a.root-servers.net > >> > > >> > Yes. > >> > > >> >> Is that sensible? > >> > > >> > Yes. > >> > > >> >> How much glue is enough? > >> > > >> > Depends on the delegation. The only safe answer is all you have. > >> > >> One suggestion that might work is that glue which matchs QNAME+QTYPE MUST > >> be included, but other glue can be omitted. > > > > This does not work in all cases where glue needs to be returned. > > > > Zone A.net is served by servers in B.net. Zone B.net is served by > > servers in A.net. > > So something like > > > But nothing will work in that case - if you make a recursive loop like this, > then there is no glue ( the name server names are not "below" the cut ) and > you have had it regardless. Glue records are records in the parent zone to enable you to reach the servers for the child zone. RFC 1034 gave a obvious example of such records. There are less obvious examples. > That's a mis-configuration, not a counter-example. No. It is not a mis-configuration. > George > > > Mark > > -- > > Mark Andrews, ISC > > 1 Seymour St., Dundas Valley, NSW 2117, Australia > > PHONE: +61 2 9871 4742 INTERNET: marka@isc.org -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From james.mitchell@ausregistry.com.au Sun Feb 20 15:07:43 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E4AB23A6CFB for ; Sun, 20 Feb 2011 15:07:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.295 X-Spam-Level: X-Spam-Status: No, score=-1.295 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, J_CHICKENPOX_55=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CLPFjNt6P-gy for ; Sun, 20 Feb 2011 15:07:42 -0800 (PST) Received: from mx10-1.ausregistry.net.au (mx10-1.ausregistry.net.au [202.65.12.90]) by core3.amsl.com (Postfix) with ESMTP id 699423A6CD6 for ; Sun, 20 Feb 2011 15:07:42 -0800 (PST) Received: from off-win2003-01.ausregistrygroup.local (off-win2003-01.stkildard.vic.ausregistry.com.au [10.30.1.3]) by mx10-1.ausregistry.net.au (8.13.8/8.13.8) with ESMTP id p1KN8B32009151; Mon, 21 Feb 2011 10:08:11 +1100 Received: from off-win2003-01.ausregistrygroup.local ([10.30.1.3]) by off-win2003-01.ausregistrygroup.local ([10.30.1.3]) with mapi; Mon, 21 Feb 2011 10:08:12 +1100 From: James Mitchell To: Mark Andrews , George Barwood Date: Mon, 21 Feb 2011 10:08:11 +1100 Thread-Topic: [dnsext] Failure to add glue MUST cause TC to be set. Thread-Index: AcvRUb4pIPch0b70R4y+A3WkDwNG9wAAGBcQ Message-ID: <8CEF048B9EC83748B1517DC64EA130FB4B348699D3@off-win2003-01.ausregistrygroup.local> References: <20110219210716.72943A5602B@drugs.dv.isc.org> <20110220203156.C1F83A6526F@drugs.dv.isc.org><3764325DE7FA4B2F9B77387EBD15EAF8@local> <20110220210758.81B93A65431@drugs.dv.isc.org><3D9B2A0D15F84DC6822FCF0FC6F8F214@local> <20110220225811.1F68CA65BFC@drugs.dv.isc.org> In-Reply-To: <20110220225811.1F68CA65BFC@drugs.dv.isc.org> Accept-Language: en-US, en-AU Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-AU Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "dnsext@ietf.org" Subject: Re: [dnsext] Failure to add glue MUST cause TC to be set. X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 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, 20 Feb 2011 23:07:44 -0000 Whether it is a mis-configuration depends on the glue policy of the parent = zone. There would be a mis-configuration under a "narrow" policy, where glue RRs = are registered if and only if the name server resides within or below the d= elegated (child) zone. On the other hand it would be fine under a "wide" po= licy, where glue RRs are registered if and only if the name server resides = below the delegating (parent) zone. Glue policy definitions came from http://tools.ietf.org/html/draft-koch-dns= -glue-clarifications-04. James > -----Original Message----- > From: dnsext-bounces@ietf.org [mailto:dnsext-bounces@ietf.org] On Behalf = Of > Mark Andrews > Sent: Monday, 21 February 2011 9:58 AM > To: George Barwood > Cc: dnsext@ietf.org > Subject: Re: [dnsext] Failure to add glue MUST cause TC to be set. >=20 >=20 > In message <3D9B2A0D15F84DC6822FCF0FC6F8F214@local>, "George Barwood" wri= tes: > > > > ----- Original Message ----- > > From: "Mark Andrews" > > To: "George Barwood" > > Cc: > > Sent: Sunday, February 20, 2011 9:07 PM > > Subject: Re: [dnsext] Failure to add glue MUST cause TC to be set. > > > > > > > > > > In message <3764325DE7FA4B2F9B77387EBD15EAF8@local>, "George Barwood" > writes: > > >> >> ----- Original Message ----- > > >> >> From: "Mark Andrews" > > >> >> To: > > >> >> Sent: Saturday, February 19, 2011 9:07 PM > > >> >> Subject: [dnsext] Failure to add glue MUST cause TC to be set. > > >> >> > > >> >> > Below is a example of why TC should be set when glue cannot be = added > > >> >> > to the answer. > > >> >> > > > >> >> > [..] > > >> >> > > >> >> Agreed, but where exactly should the line be drawn? > > >> > > > >> > What line? If the glue doesn't fit then the referral is not compl= ete. > > >> > > > >> >> If omitting any glue leads to truncation, then many (non-DNSSEC) > referrals > > >> >> over UDP will have TC set. e.g. > > >> >> > > >> >> dig foo.com @a.root-servers.net > > >> > > > >> > Yes. > > >> > > > >> >> Is that sensible? > > >> > > > >> > Yes. > > >> > > > >> >> How much glue is enough? > > >> > > > >> > Depends on the delegation. The only safe answer is all you have. > > >> > > >> One suggestion that might work is that glue which matchs QNAME+QTYPE= MUST > > >> be included, but other glue can be omitted. > > > > > > This does not work in all cases where glue needs to be returned. > > > > > > Zone A.net is served by servers in B.net. Zone B.net is served by > > > servers in A.net. > > > > So something like > > > > > > But nothing will work in that case - if you make a recursive loop like = this, > > then there is no glue ( the name server names are not "below" the cut )= and > > you have had it regardless. >=20 > Glue records are records in the parent zone to enable you to reach > the servers for the child zone. RFC 1034 gave a obvious example > of such records. There are less obvious examples. >=20 > > That's a mis-configuration, not a counter-example. >=20 > No. It is not a mis-configuration. >=20 > > George > > > > > Mark > > > -- > > > Mark Andrews, ISC > > > 1 Seymour St., Dundas Valley, NSW 2117, Australia > > > PHONE: +61 2 9871 4742 INTERNET: marka@isc.org >=20 >=20 > -- > Mark Andrews, ISC > 1 Seymour St., Dundas Valley, NSW 2117, Australia > PHONE: +61 2 9871 4742 INTERNET: marka@isc.org > _______________________________________________ > dnsext mailing list > dnsext@ietf.org > https://www.ietf.org/mailman/listinfo/dnsext From mohta@necom830.hpcl.titech.ac.jp Sun Feb 20 16:52:07 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4637E3A6D4D for ; Sun, 20 Feb 2011 16:52:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.101 X-Spam-Level: X-Spam-Status: No, score=-0.101 tagged_above=-999 required=5 tests=[AWL=-0.011, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KwpXxOVMCDkc for ; Sun, 20 Feb 2011 16:52:06 -0800 (PST) Received: from necom830.hpcl.titech.ac.jp (necom830.hpcl.titech.ac.jp [131.112.32.132]) by core3.amsl.com (Postfix) with SMTP id 2A1063A6CC3 for ; Sun, 20 Feb 2011 16:52:05 -0800 (PST) Received: (qmail 16595 invoked from network); 21 Feb 2011 01:04:03 -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 Feb 2011 01:04:03 -0000 Message-ID: <4D61B702.7060902@necom830.hpcl.titech.ac.jp> Date: Mon, 21 Feb 2011 09:51:14 +0900 From: Masataka Ohta User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; ja; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: Phillip Hallam-Baker References: <20110216032120.43474.qmail@joyce.lan> <20110216212930.57D64A3F344@drugs.dv.isc.org> <4D5D24F3.70206@gis.net> <20110217231720.1FCF3A49096@drugs.dv.isc.org> <4D5E08E4.8060106@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] SRV and wildcard CNAME X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 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, 21 Feb 2011 00:52:07 -0000 Phillip Hallam-Baker wrote: > It does indeed. And worse, it works for > > _null._random.example.com SRV... > > And other non existent protocols. Non existent protocols are not a problem, because they just do not work, which is fine. The problem is that protocols used share a port. However, as the only protocol which may be used by *LAZY* users, other than http, is https, it may share the same port as http, if servers are implemented to distinguish them by the first byte of the request. Maybe, some of you are thinking that SRV can't differentiate server names of name based virtual hosting. But, *.example.com CNAME com.example.net *.example.org CNAME org.example.net com.example.net SRV 0 1 P com.server.example.net org.example.net SRV 0 1 P org.server.example.net com.server.example.net CNAME shared.server.example.net org.server.example.net CNAME shared.server.example.net should work, even though it violates SRV specification requiring "name MUST NOT be an alias". > There is a way to fix the issue. Instead of resolving in a single step, a > two step resolution is performed. The first step being for an unprefixed > name. This will result in either 'not found' or a canonical name being > returned. The prefix is applied to the canonical name in the second phase. Why do we have to fix a non existent issue? Masataka Ohta From blblack@gmail.com Sun Feb 20 17:10:09 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2813E3A6CC3 for ; Sun, 20 Feb 2011 17:10:09 -0800 (PST) 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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WBa6qrKN7t-3 for ; Sun, 20 Feb 2011 17:10:08 -0800 (PST) Received: from mail-gw0-f42.google.com (mail-gw0-f42.google.com [74.125.83.42]) by core3.amsl.com (Postfix) with ESMTP id 34DA13A6EAC for ; Sun, 20 Feb 2011 17:10:08 -0800 (PST) Received: by gwj23 with SMTP id 23so1172642gwj.15 for ; Sun, 20 Feb 2011 17:10:48 -0800 (PST) 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=QnZ6hZKBne/On9F0M/oYqdrczb6z3r5gkxSu7TTiG9o=; b=phGkz+gZiM9b3GhZKmyN67GDSFzbt2DabIVfSNfCbERpWJEuxp+JXbtyi8VWg3NYIH LmBFFPESgiVbGQo1tJ3AS4zdHVjafkhyjrxgvaKxl+bYkedILRWvUY7UqGacbL+ApGdG eiJZL3ya9pKcRsnUFG0SwxlHfMu9W04sg19WM= 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=pGkZP3WBIZJl07Iu5zWuWTkipnTcBPZJhHYV/NbPpX/VdxfNtgj3E1+oh+N/YgcVt0 jrmG4v8W9pOWNbKNypgHKHkdNuqDF9GZn0bOBXjcdBP0/A+gcPlQr0sG/gCnjVAQe75K xkhGrePNsG7tlga7j9nzBsdHCLsLBjH0xfOC8= MIME-Version: 1.0 Received: by 10.100.123.1 with SMTP id v1mr364945anc.267.1298250648019; Sun, 20 Feb 2011 17:10:48 -0800 (PST) Received: by 10.101.68.7 with HTTP; Sun, 20 Feb 2011 17:10:47 -0800 (PST) In-Reply-To: <20110220224741.2ED73A65B39@drugs.dv.isc.org> References: <20110219210716.72943A5602B@drugs.dv.isc.org> <20110220203156.C1F83A6526F@drugs.dv.isc.org> <3764325DE7FA4B2F9B77387EBD15EAF8@local> <20110220210758.81B93A65431@drugs.dv.isc.org> <20110220224741.2ED73A65B39@drugs.dv.isc.org> Date: Sun, 20 Feb 2011 19:10:47 -0600 Message-ID: From: Brandon Black To: Mark Andrews Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: dnsext@ietf.org Subject: Re: [dnsext] Failure to add glue MUST cause TC to be set. X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 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, 21 Feb 2011 01:10:09 -0000 On Sun, Feb 20, 2011 at 4:47 PM, Mark Andrews wrote: >> the same single server to trust the suspicious cross-zone >> glue from. > > Your trusting the parent to supply glue for names beneath it. =C2=A0You > *have* to trust the parent when it gives you this information. > These names are all within the baliwick of the parent. Yes, I was thinking incorrectly when I wrote that, re: A.net. and B.net. In the terms of the glue clarification draft James linked, I guess narrow glue is pretty much required to function if it exists, and wide glue can work (and is often necessary in examples like your A.net. vs B.net. one), although it does require some security policy and management on the part of the parent registrar. For an easy general-case rule, you'd probably only want to allow those authorized to make updates related to B.net.'s NS records to register other glue address records underneath B.net. upstream, but still allow A.net. admins to reference existing B.net. glue in their NS records. The case I was confusing this with (re: optimization, etc) was the case where there was no immediate common parent domain to host the cross-zone glue (e.g. A.net. NS ns1.B.org. + B.org. NS ns1.A.net.). In the special case that the org. and net. nameservers shared IP addresses (and were in fact the same namservers) and handed out cross-zone glue addresses for those cases, a smart enough resolver might figure it out and believe them based on the shared nameserver IPs ("I already know 192.0.2.3 is authoritative for org. from earlier, and now during a query for A.net to the same IP address, I'm seeing B.org. glue records and it's ok to believe them"), but a dumber resolver would be unable to see records in either domain if it implemented a sane basic security model (bailiwick of QNAME). I think we have to assume the simpler resolver behavior rather than try to construct schemes that rely on the "smarter" behavior, right? The optimization part is on the authoritative servers' part. Should an authoritative server ever serve glue that's outside the bailiwick of the delegation's parent zone, just because it knows those glue addresses are part of other "unrelated" zones it serves, and a resolver might be smart enough to figure out the relationship? I think the answer is no, it's not worth serving that glue. Most resolvers are going to send you a second query for it anyway based on the simple bailwick of QNAME security model. In general I think the smartest policy in light of all of this is to always put the NS names for a zone beneath that zone itself, even if the IPs refer to 3rd-party nameservers, but it certainly doesn't have to be a requirement to function. From mohta@necom830.hpcl.titech.ac.jp Sun Feb 20 17:16:22 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C281C3A6D6F for ; Sun, 20 Feb 2011 17:16:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.1 X-Spam-Level: X-Spam-Status: No, score=-0.1 tagged_above=-999 required=5 tests=[AWL=-0.010, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VOUsN-UwuASV for ; Sun, 20 Feb 2011 17:16:22 -0800 (PST) Received: from necom830.hpcl.titech.ac.jp (necom830.hpcl.titech.ac.jp [131.112.32.132]) by core3.amsl.com (Postfix) with SMTP id CBC323A6D4D for ; Sun, 20 Feb 2011 17:16:21 -0800 (PST) Received: (qmail 16813 invoked from network); 21 Feb 2011 01:28:32 -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 Feb 2011 01:28:32 -0000 Message-ID: <4D61BCBE.7020102@necom830.hpcl.titech.ac.jp> Date: Mon, 21 Feb 2011 10:15:42 +0900 From: Masataka Ohta User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; ja; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: dnsext@ietf.org References: <20110219210716.72943A5602B@drugs.dv.isc.org> <20110220203156.C1F83A6526F@drugs.dv.isc.org><3764325DE7FA4B2F9B77387EBD15EAF8@local> <20110220210758.81B93A65431@drugs.dv.isc.org><3D9B2A0D15F84DC6822FCF0FC6F8F214@local> <20110220225811.1F68CA65BFC@drugs.dv.isc.org> In-Reply-To: <20110220225811.1F68CA65BFC@drugs.dv.isc.org> Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit Subject: Re: [dnsext] Failure to add glue MUST cause TC to be set. X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 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, 21 Feb 2011 01:16:22 -0000 Mark Andrews wrote: >> That's a mis-configuration, not a counter-example. > > No. It is not a mis-configuration. For example, "org." and "info." are configured so. Masataka Ohta From marka@isc.org Sun Feb 20 17:17:06 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 70C5F3A6F76 for ; Sun, 20 Feb 2011 17:17:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.499 X-Spam-Level: X-Spam-Status: No, score=-2.499 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nxpthuAO1HO9 for ; Sun, 20 Feb 2011 17:17:05 -0800 (PST) Received: from mx.pao1.isc.org (mx.pao1.isc.org [IPv6:2001:4f8:0:2::2b]) by core3.amsl.com (Postfix) with ESMTP id 6AE223A6CC3 for ; Sun, 20 Feb 2011 17:17:05 -0800 (PST) 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 8C08DC9434; Mon, 21 Feb 2011 01:17:35 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (drugs.dv.isc.org [IPv6:2001:470:1f00:820:ea06:88ff:fef3:4f9c]) (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 23EA0216C1E; Mon, 21 Feb 2011 01:17:35 +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 F0FE0A6B00F; Mon, 21 Feb 2011 12:17:31 +1100 (EST) To: Masataka Ohta From: Mark Andrews References: <20110216032120.43474.qmail@joyce.lan> <20110216212930.57D64A3F344@drugs.dv.isc.org> <4D5D24F3.70206@gis.net> <20110217231720.1FCF3A49096@drugs.dv.isc.org> <4D5E08E4.8060106@necom830.hpcl.titech.ac.jp> <4D61B702.7060902@necom830.hpcl.titech.ac.jp> In-reply-to: Your message of "Mon, 21 Feb 2011 09:51:14 +0900." <4D61B702.7060902@necom830.hpcl.titech.ac.jp> Date: Mon, 21 Feb 2011 12:17:31 +1100 Message-Id: <20110221011731.F0FE0A6B00F@drugs.dv.isc.org> Cc: dnsext@ietf.org Subject: Re: [dnsext] SRV and wildcard CNAME X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 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, 21 Feb 2011 01:17:06 -0000 In message <4D61B702.7060902@necom830.hpcl.titech.ac.jp>, Masataka Ohta writes: > Phillip Hallam-Baker wrote: > > > It does indeed. And worse, it works for > > > > _null._random.example.com SRV... > > > > And other non existent protocols. > > Non existent protocols are not a problem, because they just do > not work, which is fine. > > The problem is that protocols used share a port. > > However, as the only protocol which may be used by *LAZY* users, > other than http, is https, it may share the same port as http, > if servers are implemented to distinguish them by the first > byte of the request. It breaks *all* protocols that use SRV. Wildcarding a SRV record is a bad idea. > Maybe, some of you are thinking that SRV can't differentiate > server names of name based virtual hosting. > > But, > > *.example.com CNAME com.example.net > > *.example.org CNAME org.example.net > > com.example.net SRV 0 1 P com.server.example.net > org.example.net SRV 0 1 P org.server.example.net > com.server.example.net CNAME shared.server.example.net > org.server.example.net CNAME shared.server.example.net > > should work, even though it violates SRV specification requiring > "name MUST NOT be an alias". The you have a client that tries to use the "foo" protocol which is SRV aware. The client asks for _foo._tcp.bar.example.com SRV and sends up being sent to the http server. Wildcards match multiple labels. > > There is a way to fix the issue. Instead of resolving in a single step, a > > two step resolution is performed. The first step being for an unprefixed > > name. This will result in either 'not found' or a canonical name being > > returned. The prefix is applied to the canonical name in the second phase. > > Why do we have to fix a non existent issue? > > Masataka Ohta > _______________________________________________ > 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 blblack@gmail.com Sun Feb 20 17:21:32 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7030E3A6D4D for ; Sun, 20 Feb 2011 17:21:32 -0800 (PST) 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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0gR-5kWiujCU for ; Sun, 20 Feb 2011 17:21:31 -0800 (PST) Received: from mail-gw0-f42.google.com (mail-gw0-f42.google.com [74.125.83.42]) by core3.amsl.com (Postfix) with ESMTP id D82843A6CC3 for ; Sun, 20 Feb 2011 17:21:30 -0800 (PST) Received: by gwj23 with SMTP id 23so1178264gwj.15 for ; Sun, 20 Feb 2011 17:22:10 -0800 (PST) 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=Q3GeOVm0Hbz1RieHYZ7zanmdGFHiOGUpbH7bNO6cgKE=; b=HshDj42R64aXSdT2/1fNJx2DZoxjs6EKq3NC03a4g2CbKZigK9jXFSKCLb/CAArRq/ b+ccLXy4qX4vl61nM0OcGCgiU9N9+roHVQGKth1IkZaEd9T2UGhV3rKVTO4wYxcXKeyw Yd/idTx1DjbpcfbCAH5Gk2UPQlYoShOjjVz3I= 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=KvV5bcs+rbytu8YT8he0lbHvLXb87rRs7CJ1tlaQXzI0+lf1oaYy3MXXewXPZWTBpm qUFN08dQ4psZV9j8ddKaYF19S/xBY5HZk02dzGGxmgvBBm2G1w0uAMaKJVkl0ZzAvZGw crdzGf59W1Ul3B31l/nyl+RB5dg5Kc+6oubwc= MIME-Version: 1.0 Received: by 10.100.95.14 with SMTP id s14mr376608anb.29.1298251329555; Sun, 20 Feb 2011 17:22:09 -0800 (PST) Received: by 10.101.68.7 with HTTP; Sun, 20 Feb 2011 17:22:09 -0800 (PST) In-Reply-To: References: <20110219210716.72943A5602B@drugs.dv.isc.org> <11263.1298150425@nsa.vix.com> <20110220072916.GA3505@vacation.karoshi.com.> <30899A4A-833B-42EF-9850-AFEE8B8DBE02@dotat.at> Date: Sun, 20 Feb 2011 19:22:09 -0600 Message-ID: From: Brandon Black To: Jim Reid Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: "bmanning@vacation.karoshi.com" , "dnsext@ietf.org" Subject: Re: [dnsext] zone cut semantics X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 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, 21 Feb 2011 01:21:32 -0000 On Sun, Feb 20, 2011 at 2:44 PM, Jim Reid wrote: > On 20 Feb 2011, at 20:14, Brandon Black wrote: > >> Isn't this really a matter of semantics? > > Yes: zone cut semantics, not language semantics. > >> The parent zone is >> authoritative for everything beneath itself, even if it choses to use >> that power of authority to give a delegation response. =C2=A0e.g. the .c= om >> servers are authoritative for www.example.com, but they choose to >> delegate that answer to the NS for example.com. > > Nope. Query the .com name servers for the NS records for example.com. The= y > correctly return a non-authoritative answer. It's only the name servers f= or > example.com that are authoritative for example.com and will authoritative= ly > answer that query. In other words, it's the child that's responsible for = the > zone's authoritative NS RRset, not the parent. Which is how things should= be > when you consider what delegation actually means: crossing an administrat= ive > boundary from one authority to another. > > Please think again about what you posted. The inference of what you say i= s > that the root servers are authoritative for everything. That's clearly no= t > true. IMHO, this is where it's semantics. The root servers are authoritative for everything, that's why we believe their delegation answers. The AA-bit is just part of how the protocol signals delegation of authority. Yes, the child is responsible for its own NS records while the parent delegates, but the parent can take away the delegation at any time and serve the child's zone data directly. This does come into play in the glue issues. You can trust glue data which falls within the delegating (parent) zone , but you can't necessarily trust other glue records that might come in a response. This is much like a corporate hierarchy model: the CEO is authoritative for everything, but delegates decisions throughout a hierarchy of lower level managers. The fact that Joe the VP of Sales is responsible for all Sales decisions doesn't take away the CEO's authority over everything the company does. From marka@isc.org Sun Feb 20 17:41:38 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1DFAD3A6EAC for ; Sun, 20 Feb 2011 17:41:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.476 X-Spam-Level: ** X-Spam-Status: No, score=2.476 tagged_above=-999 required=5 tests=[AWL=-4.925, BAYES_00=-2.599, URIBL_JP_SURBL=10] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qN9Acrfq3pDG for ; Sun, 20 Feb 2011 17:41:37 -0800 (PST) Received: from mx.pao1.isc.org (mx.pao1.isc.org [IPv6:2001:4f8:0:2::2b]) by core3.amsl.com (Postfix) with ESMTP id B6F5E3A6D6F for ; Sun, 20 Feb 2011 17:41:36 -0800 (PST) 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 374EBC9421; Mon, 21 Feb 2011 01:42:04 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (drugs.dv.isc.org [IPv6:2001:470:1f00:820:ea06:88ff:fef3:4f9c]) (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 B9BAE216C1E; Mon, 21 Feb 2011 01:42:03 +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 9964BA6B0BA; Mon, 21 Feb 2011 12:42:01 +1100 (EST) To: Brandon Black From: Mark Andrews References: <20110219210716.72943A5602B@drugs.dv.isc.org> <20110220203156.C1F83A6526F@drugs.dv.isc.org> <3764325DE7FA4B2F9B77387EBD15EAF8@local> <20110220210758.81B93A65431@drugs.dv.isc.org> <20110220224741.2ED73A65B39@drugs.dv.isc.org> In-reply-to: Your message of "Sun, 20 Feb 2011 19:10:47 MDT." Date: Mon, 21 Feb 2011 12:42:01 +1100 Message-Id: <20110221014201.9964BA6B0BA@drugs.dv.isc.org> Cc: dnsext@ietf.org Subject: Re: [dnsext] Failure to add glue MUST cause TC to be set. X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 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, 21 Feb 2011 01:41:38 -0000 In message , Bran don Black writes: > On Sun, Feb 20, 2011 at 4:47 PM, Mark Andrews wrote: > >> the same single server to trust the suspicious cross-zone > >> glue from. > > > > Your trusting the parent to supply glue for names beneath it. =C2=A0You > > *have* to trust the parent when it gives you this information. > > These names are all within the baliwick of the parent. > > Yes, I was thinking incorrectly when I wrote that, re: A.net. and > B.net. In the terms of the glue clarification draft James linked, I > guess narrow glue is pretty much required to function if it exists, > and wide glue can work (and is often necessary in examples like your > A.net. vs B.net. one), although it does require some security policy > and management on the part of the parent registrar. For an easy > general-case rule, you'd probably only want to allow those authorized > to make updates related to B.net.'s NS records to register other glue > address records underneath B.net. upstream, but still allow A.net. > admins to reference existing B.net. glue in their NS records. > > The case I was confusing this with (re: optimization, etc) was the > case where there was no immediate common parent domain to host the > cross-zone glue (e.g. A.net. NS ns1.B.org. + B.org. NS ns1.A.net.). > In the special case that the org. and net. nameservers shared IP > addresses (and were in fact the same namservers) and handed out > cross-zone glue addresses for those cases, a smart enough resolver > might figure it out and believe them based on the shared nameserver > IPs ("I already know 192.0.2.3 is authoritative for org. from earlier, > and now during a query for A.net to the same IP address, I'm seeing > B.org. glue records and it's ok to believe them"), but a dumber > resolver would be unable to see records in either domain if it > implemented a sane basic security model (bailiwick of QNAME). I think > we have to assume the simpler resolver behavior rather than try to > construct schemes that rely on the "smarter" behavior, right? > > The optimization part is on the authoritative servers' part. Should > an authoritative server ever serve glue that's outside the bailiwick > of the delegation's parent zone, just because it knows those glue > addresses are part of other "unrelated" zones it serves, and a > resolver might be smart enough to figure out the relationship? I > think the answer is no, it's not worth serving that glue. Most > resolvers are going to send you a second query for it anyway based on > the simple bailwick of QNAME security model. There is something to be said for the argument up to here ... > In general I think the smartest policy in light of all of this is to > always put the NS names for a zone beneath that zone itself, even if > the IPs refer to 3rd-party nameservers, but it certainly doesn't have > to be a requirement to function. but this section is a really, really bad idea and defeats the whole purpose of having NS records be names not addresses. If you don't want to handle loops then the rule is that "nameservers MUST be listed as nameservers for the zone they live in" not "nameservers MUST live in the zones they serve". People always seem to want to go one step too far. foo.net NS ns1.foo.net foo.net NS ns2.foo.net ns1.foo.net A 1.2.3.4 ns2.foo.net A 1.2.3.5 bar.net NS ns1.foo.net bar.net NS ns2.foo.net xxx.net NS ns1.foo.net xxx.net NS ns2.foo.net yyy.net NS ns1.foo.net yyy.net NS ns2.foo.net zzz.net NS ns1.foo.net zzz.net NS ns2.foo.net Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From jra@baylink.com Sun Feb 20 17:43:28 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C8DCE3A6F7A for ; Sun, 20 Feb 2011 17:43:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.842 X-Spam-Level: X-Spam-Status: No, score=-1.842 tagged_above=-999 required=5 tests=[AWL=-0.108, BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, RDNS_DYNAMIC=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0GIm4fUOM-51 for ; Sun, 20 Feb 2011 17:43:28 -0800 (PST) Received: from benjamin.baylink.com (rrcs-24-129-180-187.se.biz.rr.com [24.129.180.187]) by core3.amsl.com (Postfix) with ESMTP id 9AF833A6EAC for ; Sun, 20 Feb 2011 17:43:27 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by benjamin.baylink.com (Postfix) with ESMTP id DD7091F0012D for ; Sun, 20 Feb 2011 20:44:18 -0500 (EST) X-Virus-Scanned: amavisd-new at benjamin.baylink.com Received: from benjamin.baylink.com ([127.0.0.1]) by localhost (benjamin.baylink.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ylVgjGjM3YLz for ; Sun, 20 Feb 2011 20:44:15 -0500 (EST) Received: from benjamin.baylink.com (benjamin.baylink.com [192.168.253.10]) by benjamin.baylink.com (Postfix) with ESMTP id A40881F00121 for ; Sun, 20 Feb 2011 20:44:15 -0500 (EST) Date: Sun, 20 Feb 2011 20:44:15 -0500 (EST) From: Jay Ashworth To: dnsext@ietf.org Message-ID: <32361744.800.1298252655591.JavaMail.root@benjamin.baylink.com> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [65.34.93.30] X-Mailer: Zimbra 6.0.9_GA_2686 (ZimbraWebClient - FF3.0 (Linux)/6.0.9_GA_2686) Subject: Re: [dnsext] zone cut semantics X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 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, 21 Feb 2011 01:43:28 -0000 ----- Original Message ----- > From: "Brandon Black" > On Sun, Feb 20, 2011 at 2:44 PM, Jim Reid wrote: > > Nope. Query the .com name servers for the NS records for > > example.com. They > > correctly return a non-authoritative answer. It's only the name > > servers for > > example.com that are authoritative for example.com and will > > authoritatively > > answer that query. In other words, it's the child that's responsible > > for the > > zone's authoritative NS RRset, not the parent. Which is how things > > should be > > when you consider what delegation actually means: crossing an > > administrative > > boundary from one authority to another. > > > > Please think again about what you posted. The inference of what you > > say is > > that the root servers are authoritative for everything. That's > > clearly not > > true. > > IMHO, this is where it's semantics. The root servers are > authoritative for everything, that's why we believe their delegation > answers. The AA-bit is just part of how the protocol signals > delegation of authority. Yes, the child is responsible for its own NS > records while the parent delegates, but the parent can take away the > delegation at any time and serve the child's zone data directly. You appear to be suggesting that the AA bit on the glue records in a parent zone *can be set*, merely by changing something in the parent zone file. I don't believe that to be true; TTBOMK, *the name server* makes that choice (to not set AA), *precisely because the parent server is not considered to be authoritative for objects within its children's zones*. I don't think that it's physically possible to make a parent server set the AA bit on that glue, though I'd be happy to be proven wrong. I don't operate many parent zones. :-) So: people-who-do: is my supposition/assertion above correct? If it is, is it reasonable to draw from it the inference that I do (IE, that Jim is correct and Brandon's not)? I'm sure Albitz & Liu would tell me, but I do fancy stuff with DNS insufficiently frequently for me to know where it is... Cheers,. -- jra From mohta@necom830.hpcl.titech.ac.jp Sun Feb 20 17:49:13 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C542D3A6F79 for ; Sun, 20 Feb 2011 17:49:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.1 X-Spam-Level: X-Spam-Status: No, score=-0.1 tagged_above=-999 required=5 tests=[AWL=-0.010, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Vx4VRwbfQyeU for ; Sun, 20 Feb 2011 17:49:13 -0800 (PST) Received: from necom830.hpcl.titech.ac.jp (necom830.hpcl.titech.ac.jp [131.112.32.132]) by core3.amsl.com (Postfix) with SMTP id 943D03A6F93 for ; Sun, 20 Feb 2011 17:49:12 -0800 (PST) Received: (qmail 17194 invoked from network); 21 Feb 2011 02:01:07 -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 Feb 2011 02:01:07 -0000 Message-ID: <4D61C45E.7000506@necom830.hpcl.titech.ac.jp> Date: Mon, 21 Feb 2011 10:48:14 +0900 From: Masataka Ohta User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; ja; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: Mark Andrews References: <20110216032120.43474.qmail@joyce.lan> <20110216212930.57D64A3F344@drugs.dv.isc.org> <4D5D24F3.70206@gis.net> <20110217231720.1FCF3A49096@drugs.dv.isc.org> <4D5E08E4.8060106@necom830.hpcl.titech.ac.jp> <4D61B702.7060902@necom830.hpcl.titech.ac.jp> <20110221011731.F0FE0A6B00F@drugs.dv.isc.org> In-Reply-To: <20110221011731.F0FE0A6B00F@drugs.dv.isc.org> Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit Cc: dnsext@ietf.org Subject: Re: [dnsext] SRV and wildcard CNAME X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 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, 21 Feb 2011 01:49:13 -0000 Mark Andrews wrote: >> However, as the only protocol which may be used by *LAZY* users, >> other than http, is https, it may share the same port as http, >> if servers are implemented to distinguish them by the first >> byte of the request. > > It breaks *all* protocols that use SRV. When the protocols used at the domain are http and https only, nothing break. Otherwise, users can not be very lazy. > Wildcarding a SRV record is a bad idea. If you say so, you should also say: Wildcarding a CNAME record is a bad idea to deny *YOUR* example. >> *.example.com CNAME com.example.net >> >> *.example.org CNAME org.example.net >> >> com.example.net SRV 0 1 P com.server.example.net >> org.example.net SRV 0 1 P org.server.example.net >> >> should work, even though it violates SRV specification requiring >> "name MUST NOT be an alias". > > The you have a client that tries to use the "foo" protocol which is > SRV aware. The client asks for _foo._tcp.bar.example.com SRV and > sends up being sent to the http server. If users are less lazy, they can set up: _http._tcp.www.example.com SRV 0 1 P com.server.example.net _http._tcp.www.example.org SRV 0 1 P org.server.example.net and a server operator set up: com.server.example.net CNAME shared.server.example.net org.server.example.net CNAME shared.server.example.net for name based virtual hosting, which is not more difficult for users than users set up: www.example.com CNAME shared.server.example.net www.example.org CNAME shared.server.example.net Masataka Ohta From marka@isc.org Sun Feb 20 18:29:31 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ED24F3A6D52 for ; Sun, 20 Feb 2011 18:29:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.539 X-Spam-Level: X-Spam-Status: No, score=-1.539 tagged_above=-999 required=5 tests=[AWL=1.060, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7flErDeVuOba for ; Sun, 20 Feb 2011 18:29:30 -0800 (PST) Received: from mx.ams1.isc.org (mx.ams1.isc.org [IPv6:2001:500:60::65]) by core3.amsl.com (Postfix) with ESMTP id C2A273A6D07 for ; Sun, 20 Feb 2011 18:29:29 -0800 (PST) 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 A7E3D5F985D; Mon, 21 Feb 2011 02:29:54 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (drugs.dv.isc.org [IPv6:2001:470:1f00:820:ea06:88ff:fef3:4f9c]) (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 D5383216C1E; Mon, 21 Feb 2011 02:29:52 +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 BE88CA6B2DD; Mon, 21 Feb 2011 13:29:50 +1100 (EST) To: Masataka Ohta From: Mark Andrews References: <20110216032120.43474.qmail@joyce.lan> <20110216212930.57D64A3F344@drugs.dv.isc.org> <4D5D24F3.70206@gis.net> <20110217231720.1FCF3A49096@drugs.dv.isc.org> <4D5E08E4.8060106@necom830.hpcl.titech.ac.jp> <4D61B702.7060902@necom830.hpcl.titech.ac.jp> <20110221011731.F0FE0A6B00F@drugs.dv.isc.org> <4D61C45E.7000506@necom830.hpcl.titech.ac.jp> In-reply-to: Your message of "Mon, 21 Feb 2011 10:48:14 +0900." <4D61C45E.7000506@necom830.hpcl.titech.ac.jp> Date: Mon, 21 Feb 2011 13:29:50 +1100 Message-Id: <20110221022950.BE88CA6B2DD@drugs.dv.isc.org> Cc: dnsext@ietf.org Subject: Re: [dnsext] SRV and wildcard CNAME X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 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, 21 Feb 2011 02:29:31 -0000 In message <4D61C45E.7000506@necom830.hpcl.titech.ac.jp>, Masataka Ohta writes: > Mark Andrews wrote: > > >> However, as the only protocol which may be used by *LAZY* users, > >> other than http, is https, it may share the same port as http, > >> if servers are implemented to distinguish them by the first > >> byte of the request. > > > > It breaks *all* protocols that use SRV. > > When the protocols used at the domain are http and https only, > nothing break. It breaks all protocols and I'm sorry that you can't see how but it does. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From jim@rfc1035.com Sun Feb 20 18:42:45 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EA1C53A6F7F for ; Sun, 20 Feb 2011 18:42:45 -0800 (PST) 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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mzpi0ghD6mBl for ; Sun, 20 Feb 2011 18:42:45 -0800 (PST) Received: from hutch.rfc1035.com (hutch.rfc1035.com [195.54.233.70]) by core3.amsl.com (Postfix) with ESMTP id 083543A6F7D for ; Sun, 20 Feb 2011 18:42:45 -0800 (PST) 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 9467B15420A1; Mon, 21 Feb 2011 02:43:23 +0000 (GMT) Message-Id: <4AAEDEAF-AE3B-48D0-92AC-7C86538BF54E@rfc1035.com> From: Jim Reid To: Brandon Black In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Mon, 21 Feb 2011 02:43:22 +0000 References: <20110219210716.72943A5602B@drugs.dv.isc.org> <11263.1298150425@nsa.vix.com> <20110220072916.GA3505@vacation.karoshi.com.> <30899A4A-833B-42EF-9850-AFEE8B8DBE02@dotat.at> X-Mailer: Apple Mail (2.936) Cc: "bmanning@vacation.karoshi.com" , "dnsext@ietf.org" Subject: Re: [dnsext] zone cut semantics X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 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, 21 Feb 2011 02:42:46 -0000 On 21 Feb 2011, at 01:22, Brandon Black wrote: > IMHO, this is where it's semantics. The protocol specs say otherwise. Please read Section 6 of RFC2181. If you wish to continue an angels on pinhead debate about linguistic semantics of "authoritative" or what you mean by that, let's stop wasting each other's time and stop now. > The root servers are authoritative for everything, that's why we > believe their delegation answers. No they are not. The root servers are authoritative for the root zone*. Which largely holds pointers to where we can find authoritative data about other names in the DNS. The root zone cannot be authoritative for those pointers (delegations) because they live beneath the zone cuts for the TLDs. I'm not sure what you mean by "believe delegation answers". No, please don't try to explain... But you seem to be wrong about that too. The root servers may well tell us there's a delegation for .brandon. But a resolving name server won't "believe" that until it gets an authoritative answer from one of the .brandon name servers, confirming the TLD's existence. And hopefully validates all of that with DNSSEC. The word "authoritative" has a well defined meaning in the DNS protocol. You seem to want to use it in a different context. Which is fine: words can mean whatever you want them to mean. However please don't do that in this forum with technical terms which have carefully defined meanings when used for the DNS protocol. This list is for DNS protocol geeks after all. *Well, OK, they also authoritatively serve root-servers.net. From mohta@necom830.hpcl.titech.ac.jp Sun Feb 20 18:45:35 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6F6253A6F7D for ; Sun, 20 Feb 2011 18:45:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.099 X-Spam-Level: X-Spam-Status: No, score=-0.099 tagged_above=-999 required=5 tests=[AWL=-0.009, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Tup2RwPqjpfr for ; Sun, 20 Feb 2011 18:45:34 -0800 (PST) Received: from necom830.hpcl.titech.ac.jp (necom830.hpcl.titech.ac.jp [131.112.32.132]) by core3.amsl.com (Postfix) with SMTP id 6DE5C3A6F7A for ; Sun, 20 Feb 2011 18:45:34 -0800 (PST) Received: (qmail 18365 invoked from network); 21 Feb 2011 02:57:32 -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 Feb 2011 02:57:32 -0000 Message-ID: <4D61D194.9040804@necom830.hpcl.titech.ac.jp> Date: Mon, 21 Feb 2011 11:44:36 +0900 From: Masataka Ohta User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; ja; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: Mark Andrews References: <20110216032120.43474.qmail@joyce.lan> <20110216212930.57D64A3F344@drugs.dv.isc.org> <4D5D24F3.70206@gis.net> <20110217231720.1FCF3A49096@drugs.dv.isc.org> <4D5E08E4.8060106@necom830.hpcl.titech.ac.jp> <4D61B702.7060902@necom830.hpcl.titech.ac.jp> <20110221011731.F0FE0A6B00F@drugs.dv.isc.org> <4D61C45E.7000506@necom830.hpcl.titech.ac.jp> <20110221022950.BE88CA6B2DD@drugs.dv.isc.org> In-Reply-To: <20110221022950.BE88CA6B2DD@drugs.dv.isc.org> Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit Cc: dnsext@ietf.org Subject: Re: [dnsext] SRV and wildcard CNAME X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 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, 21 Feb 2011 02:45:35 -0000 Mark Andrews wrote: >> When the protocols used at the domain are http and https only, >> nothing break. > > It breaks all protocols and I'm sorry that you can't see how but > it does. I'm afraid you are wasting bandwidth of the mailing list. Masataka Ohta From larry-lists@maxqe.com Sun Feb 20 18:51:24 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F2A7F3A6F2C for ; Sun, 20 Feb 2011 18:51:23 -0800 (PST) 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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dwuI+aWxlpop for ; Sun, 20 Feb 2011 18:51:22 -0800 (PST) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by core3.amsl.com (Postfix) with ESMTP id B91173A6D52 for ; Sun, 20 Feb 2011 18:51:22 -0800 (PST) Received: by vxi40 with SMTP id 40so3500614vxi.31 for ; Sun, 20 Feb 2011 18:52:03 -0800 (PST) Received: by 10.52.156.233 with SMTP id wh9mr1146143vdb.26.1298256722787; Sun, 20 Feb 2011 18:52:02 -0800 (PST) Received: from workstation.houston.hostgator.com (216-110-94-228.static.twtelecom.net [216.110.94.228]) by mx.google.com with ESMTPS id h18sm3408099vbr.4.2011.02.20.18.52.01 (version=SSLv3 cipher=OTHER); Sun, 20 Feb 2011 18:52:02 -0800 (PST) Message-ID: <4D61D350.9040401@maxqe.com> Date: Sun, 20 Feb 2011 20:52:00 -0600 From: Larry Brower User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.13) Gecko/20101208 Thunderbird/3.1.7 MIME-Version: 1.0 To: dnsext@ietf.org References: <20110216032120.43474.qmail@joyce.lan> <20110216212930.57D64A3F344@drugs.dv.isc.org> <4D5D24F3.70206@gis.net> <20110217231720.1FCF3A49096@drugs.dv.isc.org> <4D5E08E4.8060106@necom830.hpcl.titech.ac.jp> <4D61B702.7060902@necom830.hpcl.titech.ac.jp> <20110221011731.F0FE0A6B00F@drugs.dv.isc.org> <4D61C45E.7000506@necom830.hpcl.titech.ac.jp> <20110221022950.BE88CA6B2DD@drugs.dv.isc.org> <4D61D194.9040804@necom830.hpcl.titech.ac.jp> In-Reply-To: <4D61D194.9040804@necom830.hpcl.titech.ac.jp> X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [dnsext] SRV and wildcard CNAME X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 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, 21 Feb 2011 02:51:24 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 On 02/20/2011 08:44 PM, Masataka Ohta wrote: > > I'm afraid you are wasting bandwidth of the mailing list. > > Masataka Ohta I disagree, I say you are wasting it. Mark told you why it was a bad idea and you just want to argue the point. Sending a message saying "I'm afraid you are wasting bandwidth of the mailing list" is what is wasting bandwidth. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBCgAGBQJNYdNQAAoJEPXCUD/44PWq+LUP/215jqxL0DH+ke0LnCQ5u8MQ ykR0Cac45hCHD1D+E9So/EQLVrH6Q+CNwoZCDTD1wtuPErUJiCuIBwXwRmU2xz1B 0zj74HuO7lTQ7HAe0PBdbtejXqvJNeZn8QlsFLYEZAaoFTwY2uKy4pJryBgl+eZd t4BkaAz5ovWobpQyzlfylT8j31xqxWjDLMObXF3CyEoU4wcpdhdc2SHUKnbdgxXX Gg8mvVbNM0OCYa/EZJxBIyZ0RNhbHnaYAOEqLr/GoBw2ffE8e1TI74dh0IpvTFf5 vIIuwkbS7OXrwQgCEXL9/oZwxVLXZM49O6HEDDJJWZTkhM7XMgNIQBJdMyM5qKcj 0GKLeZUG6dT9GSPuiXZAGTclUmUOtELujVHE1TdBZohPEu6B1jygSFuSL+JFC3To p5Rb6W9qXCOEi2TRJGDIXG1MT7JceBaq0KDUoOZta/2Zgj0x7Vm1YgT/J5+qsIIh 9pBI3NQ2W/Gc1I1ZvDEwuhHWxp693LS1cQ7o28ypfD6kyL8y8zWGIR5L/5Za5EPG MdV9HNKmTqc2dBTYnE7gRAUZ5jHg8o0y+biWv3iMmPpAtJmRDA8tmZrJdTTGbqTx nokGmYQ29508WpeT/0o7J+dFQOyFwL9wU4eNCZVjf2XsNkiyUKK8pfuppMHHOzAc o7vxjFpr7bfs9Ygp9s1s =Uj11 -----END PGP SIGNATURE----- From mohta@necom830.hpcl.titech.ac.jp Sun Feb 20 19:56:56 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1CCA13A6E7D for ; Sun, 20 Feb 2011 19:56:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.099 X-Spam-Level: X-Spam-Status: No, score=-0.099 tagged_above=-999 required=5 tests=[AWL=-0.009, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tr6f6En2z4CJ for ; Sun, 20 Feb 2011 19:56:54 -0800 (PST) Received: from necom830.hpcl.titech.ac.jp (necom830.hpcl.titech.ac.jp [131.112.32.132]) by core3.amsl.com (Postfix) with SMTP id 2C1303A6D52 for ; Sun, 20 Feb 2011 19:56:53 -0800 (PST) Received: (qmail 19472 invoked from network); 21 Feb 2011 04:08:46 -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 Feb 2011 04:08:46 -0000 Message-ID: <4D61E272.1050600@necom830.hpcl.titech.ac.jp> Date: Mon, 21 Feb 2011 12:56:34 +0900 From: Masataka Ohta User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; ja; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: dnsext@ietf.org References: <20110216032120.43474.qmail@joyce.lan> <20110216212930.57D64A3F344@drugs.dv.isc.org> <4D5D24F3.70206@gis.net> <20110217231720.1FCF3A49096@drugs.dv.isc.org> <4D5E08E4.8060106@necom830.hpcl.titech.ac.jp> <4D61B702.7060902@necom830.hpcl.titech.ac.jp> <20110221011731.F0FE0A6B00F@drugs.dv.isc.org> <4D61C45E.7000506@necom830.hpcl.titech.ac.jp> <20110221022950.BE88CA6B2DD@drugs.dv.isc.org> <4D61D194.9040804@necom830.hpcl.titech.ac.jp> <4D61D350.9040401@maxqe.com> In-Reply-To: <4D61D350.9040401@maxqe.com> Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit Subject: Re: [dnsext] SRV and wildcard CNAME X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 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, 21 Feb 2011 03:56:56 -0000 Larry Brower wrote: > I disagree, I say you are wasting it. Mark told you why it was a bad > idea and you just want to argue the point. It was already argued before Mark's first response: > Non existent protocols are not a problem, because they just do > not work, which is fine. > The problem is that protocols used share a port. > However, as the only protocol which may be used by *LAZY* users, > other than http, is https, it may share the same port as http, > if servers are implemented to distinguish them by the first > byte of the request. and, again, just after Mark's first response: > When the protocols used at the domain are http and https only, > nothing break. Protocols not used at a domain can not break at the domain, because they are not used. But Mark *REPEATED* his unfounded statement, which is the waste of bandwidth. Masataka Ohta From blblack@gmail.com Sun Feb 20 19:59:44 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ECDC93A6D99 for ; Sun, 20 Feb 2011 19:59:44 -0800 (PST) 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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YjXWJvu+OhJB for ; Sun, 20 Feb 2011 19:59:44 -0800 (PST) Received: from mail-yi0-f44.google.com (mail-yi0-f44.google.com [209.85.218.44]) by core3.amsl.com (Postfix) with ESMTP id D9FD53A6D52 for ; Sun, 20 Feb 2011 19:59:43 -0800 (PST) Received: by yie19 with SMTP id 19so2612011yie.31 for ; Sun, 20 Feb 2011 20:00:24 -0800 (PST) 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=Ueh8KsnvOTTVArwT6Vk0T4Tv50sOEu9OZcUw/yqL/oU=; b=Rtmz4ihMpkho/9UywNH/CQHhS3oYNM3IDlEbO20ZgjBYW6PbYdFc9PQXMIqFBrmLD5 +8fYI1ecDNflM3GUP+HZgnmYeR93ss6CgFiqZV8y62FV6IsGTZjkLnt16Aj8IkO8vrRB 0vPHGsAMZODKvLEos6Oc8WpXrc24dcBaqFrj4= 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=OzaumBPrc2NBMI3nGIFGC6hWydPMOsojH9/6h3RSAiHn8m3lGrHv7nbFFHUpWoeXWU ThpmvGMH3/Aq4IxJ4fNRZmAWhGdDmQDTlQU01sP2Zo9+rAram39U+DbSzEwTIOXFoHMM FW7BA9IRR9RH/Ci5RjoBT9l4w0CviXoHcOjqg= MIME-Version: 1.0 Received: by 10.100.3.12 with SMTP id 12mr411381anc.233.1298260823958; Sun, 20 Feb 2011 20:00:23 -0800 (PST) Received: by 10.101.68.7 with HTTP; Sun, 20 Feb 2011 20:00:23 -0800 (PST) In-Reply-To: <4AAEDEAF-AE3B-48D0-92AC-7C86538BF54E@rfc1035.com> References: <20110219210716.72943A5602B@drugs.dv.isc.org> <11263.1298150425@nsa.vix.com> <20110220072916.GA3505@vacation.karoshi.com.> <30899A4A-833B-42EF-9850-AFEE8B8DBE02@dotat.at> <4AAEDEAF-AE3B-48D0-92AC-7C86538BF54E@rfc1035.com> Date: Sun, 20 Feb 2011 22:00:23 -0600 Message-ID: From: Brandon Black To: Jim Reid Content-Type: text/plain; charset=UTF-8 Cc: "bmanning@vacation.karoshi.com" , "dnsext@ietf.org" Subject: Re: [dnsext] zone cut semantics X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 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, 21 Feb 2011 03:59:45 -0000 On Sun, Feb 20, 2011 at 8:43 PM, Jim Reid wrote: >> The root servers are authoritative for everything, that's why we believe >> their delegation answers. > > No they are not. The root servers are authoritative for the root zone*. > Which largely holds pointers to where we can find authoritative data about > other names in the DNS. The root zone cannot be authoritative for those > pointers (delegations) because they live beneath the zone cuts for the TLDs. > > I'm not sure what you mean by "believe delegation answers". No, please don't > try to explain... But you seem to be wrong about that too. The root servers > may well tell us there's a delegation for .brandon. But a resolving name > server won't "believe" that until it gets an authoritative answer from one > of the .brandon name servers, confirming the TLD's existence. And hopefully > validates all of that with DNSSEC. Fine, I won't use the word Authoritative in way that doesn't conform to the specifications, that's fair. The only way the resolver knows to believe the answer from the .brandon name servers is based on glue it believed from the root server. One way or another, you cannot avoid the fact that the root servers control .brandon's resolution, directly or indirectly. The root servers make a poor example though, because they're universal. Let's look at example.com. vs example.org. again, assuming the root delegates com. and org. to different sets of nameservers. If the org. nameservers answer www.example.org. with: example.org. NS ns1.example.com. ns1.example.com. A 192.0.2.1 I thought it was part of avoiding cache poisoning, etc, that org. nameservers are not to be believed for glue outside of its authority, and that the resolver should query ns1.example.com. separately. Or is it the view of the RFCs that ns1.example.com. is basically functionally a "temporary" name that ties those two response RRs together just to be used once to contact 192.0.2.1 for this one delegation and never cached, and that this doesn't need to be independently verified through the com. servers? I was under the impression this is why it matters whether example.org.'s nameserver glue is or isn't within org., and hence my whole point about why this matters for glue. An un-snarky correction on this would be appreciated :P From jra@baylink.com Sun Feb 20 20:08:26 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 87D3C3A6D99 for ; Sun, 20 Feb 2011 20:08:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.821 X-Spam-Level: X-Spam-Status: No, score=-1.821 tagged_above=-999 required=5 tests=[AWL=-0.087, BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, RDNS_DYNAMIC=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0Poqy2ozY2gF for ; Sun, 20 Feb 2011 20:08:25 -0800 (PST) Received: from benjamin.baylink.com (rrcs-24-129-180-187.se.biz.rr.com [24.129.180.187]) by core3.amsl.com (Postfix) with ESMTP id 4ADEC3A6D52 for ; Sun, 20 Feb 2011 20:08:25 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by benjamin.baylink.com (Postfix) with ESMTP id B687C1F0012D for ; Sun, 20 Feb 2011 23:09:18 -0500 (EST) X-Virus-Scanned: amavisd-new at benjamin.baylink.com Received: from benjamin.baylink.com ([127.0.0.1]) by localhost (benjamin.baylink.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id esbNK4SXJ0dN for ; Sun, 20 Feb 2011 23:09:18 -0500 (EST) Received: from benjamin.baylink.com (benjamin.baylink.com [192.168.253.10]) by benjamin.baylink.com (Postfix) with ESMTP id 24E921F000F0 for ; Sun, 20 Feb 2011 23:09:18 -0500 (EST) Date: Sun, 20 Feb 2011 23:09:18 -0500 (EST) From: Jay Ashworth To: dnsext@ietf.org Message-ID: <29759628.846.1298261358059.JavaMail.root@benjamin.baylink.com> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [65.34.93.30] X-Mailer: Zimbra 6.0.9_GA_2686 (ZimbraWebClient - FF3.0 (Linux)/6.0.9_GA_2686) Subject: Re: [dnsext] zone cut semantics X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 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, 21 Feb 2011 04:08:26 -0000 [ SPECULATION AHEAD ] ----- Original Message ----- > From: "Brandon Black" > The only way the resolver knows to believe the answer from the > .brandon name servers is based on glue it believed from the root > server. One way or another, you cannot avoid the fact that the root > servers control .brandon's resolution, directly or indirectly. The > root servers make a poor example though, because they're universal. > Let's look at example.com. vs example.org. again, assuming the root > delegates com. and org. to different sets of nameservers. > > If the org. nameservers answer www.example.org. with: > > example.org. NS ns1.example.com. > ns1.example.com. A 192.0.2.1 > > I thought it was part of avoiding cache poisoning, etc, that org. > nameservers are not to be believed for glue outside of its authority, I believe that you're not supposed to *cache* them. But you *have* to believe the parent glue, as it's the only way you *have* to locate the zone servers for the subdomain, is it not? root -> .org -> example.org ^^ that right there is the referral we're talking about. > and that the resolver should query ns1.example.com. separately. If you don't believe the IP addresses that .org hands you for example.org's zone servers, where else are you going to ask? > Or is it the view of the RFCs that ns1.example.com. is basically > functionally a "temporary" name that ties those two response RRs > together just to be used once to contact 192.0.2.1 for this one > delegation and never cached, and that this doesn't need to be > independently verified through the com. servers? I was under the > impression this is why it matters whether example.org.'s nameserver > glue is or isn't within org., and hence my whole point about why this > matters for glue. An un-snarky correction on this would be > appreciated :P It is just a "temporary name", I suppose, and if you have an authoritative locally cached copy of the pointer to the zone server, I suppose it might override what you're handed... but then you wouldn't trace the whole chain, anyway, would you? I suspect that, orthogonal to the questions about zone cut semantics, exactly how the resolvers work is implementation-defined... as Apple taught us a decade or more ago... Cheers, -- jra From hallam@gmail.com Sun Feb 20 20:22:47 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E695E3A6F2C for ; Sun, 20 Feb 2011 20:22:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.546 X-Spam-Level: X-Spam-Status: No, score=-3.546 tagged_above=-999 required=5 tests=[AWL=0.052, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ny5X48OaRtZI for ; Sun, 20 Feb 2011 20:22:46 -0800 (PST) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by core3.amsl.com (Postfix) with ESMTP id 7234D3A6F11 for ; Sun, 20 Feb 2011 20:22:46 -0800 (PST) Received: by iyj8 with SMTP id 8so201689iyj.31 for ; Sun, 20 Feb 2011 20:23:27 -0800 (PST) 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=H2RwFMmTtYT+ELeNvDVqUmebBJ+AvyHpOYkurWrpzLg=; b=nTivhTBhZ4U3E/0pqAZycczAse3Nhs9s9L3mQHJ4DYzd3pRTudUPPV5G4NhzWoUrS/ LxFr5uBXRQg3rI+dn8pB2QpfYdrEJxTQPrhoFT+d9BkVuLFVsQ4+jQJGkyeVeGsShelu YVi5PJSI0n48FYGEWeP4417j9RnaeAdYthI6E= 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=Bx68TKI/8fWCDluAawGWiA/eTDlaKa3DDSxjOVD6ZUO5cPOVt2KLykCfJ2NRaaEiJK ynCu8q7E+VPFxf6kEp+IrFQ+ljyTLNmepXmH22J/AWPKqvJZV1+uu0v4FF8ZP0KPd8fh RWjEN0C0qi0Dm4nidVTiv3BdJp1Jnun7kB+WQ= MIME-Version: 1.0 Received: by 10.42.174.193 with SMTP id w1mr1341388icz.338.1298262206883; Sun, 20 Feb 2011 20:23:26 -0800 (PST) Received: by 10.42.211.138 with HTTP; Sun, 20 Feb 2011 20:23:26 -0800 (PST) In-Reply-To: <4D61E272.1050600@necom830.hpcl.titech.ac.jp> References: <20110216032120.43474.qmail@joyce.lan> <20110216212930.57D64A3F344@drugs.dv.isc.org> <4D5D24F3.70206@gis.net> <20110217231720.1FCF3A49096@drugs.dv.isc.org> <4D5E08E4.8060106@necom830.hpcl.titech.ac.jp> <4D61B702.7060902@necom830.hpcl.titech.ac.jp> <20110221011731.F0FE0A6B00F@drugs.dv.isc.org> <4D61C45E.7000506@necom830.hpcl.titech.ac.jp> <20110221022950.BE88CA6B2DD@drugs.dv.isc.org> <4D61D194.9040804@necom830.hpcl.titech.ac.jp> <4D61D350.9040401@maxqe.com> <4D61E272.1050600@necom830.hpcl.titech.ac.jp> Date: Sun, 20 Feb 2011 20:23:26 -0800 Message-ID: From: Phillip Hallam-Baker To: Masataka Ohta Content-Type: multipart/alternative; boundary=90e6ba6e8cc8aaa895049cc33912 Cc: dnsext@ietf.org Subject: Re: [dnsext] SRV and wildcard CNAME X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 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, 21 Feb 2011 04:22:48 -0000 --90e6ba6e8cc8aaa895049cc33912 Content-Type: text/plain; charset=ISO-8859-1 On Sun, Feb 20, 2011 at 7:56 PM, Masataka Ohta < mohta@necom830.hpcl.titech.ac.jp> wrote: > Larry Brower wrote: > > > I disagree, I say you are wasting it. Mark told you why it was a bad > > idea and you just want to argue the point. > > It was already argued before Mark's first response: > > > Non existent protocols are not a problem, because they just do > > not work, which is fine. > > The problem is that protocols used share a port. > > However, as the only protocol which may be used by *LAZY* users, > > other than http, is https, it may share the same port as http, > > if servers are implemented to distinguish them by the first > > byte of the request. > > and, again, just after Mark's first response: > > > When the protocols used at the domain are http and https only, > > nothing break. > > Protocols not used at a domain can not break at the domain, > because they are not used. > > But Mark *REPEATED* his unfounded statement, which is > the waste of bandwidth. Mark is quite correct here. I have been looking at this problem for five years now and I can assure you that if Mark was wrong, I would know it. The fundamental limitation here is that prefix records can only be applied to canonical names. They do not give the desired results if either wildcards or aliases are used. Consider the following: *.example.com SRV 1 1 80 host1.example.com Any attempt to resolve any service in example.com will succeed whether or not the service is provided. In other words the domain is advertising services it does not support, this is a failure for a discovery mechanism. The following attempt to create an alias for example.net to example.com also fails: example.net CNAME example.com _http._tcp.example.com SRV 1 1 80 host1.example.com These are problematic because wildcards and aliases are features we want in the DNS and they should be supported by advanced discovery. The mechanism that I hope to have ready for an ID next week adopts the following approach Phase 1: Domain Resolution The query is made for an unprefixed record. This query will return one of the following results: 1) Domain not found - game over 2) CNAME alias - maps to canonical name 3) Record returned saying 'use SRV, use URI, use TBD' In the case of a wildcard, there is a need to specify the address at which a prefix record is to be applied. Phase 2: Service Resolution If indicated by domain resolution, SRV or URI resolution is employed to resolve the service to a host. It is possible to save the principle of prefix resolution and make aliases and wildcard work. But not by pretending that there is no issue to be solved. -- Website: http://hallambaker.com/ --90e6ba6e8cc8aaa895049cc33912 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Sun, Feb 20, 2011 at 7:56 PM, Masatak= a Ohta <mohta@necom830.hpcl.titech.ac.jp> wrote:
Larry Brower wrote:

> I disagree, I say you are wasting it. Mark told you why it was a bad > idea and you just want to argue the point.

It was already argued before Mark's first response:

> Non existent protocols are not a problem, because they just do
> not work, which is fine.
> The problem is that protocols used share a port.
> However, as the only protocol which may be use= d by *LAZY* users,
> other than http, is https, it may share the same port as http,
> if servers are implemented to distinguish them by the first
> byte of the request.

and, again, just after Mark's first response:

> When the protocols used at the domain are http and https only,
> nothing break.

Protocols not used at a domain can not break at the domain,
because they are not used.

But Mark *REPEATED* his unfounded statement, which is
the waste of bandwidth.

Mark is quite corre= ct here.

I have been looking at this problem for f= ive years now and I can assure you that if Mark was wrong, I would know it.=


The fundamental limitation here is that = prefix records can only be applied to canonical names. They do not give the= desired results if either wildcards or aliases are used.

Consider the following:

*.example.com=A0=A0 SRV 1 1 80 host1.example.com

Any attempt to = resolve any service in example.com =A0wi= ll succeed whether or not the service is provided. In other words the domai= n is advertising services it does not support, this is a failure for a disc= overy mechanism.


The following attempt to create an alias= for example.net to example.com also fails:


These are problematic because wildcards and alia= ses are features we want in the DNS and they should be supported by advance= d discovery.

The mechanism that I hope to have ready for an ID next = week adopts the following approach

Phase 1: Domain= Resolution

The query is made for an unprefixed re= cord. This query will return one of the following results:

1) Domain not found - game over
2) CNAME alia= s - maps to canonical name
3) Record returned saying 'use SRV= , use URI, use TBD'

In the case of a wildcard,= there is a need to specify the address at which a prefix record is to be a= pplied.


Phase 2: Service Resolution
If indicated by domain resolution, SRV or URI resolution is em= ployed to resolve the service to a host.


It is possible to save the principle of prefix resolution and make ali= ases and wildcard work. But not by pretending that there is no issue to be = solved.

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

--90e6ba6e8cc8aaa895049cc33912-- From marka@isc.org Sun Feb 20 20:25:13 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A11F33A6F11 for ; Sun, 20 Feb 2011 20:25:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.716 X-Spam-Level: X-Spam-Status: No, score=-1.716 tagged_above=-999 required=5 tests=[AWL=0.883, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZCRt-W95JgN3 for ; Sun, 20 Feb 2011 20:25:12 -0800 (PST) Received: from mx.pao1.isc.org (mx.pao1.isc.org [IPv6:2001:4f8:0:2::2b]) by core3.amsl.com (Postfix) with ESMTP id 89FD33A6EC0 for ; Sun, 20 Feb 2011 20:25:12 -0800 (PST) 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 A703FC941A; Mon, 21 Feb 2011 04:25:41 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (drugs.dv.isc.org [IPv6:2001:470:1f00:820:ea06:88ff:fef3:4f9c]) (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 3C745216C1E; Mon, 21 Feb 2011 04:25:41 +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 0AE4EA6CFFF; Mon, 21 Feb 2011 15:25:37 +1100 (EST) To: Masataka Ohta From: Mark Andrews References: <20110216032120.43474.qmail@joyce.lan> <20110216212930.57D64A3F344@drugs.dv.isc.org> <4D5D24F3.70206@gis.net> <20110217231720.1FCF3A49096@drugs.dv.isc.org> <4D5E08E4.8060106@necom830.hpcl.titech.ac.jp> <4D61B702.7060902@necom830.hpcl.titech.ac.jp> <20110221011731.F0FE0A6B00F@drugs.dv.isc.org> <4D61C45E.7000506@necom830.hpcl.titech.ac.jp> <20110221022950.BE88CA6B2DD@drugs.dv.isc.org> <4D61D194.9040804@necom830.hpcl.titech.ac.jp> <4D61D350.9040401@maxqe.com> <4D61E272.1050600@necom830.hpcl.titech.ac.jp> In-reply-to: Your message of "Mon, 21 Feb 2011 12:56:34 +0900." <4D61E272.1050600@necom830.hpcl.titech.ac.jp> Date: Mon, 21 Feb 2011 15:25:36 +1100 Message-Id: <20110221042537.0AE4EA6CFFF@drugs.dv.isc.org> Cc: dnsext@ietf.org Subject: Re: [dnsext] SRV and wildcard CNAME X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 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, 21 Feb 2011 04:25:13 -0000 In message <4D61E272.1050600@necom830.hpcl.titech.ac.jp>, Masataka Ohta writes: > Larry Brower wrote: > > > I disagree, I say you are wasting it. Mark told you why it was a bad > > idea and you just want to argue the point. > > It was already argued before Mark's first response: > > > Non existent protocols are not a problem, because they just do > > not work, which is fine. > > The problem is that protocols used share a port. > > However, as the only protocol which may be used by *LAZY* users, > > other than http, is https, it may share the same port as http, > > if servers are implemented to distinguish them by the first > > byte of the request. > > and, again, just after Mark's first response: > > > When the protocols used at the domain are http and https only, > > nothing break. > > Protocols not used at a domain can not break at the domain, > because they are not used. > > But Mark *REPEATED* his unfounded statement, which is > the waste of bandwidth. When the discovery phase of the protocol returns a answer when it shouldn't have you have broken the protocol regardless of whether it would ultimately succeed or not. Additionally no one has the ability to foresee future needs. I re-iterate. Wildcards SRV records are a bad idea. 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 Sun Feb 20 20:46:32 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C0E1A3A6F05 for ; Sun, 20 Feb 2011 20:46:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.098 X-Spam-Level: X-Spam-Status: No, score=-0.098 tagged_above=-999 required=5 tests=[AWL=-0.008, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z9x3C5U62G+J for ; Sun, 20 Feb 2011 20:46:32 -0800 (PST) Received: from necom830.hpcl.titech.ac.jp (necom830.hpcl.titech.ac.jp [131.112.32.132]) by core3.amsl.com (Postfix) with SMTP id BFF183A6EC0 for ; Sun, 20 Feb 2011 20:46:31 -0800 (PST) Received: (qmail 20687 invoked from network); 21 Feb 2011 04:58: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; 21 Feb 2011 04:58:23 -0000 Message-ID: <4D61EE10.6050309@necom830.hpcl.titech.ac.jp> Date: Mon, 21 Feb 2011 13:46:08 +0900 From: Masataka Ohta User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; ja; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: Phillip Hallam-Baker References: <20110216032120.43474.qmail@joyce.lan> <20110216212930.57D64A3F344@drugs.dv.isc.org> <4D5D24F3.70206@gis.net> <20110217231720.1FCF3A49096@drugs.dv.isc.org> <4D5E08E4.8060106@necom830.hpcl.titech.ac.jp> <4D61B702.7060902@necom830.hpcl.titech.ac.jp> <20110221011731.F0FE0A6B00F@drugs.dv.isc.org> <4D61C45E.7000506@necom830.hpcl.titech.ac.jp> <20110221022950.BE88CA6B2DD@drugs.dv.isc.org> <4D61D194.9040804@necom830.hpcl.titech.ac.jp> <4D61D350.9040401@maxqe.com> <4D61E272.1050600@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] SRV and wildcard CNAME X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 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, 21 Feb 2011 04:46:32 -0000 Phillip Hallam-Baker wrote: >>> When the protocols used at the domain are http and https only, >>> nothing break. > Mark is quite correct here. Neither your example "_null._random.example.com" nor Mark's example "_foo._tcp.bar.example.com" is applicable to the case of "protocols used at the domain are http and https only", because you are assuming protocols "null" or "foo" is used at the domain. > In other words the domain is advertising > services it does not support, this is a failure for a discovery mechanism. That's fine. Lazy users do not mind if they advertise non existent services. Moreover, your statement has nothing to do with Mark's unfounded statement: It breaks *all* protocols that use SRV. Masataka Ohta From mohta@necom830.hpcl.titech.ac.jp Sun Feb 20 20:51:51 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BB4CE3A6F05 for ; Sun, 20 Feb 2011 20:51:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.098 X-Spam-Level: X-Spam-Status: No, score=-0.098 tagged_above=-999 required=5 tests=[AWL=-0.008, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j5sTVfV5rGRD for ; Sun, 20 Feb 2011 20:51:51 -0800 (PST) Received: from necom830.hpcl.titech.ac.jp (necom830.hpcl.titech.ac.jp [131.112.32.132]) by core3.amsl.com (Postfix) with SMTP id C40DD3A6EC0 for ; Sun, 20 Feb 2011 20:51:50 -0800 (PST) Received: (qmail 20763 invoked from network); 21 Feb 2011 05:04:04 -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 Feb 2011 05:04:04 -0000 Message-ID: <4D61EF65.1000602@necom830.hpcl.titech.ac.jp> Date: Mon, 21 Feb 2011 13:51:49 +0900 From: Masataka Ohta User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; ja; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: Mark Andrews References: <20110216032120.43474.qmail@joyce.lan> <20110216212930.57D64A3F344@drugs.dv.isc.org> <4D5D24F3.70206@gis.net> <20110217231720.1FCF3A49096@drugs.dv.isc.org> <4D5E08E4.8060106@necom830.hpcl.titech.ac.jp> <4D61B702.7060902@necom830.hpcl.titech.ac.jp> <20110221011731.F0FE0A6B00F@drugs.dv.isc.org> <4D61C45E.7000506@necom830.hpcl.titech.ac.jp> <20110221022950.BE88CA6B2DD@drugs.dv.isc.org> <4D61D194.9040804@necom830.hpcl.titech.ac.jp> <4D61D350.9040401@maxqe.com> <4D61E272.1050600@necom830.hpcl.titech.ac.jp> <20110221042537.0AE4EA6CFFF@drugs.dv.isc.org> In-Reply-To: <20110221042537.0AE4EA6CFFF@drugs.dv.isc.org> Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit Cc: dnsext@ietf.org Subject: Re: [dnsext] SRV and wildcard CNAME X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 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, 21 Feb 2011 04:51:51 -0000 Mark Andrews wrote: > When the discovery phase of the protocol returns a answer when it > shouldn't have you have broken the protocol regardless of whether > it would ultimately succeed or not. You can't force lazy users strictly follow your idea on how protocols should not break. They are fine if their http domains work. > Additionally no one has the ability to foresee future needs. Just say, TTL. Masataka Ohta From ogud@ogud.com Sun Feb 20 20:56:03 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2A5EB3A6EC0 for ; Sun, 20 Feb 2011 20:56:03 -0800 (PST) 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=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XQaw1cmPqzG7 for ; Sun, 20 Feb 2011 20:56:00 -0800 (PST) Received: from stora.ogud.com (stora.ogud.com [66.92.146.20]) by core3.amsl.com (Postfix) with ESMTP id D16C63A6E28 for ; Sun, 20 Feb 2011 20:55:59 -0800 (PST) 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 p1L4vDTP011576 for ; Sun, 20 Feb 2011 23:57:13 -0500 (EST) (envelope-from ogud@ogud.com) Message-ID: <4D61F085.5010606@ogud.com> Date: Sun, 20 Feb 2011 23:56:37 -0500 From: Olafur Gudmundsson User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-GB; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: dnsext@ietf.org References: <20110219210716.72943A5602B@drugs.dv.isc.org> <11263.1298150425@nsa.vix.com> <20110220072916.GA3505@vacation.karoshi.com.> <30899A4A-833B-42EF-9850-AFEE8B8DBE02@dotat.at> 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] zone cut semantics X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 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, 21 Feb 2011 04:56:03 -0000 On 20/02/2011 3:44 PM, Jim Reid wrote: > On 20 Feb 2011, at 20:14, Brandon Black wrote: > >> Isn't this really a matter of semantics? > > Yes: zone cut semantics, not language semantics. > >> The parent zone is >> authoritative for everything beneath itself, even if it choses to use >> that power of authority to give a delegation response. e.g. the .com >> servers are authoritative for www.example.com, but they choose to >> delegate that answer to the NS for example.com. > > Nope. Query the .com name servers for the NS records for example.com. > They correctly return a non-authoritative answer. It's only the name > servers for example.com that are authoritative for example.com and will > authoritatively answer that query. In other words, it's the child that's > responsible for the zone's authoritative NS RRset, not the parent. Which > is how things should be when you consider what delegation actually > means: crossing an administrative boundary from one authority to another. > > Please think again about what you posted. The inference of what you say > is that the root servers are authoritative for everything. That's > clearly not true. > In RCF103x with RFC2181 clarification the world it was simple: Parent zone is authoritative for the existence of delegation, child servers are authoritative for content. ==> Everything but the presence of NS records is hint/glue in parent servers. But we could not keep it simple forever in the DNSSEC world thus this amendment: Parent is Authoritative for the contents DS record and NSEC/NSEC3 records at delegation that prove if the delegation exists and if there is a trust path from parent to child. Olafur From ogud@ogud.com Mon Feb 21 00:44:47 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 55F333A6F7A for ; Mon, 21 Feb 2011 00:44:47 -0800 (PST) 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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lzFrwUMkWe8q for ; Mon, 21 Feb 2011 00:44:46 -0800 (PST) Received: from stora.ogud.com (stora.ogud.com [66.92.146.20]) by core3.amsl.com (Postfix) with ESMTP id 6BE4B3A6DFF for ; Mon, 21 Feb 2011 00:44:46 -0800 (PST) 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 p1L8k0be013168 for ; Mon, 21 Feb 2011 03:46:00 -0500 (EST) (envelope-from ogud@ogud.com) Message-ID: <4D622624.90303@ogud.com> Date: Mon, 21 Feb 2011 03:45:24 -0500 From: Olafur Gudmundsson User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-GB; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: dnsext@ietf.org 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: [dnsext] WG opinion on draft : Improvements to DNS Resolvers, for Resiliency, Robustness, and Responsiveness X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 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, 21 Feb 2011 08:44:47 -0000 The chairs have received a request to Last call this draft. http://tools.ietf.org/html/draft-vixie-dnsext-resimprove-00 This draft is clearly in scope of the Working Group. As there has not been much discussion on this draft the chairs are not ready at this point to start a Last Call but would like to get a sense of the working group participants' feelings on the draft. The draft is aimed at BCP status; thus there is no RFC2119 language in the draft. Background: The draft contains three recommendation on how resolvers operate, A. Re-validating a delegation when a parent NS RRset TTL expires. B. Stopping a downward cache search when an NXDOMAIN is encountered. C. Upgrading the credibility of NS RRsets upon delegation event. All of these have been suggested in various forms over the years. Following opinions are sought: 1. Are the suggestions in the draft something people think is a good idea? 2. Is the draft clear in its message? If not, please suggest improvements. 3. After (if any) editing fixes is this draft ready for WG Last Call? Olafur and Andrew From fweimer@bfk.de Mon Feb 21 00:53:06 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 383D53A6FEC for ; Mon, 21 Feb 2011 00:53:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.199 X-Spam-Level: X-Spam-Status: No, score=-2.199 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dQmbNEwmheVi for ; Mon, 21 Feb 2011 00:53:05 -0800 (PST) Received: from mx01.bfk.de (mx01.bfk.de [193.227.124.2]) by core3.amsl.com (Postfix) with ESMTP id 14A463A6F84 for ; Mon, 21 Feb 2011 00:53:03 -0800 (PST) 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 1PrRWY-0006AY-Vx; Mon, 21 Feb 2011 08:53:42 +0000 Received: by bfk.de with local id 1PrRWY-0005bh-QK; Mon, 21 Feb 2011 08:53:42 +0000 To: Mark Andrews References: <20110219210716.72943A5602B@drugs.dv.isc.org> From: Florian Weimer Date: Mon, 21 Feb 2011 08:53:42 +0000 In-Reply-To: <20110219210716.72943A5602B@drugs.dv.isc.org> (Mark Andrews's message of "Sun\, 20 Feb 2011 08\:07\:15 +1100") Message-ID: <82r5b1g44p.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] Failure to add glue MUST cause TC to be set. X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 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, 21 Feb 2011 08:53:06 -0000 * Mark Andrews: > Below is a example of why TC should be set when glue cannot be added > to the answer. > ; <<>> DiG 9.6.0-APPLE-P2 <<>> +norec +dnssec +bufsize=3D512 @b.gov-serve= rs.net vwall1a.nyc.gov This query is in direct violation of RFC 3226, so it is not a particularly compelling example. I agree there is a protocol problem. But you need to find something else to deal with the case above, like fallback to DO=3D0 to get the referral---which would be even bettr than TCP fallback from a performance perspective. --=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 fanf2@hermes.cam.ac.uk Mon Feb 21 02:29:01 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6BDE93A7072 for ; Mon, 21 Feb 2011 02:29:01 -0800 (PST) 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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d+CJxpibr5Lr for ; Mon, 21 Feb 2011 02:29:00 -0800 (PST) Received: from ppsw-50.csi.cam.ac.uk (ppsw-50.csi.cam.ac.uk [131.111.8.150]) by core3.amsl.com (Postfix) with ESMTP id 09D793A6E99 for ; Mon, 21 Feb 2011 02:29:00 -0800 (PST) X-Cam-AntiVirus: no malware found X-Cam-SpamDetails: not scanned X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ Received: from hermes-1.csi.cam.ac.uk ([131.111.8.51]:43193) by ppsw-50.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.157]:25) with esmtpa (EXTERNAL:fanf2) id 1PrT1O-0002XR-rQ (Exim 4.72) (return-path ); Mon, 21 Feb 2011 10:29:38 +0000 Received: from fanf2 (helo=localhost) by hermes-1.csi.cam.ac.uk (hermes.cam.ac.uk) with local-esmtp id 1PrT1O-0005O3-Hj (Exim 4.67) (return-path ); Mon, 21 Feb 2011 10:29:38 +0000 Date: Mon, 21 Feb 2011 10:29:38 +0000 From: Tony Finch X-X-Sender: fanf2@hermes-1.csi.cam.ac.uk To: Brandon Black In-Reply-To: Message-ID: References: <20110219210716.72943A5602B@drugs.dv.isc.org> <20110220203156.C1F83A6526F@drugs.dv.isc.org> <3764325DE7FA4B2F9B77387EBD15EAF8@local> <20110220210758.81B93A65431@drugs.dv.isc.org> <20110220224741.2ED73A65B39@drugs.dv.isc.org> User-Agent: Alpine 2.00 (LSU 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: Tony Finch Cc: dnsext@ietf.org Subject: Re: [dnsext] Failure to add glue MUST cause TC to be set. X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 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, 21 Feb 2011 10:29:01 -0000 On Sun, 20 Feb 2011, Brandon Black wrote: > > The case I was confusing this with (re: optimization, etc) was the > case where there was no immediate common parent domain to host the > cross-zone glue (e.g. A.net. NS ns1.B.org. + B.org. NS ns1.A.net.). > In the special case that the org. and net. nameservers shared IP > addresses (and were in fact the same namservers) and handed out > cross-zone glue addresses for those cases, a smart enough resolver > might figure it out and believe them based on the shared nameserver > IPs ("I already know 192.0.2.3 is authoritative for org. from earlier, > and now during a query for A.net to the same IP address, I'm seeing > B.org. glue records and it's ok to believe them"), but a dumber > resolver would be unable to see records in either domain if it > implemented a sane basic security model (bailiwick of QNAME). I think > we have to assume the simpler resolver behavior rather than try to > construct schemes that rely on the "smarter" behavior, right? Until about a year ago the gtld-servers.net nameserver which host .com and .net handed out cross-TLD glue. There were a number of domains which relied on this fact in order to work correctly - and they did pretty much work, which implies that resolvers are not "dumber" according to the criteria above. But as part of the preparation for DNSSEC this behaviour was tidied up. http://verisigninc.com/en_GB/products-and-services/domain-name-services/domain-information-center/frequently-asked-questions/dns-behavior-changes/ Tony. -- f.anthony.n.finch http://dotat.at/ Biscay, FitzRoy: Westerly, backing southerly for a time, 5 to 7, occasionally gale 8, decreasing 4 later in south Fitzroy. Very rough or high. Rain or showers. Moderate or good, occasionally poor. From fanf2@hermes.cam.ac.uk Mon Feb 21 02:31:57 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D7A033A707B for ; Mon, 21 Feb 2011 02:31:57 -0800 (PST) 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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 55694LvP8qQv for ; Mon, 21 Feb 2011 02:31:54 -0800 (PST) Received: from ppsw-52.csi.cam.ac.uk (ppsw-52.csi.cam.ac.uk [131.111.8.152]) by core3.amsl.com (Postfix) with ESMTP id B10573A6E99 for ; Mon, 21 Feb 2011 02:31:54 -0800 (PST) X-Cam-AntiVirus: no malware found X-Cam-SpamDetails: not scanned X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ Received: from hermes-1.csi.cam.ac.uk ([131.111.8.51]:39634) by ppsw-52.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.159]:25) with esmtpa (EXTERNAL:fanf2) id 1PrT4D-0008Ga-EV (Exim 4.72) (return-path ); Mon, 21 Feb 2011 10:32:33 +0000 Received: from fanf2 (helo=localhost) by hermes-1.csi.cam.ac.uk (hermes.cam.ac.uk) with local-esmtp id 1PrT4D-00061U-Fc (Exim 4.67) (return-path ); Mon, 21 Feb 2011 10:32:33 +0000 Date: Mon, 21 Feb 2011 10:32:33 +0000 From: Tony Finch X-X-Sender: fanf2@hermes-1.csi.cam.ac.uk To: Mark Andrews In-Reply-To: <20110221014201.9964BA6B0BA@drugs.dv.isc.org> Message-ID: References: <20110219210716.72943A5602B@drugs.dv.isc.org> <20110220203156.C1F83A6526F@drugs.dv.isc.org> <3764325DE7FA4B2F9B77387EBD15EAF8@local> <20110220210758.81B93A65431@drugs.dv.isc.org> <20110220224741.2ED73A65B39@drugs.dv.isc.org> <20110221014201.9964BA6B0BA@drugs.dv.isc.org> User-Agent: Alpine 2.00 (LSU 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: Tony Finch Cc: dnsext@ietf.org Subject: Re: [dnsext] Failure to add glue MUST cause TC to be set. X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 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, 21 Feb 2011 10:31:58 -0000 On Mon, 21 Feb 2011, Mark Andrews wrote: > Brandon Black writes: > > > In general I think the smartest policy in light of all of this is to > > always put the NS names for a zone beneath that zone itself, even if > > the IPs refer to 3rd-party nameservers, but it certainly doesn't have > > to be a requirement to function. > > but this section is a really, really bad idea and defeats the whole > purpose of having NS records be names not addresses. What problems does it cause other than reducing the opportunities to re-use cached NS records? Tony. -- f.anthony.n.finch http://dotat.at/ Biscay, FitzRoy: Westerly, backing southerly for a time, 5 to 7, occasionally gale 8, decreasing 4 later in south Fitzroy. Very rough or high. Rain or showers. Moderate or good, occasionally poor. From hallam@gmail.com Mon Feb 21 05:31:29 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 291C83A6FCF for ; Mon, 21 Feb 2011 05:31:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.549 X-Spam-Level: X-Spam-Status: No, score=-3.549 tagged_above=-999 required=5 tests=[AWL=0.049, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YdMYCu8vGwJz for ; Mon, 21 Feb 2011 05:31:28 -0800 (PST) Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by core3.amsl.com (Postfix) with ESMTP id DD74A3A6F99 for ; Mon, 21 Feb 2011 05:31:27 -0800 (PST) Received: by iwl42 with SMTP id 42so3022696iwl.31 for ; Mon, 21 Feb 2011 05:32:09 -0800 (PST) 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=DUrlgjHex/SG+aj30Tz1KkloRbSc1iHj3TxKWnzG6aM=; b=SbFC0KMu5PfM87fFpLfg3lwsjaA48HFeyE9AIuwPxaeyRBlAMfJBHHUgUJXxv6mllZ pCvYFAHugm3DpIvZSp6vhp8HaHjg9GAvOPrgxD05kv+TyoaOTGGoIEQHz5r3hE+TkuRM 1yrN3i6HCDIo346oTAV/I6cYPBYtTwTqyqSsw= 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=keMpDqyLwvfspvTm2FwrGv/+QUsyqAHPlKyHS4toMxK5z0FbfkPO0ChY+UOXBeeWbp cHu9c9DtJKB8f7bDCt0BmsexlEjs6FfuzXIrFJBppPd2lpaviSQROeYhVE1NV/UyR7Gm Rd8FSZfDH94cyVJDjTDYYPQTugmad/e9hZvG8= MIME-Version: 1.0 Received: by 10.42.223.70 with SMTP id ij6mr1964534icb.70.1298295129384; Mon, 21 Feb 2011 05:32:09 -0800 (PST) Received: by 10.42.211.138 with HTTP; Mon, 21 Feb 2011 05:32:09 -0800 (PST) In-Reply-To: <4D61EE10.6050309@necom830.hpcl.titech.ac.jp> References: <20110216032120.43474.qmail@joyce.lan> <20110216212930.57D64A3F344@drugs.dv.isc.org> <4D5D24F3.70206@gis.net> <20110217231720.1FCF3A49096@drugs.dv.isc.org> <4D5E08E4.8060106@necom830.hpcl.titech.ac.jp> <4D61B702.7060902@necom830.hpcl.titech.ac.jp> <20110221011731.F0FE0A6B00F@drugs.dv.isc.org> <4D61C45E.7000506@necom830.hpcl.titech.ac.jp> <20110221022950.BE88CA6B2DD@drugs.dv.isc.org> <4D61D194.9040804@necom830.hpcl.titech.ac.jp> <4D61D350.9040401@maxqe.com> <4D61E272.1050600@necom830.hpcl.titech.ac.jp> <4D61EE10.6050309@necom830.hpcl.titech.ac.jp> Date: Mon, 21 Feb 2011 05:32:09 -0800 Message-ID: From: Phillip Hallam-Baker To: Masataka Ohta Content-Type: multipart/alternative; boundary=20cf30549b3d0026be049ccae4e5 Cc: dnsext@ietf.org Subject: Re: [dnsext] SRV and wildcard CNAME X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 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, 21 Feb 2011 13:31:29 -0000 --20cf30549b3d0026be049ccae4e5 Content-Type: text/plain; charset=ISO-8859-1 2011/2/20 Masataka Ohta > Phillip Hallam-Baker wrote: > > >>> When the protocols used at the domain are http and https only, > >>> nothing break. > > > Mark is quite correct here. > > Neither your example "_null._random.example.com" nor Mark's > example "_foo._tcp.bar.example.com" is applicable to the case > of "protocols used at the domain are http and https only", > because you are assuming protocols "null" or "foo" is used > at the domain. > > > In other words the domain is advertising > > services it does not support, this is a failure for a discovery > mechanism. > > That's fine. > > Lazy users do not mind if they advertise non existent services. > But competent people mind a very great deal. If the client is attempting to discover which GPS protocols are supported at a site and choose the best, the wildcard scheme fails because it will advertise everything as being on offer. Now I do have some experience in Web Services that is rather relevant here. Like many protocol design issues, these are very easy if you only deal with some of the use cases. They become much harder when you actually take into account all the constraints. -- Website: http://hallambaker.com/ --20cf30549b3d0026be049ccae4e5 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

2011/2/20 Masataka Ohta <mohta@necom830.hp= cl.titech.ac.jp>
Phillip Hallam-Baker wrote:

>>> When the protocols used at the domain are http and https only,=
>>> nothing break.

> Mark is quite correct here.

Neither your example "_null._random.example.com" nor Mark's
example "_foo._tcp.bar.example.com" is applicable to the case
of "protocols used at the domain are http and https only",
because you are assuming protocols "null" or "foo" is u= sed
at the domain.

> In other words the domain is advertising
> services it does not support, this is a failure for a discovery mechan= ism.

That's fine.

Lazy users do not mind if they advertise non existent services.


But competent people mind a very gr= eat deal. If the client is attempting to discover which GPS protocols are s= upported at a site and choose the best, the wildcard scheme fails because i= t will advertise everything as being on offer.

Now I do have some experience in Web Services that is r= ather relevant here.


Like many prot= ocol design issues, these are very easy if you only deal with some of the u= se cases. They become much harder when you actually take into account all t= he constraints.=A0


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

--20cf30549b3d0026be049ccae4e5-- From wouter@nlnetlabs.nl Mon Feb 21 08:33:35 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8FF553A6FEF for ; Mon, 21 Feb 2011 08:33:35 -0800 (PST) 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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vWyVA1IpP9NF for ; Mon, 21 Feb 2011 08:33:34 -0800 (PST) Received: from open.nlnetlabs.nl (open.nlnetlabs.nl [IPv6:2001:7b8:206:1::1]) by core3.amsl.com (Postfix) with ESMTP id B29323A6FE4 for ; Mon, 21 Feb 2011 08:33:33 -0800 (PST) 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 p1LGYEMu086705 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Mon, 21 Feb 2011 17:34:14 +0100 (CET) (envelope-from wouter@nlnetlabs.nl) Message-ID: <4D629406.6070807@nlnetlabs.nl> Date: Mon, 21 Feb 2011 17:34:14 +0100 From: "W.C.A. Wijngaards" User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.13) Gecko/20101209 Fedora/3.1.7-0.35.b3pre.fc13 Lightning/1.0b3pre Thunderbird/3.1.7 MIME-Version: 1.0 To: dnsext@ietf.org References: <29759628.846.1298261358059.JavaMail.root@benjamin.baylink.com> In-Reply-To: <29759628.846.1298261358059.JavaMail.root@benjamin.baylink.com> 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.6 (open.nlnetlabs.nl [IPv6:2001:7b8:206:1::53]); Mon, 21 Feb 2011 17:34:14 +0100 (CET) Subject: Re: [dnsext] zone cut semantics X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 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, 21 Feb 2011 16:33:35 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi Brandon, Jay, On 02/21/2011 05:09 AM, Jay Ashworth wrote: >> independently verified through the com. servers? I was under the >> impression this is why it matters whether example.org.'s nameserver >> glue is or isn't within org., and hence my whole point about why this >> matters for glue. An un-snarky correction on this would be >> appreciated :P > > It is just a "temporary name", I suppose, and if you have an authoritative > locally cached copy of the pointer to the zone server, I suppose it might > override what you're handed... but then you wouldn't trace the whole > chain, anyway, would you? It is not 'temporary', but 'lower ranked', and this is defined in RFC2181. Where you find that the data from the example.org is preferred over this data. But until you have that data, this is what you use (to get there, as Jay infers). Best regards, Wouter -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iEYEARECAAYFAk1ilAUACgkQkDLqNwOhpPgVgACfYFNS7UWAlrHuaUe3HYoPggMa mOMAn0mFS3K1n7Gc6cCUdYArozYD2vDH =VVBq -----END PGP SIGNATURE----- From marka@isc.org Sat Feb 19 03:08:00 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3F87D3A6FF9 for ; Sat, 19 Feb 2011 03:08:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.753 X-Spam-Level: X-Spam-Status: No, score=-1.753 tagged_above=-999 required=5 tests=[AWL=-0.820, BAYES_00=-2.599, SARE_HTML_URI_LHOST31=1.666] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9EMRMMiGJ3qW for ; Sat, 19 Feb 2011 03:07:58 -0800 (PST) Received: from mx.ams1.isc.org (mx.ams1.isc.org [IPv6:2001:500:60::65]) by core3.amsl.com (Postfix) with ESMTP id A50E13A6FFB for ; Sat, 19 Feb 2011 03:07:56 -0800 (PST) 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 1BE755F98A2 for ; Sat, 19 Feb 2011 11:08:14 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (c211-30-172-21.carlnfd1.nsw.optusnet.com.au [211.30.172.21]) (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 C08EE216C22 for ; Sat, 19 Feb 2011 11:08:10 +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 72F45A53944 for ; Sat, 19 Feb 2011 22:08:05 +1100 (EST) Date: Sat, 19 Feb 2011 22:08:05 +1100 Message-Id: <20110219110805.72F45A53944@drugs.dv.isc.org> From: marka@isc.org To: undisclosed-recipients:; X-Mailman-Approved-At: Mon, 21 Feb 2011 08:43:29 -0800 Subject: Re: [dnsext] [SOLVED] Re: BIND9 SERVFAIL on some .gov addresses X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 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, 19 Feb 2011 11:08:00 -0000 ------- Blind-Carbon-Copy To: Shaoquan Lin Cc: bind-users@isc.org From: Mark Andrews References: <17894D6D30484DDFBBE95BEF987FF5D1@se179> Subject: Re: [SOLVED] Re: BIND9 SERVFAIL on some .gov addresses In-reply-to: Your message of "Fri, 18 Feb 2011 15:54:58 CDT." <17894D6D30484DDFBBE95BEF987FF5D1@se179> Date: Sat, 19 Feb 2011 22:08:05 +1100 In message <17894D6D30484DDFBBE95BEF987FF5D1@se179>, "Shaoquan Lin" writes: > Ryan, > > Have you solved your problem? I have similar problems. I run BIND = > 9.6..1-P3 on my Solaris 10 and can not resolve anything in domain = > nyc.gov. One thing I noticed is: BIND 9.3 send query to = > b.gov-servers.net with no Additional records and got a response with A = > records for the nyc.gov NS servers in the Additional records; but BIND = > 9.6 send query with type OPT Additional records and got a response with = > also a type OPT but no A in the Additional records. So the BIND 9.6 can = > not find the IP addresses of the nyc.gov NS servers and therefore can = > not resolve anything in that domain. Using options "max-udp-size 512" = > and "edns-udp-size 512" does not solve the problem. > > The following are the what I captured. Anyone have any suggestions to = > solve the problem? =20 > > Shaoquan Lin This is really a DNS protocol bug. Glue is not optional when returning a referral and failure to add glue should result in "tc" being set. Note: named should set "tc" in the case to work around this protocol bug. It's useful to have a real life example rather than a contrived example. 2784. [bug] TC was not always being set when required glue was dropped. [RT #20655] 1804. [bug] Ensure that if we are queried for glue that it fits in the additional section or TC is set to tell the client to retry using TCP. [RT #10114] > BIND 9.3 query: > Domain Name System (query) > > Transaction ID: 0x94ca > > Flags: 0x0000 (Standard query) > > 0... .... .... .... =3D Response: Message is a query > > .000 0... .... .... =3D Opcode: Standard query (0) > > .... ..0. .... .... =3D Truncated: Message is not truncated > > .... ...0 .... .... =3D Recursion desired: Don't do query recursively > > .... .... .0.. .... =3D Z: reserved (0) > > .... .... ...0 .... =3D Non-authenticated data OK: Non-authenticated = > data is unacceptable > > Questions: 1 > > Answer RRs: 0 > > Authority RRs: 0 > > Additional RRs: 0 > > Queries > > vwall4a.nyc.gov: type A, class IN > > Name: vwall4a.nyc.gov > > Type: A (Host address) > > Class: IN (0x0001) > > BIND 9.3 response: > > Domain Name System (response) > > Transaction ID: 0x94ca > > Flags: 0x8000 (Standard query response, No error) > > 1... .... .... .... =3D Response: Message is a response > > .000 0... .... .... =3D Opcode: Standard query (0) > > .... .0.. .... .... =3D Authoritative: Server is not an authority for = > domain > > .... ..0. .... .... =3D Truncated: Message is not truncated > > .... ...0 .... .... =3D Recursion desired: Don't do query recursively > > .... .... 0... .... =3D Recursion available: Server can't do recursive = > queries > > .... .... .0.. .... =3D Z: reserved (0) > > .... .... ..0. .... =3D Answer authenticated: Answer/authority portion = > was not authenticated by the server > > .... .... .... 0000 =3D Reply code: No error (0) > > Questions: 1 > > Answer RRs: 0 > > Authority RRs: 4 > > Additional RRs: 4 > > Queries > > vwall4a.nyc.gov: type A, class IN > > Name: vwall4a.nyc.gov > > Type: A (Host address) > > Class: IN (0x0001) > > Authoritative nameservers > > nyc.gov: type NS, class IN, ns vwall1a.nyc.gov > > Name: nyc.gov > > Type: NS (Authoritative name server) > > Class: IN (0x0001) > > Time to live: 1 day > > Data length: 10 > > Name server: vwall1a.nyc.gov > > nyc.gov: type NS, class IN, ns vwall2a.nyc.gov > > Name: nyc.gov > > Type: NS (Authoritative name server) > > Class: IN (0x0001) > > Time to live: 1 day > > Data length: 10 > > Name server: vwall2a.nyc.gov > > nyc.gov: type NS, class IN, ns vwall3a.nyc.gov > > Name: nyc.gov > > Type: NS (Authoritative name server) > > Class: IN (0x0001) > > Time to live: 1 day > > Data length: 10 > > Name server: vwall3a.nyc.gov > > nyc.gov: type NS, class IN, ns vwall4a.nyc.gov > > Name: nyc.gov > > Type: NS (Authoritative name server) > > Class: IN (0x0001) > > Time to live: 1 day > > Data length: 10 > > Name server: vwall4a.nyc.gov > > Additional records > > vwall1a.nyc.gov: type A, class IN, addr 161.185.1.3 > > Name: vwall1a.nyc.gov > > Type: A (Host address) > > Class: IN (0x0001) > > Time to live: 1 day > > Data length: 4 > > Addr: 161.185.1.3 > > vwall2a.nyc.gov: type A, class IN, addr 161.185.1.12 > > Name: vwall2a.nyc.gov > > Type: A (Host address) > > Class: IN (0x0001) > > Time to live: 1 day > > Data length: 4 > > Addr: 161.185.1.12 > > vwall3a.nyc.gov: type A, class IN, addr 167.153.130.12 > > Name: vwall3a.nyc.gov > > Type: A (Host address) > > Class: IN (0x0001) > > Time to live: 1 day > > Data length: 4 > > Addr: 167.153.130.12 > > vwall4a.nyc.gov: type A, class IN, addr 167.153.130.13 > > Name: vwall4a.nyc.gov > > Type: A (Host address) > > Class: IN (0x0001) > > Time to live: 1 day > > Data length: 4 > > Addr: 167.153.130.13 > > BIND 9.6 query: > > Domain Name System (query) > > Transaction ID: 0x6427 > > Flags: 0x0000 (Standard query) > > 0... .... .... .... =3D Response: Message is a query > > .000 0... .... .... =3D Opcode: Standard query (0) > > .... ..0. .... .... =3D Truncated: Message is not truncated > > .... ...0 .... .... =3D Recursion desired: Don't do query recursively > > .... .... .0.. .... =3D Z: reserved (0) > > .... .... ...0 .... =3D Non-authenticated data OK: Non-authenticated = > data is unacceptable > > Questions: 1 > > Answer RRs: 0 > > Authority RRs: 0 > > Additional RRs: 1 > > Queries > > vwall4a.nyc.gov: type A, class IN > > Name: vwall4a.nyc.gov > > Type: A (Host address) > > Class: IN (0x0001) > > Additional records > > : type OPT > > Name: > > Type: OPT (EDNS0 option) > > UDP payload size: 512 > > Higher bits in extended RCODE: 0x0 > > EDNS0 version: 0 > > Z: 0x8000 > > Bit 0 (DO bit): 1 (Accepts DNSSEC security RRs) > > Bits 1-15: 0x0 (reserved) > > Data length: 0 > > BIND 9.6 response: > > Domain Name System (response) > > Transaction ID: 0x6427 > > Flags: 0x8000 (Standard query response, No error) > > 1... .... .... .... =3D Response: Message is a response > > .000 0... .... .... =3D Opcode: Standard query (0) > > .... .0.. .... .... =3D Authoritative: Server is not an authority for = > domain > > .... ..0. .... .... =3D Truncated: Message is not truncated > > .... ...0 .... .... =3D Recursion desired: Don't do query recursively > > .... .... 0... .... =3D Recursion available: Server can't do recursive = > queries > > .... .... .0.. .... =3D Z: reserved (0) > > .... .... ..0. .... =3D Answer authenticated: Answer/authority portion = > was not authenticated by the server > > .... .... .... 0000 =3D Reply code: No error (0) > > Questions: 1 > > Answer RRs: 0 > > Authority RRs: 6 > > Additional RRs: 1 > > Queries > > vwall4a.nyc.gov: type A, class IN > > Name: vwall4a.nyc.gov > > Type: A (Host address) > > Class: IN (0x0001) > > Authoritative nameservers > > nyc.gov: type NS, class IN, ns vwall1a.nyc.gov > > Name: nyc.gov > > Type: NS (Authoritative name server) > > Class: IN (0x0001) > > Time to live: 1 day > > Data length: 10 > > Name server: vwall1a.nyc.gov > > nyc.gov: type NS, class IN, ns vwall2a.nyc.gov > > Name: nyc.gov > > Type: NS (Authoritative name server) > > Class: IN (0x0001) > > Time to live: 1 day > > Data length: 10 > > Name server: vwall2a.nyc.gov > > nyc.gov: type NS, class IN, ns vwall3a.nyc.gov > > Name: nyc.gov > > Type: NS (Authoritative name server) > > Class: IN (0x0001) > > Time to live: 1 day > > Data length: 10 > > Name server: vwall3a.nyc.gov > > nyc.gov: type NS, class IN, ns vwall4a.nyc.gov > > Name: nyc.gov > > Type: NS (Authoritative name server) > > Class: IN (0x0001) > > Time to live: 1 day > > Data length: 10 > > Name server: vwall4a.nyc.gov > > rq2651faaj4nen6tfis8ju5005qccn8j.gov: type Unknown (50), class IN > > Name: rq2651faaj4nen6tfis8ju5005qccn8j.gov > > Type: Unknown (50) > > Class: IN (0x0001) > > Time to live: 1 day > > Data length: 35 > > Data > > rq2651faaj4nen6tfis8ju5005qccn8j.gov: type RRSIG, class IN > > Name: rq2651faaj4nen6tfis8ju5005qccn8j.gov > > Type: RRSIG (RR signature) > > Class: IN (0x0001) > > Time to live: 1 day > > Data length: 279 > > Type covered: Unknown (50) > > Algorithm: Unknown (0x07) > > Labels: 2 > > Original TTL: 1 day > > Signature expiration: Feb 22, 2011 05:00:22.000000000 > > Time signed: Feb 17, 2011 05:00:22.000000000 > > Id of signing key(footprint): 47602 > > Signer's name: gov > > Signature > > Additional records > > : type OPT > > Name: > > Type: OPT (EDNS0 option) > > UDP payload size: 1472 > > Higher bits in extended RCODE: 0x0 > > EDNS0 version: 0 > > Z: 0x0 > > Data length: 0 > > ------=_NextPart_000_0116_01CBCF84.31A5E720 > Content-Type: text/html; > charset="iso-8859-1" > Content-Transfer-Encoding: quoted-printable > > > > http-equiv=3DContent-Type> > > > > >
Ryan,
>
 
>
Have you solved your problem?  I = > have similar=20 > problems. I run BIND 9.6..1-P3 on my Solaris 10 and can not resolve = > anything in=20 > domain nyc.gov.  One thing I noticed is:  BIND 9.3 send query = > to=20 > b.gov-servers.net with no Additional records and got a response=20 > with  A records for the nyc.gov NS servers in the Additional = > records;=20 > but BIND 9.6 send query with type OPT Additional records and got a = > response with=20 > also a type OPT but no A in the Additional records.  So the BIND = > 9.6 can=20 > not find the IP addresses of the nyc.gov NS servers and therefore can = > not=20 > resolve anything in that domain.  Using options " size=3D3>max-udp-size  512" and "edns-udp-size  512"  = > does not=20 > solve the  problem.
>
 
>
The following are the what I captured.  = > Anyone have=20 > any suggestions to solve the=20 > problem?          = >
>
 
>
Shaoquan Lin
>
 
>
BIND 9.3 query:
>
>

Domain Name System (query)

>

Transaction ID: 0x94ca

>

Flags: 0x0000 (Standard query)

>

0... .... .... .... =3D Response: Message is a query

>

.000 0... .... .... =3D Opcode: Standard query (0)

>

.... ..0. .... .... =3D Truncated: Message is not truncated

>

.... ...0 .... .... =3D Recursion desired: Don't do query = > recursively

>

.... .... .0.. .... =3D Z: reserved (0)

>

.... .... ...0 .... =3D Non-authenticated data OK: Non-authenticated = > data is=20 > unacceptable

>

Questions: 1

>

Answer RRs: 0

>

Authority RRs: 0

>

Additional RRs: 0

>

Queries

>

vwall4a.nyc.gov: type A, class IN

>

Name: vwall4a.nyc.gov

>

Type: A (Host address)

>

Class: IN (0x0001)

>

BIND 9.3 response:

>

Domain Name System (response)

>

Transaction ID: 0x94ca

>

Flags: 0x8000 (Standard query response, No error)

>

1... .... .... .... =3D Response: Message is a response

>

.000 0... .... .... =3D Opcode: Standard query (0)

>

.... .0.. .... .... =3D Authoritative: Server is not an authority for = > > domain

>

.... ..0. .... .... =3D Truncated: Message is not truncated

>

.... ...0 .... .... =3D Recursion desired: Don't do query = > recursively

>

.... .... 0... .... =3D Recursion available: Server can't do = > recursive=20 > queries

>

.... .... .0.. .... =3D Z: reserved (0)

>

.... .... ..0. .... =3D Answer authenticated: Answer/authority = > portion was not=20 > authenticated by the server

>

.... .... .... 0000 =3D Reply code: No error (0)

>

Questions: 1

>

Answer RRs: 0

>

Authority RRs: 4

>

Additional RRs: 4

>

Queries

>

vwall4a.nyc.gov: type A, class IN

>

Name: vwall4a.nyc.gov

>

Type: A (Host address)

>

Class: IN (0x0001)

>

Authoritative nameservers

>

nyc.gov: type NS, class IN, ns vwall1a.nyc.gov

>

Name: nyc.gov

>

Type: NS (Authoritative name server)

>

Class: IN (0x0001)

>

Time to live: 1 day

>

Data length: 10

>

Name server: vwall1a.nyc.gov

>

nyc.gov: type NS, class IN, ns vwall2a.nyc.gov

>

Name: nyc.gov

>

Type: NS (Authoritative name server)

>

Class: IN (0x0001)

>

Time to live: 1 day

>

Data length: 10

>

Name server: vwall2a.nyc.gov

>

nyc.gov: type NS, class IN, ns vwall3a.nyc.gov

>

Name: nyc.gov

>

Type: NS (Authoritative name server)

>

Class: IN (0x0001)

>

Time to live: 1 day

>

Data length: 10

>

Name server: vwall3a.nyc.gov

>

nyc.gov: type NS, class IN, ns vwall4a.nyc.gov

>

Name: nyc.gov

>

Type: NS (Authoritative name server)

>

Class: IN (0x0001)

>

Time to live: 1 day

>

Data length: 10

>

Name server: vwall4a.nyc.gov

>

Additional records

>

vwall1a.nyc.gov: type A, class IN, addr 161.185.1.3

>

Name: vwall1a.nyc.gov

>

Type: A (Host address)

>

Class: IN (0x0001)

>

Time to live: 1 day

>

Data length: 4

>

Addr: 161.185.1.3

>

vwall2a.nyc.gov: type A, class IN, addr 161.185.1.12

>

Name: vwall2a.nyc.gov

>

Type: A (Host address)

>

Class: IN (0x0001)

>

Time to live: 1 day

>

Data length: 4

>

Addr: 161.185.1.12

>

vwall3a.nyc.gov: type A, class IN, addr 167.153.130.12

>

Name: vwall3a.nyc.gov

>

Type: A (Host address)

>

Class: IN (0x0001)

>

Time to live: 1 day

>

Data length: 4

>

Addr: 167.153.130.12

>

vwall4a.nyc.gov: type A, class IN, addr 167.153.130.13

>

Name: vwall4a.nyc.gov

>

Type: A (Host address)

>

Class: IN (0x0001)

>

Time to live: 1 day

>

Data length: 4

>

Addr: 167.153.130.13

>
BIND 9.6 query:
>
 
>
>

Domain Name System (query)

>

Transaction ID: 0x6427

>

Flags: 0x0000 (Standard query)

>

0... .... .... .... =3D Response: Message is a query

>

.000 0... .... .... =3D Opcode: Standard query (0)

>

.... ..0. .... .... =3D Truncated: Message is not truncated

>

.... ...0 .... .... =3D Recursion desired: Don't do query = > recursively

>

.... .... .0.. .... =3D Z: reserved (0)

>

.... .... ...0 .... =3D Non-authenticated data OK: Non-authenticated = > data is=20 > unacceptable

>

Questions: 1

>

Answer RRs: 0

>

Authority RRs: 0

>

Additional RRs: 1

>

Queries

>

vwall4a.nyc.gov: type A, class IN

>

Name: vwall4a.nyc.gov

>

Type: A (Host address)

>

Class: IN (0x0001)

>

Additional records

>

<Root>: type OPT

>

Name: <Root>

>

Type: OPT (EDNS0 option)

>

UDP payload size: 512

>

Higher bits in extended RCODE: 0x0

>

EDNS0 version: 0

>

Z: 0x8000

>

Bit 0 (DO bit): 1 (Accepts DNSSEC security RRs)

>

Bits 1-15: 0x0 (reserved)

>

Data length: 0

>

BIND 9.6 response:

>

Domain Name System (response)

>

Transaction ID: 0x6427

>

Flags: 0x8000 (Standard query response, No error)

>

1... .... .... .... =3D Response: Message is a response

>

.000 0... .... .... =3D Opcode: Standard query (0)

>

.... .0.. .... .... =3D Authoritative: Server is not an authority for = > > domain

>

.... ..0. .... .... =3D Truncated: Message is not truncated

>

.... ...0 .... .... =3D Recursion desired: Don't do query = > recursively

>

.... .... 0... .... =3D Recursion available: Server can't do = > recursive=20 > queries

>

.... .... .0.. .... =3D Z: reserved (0)

>

.... .... ..0. .... =3D Answer authenticated: Answer/authority = > portion was not=20 > authenticated by the server

>

.... .... .... 0000 =3D Reply code: No error (0)

>

Questions: 1

>

Answer RRs: 0

>

Authority RRs: 6

>

Additional RRs: 1

>

Queries

>

vwall4a.nyc.gov: type A, class IN

>

Name: vwall4a.nyc.gov

>

Type: A (Host address)

>

Class: IN (0x0001)

>

Authoritative nameservers

>

nyc.gov: type NS, class IN, ns vwall1a.nyc.gov

>

Name: nyc.gov

>

Type: NS (Authoritative name server)

>

Class: IN (0x0001)

>

Time to live: 1 day

>

Data length: 10

>

Name server: vwall1a.nyc.gov

>

nyc.gov: type NS, class IN, ns vwall2a.nyc.gov

>

Name: nyc.gov

>

Type: NS (Authoritative name server)

>

Class: IN (0x0001)

>

Time to live: 1 day

>

Data length: 10

>

Name server: vwall2a.nyc.gov

>

nyc.gov: type NS, class IN, ns vwall3a.nyc.gov

>

Name: nyc.gov

>

Type: NS (Authoritative name server)

>

Class: IN (0x0001)

>

Time to live: 1 day

>

Data length: 10

>

Name server: vwall3a.nyc.gov

>

nyc.gov: type NS, class IN, ns vwall4a.nyc.gov

>

Name: nyc.gov

>

Type: NS (Authoritative name server)

>

Class: IN (0x0001)

>

Time to live: 1 day

>

Data length: 10

>

Name server: vwall4a.nyc.gov

>

rq2651faaj4nen6tfis8ju5005qccn8j.gov: type Unknown (50), class IN

>

Name: rq2651faaj4nen6tfis8ju5005qccn8j.gov

>

Type: Unknown (50)

>

Class: IN (0x0001)

>

Time to live: 1 day

>

Data length: 35

>

Data

>

rq2651faaj4nen6tfis8ju5005qccn8j.gov: type RRSIG, class IN

>

Name: rq2651faaj4nen6tfis8ju5005qccn8j.gov

>

Type: RRSIG (RR signature)

>

Class: IN (0x0001)

>

Time to live: 1 day

>

Data length: 279

>

Type covered: Unknown (50)

>

Algorithm: Unknown (0x07)

>

Labels: 2

>

Original TTL: 1 day

>

Signature expiration: Feb 22, 2011 05:00:22.000000000

>

Time signed: Feb 17, 2011 05:00:22.000000000

>

Id of signing key(footprint): 47602

>

Signer's name: gov

>

Signature

>

Additional records

>

<Root>: type OPT

>

Name: <Root>

>

Type: OPT (EDNS0 option)

>

UDP payload size: 1472

>

Higher bits in extended RCODE: 0x0

>

EDNS0 version: 0

>

Z: 0x0

>

Data length: 0

> > ------=_NextPart_000_0116_01CBCF84.31A5E720-- > > > > --===============7478579667512691322== > Content-Type: text/plain; charset="us-ascii" > MIME-Version: 1.0 > Content-Transfer-Encoding: 7bit > Content-Disposition: inline > > _______________________________________________ > bind-users mailing list > bind-users@lists.isc.org > https://lists.isc.org/mailman/listinfo/bind-users > --===============7478579667512691322==-- > > - -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org ------- End of Blind-Carbon-Copy From mgraff@isc.org Mon Feb 21 08:55:12 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AC0663A7135 for ; Mon, 21 Feb 2011 08:55:12 -0800 (PST) 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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6pklj-qudABt for ; Mon, 21 Feb 2011 08:55:11 -0800 (PST) Received: from mx.ams1.isc.org (mx.ams1.isc.org [IPv6:2001:500:60::65]) by core3.amsl.com (Postfix) with ESMTP id 642943A6DC6 for ; Mon, 21 Feb 2011 08:55:07 -0800 (PST) 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 802005F98F3 for ; Mon, 21 Feb 2011 16:55:35 +0000 (UTC) (envelope-from mgraff@isc.org) Received: from WhiteDragon.local (173-27-162-196.client.mchsi.com [173.27.162.196]) (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 33AA1216C31 for ; Mon, 21 Feb 2011 16:55:32 +0000 (UTC) (envelope-from mgraff@isc.org) Message-ID: <4D629903.1020605@isc.org> Date: Mon, 21 Feb 2011 10:55:31 -0600 From: Michael Graff User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: dnsext@ietf.org References: <20110219210716.72943A5602B@drugs.dv.isc.org> <11263.1298150425@nsa.vix.com> <20110220072916.GA3505@vacation.karoshi.com.> <30899A4A-833B-42EF-9850-AFEE8B8DBE02@dotat.at> In-Reply-To: X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [dnsext] zone cut semantics X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 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, 21 Feb 2011 16:55:12 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 2/20/11 2:44 PM, Jim Reid wrote: > Please think again about what you posted. The inference of what you say > is that the root servers are authoritative for everything. That's > clearly not true. Actually, I think he's right technically, but not operationally. The root could return an auth answer for www.example.com if it wanted to, and AFAIK resolvers would and should believe it. It's a matter of policy and current use that we don't do that in the root. - --Michael -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJNYpkCAAoJEDRzoY2A7tzbWGEH/iuQqTSbzclUjSGL1xKv0Ulo uxHWQ7DrywTo3OT4CWbIMHlokIRtuX4qACcuG0LR3BSDuucgS57bYXNk961mjyPk HVoRm+cQgnVz7peAXfRv38p5z3kmTFoup+9T3L8xyIX3sL7KkJR4xRkqfcMH9gie di61qZDqQ3QLm72qkanAuIPt+PKV3zRx1ny18Px3znvuU79P3TqoqsliesJg0W+v znFuauOmfy4h05s/Jpbu60CUb1yifr2UFNd7E87yP6iLfH3B45JwXPLOzFVvO/7S eC0GBT9eBMsKkKMacQlwnebYhxUTUFa+kkMvuAVuZDKXQhtSfheGTDOIBB4zvps= =EYI8 -----END PGP SIGNATURE----- From jabley@hopcount.ca Mon Feb 21 10:31:45 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DC9973A7146 for ; Mon, 21 Feb 2011 10:31:45 -0800 (PST) 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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fkV4K2HkwrYk for ; Mon, 21 Feb 2011 10:31:43 -0800 (PST) Received: from monster.hopcount.ca (monster.hopcount.ca [216.235.14.38]) by core3.amsl.com (Postfix) with ESMTP id B95053A6E38 for ; Mon, 21 Feb 2011 10:31:43 -0800 (PST) Received: from [2001:4900:1042:100:5a55:caff:feec:96bf] by monster.hopcount.ca with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.71 (FreeBSD)) (envelope-from ) id 1PraWl-000JdG-J2; Mon, 21 Feb 2011 18:30:32 +0000 Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Joe Abley In-Reply-To: <4AAEDEAF-AE3B-48D0-92AC-7C86538BF54E@rfc1035.com> Date: Mon, 21 Feb 2011 13:30:29 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <49C053D9-EB2E-40EF-AF16-0F9319171B8E@hopcount.ca> References: <20110219210716.72943A5602B@drugs.dv.isc.org> <11263.1298150425@nsa.vix.com> <20110220072916.GA3505@vacation.karoshi.com.> <30899A4A-833B-42EF-9850-AFEE8B8DBE02@dotat.at> <4AAEDEAF-AE3B-48D0-92AC-7C86538BF54E@rfc1035.com> To: Jim Reid X-Mailer: Apple Mail (2.1082) X-SA-Exim-Connect-IP: 2001:4900:1042:100:5a55:caff:feec:96bf X-SA-Exim-Mail-From: jabley@hopcount.ca X-SA-Exim-Scanned: No (on monster.hopcount.ca); SAEximRunCond expanded to false Cc: "bmanning@vacation.karoshi.com" , "dnsext@ietf.org" Subject: Re: [dnsext] zone cut semantics X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 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, 21 Feb 2011 18:31:46 -0000 On 2011-02-20, at 21:43, Jim Reid wrote: > *Well, OK, they also authoritatively serve root-servers.net. ... and ARPA (except J) and IN-ADDR.ARPA (except J, M, for another = couple of weeks). Joe= From anicoll@cert.org Mon Feb 21 10:53:13 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5797D3A6E40 for ; Mon, 21 Feb 2011 10:53:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id McuG6LogUGim for ; Mon, 21 Feb 2011 10:53:10 -0800 (PST) Received: from shetland.sei.cmu.edu (shetland.sei.cmu.edu [192.58.107.44]) by core3.amsl.com (Postfix) with ESMTP id 565F43A6E38 for ; Mon, 21 Feb 2011 10:53:10 -0800 (PST) Received: from pawpaw.sei.cmu.edu (pawpaw.sei.cmu.edu [10.64.21.22]) by shetland.sei.cmu.edu (8.13.8/8.13.8/1294) with ESMTP id p1LIrqlv009776 for ; Mon, 21 Feb 2011 13:53:52 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cert.org; s=jthatj15xw2j; t=1298314432; bh=4yoqlM16WLM8Eqp7VmJFs1bb11BrRdzTB/AM4N1afM4=; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version:Sender: Reply-To:Cc:In-Reply-To:References; b=MYAs677yXZnbvY+IGCX80O4UOOOoTFhM7NewPh2+wn3dljWdv3c3DhHjHDImOqeVJ WQvoEz864DuVBztc6RGohyv57Dv1IIkMjDhPRMy8BP9oHBQocWvQoszDCNnBDTFmp7 bDL762Qi3w6++16TT98D3LTvG3yXSsz1ywWFUUOg= Received: from owa.sei.cmu.edu (tyranus.sei.cmu.edu [10.64.28.15]) by pawpaw.sei.cmu.edu (8.13.8/8.13.8/1348) with ESMTP id p1LIrqSp023018 for ; Mon, 21 Feb 2011 13:53:52 -0500 Received: from EXCHANGE.sei.cmu.edu ([10.64.28.13]) by tyranus.sei.cmu.edu ([10.64.28.15]) with mapi; Mon, 21 Feb 2011 13:53:52 -0500 From: Alex Nicoll To: "dnsext@ietf.org" Date: Mon, 21 Feb 2011 13:53:51 -0500 Thread-Topic: DNSEXT in Prague? Thread-Index: AcvR+K4pXjxOg1xOQZGG8OKGrIFzHA== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_A32A045574615B4FAB96C4952BA5768BB7725E6F78EXCHANGEseicm_" MIME-Version: 1.0 Subject: [dnsext] DNSEXT in Prague? X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 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, 21 Feb 2011 18:53:13 -0000 --_000_A32A045574615B4FAB96C4952BA5768BB7725E6F78EXCHANGEseicm_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I'm sorry if I missed an official announcement somewhere along the lines, b= ut will there be a DNSEXT working group meeting in Prague during IETF80? -Alex Alex Nicoll Senior Cybersecurity Analyst CERT Carnegie Mellon University/Software Engineering Institute anicoll@cert.org (412)268-9205 (USA) --_000_A32A045574615B4FAB96C4952BA5768BB7725E6F78EXCHANGEseicm_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I’m sorry = if I missed an official announcement somewhere along the lines, but will th= ere be a DNSEXT working group meeting in Prague during IETF80?

 

-Alex=

 

Al= ex Nicoll

Senior Cybersecurity Analyst <= o:p>

CERT

= Carnegie Mellon University/Software Engineering Institute

anicoll@cert.org<= o:p>

(412)268-9205 (USA)

 

= --_000_A32A045574615B4FAB96C4952BA5768BB7725E6F78EXCHANGEseicm_-- From ajs@shinkuro.com Mon Feb 21 10:57:18 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4C3983A6F02 for ; Mon, 21 Feb 2011 10:57:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.58 X-Spam-Level: X-Spam-Status: No, score=-102.58 tagged_above=-999 required=5 tests=[AWL=0.019, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E5zKpFPgeccn for ; Mon, 21 Feb 2011 10:57:17 -0800 (PST) Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by core3.amsl.com (Postfix) with ESMTP id 6F4433A6E38 for ; Mon, 21 Feb 2011 10:57:17 -0800 (PST) Received: from crankycanuck.ca (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 418AD1ECB408 for ; Mon, 21 Feb 2011 18:57:59 +0000 (UTC) Date: Mon, 21 Feb 2011 13:57:57 -0500 From: Andrew Sullivan To: dnsext@ietf.org Message-ID: <20110221185757.GO32224@shinkuro.com> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.18 (2008-05-17) Subject: Re: [dnsext] DNSEXT in Prague? X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 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, 21 Feb 2011 18:57:18 -0000 On Mon, Feb 21, 2011 at 01:53:51PM -0500, Alex Nicoll wrote: > I'm sorry if I missed an official announcement somewhere along the lines, but will there be a DNSEXT working group meeting in Prague during IETF80? We haven't made an official announcement, but given the discussion that emerged on the list about aliasing after Olafur posted our plans not to have a meeting, we did decide we needed a slot. We requested one hour. We don't know when it will be, of course. A -- Andrew Sullivan ajs@shinkuro.com Shinkuro, Inc. From davidb@verisign.com Mon Feb 21 10:57:52 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1D5553A7160 for ; Mon, 21 Feb 2011 10:57:52 -0800 (PST) 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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q538n05H8idq for ; Mon, 21 Feb 2011 10:57:51 -0800 (PST) Received: from exprod6og107.obsmtp.com (exprod6og107.obsmtp.com [64.18.1.208]) by core3.amsl.com (Postfix) with ESMTP id 61EFC3A7159 for ; Mon, 21 Feb 2011 10:57:47 -0800 (PST) Received: from source ([216.168.239.75]) (using TLSv1) by exprod6ob107.postini.com ([64.18.5.12]) with SMTP ID DSNKTWK11cbU01jl5lycJrWXO9+UWRDxklpi@postini.com; Mon, 21 Feb 2011 10:58:32 PST Received: from dul1wnexcn03.vcorp.ad.vrsn.com (dul1wnexcn03.vcorp.ad.vrsn.com [10.170.12.113]) by osprey.verisign.com (8.13.6/8.13.4) with ESMTP id p1LIwS9G010996; Mon, 21 Feb 2011 13:58:28 -0500 Received: from dul1dblacka-m2.vcorp.ad.vrsn.com ([10.100.0.67]) by dul1wnexcn03.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 21 Feb 2011 13:58:27 -0500 Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: David Blacka In-Reply-To: <4D622624.90303@ogud.com> Date: Mon, 21 Feb 2011 13:58:27 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4D622624.90303@ogud.com> To: Olafur Gudmundsson X-Mailer: Apple Mail (2.1082) X-OriginalArrivalTime: 21 Feb 2011 18:58:28.0059 (UTC) FILETIME=[530CA2B0:01CBD1F9] Cc: dnsext@ietf.org Subject: Re: [dnsext] WG opinion on draft : Improvements to DNS Resolvers, for Resiliency, Robustness, and Responsiveness X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 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, 21 Feb 2011 18:57:52 -0000 On Feb 21, 2011, at 3:45 AM, Olafur Gudmundsson wrote: >=20 > The chairs have received a request to Last call this draft. > http://tools.ietf.org/html/draft-vixie-dnsext-resimprove-00 >=20 > This draft is clearly in scope of the Working Group. >=20 > As there has not been much discussion on this draft the chairs are > not ready at this point to start a Last Call but would like to get a = sense of the working group participants' feelings on the draft. I was not aware of this draft's existence until now, but I just read it. >=20 > The draft is aimed at BCP status; thus there is no RFC2119 language in = the draft. >=20 > Background: The draft contains three recommendation on how resolvers = operate, > A. Re-validating a delegation when a parent NS RRset TTL expires. > B. Stopping a downward cache search when an NXDOMAIN is = encountered. > C. Upgrading the credibility of NS RRsets upon delegation event. >=20 > All of these have been suggested in various forms over the years. >=20 > Following opinions are sought: > 1. Are the suggestions in the draft something people think is a good > idea? I'm unsure, although I'm leaning toward thinking that they are not good = ideas. (A) is (I think) trying to solve issues caused by "cache pinning" when = moving a zone from one set of nameservers to another. Actually, it goes = further than that (if I understand the draft correctly, which I very = well may not) by effectively removing entire delegation chains when the = ancestor NS RRset expires. So, e.g., every time the com NS RRset = expires, all delegations below it effectively expire. I have no idea = what problem this overall behavior solves, although I suspect that it = defeats a great deal of the value of a cache. (B) is about having resolvers actually believe NXDOMAIN responses. = While I think it might be nice if we could trust that NXDOMAIN actually = meant that the name didn't exist, I don't see how this improves the = "resiliency" or "robustness" of the *resolver*. (C) is about working around delegation scenarios that favor parent-side = delegation information by instructing the resolver to directly query the = child nameservers for NS records. I don't know what actual problem this = is attempting to solve. > 2. Is the draft clear in its message? If not, please suggest = improvements. It is entirely unclear to me what problems the various proposals are = actually trying to solve. > 3. After (if any) editing fixes is this draft ready for WG Last Call? Not in my opinion. I don't think the ideas are clearly BCPs. >=20 > Olafur and Andrew > _______________________________________________ > dnsext mailing list > dnsext@ietf.org > https://www.ietf.org/mailman/listinfo/dnsext -- David Blacka =20 Principal Engineer Verisign Platform Product Development From woolf@isc.org Mon Feb 21 11:19:27 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EFD733A714D for ; Mon, 21 Feb 2011 11:19:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.85 X-Spam-Level: X-Spam-Status: No, score=-2.85 tagged_above=-999 required=5 tests=[AWL=-0.250, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r-RtFsRBkxGo for ; Mon, 21 Feb 2011 11:19:27 -0800 (PST) Received: from mx.ams1.isc.org (mx.ams1.isc.org [IPv6:2001:500:60::65]) by core3.amsl.com (Postfix) with ESMTP id A45913A7138 for ; Mon, 21 Feb 2011 11:19:26 -0800 (PST) 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 24D0E5F98B6; Mon, 21 Feb 2011 19:19:54 +0000 (UTC) (envelope-from woolf@isc.org) Received: by bikeshed.isc.org (Postfix, from userid 10265) id 9B3BC216C31; Mon, 21 Feb 2011 19:19:52 +0000 (UTC) Date: Mon, 21 Feb 2011 19:19:52 +0000 From: Suzanne Woolf To: Andrew Sullivan Message-ID: <20110221191952.GA64744@bikeshed.isc.org> References: <20110221185757.GO32224@shinkuro.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20110221185757.GO32224@shinkuro.com> User-Agent: Mutt/1.4.2.3i Cc: dnsext@ietf.org Subject: Re: [dnsext] DNSEXT in Prague? X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 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, 21 Feb 2011 19:19:28 -0000 On Mon, Feb 21, 2011 at 01:57:57PM -0500, Andrew Sullivan wrote: > On Mon, Feb 21, 2011 at 01:53:51PM -0500, Alex Nicoll wrote: > > I'm sorry if I missed an official announcement somewhere along the lines, but will there be a DNSEXT working group meeting in Prague during IETF80? > > We haven't made an official announcement, but given the discussion > that emerged on the list about aliasing after Olafur posted our plans > not to have a meeting, we did decide we needed a slot. We requested > one hour. The -00 of the problem statement draft for the "aliases" work item will post in the next day or two. Suzanne From anicoll@cert.org Mon Feb 21 11:28:29 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 73DC53A714B for ; Mon, 21 Feb 2011 11:28:29 -0800 (PST) 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=[AWL=0.001, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZRqB9wCal4Br for ; Mon, 21 Feb 2011 11:28:28 -0800 (PST) Received: from plainfield.sei.cmu.edu (plainfield.sei.cmu.edu [192.58.107.45]) by core3.amsl.com (Postfix) with ESMTP id 00DFB3A6F77 for ; Mon, 21 Feb 2011 11:28:27 -0800 (PST) Received: from pawpaw.sei.cmu.edu (pawpaw.sei.cmu.edu [10.64.21.22]) by plainfield.sei.cmu.edu (8.13.8/8.13.8/1294) with ESMTP id p1LJT6lJ019104; Mon, 21 Feb 2011 14:29:06 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cert.org; s=jthatj15xw2j; t=1298316546; bh=5AD9LkPWHOTc33bqeEcgev+6gC+p/APKL4vUxiLO0xw=; h=From:To:CC:Date:Subject:Message-ID:References:In-Reply-To: Content-Type:Content-Transfer-Encoding:MIME-Version:Sender: Reply-To; b=lj5GTjMfjxXqwRi/1HP9aGFygb7qgn1yCo/tX7i1GmEavoZgzaRxLRAYDcVEqdYkz RKvu+OhgXZ4Y3HEQgRW08OLAtSFHtkD5GYrz1g3QfFfFdCM1W3lGuySlm0eHqUirRX Hf5aqMYJOAouubvax4zdhyxogVBxy4HedGHw1rsc= Received: from owa.sei.cmu.edu (tyranus.sei.cmu.edu [10.64.28.15]) by pawpaw.sei.cmu.edu (8.13.8/8.13.8/1348) with ESMTP id p1LJT5dD025898; Mon, 21 Feb 2011 14:29:05 -0500 Received: from EXCHANGE.sei.cmu.edu ([10.64.28.13]) by tyranus.sei.cmu.edu ([10.64.28.15]) with mapi; Mon, 21 Feb 2011 14:29:06 -0500 From: Alex Nicoll To: Suzanne Woolf , Andrew Sullivan Date: Mon, 21 Feb 2011 14:29:05 -0500 Thread-Topic: [dnsext] DNSEXT in Prague? Thread-Index: AcvR/F0zG4Vhgv0pRD+Xif4N3rU07gAANHew Message-ID: References: <20110221185757.GO32224@shinkuro.com> <20110221191952.GA64744@bikeshed.isc.org> In-Reply-To: <20110221191952.GA64744@bikeshed.isc.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "dnsext@ietf.org" Subject: Re: [dnsext] DNSEXT in Prague? X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 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, 21 Feb 2011 19:28:30 -0000 Thanks Andy and Suzanne! I'm trying to decide if I should attend or not, and since I've sort of adop= ted DNSEXT as my haunt of choice, that's a big factor. It's not easy convi= ncing any employer to pay for a trip to Prague! Since there is not an agen= da online yet, are there other DNS/DNSSEC related bits of fun to be had tha= t you know of? (Or high assurance operating systems?) Thanks! -Alex -----Original Message----- From: dnsext-bounces@ietf.org [mailto:dnsext-bounces@ietf.org] On Behalf Of= Suzanne Woolf Sent: Monday, February 21, 2011 2:20 PM To: Andrew Sullivan Cc: dnsext@ietf.org Subject: Re: [dnsext] DNSEXT in Prague? On Mon, Feb 21, 2011 at 01:57:57PM -0500, Andrew Sullivan wrote: > On Mon, Feb 21, 2011 at 01:53:51PM -0500, Alex Nicoll wrote: > > I'm sorry if I missed an official announcement somewhere along the line= s, but will there be a DNSEXT working group meeting in Prague during IETF80= ? >=20 > We haven't made an official announcement, but given the discussion=20 > that emerged on the list about aliasing after Olafur posted our plans=20 > not to have a meeting, we did decide we needed a slot. We requested=20 > one hour. The -00 of the problem statement draft for the "aliases" work item will pos= t in the next day or two. Suzanne _______________________________________________ dnsext mailing list dnsext@ietf.org https://www.ietf.org/mailman/listinfo/dnsext From brian.peter.dickson@gmail.com Mon Feb 21 11:52:12 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ECA503A716D for ; Mon, 21 Feb 2011 11:52:11 -0800 (PST) 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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gsGzx-3xKCD5 for ; Mon, 21 Feb 2011 11:52:09 -0800 (PST) Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by core3.amsl.com (Postfix) with ESMTP id 2B2D03A6E67 for ; Mon, 21 Feb 2011 11:52:09 -0800 (PST) Received: by fxm15 with SMTP id 15so2859501fxm.31 for ; Mon, 21 Feb 2011 11:52:51 -0800 (PST) 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=bAmKdKGFwvDG98+6hpbK43Q7Deq7jV7udXRYwJFkX5M=; b=lwxZEADD74FKrb1czjKG2n8EDp2D3z2nuwd0Tz2j0dQYYKfmFvWBAw48p349mS3zry 63L4ZSdhAmzCbCl8P+HN7IejL9pVAfrCQRk9Wy/6XUVK2755YbZEisyLIAM7FtehrQhh WbMSCwq6Orettx6QtO2DoKHlXLGYDQgF+Y1Ok= 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=c4P3OsqtzKF+qM/yXM/iCALlGLVUaCNa/TJje0QsmBhkijhKb39ovpiu0EuWLS0XGA L7VNGjH5orl7IEEmHg8vKhA7aNqeacU6z3n/fLZNaWKyW5HZNbQMtup1iZSkD39Io6rM BHE32MIsfEvOQD+YynXf6HFWr0HWyzFT+PZ8c= MIME-Version: 1.0 Received: by 10.223.73.202 with SMTP id r10mr2465729faj.133.1298317880845; Mon, 21 Feb 2011 11:51:20 -0800 (PST) Received: by 10.223.107.132 with HTTP; Mon, 21 Feb 2011 11:51:20 -0800 (PST) In-Reply-To: References: <4D622624.90303@ogud.com> Date: Mon, 21 Feb 2011 15:51:20 -0400 Message-ID: From: Brian Dickson To: David Blacka Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: dnsext@ietf.org, Olafur Gudmundsson Subject: Re: [dnsext] WG opinion on draft : Improvements to DNS Resolvers, for Resiliency, Robustness, and Responsiveness X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 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, 21 Feb 2011 19:52:12 -0000 I have read the draft, and also David's comments, and have comments of my own in-line below. Briefly, however, I'd say: - the things in the draft are all good ideas - the draft is good, should be adopted, requires only a small amount of work, and once that is done, is probably fine for WGLC. - s few clarifications will go a long way to addressing both David's issues, and making the document useful - all of the above are "IMIHO" See below for in-line comments. Brian On Mon, Feb 21, 2011 at 2:58 PM, David Blacka wrote: > > On Feb 21, 2011, at 3:45 AM, Olafur Gudmundsson wrote: > >> >> The chairs have received a request to Last call this draft. >> http://tools.ietf.org/html/draft-vixie-dnsext-resimprove-00 >> >> This draft is clearly in scope of the Working Group. >> >> As there has not been much discussion on this draft the chairs are >> not ready at this point to start a Last Call but would like to get a sen= se of the working group participants' feelings on the draft. > > I was not aware of this draft's existence until now, but I just read it. > >> >> The draft is aimed at BCP status; thus there is no RFC2119 language in t= he draft. >> >> Background: The draft contains three recommendation on how resolvers ope= rate, >> =A0 =A0A. Re-validating a delegation when a parent NS RRset TTL expires. >> =A0 =A0B. Stopping a downward cache search when an NXDOMAIN is encounter= ed. >> =A0 =A0C. Upgrading the credibility of NS RRsets upon delegation event. >> >> All of these have been suggested in various forms over the years. >> >> Following opinions are sought: >> 1. Are the suggestions in the draft something people think is a good >> =A0 idea? > > I'm unsure, although I'm leaning toward thinking that they are not good i= deas. > > (A) is (I think) trying to solve issues caused by "cache pinning" when mo= ving a zone from one set of nameservers to another. =A0Actually, it goes fu= rther than that (if I understand the draft correctly, which I very well may= not) by effectively removing entire delegation chains when the ancestor NS= RRset expires. =A0So, e.g., every time the com NS RRset expires, all deleg= ations below it effectively expire. =A0I have no idea what problem this ove= rall behavior solves, although I suspect that it defeats a great deal of th= e value of a cache. My read on the draft, and I'm reasonably confident it's what the author intended, is that "stale" delegations be "refreshed" (or have a "refresh" attempted) before they are used. It is analogous to the "refresh" between master and slave authority servers for a given zone, e.g. verifying the SOA SN if the "refresh" timer fires off. And, basically, the "refresh" is to make sure the delegation (non-authoritative) NS records are "reasonably consistent" with what was already cached, and if so, re-establishes the validity, re-sets the TTL, and re-populates the NS set if some changes have occurred. No expiration occurs, unless both (a) the TTL expires, and (b) the new delegation NS RRSET has nothing in common with the cached RRset - in which case, the child side and all descendants MUST be discarded. It actually is better than blindly discarding the children, which I think might have to happen currently. Only if the delegation points elsewhere, when the TTL expires, do the children need to be discarded. > > (B) is about having resolvers actually believe NXDOMAIN responses. =A0Whi= le I think it might be nice if we could trust that NXDOMAIN actually meant = that the name didn't exist, I don't see how this improves the "resiliency" = or "robustness" of the *resolver*. This is one place where I think some updates to the ID need to be done. Basically, we need a reference (i.e. to RFCs in standard I-D style) to the changes to the standard(s) that differentiate 1034's "Name Error" from the two cases we now know about, "NXDOMAIN", and "empty non-terminal" (a node with no RRs itself, which has descendants, inside a zone). If I understand it, things should now work as follows: - if an empty non-terminal matches a QNAME, the *answer* should be empty, but there should *not* be any error code. - if no domain exists (and that means neither the domain nor any children exist), there *should* be an error code of NXDOMAIN And, given the logic immediate above, this means that NXDOMAIN can and should be cached (if and only if the above applies), and when an NXDOMAIN is cached, children of that node get discarded, and subsequent queries to the *resolver* below that NXDOMAIN can themselves be guaranteed to be NXDOMAINed, and there is no need to send the query to the authority server for the given zone. But, this should be clarified in the text of the draft. I agree that it is a suitable optimization, and as I understand it, correct behavior. > > (C) is about working around delegation scenarios that favor parent-side d= elegation information by instructing the resolver to directly query the chi= ld nameservers for NS records. =A0I don't know what actual problem this is = attempting to solve. I *believe* it is working around situations where different implementations of authority server have interpreted existing RFCs differently, and arguably both interpretations are technically correct. And, that it is also always preferable to have the most authoritative (correct) NS data in the cache, even if it wasn't returned in the authority section of the authority server. I believe this is particularly relevant in order to also do (A) above. It would be helpful, perhaps, to differentiate the behavior of a resolver, when it does have, and when it does not have, the apex NS RRSET, and when that might trigger different behavior to a client of the resolver. (E.g. when the resolver path includes things like: "client -> recursive resolver -> bigger recursive resolver -> authority server(s)".) >> 2. Is the draft clear in its message? =A0If not, please suggest improvem= ents. > > It is entirely unclear to me what problems the various proposals are actu= ally trying to solve. > >> 3. After (if any) editing fixes is this draft ready for WG Last Call? > > Not in my opinion. =A0I don't think the ideas are clearly BCPs. > >> >> =A0 =A0Olafur and Andrew >> _______________________________________________ >> dnsext mailing list >> dnsext@ietf.org >> https://www.ietf.org/mailman/listinfo/dnsext > > -- > David Blacka =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 > Principal Engineer =A0 =A0Verisign Platform Product Development > > _______________________________________________ > dnsext mailing list > dnsext@ietf.org > https://www.ietf.org/mailman/listinfo/dnsext > From george.barwood@blueyonder.co.uk Mon Feb 21 12:03:39 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 01EBD3A716D for ; Mon, 21 Feb 2011 12:03:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.745 X-Spam-Level: X-Spam-Status: No, score=0.745 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, HELO_EQ_BLUEYON=1.4, MIME_BASE64_BLANKS=0.041, MIME_BASE64_TEXT=1.753] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H4qFCSb28bLk for ; Mon, 21 Feb 2011 12:03:35 -0800 (PST) Received: from smtp-out4.blueyonder.co.uk (smtp-out4.blueyonder.co.uk [195.188.213.7]) by core3.amsl.com (Postfix) with ESMTP id 1A3EE3A7150 for ; Mon, 21 Feb 2011 12:03:34 -0800 (PST) Received: from [172.23.170.139] (helo=anti-virus01-10) by smtp-out4.blueyonder.co.uk with smtp (Exim 4.52) id 1PrbzS-0004RY-TQ; Mon, 21 Feb 2011 20:04:15 +0000 Received: from [92.238.99.235] (helo=GeorgeLaptop) by asmtp-out4.blueyonder.co.uk with smtp (Exim 4.72) (envelope-from ) id 1PrbzH-0003NV-VS; Mon, 21 Feb 2011 20:04:04 +0000 Message-ID: From: "George Barwood" To: "Masataka Ohta" , References: <20110219210716.72943A5602B@drugs.dv.isc.org> <20110220203156.C1F83A6526F@drugs.dv.isc.org><3764325DE7FA4B2F9B77387EBD15EAF8@local> <20110220210758.81B93A65431@drugs.dv.isc.org><3D9B2A0D15F84DC6822FCF0FC6F8F214@local><20110220225811.1F68CA65BFC@drugs.dv.isc.org> <4D61BCBE.7020102@necom830.hpcl.titech.ac.jp> Date: Mon, 21 Feb 2011 20:04:00 -0000 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.5994 Subject: Re: [dnsext] Failure to add glue MUST cause TC to be set. X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 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, 21 Feb 2011 20:03:39 -0000 DQotLS0tLSBPcmlnaW5hbCBNZXNzYWdlIC0tLS0tIA0KRnJvbTogIk1hc2F0YWthIE9odGEiIDxt b2h0YUBuZWNvbTgzMC5ocGNsLnRpdGVjaC5hYy5qcD4NClRvOiA8ZG5zZXh0QGlldGYub3JnPg0K U2VudDogTW9uZGF5LCBGZWJydWFyeSAyMSwgMjAxMSAxOjE1IEFNDQpTdWJqZWN0OiBSZTogW2Ru c2V4dF0gRmFpbHVyZSB0byBhZGQgZ2x1ZSBNVVNUIGNhdXNlIFRDIHRvIGJlIHNldC4NCg0KDQo+ IE1hcmsgQW5kcmV3cyB3cm90ZToNCj4gDQo+Pj4gVGhhdCdzIGEgbWlzLWNvbmZpZ3VyYXRpb24s IG5vdCBhIGNvdW50ZXItZXhhbXBsZS4NCj4+IA0KPj4gTm8uIEl0IGlzIG5vdCBhIG1pcy1jb25m aWd1cmF0aW9uLg0KPiANCj4gRm9yIGV4YW1wbGUsICJvcmcuIiBhbmQgImluZm8uIiBhcmUgY29u ZmlndXJlZCBzby4NCg0KTm8uDQoNCm9yZyBhbmQgaW5mbyBzaGFyZSBuYW1lIHNlcnZlcnMsIGJ1 dCB0aGV5IGVhY2ggaGF2ZSA0ICJpbi16b25lIiBuYW1lIHNlcnZlciBuYW1lcyBiZWxvdyB0aGUg Y3V0Lg0KDQpBIHF1ZXJ5ICh0byByb290IHNlcnZlcnMpIGZvciA8YW55dGhpbmc+Lm9yZyBhbGxv d3MgYSByZWN1cnNvciB0byBsZWFybiB0aGUgQS9BQUFBIHJlY29yZHMgZm9yIGhhbGYgdGhlIG5h bWUgc2VydmVycywgYSBzdWJzZXF1ZW50IHF1ZXJ5IGZvciA8YW55dGhpbmc+LmluZm8gdG8gbGVh cm4gdGhlIEEvQUFBQSByZWNvcmRzIGZvciB0aGUgb3RoZXIgaGFsZi4NCg0KVGhlIHJvb3QgbmFt ZSBzZXJ2ZXJzIGFsc28gc2VydmUgYWRkaXRpb25hbCByZWNvcmRzIGZvciB0aGUgb3RoZXIgaGFs ZiBhcyB3ZWxsIGFzIGdsdWUsIHdoaWNoIGFsbG93cyBhIHJlY3Vyc29yIHdpdGggc3VmZmljaWVu dGx5IHNvcGhpc3RpY2F0ZWQgYmFpbGl3aWNrIGNoZWNraW5nIHRvIGxlYXJuIGFsbCB0aGUgQS9B QUFBIHJlY29yZHMgb24gdGhlIGZpcnN0IHF1ZXJ5Lg0KDQpHZW9yZ2UNCg0KPiBNYXNhdGFrYSBP aHRhDQo+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ IGRuc2V4dCBtYWlsaW5nIGxpc3QNCj4gZG5zZXh0QGlldGYub3JnDQo+IGh0dHBzOi8vd3d3Lmll dGYub3JnL21haWxtYW4vbGlzdGluZm8vZG5zZXh0 From ajs@shinkuro.com Mon Feb 21 12:10:10 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C14E53A6CCB for ; Mon, 21 Feb 2011 12:10:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.58 X-Spam-Level: X-Spam-Status: No, score=-102.58 tagged_above=-999 required=5 tests=[AWL=0.019, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J0ixLv+Qx-yM for ; Mon, 21 Feb 2011 12:10:06 -0800 (PST) Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by core3.amsl.com (Postfix) with ESMTP id C062B3A716D for ; Mon, 21 Feb 2011 12:10:06 -0800 (PST) Received: from crankycanuck.ca (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 73B811ECB408; Mon, 21 Feb 2011 20:10:48 +0000 (UTC) Date: Mon, 21 Feb 2011 15:10:46 -0500 From: Andrew Sullivan To: Alex Nicoll Message-ID: <20110221201046.GQ32224@shinkuro.com> References: <20110221185757.GO32224@shinkuro.com> <20110221191952.GA64744@bikeshed.isc.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.18 (2008-05-17) Cc: "dnsext@ietf.org" Subject: Re: [dnsext] DNSEXT in Prague? X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 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, 21 Feb 2011 20:10:10 -0000 On Mon, Feb 21, 2011 at 02:29:05PM -0500, Alex Nicoll wrote: > > I'm trying to decide if I should attend or not, and since I've sort > of adopted DNSEXT as my haunt of choice, that's a big factor. It's > not easy convincing any employer to pay for a trip to Prague! Since > there is not an agenda online yet, are there other DNS/DNSSEC > related bits of fun to be had that you know of? (Or high assurance > operating systems?) The overwhelming agenda item for DNSEXT will be the aliasing work; that's the basic reason we're having a meeting. DANE is, in my opinion, a crucial WG for people interested in DNSSEC to be involved. I think the progress of that WG could actually be worth the trip alone (but full disclosure: those paying my freight were not going to send me when it looked like we weren't having a DNSEXT meeting. So I sympathise). There remains important work to do in DNSOP, particularly with respect to the timings discussion and the operational practices bis document. I have agreed to arrange some sort of bar BOF around DNS APIs. Watch your local DNS stations for more news on this front in the near future. That's what I know of at the moment. The chairs of the other WGs I mention undoubtedly will have more to say on their respective lists. A -- Andrew Sullivan ajs@shinkuro.com Shinkuro, Inc. From george.barwood@blueyonder.co.uk Mon Feb 21 12:31:11 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EE0753A6F5C for ; Mon, 21 Feb 2011 12:31:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.015 X-Spam-Level: * X-Spam-Status: No, score=1.015 tagged_above=-999 required=5 tests=[AWL=-0.180, BAYES_00=-2.599, HELO_EQ_BLUEYON=1.4, J_CHICKENPOX_55=0.6, MIME_BASE64_BLANKS=0.041, MIME_BASE64_TEXT=1.753] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cAaHJfOwmNgN for ; Mon, 21 Feb 2011 12:31:10 -0800 (PST) Received: from smtp-out3.blueyonder.co.uk (smtp-out3.blueyonder.co.uk [195.188.213.6]) by core3.amsl.com (Postfix) with ESMTP id 87F573A6E38 for ; Mon, 21 Feb 2011 12:31:10 -0800 (PST) Received: from [172.23.170.138] (helo=anti-virus01-09) by smtp-out3.blueyonder.co.uk with smtp (Exim 4.52) id 1PrcQB-0007We-Mq; Mon, 21 Feb 2011 20:31:51 +0000 Received: from [92.238.99.235] (helo=GeorgeLaptop) by asmtp-out2.blueyonder.co.uk with smtp (Exim 4.72) (envelope-from ) id 1PrcOc-0000hL-AB; Mon, 21 Feb 2011 20:30:14 +0000 Message-ID: <4DFFA0E09D824AEC92EA89AFFB9F2120@local> From: "George Barwood" To: "Mark Andrews" References: <20110219210716.72943A5602B@drugs.dv.isc.org> <20110220203156.C1F83A6526F@drugs.dv.isc.org><3764325DE7FA4B2F9B77387EBD15EAF8@local> <20110220210758.81B93A65431@drugs.dv.isc.org><3D9B2A0D15F84DC6822FCF0FC6F8F214@local> <20110220225811.1F68CA65BFC@drugs.dv.isc.org> Date: Mon, 21 Feb 2011 20:30:10 -0000 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.5994 Cc: dnsext@ietf.org Subject: Re: [dnsext] Failure to add glue MUST cause TC to be set. X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 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, 21 Feb 2011 20:31:12 -0000 DQotLS0tLSBPcmlnaW5hbCBNZXNzYWdlIC0tLS0tIA0KRnJvbTogIk1hcmsgQW5kcmV3cyIgPG1h cmthQGlzYy5vcmc+DQpUbzogIkdlb3JnZSBCYXJ3b29kIiA8Z2VvcmdlLmJhcndvb2RAYmx1ZXlv bmRlci5jby51az4NCkNjOiA8ZG5zZXh0QGlldGYub3JnPg0KU2VudDogU3VuZGF5LCBGZWJydWFy eSAyMCwgMjAxMSAxMDo1OCBQTQ0KU3ViamVjdDogUmU6IFtkbnNleHRdIEZhaWx1cmUgdG8gYWRk IGdsdWUgTVVTVCBjYXVzZSBUQyB0byBiZSBzZXQuDQoNCg0KPiANCj4gSW4gbWVzc2FnZSA8M0Q5 QjJBMEQxNUY4NERDNjgyMkZDRjBGQzZGOEYyMTRAbG9jYWw+LCAiR2VvcmdlIEJhcndvb2QiIHdy aXRlczoNCj4+IA0KPj4gLS0tLS0gT3JpZ2luYWwgTWVzc2FnZSAtLS0tLSANCj4+IEZyb206ICJN YXJrIEFuZHJld3MiIDxtYXJrYUBpc2Mub3JnPg0KPj4gVG86ICJHZW9yZ2UgQmFyd29vZCIgPGdl b3JnZS5iYXJ3b29kQGJsdWV5b25kZXIuY28udWs+DQo+PiBDYzogPGRuc2V4dEBpZXRmLm9yZz4N Cj4+IFNlbnQ6IFN1bmRheSwgRmVicnVhcnkgMjAsIDIwMTEgOTowNyBQTQ0KPj4gU3ViamVjdDog UmU6IFtkbnNleHRdIEZhaWx1cmUgdG8gYWRkIGdsdWUgTVVTVCBjYXVzZSBUQyB0byBiZSBzZXQu DQo+PiANCj4+IA0KPj4gPiANCj4+ID4gSW4gbWVzc2FnZSA8Mzc2NDMyNURFN0ZBNEIyRjlCNzcz ODdFQkQxNUVBRjhAbG9jYWw+LCAiR2VvcmdlIEJhcndvb2QiIHdyaXRlczoNCj4+ID4+ID4+IC0t LS0tIE9yaWdpbmFsIE1lc3NhZ2UgLS0tLS0gDQo+PiA+PiA+PiBGcm9tOiAiTWFyayBBbmRyZXdz IiA8bWFya2FAaXNjLm9yZz4NCj4+ID4+ID4+IFRvOiA8ZG5zZXh0QGlldGYub3JnPg0KPj4gPj4g Pj4gU2VudDogU2F0dXJkYXksIEZlYnJ1YXJ5IDE5LCAyMDExIDk6MDcgUE0NCj4+ID4+ID4+IFN1 YmplY3Q6IFtkbnNleHRdIEZhaWx1cmUgdG8gYWRkIGdsdWUgTVVTVCBjYXVzZSBUQyB0byBiZSBz ZXQuDQo+PiA+PiA+PiANCj4+ID4+ID4+ID4gQmVsb3cgaXMgYSBleGFtcGxlIG9mIHdoeSBUQyBz aG91bGQgYmUgc2V0IHdoZW4gZ2x1ZSBjYW5ub3QgYmUgYWRkZWQNCj4+ID4+ID4+ID4gdG8gdGhl IGFuc3dlci4NCj4+ID4+ID4+ID4gDQo+PiA+PiA+PiA+IFsuLl0NCj4+ID4+ID4+IA0KPj4gPj4g Pj4gQWdyZWVkLCBidXQgd2hlcmUgZXhhY3RseSBzaG91bGQgdGhlIGxpbmUgYmUgZHJhd24/DQo+ PiA+PiA+IA0KPj4gPj4gPiBXaGF0IGxpbmU/ICBJZiB0aGUgZ2x1ZSBkb2Vzbid0IGZpdCB0aGVu IHRoZSByZWZlcnJhbCBpcyBub3QgY29tcGxldGUuDQo+PiA+PiA+IA0KPj4gPj4gPj4gSWYgb21p dHRpbmcgYW55IGdsdWUgbGVhZHMgdG8gdHJ1bmNhdGlvbiwgdGhlbiBtYW55IChub24tRE5TU0VD KSByZWZlcnJhbHMNCj4+ID4+ID4+IG92ZXIgVURQIHdpbGwgaGF2ZSBUQyBzZXQuIGUuZy4gDQo+ PiA+PiA+PiANCj4+ID4+ID4+IGRpZyBmb28uY29tIEBhLnJvb3Qtc2VydmVycy5uZXQNCj4+ID4+ ID4gDQo+PiA+PiA+IFllcy4NCj4+ID4+ID4gDQo+PiA+PiA+PiBJcyB0aGF0IHNlbnNpYmxlPw0K Pj4gPj4gPiANCj4+ID4+ID4gWWVzLg0KPj4gPj4gPiANCj4+ID4+ID4+IEhvdyBtdWNoIGdsdWUg aXMgZW5vdWdoPw0KPj4gPj4gPiANCj4+ID4+ID4gRGVwZW5kcyBvbiB0aGUgZGVsZWdhdGlvbi4g IFRoZSBvbmx5IHNhZmUgYW5zd2VyIGlzIGFsbCB5b3UgaGF2ZS4NCj4+ID4+IA0KPj4gPj4gT25l IHN1Z2dlc3Rpb24gdGhhdCBtaWdodCB3b3JrIGlzIHRoYXQgZ2x1ZSB3aGljaCBtYXRjaHMgUU5B TUUrUVRZUEUgTVVTVA0KPj4gPj4gYmUgaW5jbHVkZWQsIGJ1dCBvdGhlciBnbHVlIGNhbiBiZSBv bWl0dGVkLg0KPj4gPiANCj4+ID4gVGhpcyBkb2VzIG5vdCB3b3JrIGluIGFsbCBjYXNlcyB3aGVy ZSBnbHVlIG5lZWRzIHRvIGJlIHJldHVybmVkLg0KPj4gPiANCj4+ID4gWm9uZSBBLm5ldCBpcyBz ZXJ2ZWQgYnkgc2VydmVycyBpbiBCLm5ldC4gIFpvbmUgQi5uZXQgaXMgc2VydmVkIGJ5DQo+PiA+ IHNlcnZlcnMgaW4gQS5uZXQuDQo+PiANCj4+IFNvIHNvbWV0aGluZyBsaWtlDQo+PiANCj4+IA0K Pj4gQnV0IG5vdGhpbmcgd2lsbCB3b3JrIGluIHRoYXQgY2FzZSAtIGlmIHlvdSBtYWtlIGEgcmVj dXJzaXZlIGxvb3AgbGlrZSB0aGlzLA0KPj4gdGhlbiB0aGVyZSBpcyBubyBnbHVlICggdGhlIG5h bWUgc2VydmVyIG5hbWVzIGFyZSBub3QgImJlbG93IiB0aGUgY3V0ICkgYW5kDQo+PiB5b3UgaGF2 ZSBoYWQgaXQgcmVnYXJkbGVzcy4gDQo+IA0KPiBHbHVlIHJlY29yZHMgYXJlIHJlY29yZHMgaW4g dGhlIHBhcmVudCB6b25lIHRvIGVuYWJsZSB5b3UgdG8gcmVhY2gNCj4gdGhlIHNlcnZlcnMgZm9y IHRoZSBjaGlsZCB6b25lLiAgUkZDIDEwMzQgZ2F2ZSBhIG9idmlvdXMgZXhhbXBsZQ0KPiBvZiBz dWNoIHJlY29yZHMuICBUaGVyZSBhcmUgbGVzcyBvYnZpb3VzIGV4YW1wbGVzLg0KPiANCj4+IFRo YXQncyBhIG1pcy1jb25maWd1cmF0aW9uLCBub3QgYSBjb3VudGVyLWV4YW1wbGUuDQo+IA0KPiBO by4gSXQgaXMgbm90IGEgbWlzLWNvbmZpZ3VyYXRpb24uDQoNClJGQzEwMzQgc2F5cw0KDQogIFRv IGZpeCB0aGlzIHByb2JsZW0sIGEgem9uZSBjb250YWlucyAiZ2x1ZSIgUlJzIHdoaWNoIGFyZSBu b3QNCiAgcGFydCBvZiB0aGUgYXV0aG9yaXRhdGl2ZSBkYXRhLCBhbmQgYXJlIGFkZHJlc3MgUlJz IGZvciB0aGUgc2VydmVycy4NCiAgVGhlc2UgUlJzIGFyZSBvbmx5IG5lY2Vzc2FyeSBpZiB0aGUg bmFtZSBzZXJ2ZXIncyBuYW1lIGlzICJiZWxvdyIgdGhlDQogIGN1dCwgYW5kIGFyZSBvbmx5IHVz ZWQgYXMgcGFydCBvZiBhIHJlZmVycmFsIHJlc3BvbnNlLg0KDQpUaGUgc2Vjb25kIHNlbnRlbmNl IHJ1bGVzIG91dCB0aGUgbXV0dWFsbHkgcmVjdXJzaXZlIGNhc2UgKCB2ZXJ5IHNlbnNpYmx5ICku DQoNCk15IGVhcmxpZXIgcG9zdCB3YXMgcG9zdGVkIGVhcmx5IGJ5IG1pc3Rha2UsIEkgbWVhbnQg dG8gc2F5DQoNCjw8DQpTbyBzb21ldGhpbmcgbGlrZQ0KDQpab25lQS5uZXQuIE5TIG5zMS5ab25l Qi5uZXQuDQpab25lQS5uZXQuIE5TIG5zMi5ab25lQi5uZXQuDQoNClpvbmVCLm5ldC4gTlMgbnMx LlpvbmVBLm5ldC4NClpvbmVCLm5ldC4gTlMgbnMyLlpvbmVBLm5ldC4NCj4+DQoNCkkgdGhpbmsg dGhlIGlkZWEgb2Ygc3VwcG9ydGluZyB0aGlzIGtpbmQgb2YgbXV0dWFsbHkgcmVjdXJzaXZlIHNl dHVwIGlzIGJhZC4NCg0KU3VjaCB6b25lcyBtYXkgbm90IGJlIHBvcnRhYmxlIHRvIGEgZGlmZmVy ZW50IGF1dGhvcml0YXRpdmUgc2VydmVyICggYW4gaW1wbGVtZW50YXRpb24gbWlnaHQNCndlbGwg Y2hvb3NlIHRvIG9ubHkgYWNjZXB0IGFuZC9vciBzZXJ2ZSBpbi16b25lIGdsdWUgKS4NCg0KQW5k IHJlY3Vyc2l2ZSByZXNvbHZlcnMgd2l0aCBzaW1wbGUgQmFpbGl3aWNrIGNoZWNraW5nLCBvciBz aW1wbGUgcnVsZXMgZm9yIHdoYXQgcmVjb3Jkcw0KdG8gYWNjZXB0IGZyb20gdGhlIGFkZGl0aW9u YWwgc2VjdGlvbiAob25seSBpbi16b25lIGdsdWUpIHdpbGwgbG9vcC4NCg0KSSdtIG9wcG9zZWQg dG8gZXh0ZW5kaW5nIHRoZSBzdGFuZGFyZCBpbiB0aGlzIHdheSAoIG9mIGNvdXJzZSB5b3UgbWln aHQgZGlzcHV0ZSB0aGF0IGl0IGRvZXMgZXh0ZW5kDQp0aGUgc3RhbmRhcmQsIGJ1dCB0aGF0J3Mg bXkgcmVhZGluZyBvZiB0aGUgUkZDMTAzNCB0ZXh0IGFib3ZlICkuDQoNCkdlb3JnZQ0KDQo= From hallam@gmail.com Mon Feb 21 13:09:09 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 541813A7127 for ; Mon, 21 Feb 2011 13:09:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.539 X-Spam-Level: X-Spam-Status: No, score=-3.539 tagged_above=-999 required=5 tests=[AWL=0.059, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Py3A8V9oW4RR for ; Mon, 21 Feb 2011 13:09:08 -0800 (PST) Received: from mail-bw0-f54.google.com (mail-bw0-f54.google.com [209.85.214.54]) by core3.amsl.com (Postfix) with ESMTP id A48143A6F53 for ; Mon, 21 Feb 2011 13:09:07 -0800 (PST) Received: by bwz12 with SMTP id 12so2997145bwz.27 for ; Mon, 21 Feb 2011 13:09:49 -0800 (PST) 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=1JK2bIBukhoZbCst7u5ti6tPxmkTyko9MZrJaHgjReY=; b=vGiKAbBUfA03bQySDvrDeZ+Wezw0NdiZJDFC096iiJXDy7uVSXUe5xsU24KizMg80p MOtDdn8MUz/uVUcbhSo0UCmduZN8wPIJCe+fM55MpZP8hQ+iQchuTWZ9yH43faOlKlIV pTPwNvsurcztSYS6Xxl+HbLecnHaG04DDc/qo= 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=LHtjr1Q0HyV0FhjogrUCKf/7pxHqL40qWpxf/rBP+pK+ofNHnaOnPncmdsNPlteoLa X4Vmjh9zXf3d0mKL80jmugbnVSKoqdVJYHgLmsKfwCNhvJ6+Wkw6hs+lahRpWtq0HaWY OaHm5A6a1fxviNPVWoS9f8ExazqdSmhT1IWQU= MIME-Version: 1.0 Received: by 10.204.24.135 with SMTP id v7mr1294570bkb.99.1298322588687; Mon, 21 Feb 2011 13:09:48 -0800 (PST) Received: by 10.204.14.139 with HTTP; Mon, 21 Feb 2011 13:09:48 -0800 (PST) In-Reply-To: <20110221201046.GQ32224@shinkuro.com> References: <20110221185757.GO32224@shinkuro.com> <20110221191952.GA64744@bikeshed.isc.org> <20110221201046.GQ32224@shinkuro.com> Date: Mon, 21 Feb 2011 13:09:48 -0800 Message-ID: From: Phillip Hallam-Baker To: Andrew Sullivan Content-Type: multipart/alternative; boundary=00032555ae82b3e641049cd148f8 Cc: "dnsext@ietf.org" Subject: Re: [dnsext] DNSEXT in Prague? X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 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, 21 Feb 2011 21:09:09 -0000 --00032555ae82b3e641049cd148f8 Content-Type: text/plain; charset=ISO-8859-1 On Mon, Feb 21, 2011 at 12:10 PM, Andrew Sullivan wrote: > I have agreed to arrange some sort of bar BOF around DNS APIs. Watch > your local DNS stations for more news on this front in the near > future. I know quite a few people in the Web Services world who would be very interested in that. In particular, I would like to see some sort of move toward a scheme where an application could make a call of the form: stream = Context.CreateConnection ("example.com", "_http._tcp", 80) This would return the best connection to the specified service according to the security and trust criteria specified in 'context'. Web Services are an area where the more complexity we can hide from the implementation, the better. -- Website: http://hallambaker.com/ --00032555ae82b3e641049cd148f8 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Mon, Feb 21, 2011 at 12:10 PM, Andrew Sullivan <ajs@shinkuro.com> wrote:
=
I have agreed to arrange some sort of bar BOF around DNS APIs. =A0Watch
your local DNS stations for more news on this front in the near
future.

I know quite a few people in the We= b Services world who would be very interested in that.

=
In particular, I would like to see some sort of move toward a scheme w= here an application could make a call of the form:

stream =3D Context.CreateConnection ("example.com", "_http._tcp", 80)
=

This would return the best connection to the specified = service according to the security and trust criteria specified in 'cont= ext'.


Web Services are an area where the more = complexity we can hide from the implementation, the better.

<= /div>
=A0
--
Website: http://hallambaker.com/

--00032555ae82b3e641049cd148f8-- From vixie@isc.org Mon Feb 21 13:26:57 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 551F93A717F for ; Mon, 21 Feb 2011 13:26:57 -0800 (PST) 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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EAaR9MUcBSA0 for ; Mon, 21 Feb 2011 13:26:56 -0800 (PST) Received: from nsa.vix.com (unknown [IPv6:2001:4f8:3:bb:230:48ff:fe5a:2f38]) by core3.amsl.com (Postfix) with ESMTP id 4C3703A7151 for ; Mon, 21 Feb 2011 13:26:56 -0800 (PST) Received: from nsa.vix.com (localhost [127.0.0.1]) by nsa.vix.com (Postfix) with ESMTP id 83400A1021 for ; Mon, 21 Feb 2011 21:27:37 +0000 (UTC) (envelope-from vixie@isc.org) From: Paul Vixie To: "dnsext@ietf.org" In-Reply-To: Your message of "Mon, 21 Feb 2011 14:29:05 EST." References: <20110221185757.GO32224@shinkuro.com> <20110221191952.GA64744@bikeshed.isc.org> X-Mailer: MH-E 8.2; nmh 1.2; XEmacs 21.4 (patch 22) Date: Mon, 21 Feb 2011 21:27:37 +0000 Message-ID: <72924.1298323657@nsa.vix.com> Subject: Re: [dnsext] DNSEXT in Prague? X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 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, 21 Feb 2011 21:26:57 -0000 > From: Alex Nicoll > Date: Mon, 21 Feb 2011 14:29:05 -0500 > > I'm trying to decide if I should attend or not, and since I've sort of > adopted DNSEXT as my haunt of choice, that's a big factor. It's not > easy convincing any employer to pay for a trip to Prague! Since there > is not an agenda online yet, are there other DNS/DNSSEC related bits > of fun to be had that you know of? (Or high assurance operating > systems?) based on dave blacka's response to resimprove, i think that should be on the prague agenda, and i expect it'll take as much time as we give it. From fanf2@hermes.cam.ac.uk Mon Feb 21 13:28:35 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EF9213A717B for ; Mon, 21 Feb 2011 13:28:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.203 X-Spam-Level: X-Spam-Status: No, score=-5.203 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cZur8KAHlDSk for ; Mon, 21 Feb 2011 13:28:33 -0800 (PST) Received: from ppsw-50.csi.cam.ac.uk (ppsw-50.csi.cam.ac.uk [131.111.8.150]) by core3.amsl.com (Postfix) with ESMTP id C10C13A7159 for ; Mon, 21 Feb 2011 13:28:33 -0800 (PST) X-Cam-AntiVirus: no malware found X-Cam-SpamDetails: not scanned X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ Received: from 69.91.125.91.rb4.adsl.brightview.com ([91.125.91.69]:49459 helo=[192.168.0.5]) by ppsw-50.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.157]:587) with esmtpsa (PLAIN:fanf2) (TLSv1:AES128-SHA:128) id 1PrdJg-00019q-sX (Exim 4.72) (return-path ); Mon, 21 Feb 2011 21:29:13 +0000 References: <4D622624.90303@ogud.com> In-Reply-To: Mime-Version: 1.0 (iPhone Mail 8C148) Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Message-Id: <5E260AAB-89BD-4A17-BE0B-BC42BFB7E43C@dotat.at> X-Mailer: iPhone Mail (8C148) From: Tony Finch Date: Mon, 21 Feb 2011 21:28:53 +0000 To: David Blacka Sender: Tony Finch Cc: "dnsext@ietf.org" , Olafur Gudmundsson Subject: Re: [dnsext] WG opinion on draft : Improvements to DNS Resolvers, for Resiliency, Robustness, and Responsiveness X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 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, 21 Feb 2011 21:28:35 -0000 On 21 Feb 2011, at 18:58, David Blacka wrote:. >=20 > (A) is (I think) trying to solve issues caused by "cache pinning" when mov= ing a zone from one set of nameservers to another. Actually, it goes furthe= r than that (if I understand the draft correctly, which I very well may not)= by effectively removing entire delegation chains when the ancestor NS RRset= expires. So, e.g., every time the com NS RRset expires, all delegations be= low it effectively expire. I have no idea what problem this overall behavio= r solves, although I suspect that it defeats a great deal of the value of a c= ache. There are a couple of other things that worry me about this section of the d= raft. Firstly, it suggests that there can be multiple different TTLs on the delega= tion NS RR set - it talks about the minimum TTL. It needs fixing to understa= nd that the whole RR set has the same TTL. Secondly, it is basically suggesting that the TTL of the non-authoritative s= poofable delegation NS RR set should override the TTL of the authoritative s= igned apex NS RR set. This seems to me to be contrary to DNS and DNSSEC auth= ority semantics. Tony. -- f.anthony.n.finch http://dotat.at/= From marka@isc.org Mon Feb 21 14:06:24 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E9A2C3A7160 for ; Mon, 21 Feb 2011 14:06:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.542 X-Spam-Level: X-Spam-Status: No, score=-1.542 tagged_above=-999 required=5 tests=[AWL=0.457, BAYES_00=-2.599, J_CHICKENPOX_55=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aTHl7C3ecuA6 for ; Mon, 21 Feb 2011 14:06:23 -0800 (PST) Received: from mx.ams1.isc.org (mx.ams1.isc.org [IPv6:2001:500:60::65]) by core3.amsl.com (Postfix) with ESMTP id 745273A7153 for ; Mon, 21 Feb 2011 14:06:23 -0800 (PST) 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 7204B5F985D; Mon, 21 Feb 2011 22:06:50 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (drugs.dv.isc.org [IPv6:2001:470:1f00:820:ea06:88ff:fef3:4f9c]) (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 10338216C1E; Mon, 21 Feb 2011 22:06:48 +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 D59D1A87710; Tue, 22 Feb 2011 09:06:45 +1100 (EST) To: "George Barwood" From: Mark Andrews References: <20110219210716.72943A5602B@drugs.dv.isc.org> <20110220203156.C1F83A6526F@drugs.dv.isc.org><3764325DE7FA4B2F9B77387EBD15EAF8@local> <20110220210758.81B93A65431@drugs.dv.isc.org><3D9B2A0D15F84DC6822FCF0FC6F8F214@local> <20110220225811.1F68CA65BFC@drugs.dv.isc.org> <4DFFA0E09D824AEC92EA89AFFB9F2120@local> In-reply-to: Your message of "Mon, 21 Feb 2011 20:30:10 -0000." <4DFFA0E09D824AEC92EA89AFFB9F2120@local> Date: Tue, 22 Feb 2011 09:06:45 +1100 Message-Id: <20110221220645.D59D1A87710@drugs.dv.isc.org> Cc: dnsext@ietf.org Subject: Re: [dnsext] Failure to add glue MUST cause TC to be set. X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 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, 21 Feb 2011 22:06:25 -0000 In message <4DFFA0E09D824AEC92EA89AFFB9F2120@local>, "George Barwood" writes: > > ----- Original Message ----- > From: "Mark Andrews" > To: "George Barwood" > Cc: > Sent: Sunday, February 20, 2011 10:58 PM > Subject: Re: [dnsext] Failure to add glue MUST cause TC to be set. > > > > > > In message <3D9B2A0D15F84DC6822FCF0FC6F8F214@local>, "George Barwood" writes: > >> > >> ----- Original Message ----- > >> From: "Mark Andrews" > >> To: "George Barwood" > >> Cc: > >> Sent: Sunday, February 20, 2011 9:07 PM > >> Subject: Re: [dnsext] Failure to add glue MUST cause TC to be set. > >> > >> > >> > > >> > In message <3764325DE7FA4B2F9B77387EBD15EAF8@local>, "George Barwood" writes: > >> >> >> ----- Original Message ----- > >> >> >> From: "Mark Andrews" > >> >> >> To: > >> >> >> Sent: Saturday, February 19, 2011 9:07 PM > >> >> >> Subject: [dnsext] Failure to add glue MUST cause TC to be set. > >> >> >> > >> >> >> > Below is a example of why TC should be set when glue cannot be added > >> >> >> > to the answer. > >> >> >> > > >> >> >> > [..] > >> >> >> > >> >> >> Agreed, but where exactly should the line be drawn? > >> >> > > >> >> > What line? If the glue doesn't fit then the referral is not complete. > >> >> > > >> >> >> If omitting any glue leads to truncation, then many (non-DNSSEC) referrals > >> >> >> over UDP will have TC set. e.g. > >> >> >> > >> >> >> dig foo.com @a.root-servers.net > >> >> > > >> >> > Yes. > >> >> > > >> >> >> Is that sensible? > >> >> > > >> >> > Yes. > >> >> > > >> >> >> How much glue is enough? > >> >> > > >> >> > Depends on the delegation. The only safe answer is all you have. > >> >> > >> >> One suggestion that might work is that glue which matchs QNAME+QTYPE MUST > >> >> be included, but other glue can be omitted. > >> > > >> > This does not work in all cases where glue needs to be returned. > >> > > >> > Zone A.net is served by servers in B.net. Zone B.net is served by > >> > servers in A.net. > >> > >> So something like > >> > >> > >> But nothing will work in that case - if you make a recursive loop like this, > >> then there is no glue ( the name server names are not "below" the cut ) and > >> you have had it regardless. > > > > Glue records are records in the parent zone to enable you to reach > > the servers for the child zone. RFC 1034 gave a obvious example > > of such records. There are less obvious examples. > > > >> That's a mis-configuration, not a counter-example. > > > > No. It is not a mis-configuration. > > RFC1034 says > > To fix this problem, a zone contains "glue" RRs which are not > part of the authoritative data, and are address RRs for the servers. > These RRs are only necessary if the name server's name is "below" the > cut, and are only used as part of a referral response. > > The second sentence rules out the mutually recursive case ( very sensibly ). No. It just means that they failed to fully analyse the problem. If they wanted to prevent the mutually recursive case there would have been words to outlaw it or warn of it. RFC 1034 contains lots of errors this is just another one. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From ogud@ogud.com Mon Feb 21 14:29:09 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BBC843A716D for ; Mon, 21 Feb 2011 14:29:09 -0800 (PST) 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=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5dA8c5eN24lV for ; Mon, 21 Feb 2011 14:29:08 -0800 (PST) Received: from stora.ogud.com (stora.ogud.com [66.92.146.20]) by core3.amsl.com (Postfix) with ESMTP id 075903A7126 for ; Mon, 21 Feb 2011 14:29:07 -0800 (PST) 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 p1LMUNBM019141 for ; Mon, 21 Feb 2011 17:30:24 -0500 (EST) (envelope-from ogud@ogud.com) Message-ID: <4D62E75B.1010006@ogud.com> Date: Mon, 21 Feb 2011 17:29:47 -0500 From: Olafur Gudmundsson User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-GB; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: dnsext@ietf.org 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: [dnsext] Prague Meeting X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 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, 21 Feb 2011 22:29:10 -0000 We have requested a one hour slot to talk about open issues: Alias Requirements send in agenda requests. Editors this is a good time to update your drafts or bug your chair about last calls. Olafur From vixie@isc.org Mon Feb 21 14:30:29 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D44D23A716D for ; Mon, 21 Feb 2011 14:30:29 -0800 (PST) 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=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eKfdnqDiB+Qz for ; Mon, 21 Feb 2011 14:30:28 -0800 (PST) Received: from nsa.vix.com (unknown [IPv6:2001:4f8:3:bb:230:48ff:fe5a:2f38]) by core3.amsl.com (Postfix) with ESMTP id 6E1613A7126 for ; Mon, 21 Feb 2011 14:30:28 -0800 (PST) Received: from nsa.vix.com (localhost [127.0.0.1]) by nsa.vix.com (Postfix) with ESMTP id BF019A1031 for ; Mon, 21 Feb 2011 22:31:09 +0000 (UTC) (envelope-from vixie@isc.org) From: Paul Vixie To: dnsext@ietf.org In-Reply-To: Your message of "Mon, 21 Feb 2011 13:58:27 EST." References: <4D622624.90303@ogud.com> X-Mailer: MH-E 8.2; nmh 1.2; XEmacs 21.4 (patch 22) Date: Mon, 21 Feb 2011 22:31:09 +0000 Message-ID: <76781.1298327469@nsa.vix.com> Subject: Re: [dnsext] WG opinion on draft : Improvements to DNS Resolvers, for Resiliency, Robustness, and Responsiveness X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 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, 21 Feb 2011 22:30:29 -0000 there are replies to three messages here. --- > From: David Blacka > Date: Mon, 21 Feb 2011 13:58:27 -0500 > ... > I was not aware of this draft's existence until now, but I just read it. i figured as much from the silence. hopefully this thread will stimulate other readers. > ... I'm unsure, although I'm leaning toward thinking that they are not > good ideas. you've misunderstood the text, indicating that the writing quality is too low. i won't go point by point on your misgivings and concerns, since... --- > Date: Mon, 21 Feb 2011 15:51:20 -0400 > From: Brian Dickson > > I have read the draft, and also David's comments, and have comments of > my own in-line below. ...since brian dickson's point by point followup is accurate and on target. > Briefly, however, I'd say: > - the things in the draft are all good ideas > - the draft is good, should be adopted, requires only a small amount > of work, and once that is done, is probably fine for WGLC. > - s few clarifications will go a long way to addressing both David's > issues, and making the document useful > - all of the above are "IMIHO" this echos my own view. we were not expecting to go to WGLC on -00, and in fact there is a -01 in the wings (sweeping in a fourth topic that was flying solo out of CNNIC) and we should see that posted before the cutoff for prague. what the authors were hoping for from -00 is exactly the kind of review and feedback that is occurring right now. so, let's pull back from WGLC and fix the editorial problems noted by dave blacka and put this on the prague agenda? --- > From: Tony Finch > Date: Mon, 21 Feb 2011 21:28:53 +0000 > > There are a couple of other things that worry me about this section of > the draft. > > Firstly, it suggests that there can be multiple different TTLs on the > delegation NS RR set - it talks about the minimum TTL. It needs fixing > to understand that the whole RR set has the same TTL. well, so, the protocol gives each RR a TTL and the original specification does not say what to do if the TTLs in an RR set differ. in BIND4 4.9, i decided to discard the whole RR set if any of its TTLs reached zero since otherwise we'd be modifying RR sets during TTL expiration. in RFC 2136 i enshrined this behaviour into the protocol by declaring "RR set atomicity". but editorially speaking i still think it's wise to say "discard when the minimum TTL in the RR set is reached" since the wire protocol allows TTLs to be different across an RR set and sending them out that way is not an error or a protocol violation. > Secondly, it is basically suggesting that the TTL of the > non-authoritative spoofable delegation NS RR set should override the > TTL of the authoritative signed apex NS RR set. This seems to me to be > contrary to DNS and DNSSEC authority semantics. again, the quality of the writing is evidently low, and i wrote this section of the resimprove draft so i'll take the hit for that. it is NOT an override. it's a freshness guaranty. if upon parent (non-auth) expiry the refresh (from the parent) shows that the delegation still exists then no change is made to the child (auth) data then in cache. however, if the delegation has disappeared in the parent, then we want the child GONE. e-criminals periodically use million-second TTLs on their zone data and by the time they're done with a spam run using that name it's ineffective to delete the delegation since by that time child data is widely held in caches. using the parent TTL as a freshness guaranty just means the registrar and registry operators can put shorter TTLs on the delegation than the child has at their apex, and cause periodic refreshes of this, for the purpose of having domains disappear from cache if their delegation disappears. it has no dnssec or other semantic effects. From vixie@isc.org Mon Feb 21 14:33:01 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C9D833A717E for ; Mon, 21 Feb 2011 14:33:01 -0800 (PST) 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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NtyP4dY38xHn for ; Mon, 21 Feb 2011 14:33:01 -0800 (PST) Received: from nsa.vix.com (unknown [IPv6:2001:4f8:3:bb:230:48ff:fe5a:2f38]) by core3.amsl.com (Postfix) with ESMTP id 027813A7079 for ; Mon, 21 Feb 2011 14:33:01 -0800 (PST) Received: from nsa.vix.com (localhost [127.0.0.1]) by nsa.vix.com (Postfix) with ESMTP id 556F6A1019 for ; Mon, 21 Feb 2011 22:33:43 +0000 (UTC) (envelope-from vixie@isc.org) From: Paul Vixie To: dnsext@ietf.org In-Reply-To: Your message of "Mon, 21 Feb 2011 17:29:47 EST." <4D62E75B.1010006@ogud.com> References: <4D62E75B.1010006@ogud.com> X-Mailer: MH-E 8.2; nmh 1.2; XEmacs 21.4 (patch 22) Date: Mon, 21 Feb 2011 22:33:43 +0000 Message-ID: <76896.1298327623@nsa.vix.com> Subject: Re: [dnsext] Prague Meeting X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 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, 21 Feb 2011 22:33:01 -0000 > Date: Mon, 21 Feb 2011 17:29:47 -0500 > From: Olafur Gudmundsson > > send in agenda requests. please add a slot for resimprove. > Editors this is a good time to update your drafts or bug your chair > about last calls. -01 will be out before the cutoff. From ajs@shinkuro.com Mon Feb 21 14:43:11 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6F81C3A7198 for ; Mon, 21 Feb 2011 14:43:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.581 X-Spam-Level: X-Spam-Status: No, score=-102.581 tagged_above=-999 required=5 tests=[AWL=0.018, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UBwuF9eHzrIn for ; Mon, 21 Feb 2011 14:43:10 -0800 (PST) Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by core3.amsl.com (Postfix) with ESMTP id A1A283A70F9 for ; Mon, 21 Feb 2011 14:43:10 -0800 (PST) Received: from crankycanuck.ca (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 D08171ECB408 for ; Mon, 21 Feb 2011 22:43:52 +0000 (UTC) Date: Mon, 21 Feb 2011 17:43:51 -0500 From: Andrew Sullivan To: dnsext@ietf.org Message-ID: <20110221224349.GT32224@shinkuro.com> References: <4D622624.90303@ogud.com> <76781.1298327469@nsa.vix.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <76781.1298327469@nsa.vix.com> User-Agent: Mutt/1.5.18 (2008-05-17) Subject: Re: [dnsext] WG opinion on draft : Improvements to DNS Resolvers, for Resiliency, Robustness, and Responsiveness X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 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, 21 Feb 2011 22:43:11 -0000 No hat. On Mon, Feb 21, 2011 at 10:31:09PM +0000, Paul Vixie wrote: > well, so, the protocol gives each RR a TTL and the original specification > does not say what to do if the TTLs in an RR set differ. in BIND4 4.9, i > decided to discard the whole RR set if any of its TTLs reached zero since > otherwise we'd be modifying RR sets during TTL expiration. in RFC 2136 i > enshrined this behaviour into the protocol by declaring "RR set atomicity". > but editorially speaking i still think it's wise to say "discard when the > minimum TTL in the RR set is reached" since the wire protocol allows TTLs > to be different across an RR set and sending them out that way is not an > error or a protocol violation. My reading of RFC 2181, section 5.2 says that it is an error and a protocol violation. Does that need more clarification? A -- Andrew Sullivan ajs@shinkuro.com Shinkuro, Inc. From vixie@isc.org Mon Feb 21 15:27:28 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 49FA13A635F for ; Mon, 21 Feb 2011 15:27:28 -0800 (PST) X-Quarantine-ID: X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER, Duplicate header field: "Cc" 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=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id isEUBB7rNyR5 for ; Mon, 21 Feb 2011 15:27:27 -0800 (PST) Received: from nsa.vix.com (unknown [IPv6:2001:4f8:3:bb:230:48ff:fe5a:2f38]) by core3.amsl.com (Postfix) with ESMTP id 55D5A3A6359 for ; Mon, 21 Feb 2011 15:27:27 -0800 (PST) Received: from nsa.vix.com (localhost [127.0.0.1]) by nsa.vix.com (Postfix) with ESMTP id D59F3A1059; Mon, 21 Feb 2011 23:28:08 +0000 (UTC) (envelope-from vixie@isc.org) From: Paul Vixie To: Andrew Sullivan In-Reply-To: Your message of "Mon, 21 Feb 2011 17:43:51 EST." <20110221224349.GT32224@shinkuro.com> References: <4D622624.90303@ogud.com> <76781.1298327469@nsa.vix.com> <20110221224349.GT32224@shinkuro.com> X-Mailer: MH-E 8.2; nmh 1.2; XEmacs 21.4 (patch 22) Date: Mon, 21 Feb 2011 23:28:08 +0000 Message-ID: <80121.1298330888@nsa.vix.com> Cc: dnsext@ietf.org Subject: Re: [dnsext] WG opinion on draft : Improvements to DNS Resolvers, for Resiliency, Robustness, and Responsiveness X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 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, 21 Feb 2011 23:27:28 -0000 > Date: Mon, 21 Feb 2011 17:43:51 -0500 > From: Andrew Sullivan > > My reading of RFC 2181, section 5.2 says that it is an error and a > protocol violation. Does that need more clarification? yes. no initiator i know of discards rrsets just due to ttl variance. therefore the guideance to initiators is effectively "do what BIND4 4.9 did" in other words treat the whole rr set as though it had the ttl of the lowest rr therein. if rfc 2181 does not make this clear then it is not providing reasonable and actionable guideance. From george.barwood@blueyonder.co.uk Tue Feb 22 00:47:10 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EBD5A3A677E for ; Tue, 22 Feb 2011 00:47:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.045 X-Spam-Level: * X-Spam-Status: No, score=1.045 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, HELO_EQ_BLUEYON=1.4, J_CHICKENPOX_55=0.6, MIME_BASE64_BLANKS=0.041, MIME_BASE64_TEXT=1.753] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Wfe+cqEDqH1U for ; Tue, 22 Feb 2011 00:47:09 -0800 (PST) Received: from smtp-out4.blueyonder.co.uk (smtp-out4.blueyonder.co.uk [195.188.213.7]) by core3.amsl.com (Postfix) with ESMTP id 750123A676A for ; Tue, 22 Feb 2011 00:47:09 -0800 (PST) Received: from [172.23.170.141] (helo=anti-virus02-08) by smtp-out4.blueyonder.co.uk with smtp (Exim 4.52) id 1PrnuR-000782-Sw; Tue, 22 Feb 2011 08:47:51 +0000 Received: from [92.238.99.235] (helo=GeorgeLaptop) by asmtp-out3.blueyonder.co.uk with smtp (Exim 4.72) (envelope-from ) id 1PrnuG-0005pu-7i; Tue, 22 Feb 2011 08:47:40 +0000 Message-ID: <16828D1CC85F4F438BFE576A48828FBB@local> From: "George Barwood" To: "Mark Andrews" References: <20110219210716.72943A5602B@drugs.dv.isc.org> <20110220203156.C1F83A6526F@drugs.dv.isc.org><3764325DE7FA4B2F9B77387EBD15EAF8@local> <20110220210758.81B93A65431@drugs.dv.isc.org><3D9B2A0D15F84DC6822FCF0FC6F8F214@local> <20110220225811.1F68CA65BFC@drugs.dv.isc.org> <4DFFA0E09D824AEC92EA89AFFB9F2120@local> <20110221220645.D59D1A87710@drugs.dv.isc.org> Date: Tue, 22 Feb 2011 08:48:06 -0000 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.5994 Cc: dnsext@ietf.org Subject: Re: [dnsext] Failure to add glue MUST cause TC to be set. X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 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, 22 Feb 2011 08:47:11 -0000 DQotLS0tLSBPcmlnaW5hbCBNZXNzYWdlIC0tLS0tIA0KRnJvbTogIk1hcmsgQW5kcmV3cyIgPG1h cmthQGlzYy5vcmc+DQpUbzogIkdlb3JnZSBCYXJ3b29kIiA8Z2VvcmdlLmJhcndvb2RAYmx1ZXlv bmRlci5jby51az4NCkNjOiA8ZG5zZXh0QGlldGYub3JnPg0KU2VudDogTW9uZGF5LCBGZWJydWFy eSAyMSwgMjAxMSAxMDowNiBQTQ0KU3ViamVjdDogUmU6IFtkbnNleHRdIEZhaWx1cmUgdG8gYWRk IGdsdWUgTVVTVCBjYXVzZSBUQyB0byBiZSBzZXQuDQoNCg0KPiANCj4gSW4gbWVzc2FnZSA8NERG RkEwRTA5RDgyNEFFQzkyRUE4OUFGRkI5RjIxMjBAbG9jYWw+LCAiR2VvcmdlIEJhcndvb2QiIHdy aXRlczoNCj4+IA0KPj4gLS0tLS0gT3JpZ2luYWwgTWVzc2FnZSAtLS0tLSANCj4+IEZyb206ICJN YXJrIEFuZHJld3MiIDxtYXJrYUBpc2Mub3JnPg0KPj4gVG86ICJHZW9yZ2UgQmFyd29vZCIgPGdl b3JnZS5iYXJ3b29kQGJsdWV5b25kZXIuY28udWs+DQo+PiBDYzogPGRuc2V4dEBpZXRmLm9yZz4N Cj4+IFNlbnQ6IFN1bmRheSwgRmVicnVhcnkgMjAsIDIwMTEgMTA6NTggUE0NCj4+IFN1YmplY3Q6 IFJlOiBbZG5zZXh0XSBGYWlsdXJlIHRvIGFkZCBnbHVlIE1VU1QgY2F1c2UgVEMgdG8gYmUgc2V0 Lg0KPj4gDQo+PiANCj4+ID4gDQo+PiA+IEluIG1lc3NhZ2UgPDNEOUIyQTBEMTVGODREQzY4MjJG Q0YwRkM2RjhGMjE0QGxvY2FsPiwgIkdlb3JnZSBCYXJ3b29kIiB3cml0ZXM6DQo+PiA+PiANCj4+ ID4+IC0tLS0tIE9yaWdpbmFsIE1lc3NhZ2UgLS0tLS0gDQo+PiA+PiBGcm9tOiAiTWFyayBBbmRy ZXdzIiA8bWFya2FAaXNjLm9yZz4NCj4+ID4+IFRvOiAiR2VvcmdlIEJhcndvb2QiIDxnZW9yZ2Uu YmFyd29vZEBibHVleW9uZGVyLmNvLnVrPg0KPj4gPj4gQ2M6IDxkbnNleHRAaWV0Zi5vcmc+DQo+ PiA+PiBTZW50OiBTdW5kYXksIEZlYnJ1YXJ5IDIwLCAyMDExIDk6MDcgUE0NCj4+ID4+IFN1Ympl Y3Q6IFJlOiBbZG5zZXh0XSBGYWlsdXJlIHRvIGFkZCBnbHVlIE1VU1QgY2F1c2UgVEMgdG8gYmUg c2V0Lg0KPj4gPj4gDQo+PiA+PiANCj4+ID4+ID4gDQo+PiA+PiA+IEluIG1lc3NhZ2UgPDM3NjQz MjVERTdGQTRCMkY5Qjc3Mzg3RUJEMTVFQUY4QGxvY2FsPiwgIkdlb3JnZSBCYXJ3b29kIiB3cml0 ZXM6DQo+PiA+PiA+PiA+PiAtLS0tLSBPcmlnaW5hbCBNZXNzYWdlIC0tLS0tIA0KPj4gPj4gPj4g Pj4gRnJvbTogIk1hcmsgQW5kcmV3cyIgPG1hcmthQGlzYy5vcmc+DQo+PiA+PiA+PiA+PiBUbzog PGRuc2V4dEBpZXRmLm9yZz4NCj4+ID4+ID4+ID4+IFNlbnQ6IFNhdHVyZGF5LCBGZWJydWFyeSAx OSwgMjAxMSA5OjA3IFBNDQo+PiA+PiA+PiA+PiBTdWJqZWN0OiBbZG5zZXh0XSBGYWlsdXJlIHRv IGFkZCBnbHVlIE1VU1QgY2F1c2UgVEMgdG8gYmUgc2V0Lg0KPj4gPj4gPj4gPj4gDQo+PiA+PiA+ PiA+PiA+IEJlbG93IGlzIGEgZXhhbXBsZSBvZiB3aHkgVEMgc2hvdWxkIGJlIHNldCB3aGVuIGds dWUgY2Fubm90IGJlIGFkZGVkDQo+PiA+PiA+PiA+PiA+IHRvIHRoZSBhbnN3ZXIuDQo+PiA+PiA+ PiA+PiA+IA0KPj4gPj4gPj4gPj4gPiBbLi5dDQo+PiA+PiA+PiA+PiANCj4+ID4+ID4+ID4+IEFn cmVlZCwgYnV0IHdoZXJlIGV4YWN0bHkgc2hvdWxkIHRoZSBsaW5lIGJlIGRyYXduPw0KPj4gPj4g Pj4gPiANCj4+ID4+ID4+ID4gV2hhdCBsaW5lPyAgSWYgdGhlIGdsdWUgZG9lc24ndCBmaXQgdGhl biB0aGUgcmVmZXJyYWwgaXMgbm90IGNvbXBsZXRlLg0KPj4gPj4gPj4gPiANCj4+ID4+ID4+ID4+ IElmIG9taXR0aW5nIGFueSBnbHVlIGxlYWRzIHRvIHRydW5jYXRpb24sIHRoZW4gbWFueSAobm9u LUROU1NFQykgcmVmZXJyYWxzDQo+PiA+PiA+PiA+PiBvdmVyIFVEUCB3aWxsIGhhdmUgVEMgc2V0 LiBlLmcuIA0KPj4gPj4gPj4gPj4gDQo+PiA+PiA+PiA+PiBkaWcgZm9vLmNvbSBAYS5yb290LXNl cnZlcnMubmV0DQo+PiA+PiA+PiA+IA0KPj4gPj4gPj4gPiBZZXMuDQo+PiA+PiA+PiA+IA0KPj4g Pj4gPj4gPj4gSXMgdGhhdCBzZW5zaWJsZT8NCj4+ID4+ID4+ID4gDQo+PiA+PiA+PiA+IFllcy4N Cj4+ID4+ID4+ID4gDQo+PiA+PiA+PiA+PiBIb3cgbXVjaCBnbHVlIGlzIGVub3VnaD8NCj4+ID4+ ID4+ID4gDQo+PiA+PiA+PiA+IERlcGVuZHMgb24gdGhlIGRlbGVnYXRpb24uICBUaGUgb25seSBz YWZlIGFuc3dlciBpcyBhbGwgeW91IGhhdmUuDQo+PiA+PiA+PiANCj4+ID4+ID4+IE9uZSBzdWdn ZXN0aW9uIHRoYXQgbWlnaHQgd29yayBpcyB0aGF0IGdsdWUgd2hpY2ggbWF0Y2hzIFFOQU1FK1FU WVBFIE1VU1QNCj4+ID4+ID4+IGJlIGluY2x1ZGVkLCBidXQgb3RoZXIgZ2x1ZSBjYW4gYmUgb21p dHRlZC4NCj4+ID4+ID4gDQo+PiA+PiA+IFRoaXMgZG9lcyBub3Qgd29yayBpbiBhbGwgY2FzZXMg d2hlcmUgZ2x1ZSBuZWVkcyB0byBiZSByZXR1cm5lZC4NCj4+ID4+ID4gDQo+PiA+PiA+IFpvbmUg QS5uZXQgaXMgc2VydmVkIGJ5IHNlcnZlcnMgaW4gQi5uZXQuICBab25lIEIubmV0IGlzIHNlcnZl ZCBieQ0KPj4gPj4gPiBzZXJ2ZXJzIGluIEEubmV0Lg0KPj4gPj4gDQo+PiA+PiBTbyBzb21ldGhp bmcgbGlrZQ0KPj4gPj4gDQo+PiA+PiANCj4+ID4+IEJ1dCBub3RoaW5nIHdpbGwgd29yayBpbiB0 aGF0IGNhc2UgLSBpZiB5b3UgbWFrZSBhIHJlY3Vyc2l2ZSBsb29wIGxpa2UgdGhpcywNCj4+ID4+ IHRoZW4gdGhlcmUgaXMgbm8gZ2x1ZSAoIHRoZSBuYW1lIHNlcnZlciBuYW1lcyBhcmUgbm90ICJi ZWxvdyIgdGhlIGN1dCApIGFuZA0KPj4gPj4geW91IGhhdmUgaGFkIGl0IHJlZ2FyZGxlc3MuIA0K Pj4gPiANCj4+ID4gR2x1ZSByZWNvcmRzIGFyZSByZWNvcmRzIGluIHRoZSBwYXJlbnQgem9uZSB0 byBlbmFibGUgeW91IHRvIHJlYWNoDQo+PiA+IHRoZSBzZXJ2ZXJzIGZvciB0aGUgY2hpbGQgem9u ZS4gIFJGQyAxMDM0IGdhdmUgYSBvYnZpb3VzIGV4YW1wbGUNCj4+ID4gb2Ygc3VjaCByZWNvcmRz LiAgVGhlcmUgYXJlIGxlc3Mgb2J2aW91cyBleGFtcGxlcy4NCj4+ID4gDQo+PiA+PiBUaGF0J3Mg YSBtaXMtY29uZmlndXJhdGlvbiwgbm90IGEgY291bnRlci1leGFtcGxlLg0KPj4gPiANCj4+ID4g Tm8uIEl0IGlzIG5vdCBhIG1pcy1jb25maWd1cmF0aW9uLg0KPj4gDQo+PiBSRkMxMDM0IHNheXMN Cj4+IA0KPj4gICBUbyBmaXggdGhpcyBwcm9ibGVtLCBhIHpvbmUgY29udGFpbnMgImdsdWUiIFJS cyB3aGljaCBhcmUgbm90DQo+PiAgIHBhcnQgb2YgdGhlIGF1dGhvcml0YXRpdmUgZGF0YSwgYW5k IGFyZSBhZGRyZXNzIFJScyBmb3IgdGhlIHNlcnZlcnMuDQo+PiAgIFRoZXNlIFJScyBhcmUgb25s eSBuZWNlc3NhcnkgaWYgdGhlIG5hbWUgc2VydmVyJ3MgbmFtZSBpcyAiYmVsb3ciIHRoZQ0KPj4g ICBjdXQsIGFuZCBhcmUgb25seSB1c2VkIGFzIHBhcnQgb2YgYSByZWZlcnJhbCByZXNwb25zZS4N Cj4+IA0KPj4gVGhlIHNlY29uZCBzZW50ZW5jZSBydWxlcyBvdXQgdGhlIG11dHVhbGx5IHJlY3Vy c2l2ZSBjYXNlICggdmVyeSBzZW5zaWJseSApLg0KPiANCj4gTm8uICBJdCBqdXN0IG1lYW5zIHRo YXQgdGhleSBmYWlsZWQgdG8gZnVsbHkgYW5hbHlzZSB0aGUgcHJvYmxlbS4NCg0KVGhhdCdzIHBv c3NpYmxlLiBPciB0aGV5IG1heSBoYXZlIGZ1bGx5IHVuZGVyc3Rvb2QgYW5kIGNob3NlbiB0aGlz IGZvcm0gb2Ygd29yZHMNCnRvIHJ1bGUgb3V0IHRoZSBtdXR1YWxseSByZWN1cnNpdmUgY2FzZSBp biBhIHN1YnRsZSB3YXkuDQoNCkkgdGhpbmsgdGhlIG90aGVyIHBvc3NpYmlsaXR5IGlzIHRoZXkg d2VyZSB2aWV3aW5nIGl0IGZyb20gYW4gb3BlcmF0b3JzIHBvaW50IG9mIHZpZXcuDQpUaGV5IHdl cmUgc2F5aW5nICJ0aGlzIGlzIGFsbCB5b3UgbmVlZCIuIFJGQzEwMzMgaGFzIHNpbWlsYXIgbGFu Z3VhZ2UuDQoNClJlZ2FyZGxlc3MsIHRoZSBSRkMgZG9lcyBub3QgZGVhbCB3aXRoIHRoaXMgY2Fz ZSwgc28gaXQncyBiZXN0IHRvIGF2b2lkIGl0Lg0KTXkgcmVzb2x2ZXIgcmVqZWN0cyBhbGwgZ2x1 ZSB0aGF0IGlzIG5vdCBpbi16b25lLCBhbmQgaW4gc2V2ZXJhbCB5ZWFycyBvZiB1c2UgSSBoYXZl IG5vdCBzZWVuIGEgcHJvYmxlbSwNCnNvIGl0IHNlZW1zIHRoYXQgdGhpcyB0ZWNobmlxdWUgaXMg bm90IGluIHdpZGVzcHJlYWQgdXNlLg0KDQo+IA0KPiBJZiB0aGV5IHdhbnRlZCB0byBwcmV2ZW50 IHRoZSBtdXR1YWxseSByZWN1cnNpdmUgY2FzZSB0aGVyZSB3b3VsZA0KPiBoYXZlIGJlZW4gd29y ZHMgdG8gb3V0bGF3IGl0IG9yIHdhcm4gb2YgaXQuICBSRkMgMTAzNCBjb250YWlucyBsb3RzDQo+ IG9mIGVycm9ycyB0aGlzIGlzIGp1c3QgYW5vdGhlciBvbmUuDQoNCkkgZG9uJ3QgdGhpbmsgeW91 IGNhbiBjYWxsIGl0IGFuIGVycm9yLiBJdCBpcyBhbiBhbWJpZ3VpdHkgLyBvbWlzc2lvbi4NCg0K QW55d2F5LCByZWdhcmRsZXNzLCB0byBjb21lIGJhY2sgdG8gdGhlIG9yaWdpbmFsIHN1Z2dlc3Rp b24gb24gd2hlbiBnbHVlIGlzIGVzc2VudGlhbC4NCklmIHlvdSB3YW50IHRvIHN1cHBvcnQgdGhp cyBleHRlbmRlZCBmb3JtIG9mIGdsdWUsIHRoZW4gc3VjaCBnbHVlIHJlY29yZHMgbXVzdCBiZSBp bmNsdWRlZA0KaW4gYSByZWZlcnJhbCwgd2l0aCBUQyBzZXQgaWYgdGhlcmUgaXMgbm8gcm9vbS4g IkNvbnZlbnRpb25hbCIgKGluLXpvbmUpIGdsdWUgcmVjb3JkcyBjYW4NCmJlIG9taXR0ZWQgKHRv IGF2b2lkIHRydW5jYXRpb24pIHVubGVzcyB0aGV5IG1hdGNoIFFOQU1FL1FUWVBFLg0KVGhpcyBy dWxlIGF2b2lkcyBUQ1AgZmFsbGJhY2sgaW4gY29tbW9uIG5vbi1ETlNTRUMgY2FzZXMuDQoNCkdl b3JnZQ0KIA0KPiBNYXJrDQo+IC0tIA0KPiBNYXJrIEFuZHJld3MsIElTQw0KPiAxIFNleW1vdXIg U3QuLCBEdW5kYXMgVmFsbGV5LCBOU1cgMjExNywgQXVzdHJhbGlhDQo+IFBIT05FOiArNjEgMiA5 ODcxIDQ3NDIgICAgICAgICAgICAgICAgIElOVEVSTkVUOiBtYXJrYUBpc2Mub3Jn From wouter@nlnetlabs.nl Tue Feb 22 02:30:46 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 361A83A6877 for ; Tue, 22 Feb 2011 02:30:46 -0800 (PST) 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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hOwEL4CDl23F for ; Tue, 22 Feb 2011 02:30:44 -0800 (PST) Received: from open.nlnetlabs.nl (open.nlnetlabs.nl [IPv6:2001:7b8:206:1::1]) by core3.amsl.com (Postfix) with ESMTP id F0DDA3A6875 for ; Tue, 22 Feb 2011 02:30:43 -0800 (PST) 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 p1MAVMqT089134 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Tue, 22 Feb 2011 11:31:22 +0100 (CET) (envelope-from wouter@nlnetlabs.nl) Message-ID: <4D63907A.8010700@nlnetlabs.nl> Date: Tue, 22 Feb 2011 11:31:22 +0100 From: "W.C.A. Wijngaards" User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.13) Gecko/20101209 Fedora/3.1.7-0.35.b3pre.fc13 Lightning/1.0b3pre Thunderbird/3.1.7 MIME-Version: 1.0 To: dnsext@ietf.org References: <4D622624.90303@ogud.com> 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.6 (open.nlnetlabs.nl [IPv6:2001:7b8:206:1::53]); Tue, 22 Feb 2011 11:31:22 +0100 (CET) Subject: Re: [dnsext] WG opinion on draft : Improvements to DNS Resolvers, for Resiliency, Robustness, and Responsiveness X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 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, 22 Feb 2011 10:30:46 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, I read (and implemented) this draft (as config options) some time ago. They are pretty good ideas, but I have some concerns, below. On 02/21/2011 08:51 PM, Brian Dickson wrote: > On Mon, Feb 21, 2011 at 2:58 PM, David Blacka wrote: >>> Background: The draft contains three recommendation on how resolvers operate, >>> A. Re-validating a delegation when a parent NS RRset TTL expires. >>> B. Stopping a downward cache search when an NXDOMAIN is encountered. >>> C. Upgrading the credibility of NS RRsets upon delegation event. >>> >> (A) is (I think) trying to solve issues caused by "cache pinning" when moving a zone from one set of nameservers to another. Actually, it goes further than that (if I understand the draft correctly, which I very well may not) by effectively removing entire delegation chains when the ancestor NS RRset expires. So, e.g., every time the com NS RRset expires, all delegations below it effectively expire. I have no idea what problem this overall behavior solves, although I suspect that it defeats a great deal of the value of a cache. > > > My read on the draft, and I'm reasonably confident it's what the > author intended, is that "stale" delegations be "refreshed" (or have a > "refresh" attempted) before they are used. > It is analogous to the "refresh" between master and slave authority > servers for a given zone, e.g. verifying the SOA SN if the "refresh" > timer fires off. Yes, I appreciate the utility of picking up new delegation changes once-in-a-while. > And, basically, the "refresh" is to make sure the delegation > (non-authoritative) NS records are "reasonably consistent" with what > was already cached, and if so, re-establishes the validity, re-sets > the TTL, and re-populates the NS set if some changes have occurred. > No expiration occurs, unless both (a) the TTL expires, and (b) the new > delegation NS RRSET has nothing in common with the cached RRset - in > which case, the child side and all descendants MUST be discarded. I think discarding the tree below is cache-management strategy, and was not the aim of point A. The usual DNS time shifted coherency is the goal. >> (B) is about having resolvers actually believe NXDOMAIN responses. While I think it might be nice if we could trust that NXDOMAIN actually meant that the name didn't exist, I don't see how this improves the "resiliency" or "robustness" of the *resolver*. > > This is one place where I think some updates to the ID need to be done. > > Basically, we need a reference (i.e. to RFCs in standard I-D style) > to the changes to the standard(s) that differentiate 1034's "Name > Error" from the two cases we now know about, "NXDOMAIN", and "empty > non-terminal" (a node with no RRs itself, which has descendants, > inside a zone). > > If I understand it, things should now work as follows: > - if an empty non-terminal matches a QNAME, the *answer* should be > empty, but there should *not* be any error code. > - if no domain exists (and that means neither the domain nor any > children exist), there *should* be an error code of NXDOMAIN Yes this problem exists. > And, given the logic immediate above, this means that NXDOMAIN can and > should be cached (if and only if the above applies), and when an > NXDOMAIN is cached, children of that node get discarded, and > subsequent queries to the *resolver* below that NXDOMAIN can > themselves be guaranteed to be NXDOMAINed, and there is no need to > send the query to the authority server for the given zone. > > But, this should be clarified in the text of the draft. > > I agree that it is a suitable optimization, and as I understand it, > correct behavior. I do not think you could enable this by default today, because very old software might still have bugs in handling empty nonterminals and send NXDOMAINs for them. >> (C) is about working around delegation scenarios that favor parent-side delegation information by instructing the resolver to directly query the child nameservers for NS records. I don't know what actual problem this is attempting to solve. Sounds like an idea of a Dutch guy. Disabled by default ... >>> 2. Is the draft clear in its message? If not, please suggest improvements. >> >> It is entirely unclear to me what problems the various proposals are actually trying to solve. Yes, that is not a part of the text. Perhaps a light-weight fix can be applied. >>> 3. After (if any) editing fixes is this draft ready for WG Last Call? That would be a little too quick. Best regards, Wouter -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iEYEARECAAYFAk1jkHkACgkQkDLqNwOhpPg29gCgnGOIlcuwoKhv+MslQ+09Dn8/ Y+IAoKmaCRUjQBZkwoRO7R+t5CbZ3s27 =9HrR -----END PGP SIGNATURE----- From segred@ics.forth.gr Tue Feb 22 05:41:25 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 792E93A68D6 for ; Tue, 22 Feb 2011 05:41:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.69 X-Spam-Level: X-Spam-Status: No, score=-6.69 tagged_above=-999 required=5 tests=[AWL=-0.091, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cJA1VoSxWGGB for ; Tue, 22 Feb 2011 05:41:24 -0800 (PST) Received: from mailgate.ics.forth.gr (mailgate.ics.forth.gr [139.91.1.2]) by core3.amsl.com (Postfix) with ESMTP id 5A0EC3A6812 for ; Tue, 22 Feb 2011 05:41:24 -0800 (PST) Received: from av1.ics.forth.gr (av1-in.ics.forth.gr [139.91.1.71]) by mailgate.ics.forth.gr (8.14.3/ICS-FORTH/V10-1.8-GATE) with ESMTP id p1MDfv1s025909; Tue, 22 Feb 2011 15:41:59 +0200 (EET) X-AuditID: 8b5b9d47-b7c88ae0000076fe-64-4d63bd256c57 Received: from enigma.ics.forth.gr (webmail.ics.forth.gr [139.91.1.30]) by av1.ics.forth.gr (SMTP Outbound / FORTH / ICS) with SMTP id 93.BC.30462.52DB36D4; Tue, 22 Feb 2011 15:41:57 +0200 (EET) Received: from Thanatos (thanatos.ics.forth.gr [139.91.88.160]) (authenticated bits=0) by enigma.ics.forth.gr (8.14.3//ICS-FORTH/V10.3.0C-EXTNULL-SSL-SASL) with ESMTP id p1MDftmS011121 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Tue, 22 Feb 2011 15:41:56 +0200 X-ICS-AUTH-INFO: Authenticated user: segred at ics.forth.gr From: "Vaggelis Segredakis" To: "'Eric Brunner-Williams'" References: <20110216073338.7251.qmail@joyce.lan> <20110216165921.GW96213@shinkuro.com> <3B90ED2E-980D-4B01-889F-447D66D0B58D@insensate.co.uk> <20110216174011.GZ96213@shinkuro.com> <20110218143653.GC84482@bikeshed.isc.org> <20110218151209.GF66684@shinkuro.com> <4D5EEE09.4080405@dougbarton.us> <20110218222950.GL74065@shinkuro.com> <4D5EF74C.9080603@dougbarton.us><20110218230905.GN74065@shinkuro.com> <4D5F270F.20401@abenaki.wabanaki.net> Date: Tue, 22 Feb 2011 15:40:33 +0200 Message-ID: <199C7B2B4228461FB024E59A990DB46D@ics.forth.gr> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <4D5F270F.20401@abenaki.wabanaki.net> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5994 Thread-Index: AcvP2okX4bWgtcrnQdWmwo9h1lgOeACundnQ X-Brightmail-Tracker: AAAAARdxlnE= X-j-chkmail-Score: MSGID : 4D63BD25.002 on mailgate : j-chkmail score : . : R=. U=. O=. B=0.000 -> S=0.000 X-ICS-JCHK-SCL: Ham Cc: dnsext@ietf.org Subject: Re: [dnsext] we need help to make names the same, was draft-yao-dnsext-identical-resolution-02 comment X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 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, 22 Feb 2011 13:41:25 -0000 Hi Eric, >err, well, yes in principle, and no in practice. that is, a series of >pick-according-to-taste-or-belief{blunders, errors, accidents, acts of >genius} has lead to some specific use cases. han sc/tc. greek tonos. >failing to solve leads to unintended consequences. I couldn't agree more with your last sentence above. Before landing in this WG with this issue I tried to explain the situation back when the first protocol of IDNs was designed. The belief then that a protocol should not take into consideration specific issues but rather stick to the "domains are not words" motto brought us all ten years later to the point of discussing adding rr types in DNS, rather than designing correctly a translating application-layer protocol right from the beginning, with formatting data etc to solve all problems. Best, Vaggelis Segredakis From ajs@shinkuro.com Tue Feb 22 06:09:35 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 08C0B3A68F2 for ; Tue, 22 Feb 2011 06:09:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.581 X-Spam-Level: X-Spam-Status: No, score=-102.581 tagged_above=-999 required=5 tests=[AWL=0.018, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KSFnWrRLeCNR for ; Tue, 22 Feb 2011 06:09:34 -0800 (PST) Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by core3.amsl.com (Postfix) with ESMTP id 2481F3A68F0 for ; Tue, 22 Feb 2011 06:09:34 -0800 (PST) Received: from crankycanuck.ca (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 139711ECB408 for ; Tue, 22 Feb 2011 14:10:18 +0000 (UTC) Date: Tue, 22 Feb 2011 09:10:16 -0500 From: Andrew Sullivan To: dnsext@ietf.org Message-ID: <20110222141016.GC53815@shinkuro.com> References: <4D622624.90303@ogud.com> <76781.1298327469@nsa.vix.com> <20110221224349.GT32224@shinkuro.com> <80121.1298330888@nsa.vix.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <80121.1298330888@nsa.vix.com> User-Agent: Mutt/1.5.18 (2008-05-17) Subject: Re: [dnsext] WG opinion on draft : Improvements to DNS Resolvers, for Resiliency, Robustness, and Responsiveness X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 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, 22 Feb 2011 14:09:35 -0000 No hat. On Mon, Feb 21, 2011 at 11:28:08PM +0000, Paul Vixie wrote: > yes. no initiator i know of discards rrsets just due to ttl variance. > therefore the guideance to initiators is effectively "do what BIND4 > 4.9 did" in other words treat the whole rr set as though it had the > ttl of the lowest rr therein. if rfc 2181 does not make this clear > then it is not providing reasonable and actionable guideance. Well, here's the section in toto: 5.2. TTLs of RRs in an RRSet Resource Records also have a time to live (TTL). It is possible for the RRs in an RRSet to have different TTLs. No uses for this have been found that cannot be better accomplished in other ways. This can, however, cause partial replies (not marked "truncated") from a caching server, where the TTLs for some but not all the RRs in the RRSet have expired. Consequently the use of differing TTLs in an RRSet is hereby deprecated, the TTLs of all RRs in an RRSet must be the same. Should a client receive a response containing RRs from an RRSet with differing TTLs, it should treat this as an error. If the RRSet concerned is from a non-authoritative source for this data, the client should simply ignore the RRSet, and if the values were required, seek to acquire them from an authoritative source. Clients that are configured to send all queries to one, or more, particular servers should treat those servers as authoritative for this purpose. Should an authoritative source send such a malformed RRSet, the client should treat the RRs for all purposes as if all TTLs in the RRSet had been set to the value of the lowest TTL in the RRSet. In no case may a server send an RRSet with TTLs not all equal. To me, it's pretty clear (1) that having different TTL values on RRs in the RRset is an error, (2) that you should just ignore such RRsets if they're not authoritative, (3) that is is a protocol error to send an RRset with different TTLs on different RRs in the set, and (4) that any client receiving such a set should use the lowest TTL in the set for everything. My own view is that the requirements are crystal clear, and since RFC 2181 updates all of 1034, 1035, and 1123 I think it changes the protocol. According to STD1, it's a Proposed Standard. A -- Andrew Sullivan ajs@shinkuro.com Shinkuro, Inc. From hallam@gmail.com Tue Feb 22 06:34:37 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 143263A68E2 for ; Tue, 22 Feb 2011 06:34:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.551 X-Spam-Level: X-Spam-Status: No, score=-3.551 tagged_above=-999 required=5 tests=[AWL=0.047, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sJ+iwfX6JA8X for ; Tue, 22 Feb 2011 06:34:36 -0800 (PST) Received: from mail-bw0-f54.google.com (mail-bw0-f54.google.com [209.85.214.54]) by core3.amsl.com (Postfix) with ESMTP id 4F8DC3A689A for ; Tue, 22 Feb 2011 06:34:35 -0800 (PST) Received: by bwz12 with SMTP id 12so3721827bwz.27 for ; Tue, 22 Feb 2011 06:35:19 -0800 (PST) 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=HDlgv8UIdvGaBnwz/asJnheih5l3bsoiQ6wLGY/5LwU=; b=mmKfsCenWFe1TF6hb9ipqz+dxKKr1r2LTox21k8jiiG4iDPmD66l3Vbs1xlr7IBnsB 80VWuZuZ0sXqUVmEp3RzB7edIRrdVjfB29zZkwRsiOXCrNbktRYZby8vwaclFhyDMQZt W6NpfsklJHa5HjfgtYuZ7/RCh4Tpcb5Fwojok= 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=j3XhoNXHSue+7B5VtcaHX0KmJvMKd18VTzrqMsq25eQbILM2pYpVY4CvdfuUh+mErj CWxJXoYlXSW82AsMvwEKozj6tMCTiOZRqz4Z3/ITh9KLQlPBjwnZBVP4amnoIZyt3sf7 hSKC71rKQWP0OLeuAZhIGWfn5a1eKlelgiQyo= MIME-Version: 1.0 Received: by 10.204.122.68 with SMTP id k4mr2565637bkr.153.1298385318935; Tue, 22 Feb 2011 06:35:18 -0800 (PST) Received: by 10.204.14.139 with HTTP; Tue, 22 Feb 2011 06:35:18 -0800 (PST) In-Reply-To: <199C7B2B4228461FB024E59A990DB46D@ics.forth.gr> References: <20110216073338.7251.qmail@joyce.lan> <20110216165921.GW96213@shinkuro.com> <3B90ED2E-980D-4B01-889F-447D66D0B58D@insensate.co.uk> <20110216174011.GZ96213@shinkuro.com> <20110218143653.GC84482@bikeshed.isc.org> <20110218151209.GF66684@shinkuro.com> <4D5EEE09.4080405@dougbarton.us> <20110218222950.GL74065@shinkuro.com> <4D5EF74C.9080603@dougbarton.us> <20110218230905.GN74065@shinkuro.com> <4D5F270F.20401@abenaki.wabanaki.net> <199C7B2B4228461FB024E59A990DB46D@ics.forth.gr> Date: Tue, 22 Feb 2011 09:35:18 -0500 Message-ID: From: Phillip Hallam-Baker To: Vaggelis Segredakis Content-Type: multipart/alternative; boundary=0016e6dee788b77c53049cdfe39f Cc: dnsext@ietf.org Subject: Re: [dnsext] we need help to make names the same, was draft-yao-dnsext-identical-resolution-02 comment X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 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, 22 Feb 2011 14:34:37 -0000 --0016e6dee788b77c53049cdfe39f Content-Type: text/plain; charset=ISO-8859-1 I think the big problem here is the failure to accept the fact that the problem as stated is ambiguous and interpreted literally is nonsense. If we have two trees, x.y.z.a, x.y.z.b what does it mean for them both to be 'the same'? Do we mean the same from an application point of view or from a DNS layer point of view? Solving the problem from the application point of view is easy. We just invent a new pointer that aware applications can interpret. Non-aware applications will not. Making the two trees 'the same' at a DNS level appears to me to be nonsense. It is only possible for the DNSSEC signature to be for one of them. So they are not going to be exactly the same, one must inevitably be the canonical form. This particular issue seems to arise from certain political objectives, the futility of which has been amply demonstrated in the past few weeks. --0016e6dee788b77c53049cdfe39f Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I think the big problem here is the failure to accept the fact that the pro= blem as stated is ambiguous and interpreted literally is nonsense.

=

If we have two trees,=A0x.y.z.a, x.y.z.b what doe= s it mean for them both to be 'the same'?

Do we mean the same from an application point of view o= r from a DNS layer point of view?


S= olving the problem from the application point of view is easy. We just inve= nt a new pointer that aware applications can interpret. Non-aware applicati= ons will not.

Making the two trees 'the same' at a DNS level = appears to me to be nonsense. It is only possible for the DNSSEC signature = to be for one of them. So they are not going to be exactly the same, one mu= st inevitably be the canonical form.


This particular issue seems to arise fro= m certain political objectives, the futility of which has been amply demons= trated in the past few weeks.

--0016e6dee788b77c53049cdfe39f-- From ebw@abenaki.wabanaki.net Tue Feb 22 08:55:12 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9574A3A691F for ; Tue, 22 Feb 2011 08:55:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.044 X-Spam-Level: X-Spam-Status: No, score=-2.044 tagged_above=-999 required=5 tests=[AWL=0.555, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kraNvci9-z39 for ; Tue, 22 Feb 2011 08:55:11 -0800 (PST) Received: from abenaki.wabanaki.net (abenaki.wabanaki.net [65.99.1.133]) by core3.amsl.com (Postfix) with ESMTP id A19923A68EF for ; Tue, 22 Feb 2011 08:55:11 -0800 (PST) Received: from limpet.local (cpe-67-255-5-237.twcny.res.rr.com [67.255.5.237]) by abenaki.wabanaki.net (8.14.4/8.14.4) with ESMTP id p1MF9S21046013; Tue, 22 Feb 2011 10:09:28 -0500 (EST) (envelope-from ebw@abenaki.wabanaki.net) Message-ID: <4D63EA86.2090206@abenaki.wabanaki.net> Date: Tue, 22 Feb 2011 11:55:34 -0500 From: Eric Brunner-Williams Organization: wampumpeag User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: Vaggelis Segredakis References: <20110216073338.7251.qmail@joyce.lan> <20110216165921.GW96213@shinkuro.com> <3B90ED2E-980D-4B01-889F-447D66D0B58D@insensate.co.uk> <20110216174011.GZ96213@shinkuro.com> <20110218143653.GC84482@bikeshed.isc.org> <20110218151209.GF66684@shinkuro.com> <4D5EEE09.4080405@dougbarton.us> <20110218222950.GL74065@shinkuro.com> <4D5EF74C.9080603@dougbarton.us><20110218230905.GN74065@shinkuro.com> <4D5F270F.20401@abenaki.wabanaki.net> <199C7B2B4228461FB024E59A990DB46D@ics.forth.gr> In-Reply-To: <199C7B2B4228461FB024E59A990DB46D@ics.forth.gr> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: dnsext@ietf.org Subject: Re: [dnsext] we need help to make names the same, was draft-yao-dnsext-identical-resolution-02 comment X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 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, 22 Feb 2011 16:55:12 -0000 On 2/22/11 8:40 AM, Vaggelis Segredakis wrote: > Hi Eric, > >> err, well, yes in principle, and no in practice. that is, a series of >> pick-according-to-taste-or-belief{blunders, errors, accidents, acts of >> genius} has lead to some specific use cases. han sc/tc. greek tonos. >> failing to solve leads to unintended consequences. > > I couldn't agree more with your last sentence above. Before landing in this > WG with this issue I tried to explain the situation back when the first > protocol of IDNs was designed. The belief then that a protocol should not > take into consideration specific issues but rather stick to the "domains are > not words" motto brought us all ten years later to the point of discussing > adding rr types in DNS, rather than designing correctly a translating > application-layer protocol right from the beginning, with formatting data > etc to solve all problems. It is peculiar that we have both the uninterpreted 8 bits semantics, however unfashionable binary labels are presently, and the xn-- prefix to signal an encoding within a larger repertoire of characters, and the per-character associated property of directionality, and probably some other stuff that escapes me writing this will on a concall, yet we have nothing (I can think of) that provides a description of (sub)string (sequence of character) semantics (other than the charming property of "." as construed by the UTC, of directionality, which it happily associates with proximal characters, effecting directional leakage across label boundaries in bidi scripts). A source of requirements has been primarily concerned with the visual similarity of some characters in larger repertoire in a single name space. While this appears to be a "sub-word" concern, as the problem to be solved is significantly less common absent outside of that single name space, it is confusing that this is not viewed as an instance of the "domain is a word" frame of reference. I mention this to point out that the sources of requirements have addressed issues other than those identified in this thread. Eric From mohta@necom830.hpcl.titech.ac.jp Tue Feb 22 12:34:33 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 697673A6974 for ; Tue, 22 Feb 2011 12:34:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.098 X-Spam-Level: X-Spam-Status: No, score=-0.098 tagged_above=-999 required=5 tests=[AWL=-0.008, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bRrTJEwzjT3T for ; Tue, 22 Feb 2011 12:34:32 -0800 (PST) Received: from necom830.hpcl.titech.ac.jp (necom830.hpcl.titech.ac.jp [131.112.32.132]) by core3.amsl.com (Postfix) with SMTP id 41B533A6955 for ; Tue, 22 Feb 2011 12:34:31 -0800 (PST) Received: (qmail 89418 invoked from network); 22 Feb 2011 20:47:01 -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; 22 Feb 2011 20:47:01 -0000 Message-ID: <4D641DB6.4090705@necom830.hpcl.titech.ac.jp> Date: Wed, 23 Feb 2011 05:33:58 +0900 From: Masataka Ohta User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; ja; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: dnsext@ietf.org References: <20110216073338.7251.qmail@joyce.lan> <20110216165921.GW96213@shinkuro.com> <3B90ED2E-980D-4B01-889F-447D66D0B58D@insensate.co.uk> <20110216174011.GZ96213@shinkuro.com> <20110218143653.GC84482@bikeshed.isc.org> <20110218151209.GF66684@shinkuro.com> <4D5EEE09.4080405@dougbarton.us> <20110218222950.GL74065@shinkuro.com> <4D5EF74C.9080603@dougbarton.us><20110218230905.GN74065@shinkuro.com> <4D5F270F.20401@abenaki.wabanaki.net> <199C7B2B4228461FB024E59A990DB46D@ics.forth.gr> In-Reply-To: <199C7B2B4228461FB024E59A990DB46D@ics.forth.gr> Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit Subject: Re: [dnsext] we need help to make names the same, was draft-yao-dnsext-identical-resolution-02 comment X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 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, 22 Feb 2011 20:34:33 -0000 Vaggelis Segredakis wrote: >> err, well, yes in principle, and no in practice. that is, a series of >> pick-according-to-taste-or-belief{blunders, errors, accidents, acts of >> genius} has lead to some specific use cases. han sc/tc. greek tonos. >> failing to solve leads to unintended consequences. > > I couldn't agree more with your last sentence above. Before landing in this > WG with this issue I tried to explain the situation back when the first > protocol of IDNs was designed. It was about 14 or 15 years ago, when I, and some others, argued against localized domain names exactly the same reasons as today: sameness including case correspondence of accented characters and improper (prohibitively complex) support for bidirectionality. So, you have been warned. > The belief then that a protocol should not take into > consideration specific issues but rather stick to the "domains > are not words" motto brought us all ten years later to the point > of discussing adding rr types in DNS, rather than designing > correctly a translating application-layer protocol right from > the beginning, with formatting data etc to solve all problems. Some of the problems can be solved only by fundamental redesign of character encoding (effectively abandoning Unicode). Avoiding to do so, more than 10 years have wasted already. Masataka Ohta From ajs@shinkuro.com Tue Feb 22 12:55:38 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6DC923A68F9 for ; Tue, 22 Feb 2011 12:55:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.582 X-Spam-Level: X-Spam-Status: No, score=-102.582 tagged_above=-999 required=5 tests=[AWL=0.017, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W6mdOW9Ow2rh for ; Tue, 22 Feb 2011 12:55:35 -0800 (PST) Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by core3.amsl.com (Postfix) with ESMTP id F3CB33A67F1 for ; Tue, 22 Feb 2011 12:55:34 -0800 (PST) Received: from crankycanuck.ca (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 3CA3F1ECB408 for ; Tue, 22 Feb 2011 20:56:19 +0000 (UTC) Date: Tue, 22 Feb 2011 15:56:17 -0500 From: Andrew Sullivan To: dnsext@ietf.org Message-ID: <20110222205617.GS53815@shinkuro.com> References: <20110216165921.GW96213@shinkuro.com> <3B90ED2E-980D-4B01-889F-447D66D0B58D@insensate.co.uk> <20110216174011.GZ96213@shinkuro.com> <20110218143653.GC84482@bikeshed.isc.org> <20110218151209.GF66684@shinkuro.com> <4D5EEE09.4080405@dougbarton.us> <20110218222950.GL74065@shinkuro.com> <4D5F270F.20401@abenaki.wabanaki.net> <199C7B2B4228461FB024E59A990DB46D@ics.forth.gr> <4D641DB6.4090705@necom830.hpcl.titech.ac.jp> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4D641DB6.4090705@necom830.hpcl.titech.ac.jp> User-Agent: Mutt/1.5.18 (2008-05-17) Subject: Re: [dnsext] we need help to make names the same, was draft-yao-dnsext-identical-resolution-02 comment X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 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, 22 Feb 2011 20:55:38 -0000 Moderator hat on. On Wed, Feb 23, 2011 at 05:33:58AM +0900, Masataka Ohta wrote: > > Some of the problems can be solved only by fundamental redesign > of character encoding (effectively abandoning Unicode). > > Avoiding to do so, more than 10 years have wasted already. Ok, you've made this claim repeatedly. We've heard it. Like it or not, the actual computer world we actually have is using Unicode, and IDNA is using it too. Repeating over and over again that it won't work isn't helpful. If you have specific criticisms of a specific proposal, that is helpful, and I'll be happy to read it. Otherwise, I hereby ask you not to post again the claim that Unicode needs to be abandoned. There are lots of things that would be different if we'd made different decisions in the past, but we didn't and here we are. A -- Andrew Sullivan ajs@shinkuro.com Shinkuro, Inc. From dougb@dougbarton.us Tue Feb 22 14:49:02 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D93703A67B5 for ; Tue, 22 Feb 2011 14:49:02 -0800 (PST) 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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oDomvEbVak8k for ; Tue, 22 Feb 2011 14:49:01 -0800 (PST) Received: from mail2.fluidhosting.com (mx22.fluidhosting.com [204.14.89.5]) by core3.amsl.com (Postfix) with ESMTP id 737933A6983 for ; Tue, 22 Feb 2011 14:49:01 -0800 (PST) Received: (qmail 24080 invoked by uid 399); 22 Feb 2011 22:49:43 -0000 Received: from router.ka9q.net (HELO doug-optiplex.ka9q.net) (dougb@dougbarton.us@75.60.237.91) by mail2.fluidhosting.com with ESMTPAM; 22 Feb 2011 22:49:43 -0000 X-Originating-IP: 75.60.237.91 X-Sender: dougb@dougbarton.us Message-ID: <4D643D85.2020801@dougbarton.us> Date: Tue, 22 Feb 2011 14:49:41 -0800 From: Doug Barton Organization: http://SupersetSolutions.com/ User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.13) Gecko/20110129 Thunderbird/3.1.7 MIME-Version: 1.0 To: "W.C.A. Wijngaards" References: <4D622624.90303@ogud.com> <4D63907A.8010700@nlnetlabs.nl> In-Reply-To: <4D63907A.8010700@nlnetlabs.nl> 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: Re: [dnsext] WG opinion on draft : Improvements to DNS Resolvers, for Resiliency, Robustness, and Responsiveness X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 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, 22 Feb 2011 22:49:03 -0000 On 02/22/2011 02:31, W.C.A. Wijngaards wrote: > I read (and implemented) this draft (as config options) some time ago. Can you elaborate? -- 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 mohta@necom830.hpcl.titech.ac.jp Tue Feb 22 15:37:44 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 39FC63A697B for ; Tue, 22 Feb 2011 15:37:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.097 X-Spam-Level: X-Spam-Status: No, score=-0.097 tagged_above=-999 required=5 tests=[AWL=-0.007, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W5iWKcQljJhY for ; Tue, 22 Feb 2011 15:37:43 -0800 (PST) Received: from necom830.hpcl.titech.ac.jp (necom830.hpcl.titech.ac.jp [131.112.32.132]) by core3.amsl.com (Postfix) with SMTP id EF4343A67FA for ; Tue, 22 Feb 2011 15:37:42 -0800 (PST) Received: (qmail 93795 invoked from network); 22 Feb 2011 23:50:13 -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; 22 Feb 2011 23:50:13 -0000 Message-ID: <4D64489B.7020901@necom830.hpcl.titech.ac.jp> Date: Wed, 23 Feb 2011 08:36:59 +0900 From: Masataka Ohta User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; ja; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: dnsext@ietf.org References: <20110216165921.GW96213@shinkuro.com> <3B90ED2E-980D-4B01-889F-447D66D0B58D@insensate.co.uk> <20110216174011.GZ96213@shinkuro.com> <20110218143653.GC84482@bikeshed.isc.org> <20110218151209.GF66684@shinkuro.com> <4D5EEE09.4080405@dougbarton.us> <20110218222950.GL74065@shinkuro.com> <4D5F270F.20401@abenaki.wabanaki.net> <199C7B2B4228461FB024E59A990DB46D@ics.forth.gr> <4D641DB6.4090705@necom830.hpcl.titech.ac.jp> <20110222205617.GS53815@shinkuro.com> In-Reply-To: <20110222205617.GS53815@shinkuro.com> Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit Subject: Re: [dnsext] we need help to make names the same, was draft-yao-dnsext-identical-resolution-02 comment X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 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, 22 Feb 2011 23:37:44 -0000 Andrew Sullivan wrote: > Moderator hat on. You shouldn't. >> Some of the problems can be solved only by fundamental redesign >> of character encoding (effectively abandoning Unicode). >> >> Avoiding to do so, more than 10 years have wasted already. > Repeating over and over again that it won't work isn't helpful. If > you have specific criticisms of a specific proposal, that is helpful, > and I'll be happy to read it. Specific proposals on the sameness problem I made this time are: to give up to have localized domain name or develop extended case insensitivity description language and to give up DNSSEC or run extended case insensitivity database on clients which you failed to read. The latter proposal is similar to John Levine's recognition: > The pattern language for encoding variant names would probably be more > complex than people would like, but if we are serious that all the > spellings of Greek words are equivalent, or traditional and simplified > Chinese are equivalent, I don't see how anything simpler could do the > job. Remember possible case insensitivity issues related to Greek or Chinese equivalent of yyyyyyyyYyyyyyYyyyYyyyyyYyyyyyyyyyyyYyyyy or iPod That you want to have IDN politically does not mean IDN exist and even localized domain names are so hard to have, which is the technical reality. However, you are saying you can't accept the technical consequences only to waste yet another 10 years. Masataka Ohta From mohta@necom830.hpcl.titech.ac.jp Tue Feb 22 16:01:58 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D80DF3A63C9 for ; Tue, 22 Feb 2011 16:01:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.097 X-Spam-Level: X-Spam-Status: No, score=-0.097 tagged_above=-999 required=5 tests=[AWL=-0.007, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6aG+S8WMEmzd for ; Tue, 22 Feb 2011 16:01:58 -0800 (PST) Received: from necom830.hpcl.titech.ac.jp (necom830.hpcl.titech.ac.jp [131.112.32.132]) by core3.amsl.com (Postfix) with SMTP id DC8273A635F for ; Tue, 22 Feb 2011 16:01:57 -0800 (PST) Received: (qmail 94516 invoked from network); 23 Feb 2011 00:14:49 -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; 23 Feb 2011 00:14:49 -0000 Message-ID: <4D644E5E.70406@necom830.hpcl.titech.ac.jp> Date: Wed, 23 Feb 2011 09:01:34 +0900 From: Masataka Ohta User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; ja; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: dnsext@ietf.org References: <20110216073338.7251.qmail@joyce.lan> <20110216165921.GW96213@shinkuro.com> <3B90ED2E-980D-4B01-889F-447D66D0B58D@insensate.co.uk> <20110216174011.GZ96213@shinkuro.com> <20110218143653.GC84482@bikeshed.isc.org> <20110218151209.GF66684@shinkuro.com> <4D5EEE09.4080405@dougbarton.us> <20110218222950.GL74065@shinkuro.com> <4D5EF74C.9080603@dougbarton.us><20110218230905.GN74065@shinkuro.com> <4D5F270F.20401@abenaki.wabanaki.net> <199C7B2B4228461FB024E59A990DB46D@ics.forth.gr> <4D63EA86.2090206@abenaki.wabanaki.net> In-Reply-To: <4D63EA86.2090206@abenaki.wabanaki.net> Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit Subject: [dnsext] bi-directionality X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 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, 23 Feb 2011 00:01:59 -0000 As Andrew requests a specific proposal, I give it also for bi-directionality. Hope Andrew not change his mind to say I shouldn't make a specific proposal because it was already made 15 years ago. Eric Brunner-Williams wrote: > yet we have > nothing (I can think of) that provides a description of (sub)string > (sequence of character) semantics (other than the charming property of > "." as construed by the UTC, of directionality, which it happily > associates with proximal characters, effecting directional leakage > across label boundaries in bidi scripts). The problem is that bi-directionality of Unicode (and ISO 2022 extension) is not finite state but requires PDA (push down automaton). While PDA is fine with structured text, having PDA with plain text is overkill. For example, search pattern with PDA have time complexity of O(L^3) where L is the length of text to be searched. As I wrote recently (2/18) on IETF main ML; https://www.ietf.org/ibin/c5i?mid=6&rid=49&gid=0&k1=933&k2=55532 Subject: Re: MHonArc mail archive line wrapping > The assumption on line length is necessary to have multilevel > quotation ("> ", ">> ", etc., see above) with plain text. > We know that we can use directives of structured text such as: >.in +3 >... >.in -3 >when necessary. >But, when plain text is good enough, we use plain text. which is seemingly agreed by most, we (and DNS, especially) shouldn't be bothered by PDA unless it is necessary. It is not difficult to support bi-directionality with finite state if line length is known (or known to be infinite,which should be the case for DNS) in advance. Just spell words backward if directionality of the words are different from directionality of lines containing the words. So, a specific proposal is to stick to finite state, even though it might mean abandoning Unicode. Masataka Ohta From Internet-Drafts@ietf.org Tue Feb 22 16:15:02 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BE1503A672E; Tue, 22 Feb 2011 16:15:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.567 X-Spam-Level: X-Spam-Status: No, score=-102.567 tagged_above=-999 required=5 tests=[AWL=0.032, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hhcrYoGZdzgE; Tue, 22 Feb 2011 16:15:02 -0800 (PST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 146CE3A635F; Tue, 22 Feb 2011 16:15:02 -0800 (PST) MIME-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.12 Message-ID: <20110223001502.31614.56353.idtracker@localhost> Date: Tue, 22 Feb 2011 16:15:02 -0800 Cc: dnsext@ietf.org Subject: [dnsext] I-D Action:draft-ietf-dnsext-aliasing-requirements-00.txt X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 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, 23 Feb 2011 00:15:02 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the DNS Extensions Working Group of the IETF. Title : Problem Statement: DNS Resolution of Aliased Names Author(s) : S. Woolf, X. Lee Filename : draft-ietf-dnsext-aliasing-requirements-00.txt Pages : 20 Date : 2011-02-22 This document attempts to describe a set of issues that arises from the desire to treat a set or group of names as "aliases" of each other, "bundled," "variants," or "the same," which is problematic in terms of corresponding behavior for DNS labels and FQDNs. With the emergence of internationalized domain names, among other potential use cases, two or more names that users will regard as having identical meaning may sometimes require corresponding behavior in the underlying infrastructure, possibly in the DNS itself. It's not clear how to accommodate this required behavior of such names in DNS resolution; in particular, it's not clear when they are best accommodated in registry practices for generating names for lookup in the DNS, existing DNS protocol elements and behavior, existing application-layer mechanisms and practices, or some set of protocol elements or behavior not yet defined. This document attempts to describe some of these cases and the behavior of some of the possible solutions discussed to date. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dnsext-aliasing-requirements-00.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-dnsext-aliasing-requirements-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2011-02-22160814.I-D@ietf.org> --NextPart-- From nweaver@icsi.berkeley.edu Tue Feb 22 18:01:24 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4D39F3A67DF for ; Tue, 22 Feb 2011 18:01:24 -0800 (PST) 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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jGG8SCctNadU for ; Tue, 22 Feb 2011 18:01:23 -0800 (PST) Received: from taffy.ICSI.Berkeley.EDU (taffy.ICSI.Berkeley.EDU [192.150.187.26]) by core3.amsl.com (Postfix) with ESMTP id 3B2AA3A67BD for ; Tue, 22 Feb 2011 18:01:23 -0800 (PST) Received: from albook.hsd1.ca.comcast.net (c-67-164-126-174.hsd1.ca.comcast.net [67.164.126.174]) (Authenticated sender: nweaver) by taffy.ICSI.Berkeley.EDU (Postfix) with ESMTP id 280F936A030; Tue, 22 Feb 2011 18:02:06 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Nicholas Weaver In-Reply-To: <4D64489B.7020901@necom830.hpcl.titech.ac.jp> Date: Tue, 22 Feb 2011 18:02:05 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <713D992A-1DB9-4F72-9D18-8E923AD51D8D@icsi.berkeley.edu> References: <20110216165921.GW96213@shinkuro.com> <3B90ED2E-980D-4B01-889F-447D66D0B58D@insensate.co.uk> <20110216174011.GZ96213@shinkuro.com> <20110218143653.GC84482@bikeshed.isc.org> <20110218151209.GF66684@shinkuro.com> <4D5EEE09.4080405@dougbarton.us> <20110218222950.GL74065@shinkuro.com> <4D5F270F.20401@abenaki.wabanaki.net> <199C7B2B4228461FB024E59A990DB46D@ics.forth.gr> <4D641DB6.4090705@necom830.hpcl.titech.ac.jp> <20110222205617.GS53815@shinkuro.com> <4D64489B.7020901@necom830.hpcl.titech.ac.jp> To: Masataka Ohta X-Mailer: Apple Mail (2.1082) Cc: dnsext@ietf.org Subject: Re: [dnsext] we need help to make names the same, was draft-yao-dnsext-identical-resolution-02 comment X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 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, 23 Feb 2011 02:01:24 -0000 On Feb 22, 2011, at 3:36 PM, Masataka Ohta wrote: >=20 > Specific proposals on the sameness problem I made this time are: >=20 > to give up to have localized domain name >=20 > or >=20 > develop extended case insensitivity description language >=20 > and >=20 > to give up DNSSEC or run extended case insensitivity > database on clients OR use DNSSEC but sign data dynamically. 10 years ago, online signatures may have been questionable = computationally. Today, online signatures are near-trivial = computationally. From mohta@necom830.hpcl.titech.ac.jp Tue Feb 22 18:48:40 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8B3FD3A67BD for ; Tue, 22 Feb 2011 18:48:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.097 X-Spam-Level: X-Spam-Status: No, score=-0.097 tagged_above=-999 required=5 tests=[AWL=-0.007, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nsJdtClF9whB for ; Tue, 22 Feb 2011 18:48:39 -0800 (PST) Received: from necom830.hpcl.titech.ac.jp (necom830.hpcl.titech.ac.jp [131.112.32.132]) by core3.amsl.com (Postfix) with SMTP id 248733A67A8 for ; Tue, 22 Feb 2011 18:48:38 -0800 (PST) Received: (qmail 97621 invoked from network); 23 Feb 2011 03:01:12 -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; 23 Feb 2011 03:01:12 -0000 Message-ID: <4D647551.5060602@necom830.hpcl.titech.ac.jp> Date: Wed, 23 Feb 2011 11:47:45 +0900 From: Masataka Ohta User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; ja; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: Nicholas Weaver References: <20110216165921.GW96213@shinkuro.com> <3B90ED2E-980D-4B01-889F-447D66D0B58D@insensate.co.uk> <20110216174011.GZ96213@shinkuro.com> <20110218143653.GC84482@bikeshed.isc.org> <20110218151209.GF66684@shinkuro.com> <4D5EEE09.4080405@dougbarton.us> <20110218222950.GL74065@shinkuro.com> <4D5F270F.20401@abenaki.wabanaki.net> <199C7B2B4228461FB024E59A990DB46D@ics.forth.gr> <4D641DB6.4090705@necom830.hpcl.titech.ac.jp> <20110222205617.GS53815@shinkuro.com> <4D64489B.7020901@necom830.hpcl.titech.ac.jp> <713D992A-1DB9-4F72-9D18-8E923AD51D8D@icsi.berkeley.edu> In-Reply-To: <713D992A-1DB9-4F72-9D18-8E923AD51D8D@icsi.berkeley.edu> Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit Cc: dnsext@ietf.org Subject: Re: [dnsext] we need help to make names the same, was draft-yao-dnsext-identical-resolution-02 comment X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 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, 23 Feb 2011 02:48:40 -0000 Nicholas Weaver wrote: > OR use DNSSEC but sign data dynamically. > > 10 years ago, online signatures may have been questionable > computationally. Today, online signatures are near-trivial > computationally. Any reference? Note that "near-trivial computationally" means more lengthy signatures are required than 10 years ago. Masataka Ohta From nweaver@ICSI.Berkeley.EDU Tue Feb 22 19:35:39 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 99C463A67F5 for ; Tue, 22 Feb 2011 19:35:39 -0800 (PST) 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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FrrNsQZZM1+2 for ; Tue, 22 Feb 2011 19:35:38 -0800 (PST) Received: from taffy.ICSI.Berkeley.EDU (taffy.ICSI.Berkeley.EDU [192.150.187.26]) by core3.amsl.com (Postfix) with ESMTP id B74BD3A699C for ; Tue, 22 Feb 2011 19:35:38 -0800 (PST) Received: from albook.hsd1.ca.comcast.net (c-67-164-126-174.hsd1.ca.comcast.net [67.164.126.174]) (Authenticated sender: nweaver) by taffy.ICSI.Berkeley.EDU (Postfix) with ESMTP id 81DAD36A030; Tue, 22 Feb 2011 19:36:21 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Nicholas Weaver In-Reply-To: <4D647551.5060602@necom830.hpcl.titech.ac.jp> Date: Tue, 22 Feb 2011 19:36:20 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20110216165921.GW96213@shinkuro.com> <3B90ED2E-980D-4B01-889F-447D66D0B58D@insensate.co.uk> <20110216174011.GZ96213@shinkuro.com> <20110218143653.GC84482@bikeshed.isc.org> <20110218151209.GF66684@shinkuro.com> <4D5EEE09.4080405@dougbarton.us> <20110218222950.GL74065@shinkuro.com> <4D5F270F.20401@abenaki.wabanaki.net> <199C7B2B4228461FB024E59A990DB46D@ics.forth.gr> <4D641DB6.4090705@necom830.hpcl.titech.ac.jp> <20110222205617.GS53815@shinkuro.com> <4D64489B.7020901@necom830.hpcl.titech.ac.jp> <713D992A-1DB9-4F72-9D18-8E923AD51D8D@icsi.berkeley.edu> <4D647551.5060602@necom830.hpcl.titech.ac.jp> To: Masataka Ohta X-Mailer: Apple Mail (2.1082) Cc: Nicholas Weaver , dnsext@ietf.org Subject: Re: [dnsext] we need help to make names the same, was draft-yao-dnsext-identical-resolution-02 comment X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 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, 23 Feb 2011 03:35:39 -0000 On Feb 22, 2011, at 6:47 PM, Masataka Ohta wrote: > Nicholas Weaver wrote: >=20 >> OR use DNSSEC but sign data dynamically. >>=20 >> 10 years ago, online signatures may have been questionable >> computationally. Today, online signatures are near-trivial >> computationally. >=20 > Any reference? Not for DNSSEC, but computationally DNSSEC signature generation is no = harder than SSL connection setup. Google was able to make Gmail SSL = only with a trivially small increase in computation. Random reported SSL setups per second are ~1500/s for a commodity 64B = processor with 1024B keys. (People don't benchmark this kind of thing = as much as they used to...) AND this parallelizes obscenely well: because of the stateless nature of = DNS, a simple salted hash function dispatch to compute nodes will easily = handle a cluster to however many requests per second you need to = case-sensitive-normalize. =20 AND such compute nodes could cache the signatures for common = conventions, which means you can't computationally DOS the common cases = and the COMMON cases no longer require dynamically executed DNSSEC... > Note that "near-trivial computationally" means more lengthy > signatures are required than 10 years ago. 2048B signatures are only ~4x harder than 1024B signatures = computationally to GENERATE, but vastly harder to crack using brute = force. Thats the wonder of cryptography and the exponentials involved. = Its quadratic increase in complexity to add bits to your RSA keysize, = but far far far greater impact on the cost of cryptanalysis. From hallam@gmail.com Tue Feb 22 19:47:48 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0EC923A699E for ; Tue, 22 Feb 2011 19:47:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.56 X-Spam-Level: X-Spam-Status: No, score=-3.56 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kIhKUoy3juYD for ; Tue, 22 Feb 2011 19:47:46 -0800 (PST) Received: from mail-bw0-f54.google.com (mail-bw0-f54.google.com [209.85.214.54]) by core3.amsl.com (Postfix) with ESMTP id 2450D3A6803 for ; Tue, 22 Feb 2011 19:47:45 -0800 (PST) Received: by bwz12 with SMTP id 12so4428958bwz.27 for ; Tue, 22 Feb 2011 19:48:31 -0800 (PST) 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=Ag6dYPpApzGiRT574Nx3SoP1yIzGOK+EV+vCS92tc20=; b=Of8XzFYqS5z3lIwLC3kk1CLW5MFwePplNRr0uxzqHI2ZPezlqoPSjUg9KOxSh++QGS FgtpjJUFbNdE7e7US4ukC9DUgJ9CpeBZ+qANrOtQHjs783p08tn3+PysabwUkt4Jdk/u MrP3LN7D12rHZmxFrSOYZGm7HdnLOG/HkQDVM= 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=jzr9FY/TRmmZKcDLQU13qPORhsvFSqxC0TKsKFcTnpBotDQahHBmmWO+Z6hkJLkdFa 3A8lOA5DGuyivX+pmDtWVQH55x9PXKiHIDCHEPscTACmnBrujniyN50DxlNUxHw5mO4/ iBh6LTMptXt6msUJCmnuW8RsnFv0KRe+rGNQA= MIME-Version: 1.0 Received: by 10.204.24.135 with SMTP id v7mr2792338bkb.99.1298432909799; Tue, 22 Feb 2011 19:48:29 -0800 (PST) Received: by 10.204.14.139 with HTTP; Tue, 22 Feb 2011 19:48:29 -0800 (PST) In-Reply-To: <713D992A-1DB9-4F72-9D18-8E923AD51D8D@icsi.berkeley.edu> References: <20110216165921.GW96213@shinkuro.com> <3B90ED2E-980D-4B01-889F-447D66D0B58D@insensate.co.uk> <20110216174011.GZ96213@shinkuro.com> <20110218143653.GC84482@bikeshed.isc.org> <20110218151209.GF66684@shinkuro.com> <4D5EEE09.4080405@dougbarton.us> <20110218222950.GL74065@shinkuro.com> <4D5F270F.20401@abenaki.wabanaki.net> <199C7B2B4228461FB024E59A990DB46D@ics.forth.gr> <4D641DB6.4090705@necom830.hpcl.titech.ac.jp> <20110222205617.GS53815@shinkuro.com> <4D64489B.7020901@necom830.hpcl.titech.ac.jp> <713D992A-1DB9-4F72-9D18-8E923AD51D8D@icsi.berkeley.edu> Date: Tue, 22 Feb 2011 22:48:29 -0500 Message-ID: From: Phillip Hallam-Baker To: Nicholas Weaver Content-Type: multipart/alternative; boundary=00032555ae825a72e2049ceaf89a Cc: dnsext@ietf.org Subject: Re: [dnsext] we need help to make names the same, was draft-yao-dnsext-identical-resolution-02 comment X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 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, 23 Feb 2011 03:47:48 -0000 --00032555ae825a72e2049ceaf89a Content-Type: text/plain; charset=ISO-8859-1 If you are going to do that, you might as well do a key exchange inline as well as we do in TLS. One key exchange can then be leveraged across multiple connections using kerberos style tickets (see DPLS for an example). DNS does not require non-repudiation so this would be the appropriate technology. On Tue, Feb 22, 2011 at 9:02 PM, Nicholas Weaver wrote: > > On Feb 22, 2011, at 3:36 PM, Masataka Ohta wrote: > > > > Specific proposals on the sameness problem I made this time are: > > > > to give up to have localized domain name > > > > or > > > > develop extended case insensitivity description language > > > > and > > > > to give up DNSSEC or run extended case insensitivity > > database on clients > > OR use DNSSEC but sign data dynamically. > > 10 years ago, online signatures may have been questionable computationally. > Today, online signatures are near-trivial computationally. > > _______________________________________________ > dnsext mailing list > dnsext@ietf.org > https://www.ietf.org/mailman/listinfo/dnsext > -- Website: http://hallambaker.com/ --00032555ae825a72e2049ceaf89a Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable If you are going to do that, you might as well do a key exchange inline as = well as we do in TLS.

One key exchange can then be lever= aged across multiple connections using kerberos style tickets (see DPLS for= an example).


DNS does not require non-repudiation so = this would be the appropriate technology.




On Tue, Feb 22, 2011 at 9:02 PM, = Nicholas Weaver <nweaver@icsi.berkeley.edu> wrote:

On Feb 22, 2011, at 3:36 PM, Masataka Ohta wrote:
>
> Specific proposals on the sameness problem I made this time are:
>
> =A0 =A0 =A0 to give up to have localized domain name
>
> or
>
> =A0 =A0 =A0 develop extended case insensitivity description language >
> and
>
> =A0 =A0 =A0 to give up DNSSEC or run extended case insensitivity
> =A0 =A0 =A0 database on clients

OR use DNSSEC but sign data dynamically.

10 years ago, online signatures may have been questionable computationally.= =A0Today, online signatures are near-trivial computationally.

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



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

--00032555ae825a72e2049ceaf89a-- From paf@cisco.com Tue Feb 22 21:23:20 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 395B43A681B for ; Tue, 22 Feb 2011 21:23:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.963 X-Spam-Level: X-Spam-Status: No, score=-9.963 tagged_above=-999 required=5 tests=[AWL=0.335, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dXDfBGZrunSb for ; Tue, 22 Feb 2011 21:23:19 -0800 (PST) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by core3.amsl.com (Postfix) with ESMTP id E05C43A6A06 for ; Tue, 22 Feb 2011 21:23:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=paf@cisco.com; l=302; q=dns/txt; s=iport; t=1298438645; x=1299648245; h=from:content-transfer-encoding:subject:date:references: to:message-id:mime-version; bh=FeQC81ajjWmNpYaLJYjvpKRqYhqFl6RB9a/LCqdJy+g=; b=HcQa9kDW/JYOhtKX8rAgeIkYg9AxjsGbOPuLcH/+jv/euh0JokLb+8OB RtCHHj5TapzBZ8KuEAIIHhUfhl0vaGdW/++dcyoZ3kZFNmqYykI7SfxL9 B01kapNh8Ghg52fOi3t6iNtyFWkmvPslrY1i3QMSdGaPWBA7mf0MfzEB1 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ag0GAL4oZE2Q/khMgWdsb2JhbACYGY4NFQEBFiIkoSWbZoVeBIwU X-IronPort-AV: E=Sophos;i="4.62,210,1297036800"; d="scan'208";a="19863860" Received: from ams-core-3.cisco.com ([144.254.72.76]) by ams-iport-2.cisco.com with ESMTP; 23 Feb 2011 05:24:04 +0000 Received: from ams3-vpn-dhcp5256.cisco.com (ams3-vpn-dhcp5256.cisco.com [10.61.84.135]) by ams-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p1N5O4GY018449 for ; Wed, 23 Feb 2011 05:24:04 GMT From: =?iso-8859-1?Q?Patrik_F=E4ltstr=F6m?= Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Wed, 23 Feb 2011 06:24:03 +0100 References: To: dnsext@ietf.org Message-Id: <2409944E-7795-4945-9685-2F07C52A2B6F@cisco.com> Mime-Version: 1.0 (Apple Message framework v1082) X-Mailer: Apple Mail (2.1082) Subject: [dnsext] FYI: [IANA #376037] [dns-rrtype-applications] Request for new DNS RR Type: URI X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 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, 23 Feb 2011 05:23:20 -0000 URI RRType is allocated as number 256 Patrik Begin forwarded message: > Hi Patrik, > > We assigned the following with you as the point of reference: > > URI 256 > > Please see > http://www.iana.org/assignments/dns-parameters > > thanks, > > Amanda Baber > IANA From mohta@necom830.hpcl.titech.ac.jp Tue Feb 22 21:34:00 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D6BF53A681E for ; Tue, 22 Feb 2011 21:34:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.096 X-Spam-Level: X-Spam-Status: No, score=-0.096 tagged_above=-999 required=5 tests=[AWL=-0.006, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gqRxaV5i7OlR for ; Tue, 22 Feb 2011 21:34:00 -0800 (PST) Received: from necom830.hpcl.titech.ac.jp (necom830.hpcl.titech.ac.jp [131.112.32.132]) by core3.amsl.com (Postfix) with SMTP id B8D763A6804 for ; Tue, 22 Feb 2011 21:33:59 -0800 (PST) Received: (qmail 1436 invoked from network); 23 Feb 2011 05:46:35 -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; 23 Feb 2011 05:46:35 -0000 Message-ID: <4D649C0B.40905@necom830.hpcl.titech.ac.jp> Date: Wed, 23 Feb 2011 14:32:59 +0900 From: Masataka Ohta User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; ja; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: Nicholas Weaver References: <20110216165921.GW96213@shinkuro.com> <3B90ED2E-980D-4B01-889F-447D66D0B58D@insensate.co.uk> <20110216174011.GZ96213@shinkuro.com> <20110218143653.GC84482@bikeshed.isc.org> <20110218151209.GF66684@shinkuro.com> <4D5EEE09.4080405@dougbarton.us> <20110218222950.GL74065@shinkuro.com> <4D5F270F.20401@abenaki.wabanaki.net> <199C7B2B4228461FB024E59A990DB46D@ics.forth.gr> <4D641DB6.4090705@necom830.hpcl.titech.ac.jp> <20110222205617.GS53815@shinkuro.com> <4D64489B.7020901@necom830.hpcl.titech.ac.jp> <713D992A-1DB9-4F72-9D18-8E923AD51D8D@icsi.berkeley.edu> <4D647551.5060602@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] we need help to make names the same, was draft-yao-dnsext-identical-resolution-02 comment X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 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, 23 Feb 2011 05:34:01 -0000 Nicholas Weaver wrote: > Random reported SSL setups per second are ~1500/s for a commodity > 64B processor with 1024B keys. I think you are saying 1024b keys. That's a lot slower than typical number on TCP connections per second, which means computation load dominates. Considering the following statement in RFC5507 (April 2009): DNS queries over TCP are not subject to this length limitation, but TCP imposes significantly higher per- query overhead on name servers than UDP. dynamic generation is not feasible at all. > AND such compute nodes could cache the signatures for > common conventions, which means you can't computationally > DOS the common cases DOS will clear the cache. Worse, multiple layers of labels increase the number of common cases exponentially, unless you introduce redirection by BNAME. > 2048B signatures are only ~4x harder than 1024B signatures > computationally to GENERATE, As 2048 is not very large that Karatsuba Multiplication is not very effective. > but vastly harder to crack using brute force. If it were vastly harder we should be using 520b key, if 512b key was good enough 15 years ago. Masataka Ohta From fweimer@bfk.de Wed Feb 23 01:52:56 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B7E153A69C4 for ; Wed, 23 Feb 2011 01:52:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.212 X-Spam-Level: X-Spam-Status: No, score=-2.212 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sK+K8Bz7dzwS for ; Wed, 23 Feb 2011 01:52:55 -0800 (PST) Received: from mx01.bfk.de (mx01.bfk.de [193.227.124.2]) by core3.amsl.com (Postfix) with ESMTP id 3AE6B3A67F2 for ; Wed, 23 Feb 2011 01:52:51 -0800 (PST) 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 1PsBPc-0006ku-Ox; Wed, 23 Feb 2011 09:53:36 +0000 Received: by bfk.de with local id 1PsBPc-0001vH-KM; Wed, 23 Feb 2011 09:53:36 +0000 To: "W.C.A. Wijngaards" References: <4D622624.90303@ogud.com> <4D63907A.8010700@nlnetlabs.nl> From: Florian Weimer Date: Wed, 23 Feb 2011 09:53:36 +0000 In-Reply-To: <4D63907A.8010700@nlnetlabs.nl> (W. C. A. Wijngaards's message of "Tue\, 22 Feb 2011 11\:31\:22 +0100") Message-ID: <82zkpnyt3z.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] WG opinion on draft : Improvements to DNS Resolvers, for Resiliency, Robustness, and Responsiveness X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 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, 23 Feb 2011 09:52:57 -0000 * W. C. A. Wijngaards: > I do not think you could enable this by default today, because very old > software might still have bugs in handling empty nonterminals and send > NXDOMAINs for them. A lot of DNSBLs are hosted on servers which send NXDOMAIN for empty non-terminals. I don't think this change is worth the effort. I would rather prefer official blessing of NXDOMAIN synthesis from NSEC/NSEC3 records. This would be both more deterministic and more effective. --=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 vixie@isc.org Wed Feb 23 02:11:27 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7A2633A6839 for ; Wed, 23 Feb 2011 02:11:24 -0800 (PST) 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=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XmyxQ4T4hzM9 for ; Wed, 23 Feb 2011 02:11:14 -0800 (PST) Received: from nsa.vix.com (unknown [IPv6:2001:4f8:3:bb:230:48ff:fe5a:2f38]) by core3.amsl.com (Postfix) with ESMTP id E85353A6859 for ; Wed, 23 Feb 2011 02:11:12 -0800 (PST) Received: from nsa.vix.com (localhost [127.0.0.1]) by nsa.vix.com (Postfix) with ESMTP id 924CAA1019 for ; Wed, 23 Feb 2011 10:11:56 +0000 (UTC) (envelope-from vixie@isc.org) From: Paul Vixie To: dnsext@ietf.org In-Reply-To: Your message of "Wed, 23 Feb 2011 09:53:36 GMT." <82zkpnyt3z.fsf@mid.bfk.de> References: <4D622624.90303@ogud.com> <4D63907A.8010700@nlnetlabs.nl> <82zkpnyt3z.fsf@mid.bfk.de> X-Mailer: MH-E 8.2; nmh 1.2; XEmacs 21.4 (patch 22) Date: Wed, 23 Feb 2011 10:11:56 +0000 Message-ID: <22348.1298455916@nsa.vix.com> Subject: Re: [dnsext] WG opinion on draft : Improvements to DNS Resolvers, for Resiliency, Robustness, and Responsiveness X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 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, 23 Feb 2011 10:11:27 -0000 > From: Florian Weimer > Date: Wed, 23 Feb 2011 09:53:36 +0000 > > > I do not think you could enable this by default today, because very > old > software might still have bugs in handling empty nonterminals > and send > NXDOMAINs for them. > > A lot of DNSBLs are hosted on servers which send NXDOMAIN for empty > non-terminals. those servers are lying and/or seriously broken/nonconformant. i don't like walking as if on on eggshells to avoid offending them. they ought to be fixed, not tolerated. consider BIND4 4.8's odd AXFR behaviour. it only looked at the first answer in each message, and only sent one answer per message. it had a 100% market share. we fixed the problem in 4.9.3 and added configuration knobs defaulting to sending single-answer output (to avoid causing older noncompliant initiators to reject the transfers) but allowing this to be overridden. eventually we just changed the default. microsoft, whose correct DNS implementation was not compatible with BIND, had to do the same thing. they deserved an apology from me, which they got, not excuses. the standards weren't changed as a result. again, at the beginning of this debacle the offending DNS implementation had a 100% market share. > I don't think this change is worth the effort. I would rather prefer > official blessing of NXDOMAIN synthesis from NSEC/NSEC3 records. This > would be both more deterministic and more effective. while i'd like the DNSSEC solution you propose to also be done, i note that RBLDNSD operators are among the most technically adept name server operators in the history of the internet. a campaign to get this software patched and to get upgrades installed would have a very short tail (shorter than the BIND4 AXFR example cited earlier). this does seem to me worth doing since i'm not expecting all zones to be signed and since the specification with respect to empty non-terminals was never unclear. From fanf2@hermes.cam.ac.uk Wed Feb 23 02:30:03 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 388803A69EE for ; Wed, 23 Feb 2011 02:30:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.199 X-Spam-Level: X-Spam-Status: No, score=-6.199 tagged_above=-999 required=5 tests=[AWL=0.400, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8CfKkYUjurpV for ; Wed, 23 Feb 2011 02:30:00 -0800 (PST) Received: from ppsw-41.csi.cam.ac.uk (ppsw-41.csi.cam.ac.uk [131.111.8.141]) by core3.amsl.com (Postfix) with ESMTP id 2BB333A6832 for ; Wed, 23 Feb 2011 02:30:00 -0800 (PST) X-Cam-AntiVirus: no malware found X-Cam-SpamDetails: not scanned X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ Received: from hermes-1.csi.cam.ac.uk ([131.111.8.51]:40767) by ppsw-41.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.156]:25) with esmtpa (EXTERNAL:fanf2) id 1PsBzX-0003Pq-Rg (Exim 4.72) (return-path ); Wed, 23 Feb 2011 10:30:43 +0000 Received: from fanf2 (helo=localhost) by hermes-1.csi.cam.ac.uk (hermes.cam.ac.uk) with local-esmtp id 1PsBzX-0001Ni-IN (Exim 4.67) (return-path ); Wed, 23 Feb 2011 10:30:43 +0000 Date: Wed, 23 Feb 2011 10:30:43 +0000 From: Tony Finch X-X-Sender: fanf2@hermes-1.csi.cam.ac.uk To: Phillip Hallam-Baker In-Reply-To: Message-ID: References: <20110216165921.GW96213@shinkuro.com> <3B90ED2E-980D-4B01-889F-447D66D0B58D@insensate.co.uk> <20110216174011.GZ96213@shinkuro.com> <20110218143653.GC84482@bikeshed.isc.org> <20110218151209.GF66684@shinkuro.com> <4D5EEE09.4080405@dougbarton.us> <20110218222950.GL74065@shinkuro.com> <4D5F270F.20401@abenaki.wabanaki.net> <199C7B2B4228461FB024E59A990DB46D@ics.forth.gr> <4D641DB6.4090705@necom830.hpcl.titech.ac.jp> <20110222205617.GS53815@shinkuro.com> <4D64489B.7020901@necom830.hpcl.titech.ac.jp> <713D992A-1DB9-4F72-9D18-8E923AD51D8D@icsi.berkeley.edu> User-Agent: Alpine 2.00 (LSU 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: Tony Finch Cc: dnsext@ietf.org Subject: Re: [dnsext] we need help to make names the same, was draft-yao-dnsext-identical-resolution-02 comment X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 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, 23 Feb 2011 10:30:03 -0000 On Tue, 22 Feb 2011, Phillip Hallam-Baker wrote: > If you are going to do [online signing], you might as well do a key > exchange inline as well as we do in TLS. One key exchange can then be > leveraged across multiple connections using kerberos style tickets (see > DPLS for an example). That gives you channel security whereas DNSSEC gives you data origin authentication. They are not the same things. Tony. -- f.anthony.n.finch http://dotat.at/ Viking, North Utsire, South Utsire, Northeast Forties: Southeasterly 7 to severe gale 9, occasionally storm 10 in Viking. Rough or very rough, becoming high in north Viking. Rain or snow. Moderate or good, occasionally poor, light icing in north and South Utsire. From fanf2@hermes.cam.ac.uk Wed Feb 23 02:34:27 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C1ADA3A65A6 for ; Wed, 23 Feb 2011 02:34:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.266 X-Spam-Level: X-Spam-Status: No, score=-6.266 tagged_above=-999 required=5 tests=[AWL=0.333, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vVfDJ-JZd4Cr for ; Wed, 23 Feb 2011 02:34:26 -0800 (PST) Received: from ppsw-52.csi.cam.ac.uk (ppsw-52.csi.cam.ac.uk [131.111.8.152]) by core3.amsl.com (Postfix) with ESMTP id 5CBD43A6859 for ; Wed, 23 Feb 2011 02:34:26 -0800 (PST) X-Cam-AntiVirus: no malware found X-Cam-SpamDetails: not scanned X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ Received: from hermes-1.csi.cam.ac.uk ([131.111.8.51]:46543) by ppsw-52.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.159]:25) with esmtpa (EXTERNAL:fanf2) id 1PsC3m-0006n4-Fg (Exim 4.72) (return-path ); Wed, 23 Feb 2011 10:35:06 +0000 Received: from fanf2 (helo=localhost) by hermes-1.csi.cam.ac.uk (hermes.cam.ac.uk) with local-esmtp id 1PsC3m-0002Ee-RQ (Exim 4.67) (return-path ); Wed, 23 Feb 2011 10:35:06 +0000 Date: Wed, 23 Feb 2011 10:35:06 +0000 From: Tony Finch X-X-Sender: fanf2@hermes-1.csi.cam.ac.uk To: Masataka Ohta In-Reply-To: <4D647551.5060602@necom830.hpcl.titech.ac.jp> Message-ID: References: <20110216165921.GW96213@shinkuro.com> <3B90ED2E-980D-4B01-889F-447D66D0B58D@insensate.co.uk> <20110216174011.GZ96213@shinkuro.com> <20110218143653.GC84482@bikeshed.isc.org> <20110218151209.GF66684@shinkuro.com> <4D5EEE09.4080405@dougbarton.us> <20110218222950.GL74065@shinkuro.com> <4D5F270F.20401@abenaki.wabanaki.net> <199C7B2B4228461FB024E59A990DB46D@ics.forth.gr> <4D641DB6.4090705@necom830.hpcl.titech.ac.jp> <20110222205617.GS53815@shinkuro.com> <4D64489B.7020901@necom830.hpcl.titech.ac.jp> <713D992A-1DB9-4F72-9D18-8E923AD51D8D@icsi.berkeley.edu> <4D647551.5060602@necom830.hpcl.titech.ac.jp> User-Agent: Alpine 2.00 (LSU 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: Tony Finch Cc: dnsext@ietf.org Subject: Re: [dnsext] we need help to make names the same, was draft-yao-dnsext-identical-resolution-02 comment X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 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, 23 Feb 2011 10:34:27 -0000 On Wed, 23 Feb 2011, Masataka Ohta wrote: > Nicholas Weaver wrote: > > > OR use DNSSEC but sign data dynamically. > > > > 10 years ago, online signatures may have been questionable > > computationally. Today, online signatures are near-trivial > > computationally. > > Any reference? PowerDNSSEC is designed for online signing, though its author doesn't recommend this mode for heavily loaded servers: http://doc.powerdns.com/powerdnssec.html http://doc.powerdns.com/dnssec-performance.html Tony. -- f.anthony.n.finch http://dotat.at/ Faeroes, South-east Iceland: Southeasterly veering southwesterly 6 to gale 8, occasionally severe gale 9 in east Faeroes. Rough or very rough, becoming high. Occasional rain. Moderate, occasionally poor. From fanf2@hermes.cam.ac.uk Wed Feb 23 02:37:27 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 472763A69FE for ; Wed, 23 Feb 2011 02:37:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.313 X-Spam-Level: X-Spam-Status: No, score=-6.313 tagged_above=-999 required=5 tests=[AWL=0.286, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YH97vTAdXs8G for ; Wed, 23 Feb 2011 02:37:26 -0800 (PST) Received: from ppsw-51.csi.cam.ac.uk (ppsw-51.csi.cam.ac.uk [131.111.8.151]) by core3.amsl.com (Postfix) with ESMTP id 126CB3A69FC for ; Wed, 23 Feb 2011 02:37:26 -0800 (PST) X-Cam-AntiVirus: no malware found X-Cam-SpamDetails: not scanned X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ Received: from hermes-1.csi.cam.ac.uk ([131.111.8.51]:56518) by ppsw-51.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.158]:25) with esmtpa (EXTERNAL:fanf2) id 1PsC6j-0003Ci-We (Exim 4.72) (return-path ); Wed, 23 Feb 2011 10:38:09 +0000 Received: from fanf2 (helo=localhost) by hermes-1.csi.cam.ac.uk (hermes.cam.ac.uk) with local-esmtp id 1PsC6j-0002oW-3U (Exim 4.67) (return-path ); Wed, 23 Feb 2011 10:38:09 +0000 Date: Wed, 23 Feb 2011 10:38:09 +0000 From: Tony Finch X-X-Sender: fanf2@hermes-1.csi.cam.ac.uk To: Masataka Ohta In-Reply-To: Message-ID: References: <20110216165921.GW96213@shinkuro.com> <3B90ED2E-980D-4B01-889F-447D66D0B58D@insensate.co.uk> <20110216174011.GZ96213@shinkuro.com> <20110218143653.GC84482@bikeshed.isc.org> <20110218151209.GF66684@shinkuro.com> <4D5EEE09.4080405@dougbarton.us> <20110218222950.GL74065@shinkuro.com> <4D5F270F.20401@abenaki.wabanaki.net> <199C7B2B4228461FB024E59A990DB46D@ics.forth.gr> <4D641DB6.4090705@necom830.hpcl.titech.ac.jp> <20110222205617.GS53815@shinkuro.com> <4D64489B.7020901@necom830.hpcl.titech.ac.jp> <713D992A-1DB9-4F72-9D18-8E923AD51D8D@icsi.berkeley.edu> <4D647551.5060602@necom830.hpcl.titech.ac.jp> User-Agent: Alpine 2.00 (LSU 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: Tony Finch Cc: dnsext@ietf.org Subject: Re: [dnsext] we need help to make names the same, was draft-yao-dnsext-identical-resolution-02 comment X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 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, 23 Feb 2011 10:37:27 -0000 On Wed, 23 Feb 2011, Tony Finch wrote: > On Wed, 23 Feb 2011, Masataka Ohta wrote: > > Nicholas Weaver wrote: > > > > > OR use DNSSEC but sign data dynamically. > > > > > > 10 years ago, online signatures may have been questionable > > > computationally. Today, online signatures are near-trivial > > > computationally. > > > > Any reference? > > PowerDNSSEC is designed for online signing, though its author doesn't > recommend this mode for heavily loaded servers: > > http://doc.powerdns.com/powerdnssec.html > http://doc.powerdns.com/dnssec-performance.html And Dan Kaminsky's Phreebird DNSSEC reverse proxy does too: http://dankaminsky.com/phreebird/ Tony. -- f.anthony.n.finch http://dotat.at/ Fisher, German Bight: Southeasterly 5 to 7, occasionally gale 8 in Fisher. Moderate or rough. Rain or snow. Moderate, occasionally poor, light icing. From fweimer@bfk.de Wed Feb 23 02:43:52 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F2CF93A69F3 for ; Wed, 23 Feb 2011 02:43:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.219 X-Spam-Level: X-Spam-Status: No, score=-2.219 tagged_above=-999 required=5 tests=[AWL=0.030, BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7blN4kWu97xA for ; Wed, 23 Feb 2011 02:43:51 -0800 (PST) Received: from mx01.bfk.de (mx01.bfk.de [193.227.124.2]) by core3.amsl.com (Postfix) with ESMTP id E6A123A6834 for ; Wed, 23 Feb 2011 02:43:50 -0800 (PST) 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 1PsCCy-00048t-KB; Wed, 23 Feb 2011 10:44:36 +0000 Received: by bfk.de with local id 1PsCCy-0006gU-HO; Wed, 23 Feb 2011 10:44:36 +0000 To: Paul Vixie References: <4D622624.90303@ogud.com> <4D63907A.8010700@nlnetlabs.nl> <82zkpnyt3z.fsf@mid.bfk.de> <22348.1298455916@nsa.vix.com> From: Florian Weimer Date: Wed, 23 Feb 2011 10:44:36 +0000 In-Reply-To: <22348.1298455916@nsa.vix.com> (Paul Vixie's message of "Wed\, 23 Feb 2011 10\:11\:56 +0000") Message-ID: <82ei6zyqqz.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] WG opinion on draft : Improvements to DNS Resolvers, for Resiliency, Robustness, and Responsiveness X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 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, 23 Feb 2011 10:43:52 -0000 * Paul Vixie: >> > I do not think you could enable this by default today, because very >> old > software might still have bugs in handling empty nonterminals >> and send > NXDOMAINs for them. >>=20 >> A lot of DNSBLs are hosted on servers which send NXDOMAIN for empty >> non-terminals. > > those servers are lying and/or seriously broken/nonconformant. i don't > like walking as if on on eggshells to avoid offending them. they ought > to be fixed, not tolerated. But there's no significant benefit from this protocol change (at least none that I can see). On the contrary, it adds one more case where stub queries which are not observed regularly can result in drastically altered resolver behavior. That's quite an annoying inconsistency. > consider BIND4 4.8's odd AXFR behaviour. I don't want to sound flippant, but I don't see how this is relevant here and now. > while i'd like the DNSSEC solution you propose to also be done, i note > that RBLDNSD operators are among the most technically adept name server > operators in the history of the internet. a campaign to get this > software patched and to get upgrades installed would have a very short > tail (shorter than the BIND4 AXFR example cited earlier). For a while, I've been sitting on another rbldnsd/resolver interaction bug and have been given the run-around so far. I'm not convinced that deploying new code is simple. > this does seem to me worth doing since i'm not expecting all zones > to be signed and since the specification with respect to empty > non-terminals was never unclear. If it wasn't unclear, why did almost everyone implement the old behavior? --=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 woolf@isc.org Wed Feb 23 03:46:51 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 846B53A684B for ; Wed, 23 Feb 2011 03:46:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.743 X-Spam-Level: X-Spam-Status: No, score=-2.743 tagged_above=-999 required=5 tests=[AWL=-0.143, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qavsZApzFXTr for ; Wed, 23 Feb 2011 03:46:50 -0800 (PST) Received: from mx.ams1.isc.org (mx.ams1.isc.org [IPv6:2001:500:60::65]) by core3.amsl.com (Postfix) with ESMTP id 6605E3A67F0 for ; Wed, 23 Feb 2011 03:46:50 -0800 (PST) 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 90DFD5F98A2 for ; Wed, 23 Feb 2011 11:47:22 +0000 (UTC) (envelope-from woolf@isc.org) Received: by bikeshed.isc.org (Postfix, from userid 10265) id CD16D216C33; Wed, 23 Feb 2011 11:47:20 +0000 (UTC) Date: Wed, 23 Feb 2011 11:47:20 +0000 From: Suzanne Woolf To: dnsext@ietf.org Message-ID: <20110223114720.GA10740@bikeshed.isc.org> References: <20110223001502.31614.56353.idtracker@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20110223001502.31614.56353.idtracker@localhost> User-Agent: Mutt/1.4.2.3i Subject: Re: [dnsext] I-D Action:draft-ietf-dnsext-aliasing-requirements-00.txt X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 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, 23 Feb 2011 11:46:51 -0000 Colleagues, Per the announcement to the list last night, the -00 of the "aliases" problem statement has been posted to the i-d repository. Your comments are sought. It was pushed out this week to keep the discussion here going. It's a working draft and obviously needs a number of refinements on terminology and details, but the most important thing to establish at this point is whether it gets the overall landscape right. I hope we will have a -01 ready before Prague, so we can have a strong document by then and focus in the meeting on some decisions. best, Suzanne On Tue, Feb 22, 2011 at 04:15:02PM -0800, Internet-Drafts@ietf.org wrote: > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the DNS Extensions Working Group of the IETF. > > > Title : Problem Statement: DNS Resolution of Aliased Names > Author(s) : S. Woolf, X. Lee > Filename : draft-ietf-dnsext-aliasing-requirements-00.txt > Pages : 20 > Date : 2011-02-22 > > This document attempts to describe a set of issues that arises from > the desire to treat a set or group of names as "aliases" of each > other, "bundled," "variants," or "the same," which is problematic in > terms of corresponding behavior for DNS labels and FQDNs. > > With the emergence of internationalized domain names, among other > potential use cases, two or more names that users will regard as > having identical meaning may sometimes require corresponding behavior > in the underlying infrastructure, possibly in the DNS itself. It's > not clear how to accommodate this required behavior of such names in > DNS resolution; in particular, it's not clear when they are best > accommodated in registry practices for generating names for lookup in > the DNS, existing DNS protocol elements and behavior, existing > application-layer mechanisms and practices, or some set of protocol > elements or behavior not yet defined. This document attempts to > describe some of these cases and the behavior of some of the possible > solutions discussed to date. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-dnsext-aliasing-requirements-00.txt > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. > _______________________________________________ > dnsext mailing list > dnsext@ietf.org > https://www.ietf.org/mailman/listinfo/dnsext From jabley@hopcount.ca Wed Feb 23 05:53:08 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 668193A68D5 for ; Wed, 23 Feb 2011 05:53:08 -0800 (PST) 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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 048dScddMWn9 for ; Wed, 23 Feb 2011 05:53:07 -0800 (PST) Received: from monster.hopcount.ca (monster.hopcount.ca [216.235.14.38]) by core3.amsl.com (Postfix) with ESMTP id C53123A689D for ; Wed, 23 Feb 2011 05:53:07 -0800 (PST) Received: from [199.212.90.30] (helo=dh30.r1.owls.hopcount.ca) by monster.hopcount.ca with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.71 (FreeBSD)) (envelope-from ) id 1PsFA2-0001WN-Qe; Wed, 23 Feb 2011 13:53:47 +0000 Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Joe Abley X-Priority: 3 In-Reply-To: Date: Wed, 23 Feb 2011 08:53:45 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <5A918D71-486B-49E4-AD39-3EF10C659C6B@hopcount.ca> References: <20110219210716.72943A5602B@drugs.dv.isc.org> <20110220203156.C1F83A6526F@drugs.dv.isc.org><3764325DE7FA4B2F9B77387EBD15EAF8@local> <20110220210758.81B93A65431@drugs.dv.isc.org><3D9B2A0D15F84DC6822FCF0FC6F8F214@local><20110220225811.1F68CA65BFC@drugs.dv.isc.org> <4D61BCBE.7020102@necom830.hpcl.titech.ac.jp> To: George Barwood X-Mailer: Apple Mail (2.1082) X-SA-Exim-Connect-IP: 199.212.90.30 X-SA-Exim-Mail-From: jabley@hopcount.ca X-SA-Exim-Scanned: No (on monster.hopcount.ca); SAEximRunCond expanded to false Cc: dnsext@ietf.org Subject: Re: [dnsext] Failure to add glue MUST cause TC to be set. X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 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, 23 Feb 2011 13:53:08 -0000 On 2011-02-21, at 15:04, George Barwood wrote: > org and info share name servers, but they each have 4 "in-zone" name = server names below the cut. No, ORG and INFO do not share nameservers. Joe From nweaver@ICSI.Berkeley.EDU Wed Feb 23 06:45:41 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2EA103A6A15 for ; Wed, 23 Feb 2011 06:45:41 -0800 (PST) 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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IubAUfz5o5DB for ; Wed, 23 Feb 2011 06:45:40 -0800 (PST) Received: from taffy.ICSI.Berkeley.EDU (taffy.ICSI.Berkeley.EDU [192.150.187.26]) by core3.amsl.com (Postfix) with ESMTP id 43D353A6A0D for ; Wed, 23 Feb 2011 06:45:40 -0800 (PST) Received: from albook.hsd1.ca.comcast.net (c-67-164-126-174.hsd1.ca.comcast.net [67.164.126.174]) (Authenticated sender: nweaver) by taffy.ICSI.Berkeley.EDU (Postfix) with ESMTP id 18ABC36A582; Wed, 23 Feb 2011 06:46:24 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Nicholas Weaver In-Reply-To: <4D649C0B.40905@necom830.hpcl.titech.ac.jp> Date: Wed, 23 Feb 2011 06:46:22 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <24BA1B5B-5FA3-4A94-8174-B82066702D57@ICSI.Berkeley.EDU> References: <20110216165921.GW96213@shinkuro.com> <3B90ED2E-980D-4B01-889F-447D66D0B58D@insensate.co.uk> <20110216174011.GZ96213@shinkuro.com> <20110218143653.GC84482@bikeshed.isc.org> <20110218151209.GF66684@shinkuro.com> <4D5EEE09.4080405@dougbarton.us> <20110218222950.GL74065@shinkuro.com> <4D5F270F.20401@abenaki.wabanaki.net> <199C7B2B4228461FB024E59A990DB46D@ics.forth.gr> <4D641DB6.4090705@necom830.hpcl.titech.ac.jp> <20110222205617.GS53815@shinkuro.com> <4D64489B.7020901@necom830.hpcl.titech.ac.jp> <713D992A-1DB9-4F72-9D18-8E923AD51D8D@icsi.berkeley.edu> <4D647551.5060602@necom830.hpcl.titech.ac.jp> <4D649C0B.40905@necom830.hpcl.titech.ac.jp> To: Masataka Ohta X-Mailer: Apple Mail (2.1082) Cc: Nicholas Weaver , dnsext@ietf.org Subject: Re: [dnsext] we need help to make names the same, was draft-yao-dnsext-identical-resolution-02 comment X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 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, 23 Feb 2011 14:45:41 -0000 On Feb 22, 2011, at 9:32 PM, Masataka Ohta wrote: > Nicholas Weaver wrote: >=20 >> Random reported SSL setups per second are ~1500/s for a commodity >> 64B processor with 1024B keys. >=20 > I think you are saying 1024b keys. >=20 > That's a lot slower than typical number on TCP connections per > second, which means computation load dominates. >=20 > Considering the following statement in RFC5507 (April 2009): >=20 > DNS queries over TCP are not subject > to this length limitation, but TCP imposes significantly higher per- > query overhead on name servers than UDP. >=20 > dynamic generation is not feasible at all. That is a statement in the RFC I find a bit of a red herring: I = personally find that the DNS community's fear of computation made sense = 15 years ago, but we are in the days where 1U servers are massively = powerful (8+ core 1U servers are reasonable) and, more importantly, we = understand how to make huge cluster servers that can RELIABLY scale to = entire data centers. Remember, a cluster solution is ONLY needed for those heavily loaded = authorities (TLDs, cc-TLDs) which require case insensitivity in non = ASCII text, which is not all that many anyway. An authority that has more like a few hundred base names can just run on = a single system, cache all the common cases, and call it good. >> AND such compute nodes could cache the signatures for >> common conventions, which means you can't computationally >> DOS the common cases >=20 > DOS will clear the cache. Worse, multiple layers of labels > increase the number of common cases exponentially, unless > you introduce redirection by BNAME. I disagree: a) The cache can be VERY large: a few GB or more of ram per NODE is = trivial (after all, its hard to buy nodes with LESS than 8 GB of RAM = these days). That can hold a lot of entries. b) You don't evict old but active entries, so the DOS attack can't = evict the common cases that you've learned. As long as the DOS doesn't start up when you start for the first time, = you can learn the common cases and make sure they remain cached in the = face of a computational DOS. Yes, DOS is a problem, but you can structure it so a COMPUTE DOS can = only affect new queries which is a far smaller problem: The problem = space may be near eXpoNenTIAl, but people don't type that way. >> 2048B signatures are only ~4x harder than 1024B signatures >> computationally to GENERATE, >=20 > As 2048 is not very large that Karatsuba Multiplication is > not very effective. >=20 >> but vastly harder to crack using brute force. >=20 > If it were vastly harder we should be using 520b key, if 512b > key was good enough 15 years ago. No, we should have ALWAYS been using 2048B RSA keys and 256B symmetric = keys and 512B hashes. =20 "If your crypto is in danger of brute forcing by anything short of a = cubic earth of sci-fi nanotech, use a longer key." =20 We failed that earlier on, but there really IS no excuse for that now. = And 2048B keys should still be on the order of ~300 ops/s/node. From vixie@isc.org Wed Feb 23 07:19:30 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 993963A6A14 for ; Wed, 23 Feb 2011 07:19:30 -0800 (PST) X-Quarantine-ID: X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER, Duplicate header field: "Cc" 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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dKZlKtzppz3e for ; Wed, 23 Feb 2011 07:19:29 -0800 (PST) Received: from nsa.vix.com (unknown [IPv6:2001:4f8:3:bb:230:48ff:fe5a:2f38]) by core3.amsl.com (Postfix) with ESMTP id 69F3D3A6A32 for ; Wed, 23 Feb 2011 07:19:29 -0800 (PST) Received: from nsa.vix.com (localhost [127.0.0.1]) by nsa.vix.com (Postfix) with ESMTP id 65D10A1019; Wed, 23 Feb 2011 15:20:14 +0000 (UTC) (envelope-from vixie@isc.org) From: Paul Vixie To: Florian Weimer In-Reply-To: Your message of "Wed, 23 Feb 2011 10:44:36 GMT." <82ei6zyqqz.fsf@mid.bfk.de> References: <4D622624.90303@ogud.com> <4D63907A.8010700@nlnetlabs.nl> <82zkpnyt3z.fsf@mid.bfk.de> <22348.1298455916@nsa.vix.com> <82ei6zyqqz.fsf@mid.bfk.de> X-Mailer: MH-E 8.2; nmh 1.2; XEmacs 21.4 (patch 22) Date: Wed, 23 Feb 2011 15:20:14 +0000 Message-ID: <39328.1298474414@nsa.vix.com> Cc: dnsext@ietf.org Subject: Re: [dnsext] WG opinion on draft : Improvements to DNS Resolvers, for Resiliency, Robustness, and Responsiveness X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 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, 23 Feb 2011 15:19:30 -0000 > From: Florian Weimer > Date: Wed, 23 Feb 2011 10:44:36 +0000 > > > while i'd like the DNSSEC solution you propose to also be done, i note > > that RBLDNSD operators are among the most technically adept name server > > operators in the history of the internet. a campaign to get this > > software patched and to get upgrades installed would have a very short > > tail (shorter than the BIND4 AXFR example cited earlier). > > For a while, I've been sitting on another rbldnsd/resolver interaction > bug and have been given the run-around so far. I'm not convinced that > deploying new code is simple. sometimes it takes a code fork if the author is no longer supporting a thing. > > this does seem to me worth doing since i'm not expecting all zones > > to be signed and since the specification with respect to empty > > non-terminals was never unclear. > > If it wasn't unclear, why did almost everyone implement the old behavior? who is everyone? i don't think bind or nominum or microsoft's or american internet's (now cisco's) authority servers have ever sent nxdomain on an empty non-terminal, and for a long time that was 100% of the market. nlnetlabs nsd and verisign atlas both understood the spec in this regard also. the behaviour everyone implemented was on the initiator side, wherein they did not stop a downward traversal on a cached nxdomain, even with an rfc 2308 proof in cache, thus shortcutting iteration and forwarding. the specification was not ambiguous on this point; it was utterly silent. however, given that the authority server's behaviour (send NOERROR with ANCOUNT=0) has always been unambiguous, this silence looks like a missed implication to me rather than omission by intent. From fweimer@bfk.de Wed Feb 23 07:47:42 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1F1043A68A2 for ; Wed, 23 Feb 2011 07:47:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.224 X-Spam-Level: X-Spam-Status: No, score=-2.224 tagged_above=-999 required=5 tests=[AWL=0.025, BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QBiqHl1Y5z17 for ; Wed, 23 Feb 2011 07:47:41 -0800 (PST) Received: from mx01.bfk.de (mx01.bfk.de [193.227.124.2]) by core3.amsl.com (Postfix) with ESMTP id BEC0D3A6845 for ; Wed, 23 Feb 2011 07:47:39 -0800 (PST) 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 1PsGwz-0007BI-1U; Wed, 23 Feb 2011 15:48:25 +0000 Received: by bfk.de with local id 1PsGwy-0005kv-Ug; Wed, 23 Feb 2011 15:48:24 +0000 To: Paul Vixie References: <4D622624.90303@ogud.com> <4D63907A.8010700@nlnetlabs.nl> <82zkpnyt3z.fsf@mid.bfk.de> <22348.1298455916@nsa.vix.com> <82ei6zyqqz.fsf@mid.bfk.de> <39328.1298474414@nsa.vix.com> From: Florian Weimer Date: Wed, 23 Feb 2011 15:48:24 +0000 In-Reply-To: <39328.1298474414@nsa.vix.com> (Paul Vixie's message of "Wed\, 23 Feb 2011 15\:20\:14 +0000") Message-ID: <82y656u4zb.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] WG opinion on draft : Improvements to DNS Resolvers, for Resiliency, Robustness, and Responsiveness X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 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, 23 Feb 2011 15:47:42 -0000 * Paul Vixie: >> If it wasn't unclear, why did almost everyone implement the old behavior? > > who is everyone? i don't think bind or nominum or microsoft's or > american internet's (now cisco's) authority servers have ever sent > nxdomain on an empty non-terminal, and for a long time that was 100% > of the market. The handling of empty non-terminals was changed in BIND 9.2.3, probably prompted by the standardization work on DNSSECbis. According to the CHANGES file, this is RT #4715 in your bug tracker. > nlnetlabs nsd and verisign atlas both understood the spec in this > regard also. Actually, ATLAS sent NXDOMAIN instead of NODATA for existing, non-delegated names with a missing RRset (that is, empty terminals) at one point in the not too-distant past. I don't remember if they implemented the old BIND behavior, too, but it would be odd to send NXDOMAIN for empty terminals, and NODATA for empty non-terminals. --=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 Wed Feb 23 08:18:54 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 48B663A6A0C for ; Wed, 23 Feb 2011 08:18:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.228 X-Spam-Level: X-Spam-Status: No, score=-2.228 tagged_above=-999 required=5 tests=[AWL=0.021, BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5Pr3E1FzdIlj for ; Wed, 23 Feb 2011 08:18:53 -0800 (PST) Received: from mx01.bfk.de (mx01.bfk.de [193.227.124.2]) by core3.amsl.com (Postfix) with ESMTP id 550CD3A67A1 for ; Wed, 23 Feb 2011 08:18:51 -0800 (PST) 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 1PsHRB-0001wj-FB; Wed, 23 Feb 2011 16:19:37 +0000 Received: by bfk.de with local id 1PsHRB-0007dq-Bz; Wed, 23 Feb 2011 16:19:37 +0000 To: Paul Vixie References: <4D622624.90303@ogud.com> <4D63907A.8010700@nlnetlabs.nl> <82zkpnyt3z.fsf@mid.bfk.de> <22348.1298455916@nsa.vix.com> <82ei6zyqqz.fsf@mid.bfk.de> <39328.1298474414@nsa.vix.com> <82y656u4zb.fsf@mid.bfk.de> From: Florian Weimer Date: Wed, 23 Feb 2011 16:19:37 +0000 In-Reply-To: <82y656u4zb.fsf@mid.bfk.de> (Florian Weimer's message of "Wed\, 23 Feb 2011 15\:48\:24 +0000") Message-ID: <82ei6yu3ja.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] WG opinion on draft : Improvements to DNS Resolvers, for Resiliency, Robustness, and Responsiveness X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 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, 23 Feb 2011 16:18:54 -0000 * Florian Weimer: >> nlnetlabs nsd and verisign atlas both understood the spec in this >> regard also. > > Actually, ATLAS sent NXDOMAIN instead of NODATA for existing, > non-delegated names with a missing RRset (that is, empty terminals) at > one point in the not too-distant past. I don't remember if they > implemented the old BIND behavior, too, but it would be odd to send > NXDOMAIN for empty terminals, and NODATA for empty non-terminals. Off-list, I was told that my terminology is off, which is true. Please read "empty RRsets" for "empty terminals". --=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 ebw@abenaki.wabanaki.net Wed Feb 23 08:43:31 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 88B533A690A for ; Wed, 23 Feb 2011 08:43:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.229 X-Spam-Level: X-Spam-Status: No, score=-2.229 tagged_above=-999 required=5 tests=[AWL=0.370, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Cd4zUXPik-gX for ; Wed, 23 Feb 2011 08:43:30 -0800 (PST) Received: from abenaki.wabanaki.net (abenaki.wabanaki.net [65.99.1.133]) by core3.amsl.com (Postfix) with ESMTP id 9DC5B3A68C5 for ; Wed, 23 Feb 2011 08:43:30 -0800 (PST) Received: from limpet.local (cpe-67-255-5-237.twcny.res.rr.com [67.255.5.237]) by abenaki.wabanaki.net (8.14.4/8.14.4) with ESMTP id p1NEvnnc052853 for ; Wed, 23 Feb 2011 09:57:50 -0500 (EST) (envelope-from ebw@abenaki.wabanaki.net) Message-ID: <4D653959.8070107@abenaki.wabanaki.net> Date: Wed, 23 Feb 2011 11:44:09 -0500 From: Eric Brunner-Williams Organization: wampumpeag User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: dnsext@ietf.org References: <20110216165921.GW96213@shinkuro.com> <3B90ED2E-980D-4B01-889F-447D66D0B58D@insensate.co.uk> <20110216174011.GZ96213@shinkuro.com> <20110218143653.GC84482@bikeshed.isc.org> <20110218151209.GF66684@shinkuro.com> <4D5EEE09.4080405@dougbarton.us> <20110218222950.GL74065@shinkuro.com> <4D5F270F.20401@abenaki.wabanaki.net> <199C7B2B4228461FB024E59A990DB46D@ics.forth.gr> <4D641DB6.4090705@necom830.hpcl.titech.ac.jp> <20110222205617.GS53815@shinkuro.com> <4D64489B.7020901@necom830.hpcl.titech.ac.jp> <713D992A-1DB9-4F72-9D18-8E923AD51D8D@icsi.berkeley.edu> <4D647551.5060602@necom830.hpcl.titech.ac.jp> <4D649C0B.40905@necom830.hpcl.titech.ac.jp> <24BA1B5B-5FA3-4A94-8174-B82066702D57@ICSI.Berkeley.EDU> In-Reply-To: <24BA1B5B-5FA3-4A94-8174-B82066702D57@ICSI.Berkeley.EDU> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [dnsext] we need help to make names the same, was draft-yao-dnsext-identical-resolution-02 comment X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 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, 23 Feb 2011 16:43:31 -0000 i think there are two unrelated issues: >> dynamic generation is not feasible at all. first, there are zones who's editors generate updates with on the order of 1 time/day, and zones who's editors generate updates with an order of 100 times/day. requirements for the CNOBI business model is not a general requirement. restated, for a large number of zones, including a plurality of zones who's editors have a contractual relation with a technical coordinating body, dynamic generation is simply not present or in plan. > Remember, a cluster solution is ONLY needed for those heavily loaded authorities (TLDs, cc-TLDs) which require case insensitivity in non ASCII text, which is not all that many anyway. second, overlooking the persistent error of using case to reason about caseless character repertoires, there is very limited experience with this use case at present. it is possible that one or more arabic script registries, of arbitrary contractual or memorandum or other documented policy stripe, will elect to map arabic script labels and latin script labels (see "chat arabic"). i don't want to itemize the possible pairings (or poly pairings) that operators may choose to attempt, whether uniform or conditional in their zones, though i'm trying to write a candidate policy document for a technical coordinating body. i simply want to suggest that "heavily loaded" may have a bi-modal distribution, and correlate to operators which map labels as a default, e.g., the .cn and similar operators for labels containing characters from the sc and tc repertories, and operators which do not map labels as a default, e.g., operators pursuing the CNOBI business model and monitizing each nominally distinct label. > An authority that has more like a few hundred base names can just run on a single system, cache all the common cases, and call it good. i hope this is several orders of magnitude lower than obtains for authorities offering a zone or zones in or between which label mapping for script and identifier support is offered. hope springes eternal, etc. -e From brian.peter.dickson@gmail.com Wed Feb 23 09:10:16 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EE6463A68C5 for ; Wed, 23 Feb 2011 09:10:16 -0800 (PST) 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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NXY4qdIm12Pq for ; Wed, 23 Feb 2011 09:10:16 -0800 (PST) Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by core3.amsl.com (Postfix) with ESMTP id DD4E53A67A1 for ; Wed, 23 Feb 2011 09:10:15 -0800 (PST) Received: by fxm15 with SMTP id 15so5094858fxm.31 for ; Wed, 23 Feb 2011 09:11:02 -0800 (PST) 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=wVvgmMoedhyfuMQXvY+O1AGIephljF5C9o6nJwO650k=; b=SUcTiuYmyRtVQeaClviHzh7jqb6K+WZ+2CzmA+pksxCFD1BEvnOwsSLrtTAaLx70UH dGm5oEkuxBaPvtkBam9lGTsvpiW8unAo4Nx0JN+y4MtxcKnTb5NREYUESgSkroyxq9cV JUb8SpiDYOnXVU4l8s7+ouah8QSiCZ2cgOckI= 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=iOSrc8zp+wZ2tsCM/dC9xAjEO6IXcpLkKyLBwOuQ4gFVrcwvHIsFLP+sONP5ljYk+/ cfdvtcMhSGrzQ7gbmU/gpdBzZ4KeURb8Iube7Lfd85pFaQwDC/j0dxD/cKGo6ODR2YxI 1Fxl1tcA/3cgGZe+QD0HXetmyLR08lGE13VI0= MIME-Version: 1.0 Received: by 10.223.114.209 with SMTP id f17mr5335004faq.136.1298479976470; Wed, 23 Feb 2011 08:52:56 -0800 (PST) Received: by 10.223.107.132 with HTTP; Wed, 23 Feb 2011 08:52:56 -0800 (PST) In-Reply-To: <82ei6yu3ja.fsf@mid.bfk.de> References: <4D622624.90303@ogud.com> <4D63907A.8010700@nlnetlabs.nl> <82zkpnyt3z.fsf@mid.bfk.de> <22348.1298455916@nsa.vix.com> <82ei6zyqqz.fsf@mid.bfk.de> <39328.1298474414@nsa.vix.com> <82y656u4zb.fsf@mid.bfk.de> <82ei6yu3ja.fsf@mid.bfk.de> Date: Wed, 23 Feb 2011 12:52:56 -0400 Message-ID: From: Brian Dickson To: Florian Weimer Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: dnsext@ietf.org Subject: Re: [dnsext] WG opinion on draft : Improvements to DNS Resolvers, for Resiliency, Robustness, and Responsiveness X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 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, 23 Feb 2011 17:10:17 -0000 On Wed, Feb 23, 2011 at 12:19 PM, Florian Weimer wrote: > * Florian Weimer: > >>> nlnetlabs nsd and verisign atlas both understood the spec in this >>> regard also. >> >> Actually, ATLAS sent NXDOMAIN instead of NODATA for existing, >> non-delegated names with a missing RRset (that is, empty terminals) at >> one point in the not too-distant past. =A0I don't remember if they >> implemented the old BIND behavior, too, but it would be odd to send >> NXDOMAIN for empty terminals, and NODATA for empty non-terminals. > > Off-list, I was told that my terminology is off, which is true. > Please read "empty RRsets" for "empty terminals". So, this is an interesting data point, arguably in support of Paul, because of the following: - it was clearly broken behavior (really, really broken) - you won't find a shorter tail than that - the vendor *is* the *only* user of the software (!!) - it helps illustrate the difference between NODATA and NXDOMAIN (and when the latter is the wrong answer) - wow - see point 1 :-) - it shows that regardless of deployment scope, there should be pressure to fix broken deployments, rather than to ankylose (rigidly anchor, forever) that broken-ness into the specifications (IMHO) Brian From ted.ietf@gmail.com Wed Feb 23 09:44:20 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A4CE43A691D for ; Wed, 23 Feb 2011 09:44:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.549 X-Spam-Level: X-Spam-Status: No, score=-4.549 tagged_above=-999 required=5 tests=[AWL=1.050, BAYES_00=-2.599, GB_I_LETTER=-2, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Sx8FCXQHhnTj for ; Wed, 23 Feb 2011 09:44:19 -0800 (PST) Received: from mail-qw0-f44.google.com (mail-qw0-f44.google.com [209.85.216.44]) by core3.amsl.com (Postfix) with ESMTP id 5D8863A68DC for ; Wed, 23 Feb 2011 09:44:19 -0800 (PST) Received: by qwh6 with SMTP id 6so2521441qwh.31 for ; Wed, 23 Feb 2011 09:45:06 -0800 (PST) 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=uoYwxNMhKj1k6Y08BMvNrRA2MQZjP2hUc5QringjPdA=; b=vAw1ilwxBarS9Ozn+6lQogjpwQay25xvoNBGLwiZUbhsjofAJcGbES0g3iqDrR5tYq aUmv3THhDAXjCEbBta3j/Th/4RigVHnsElD8qIW0o5vTQVkN6qjeOhtb4/hPENJysJmQ G+BCWrqlwglmbZQJRsR/Gm6dIDJPRvWUpEQy8= 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=LiIlBQLR0fpApKjBApVgMaGc3J7t3V5udiTFlCAJpVnD8Ogdq8GAY5jp3pnNBahiVJ Z9N86VRQSMTwEJby0DD6INRjFBnIlodQ49mC2wQ132J/gYsoCqmg2iQAQM3v9LioFqJb kiYLJocQzQ81PhTWevgNajhG0pZ/C4FawNddY= MIME-Version: 1.0 Received: by 10.229.98.198 with SMTP id r6mr3283512qcn.224.1298483106534; Wed, 23 Feb 2011 09:45:06 -0800 (PST) Received: by 10.229.98.210 with HTTP; Wed, 23 Feb 2011 09:45:06 -0800 (PST) In-Reply-To: <20110223114720.GA10740@bikeshed.isc.org> References: <20110223001502.31614.56353.idtracker@localhost> <20110223114720.GA10740@bikeshed.isc.org> Date: Wed, 23 Feb 2011 09:45:06 -0800 Message-ID: From: Ted Hardie To: Suzanne Woolf Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: dnsext@ietf.org Subject: Re: [dnsext] I-D Action:draft-ietf-dnsext-aliasing-requirements-00.txt X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 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, 23 Feb 2011 17:44:20 -0000 Hi Suzanne, Xiaodong, Thanks for producing the document; I think it's a good start toward getting a common terminology around the problem space. Reading through the text for "variants", I think it might actually be useful, though, to start a little further back. This might be particularly useful for non-DNS geek readers. What I'm thinking of is adding a section that says, in big bold letters: The DNS is a known-item lookup protocol. If you start up from that in big, bold letters, it first clarifies that any version of "sameness" or "variation" that is not about lookup is work that has to be done at some other layer. It also suggests describing different variant types in terms of the desired lookup behavior. CNAME is the "referral" version--it provides a pointer to another part of the namespace at which subsequent lookups should occur. Some variants may desire "referral" lookup behavior of some type not yet supported. Your text makes clear that there is a desired lookup behavior of "consistent result", where a query to and < will return (as much as possible) the same data. I think there are two flavors of "consistent result". For one, the relationship between or among the names queried is exposed. Much of the current text seems to assume that it would advantageous to expose that in order to reduce provisioning costs (especially for higher-layer constructs like names in certificates). A different flavor synthesizes a response that are consistent, but does not exposes the relationships among labels whose responses are "the same". (The different cache characteristics is probably something worth exploring as well). This probably seems both obvious and pedantic, but given that the likely audience will include folks more used to search-engine style behavior, I think trying to describe things in terms of pure lookup may help in the long run. regards, Ted Hardie On Wed, Feb 23, 2011 at 3:47 AM, Suzanne Woolf wrote: > > Colleagues, > > Per the announcement to the list last night, the -00 of the "aliases" > problem statement has been posted to the i-d repository. > > Your comments are sought. It was pushed out this week to keep the > discussion here going. > > It's a working draft and obviously needs a number of refinements on > terminology and details, but the most important thing to establish at > this point is whether it gets the overall landscape right. > > I hope we will have a -01 ready before Prague, so we can have a strong > document by then and focus in the meeting on some decisions. > > > best, > Suzanne > > On Tue, Feb 22, 2011 at 04:15:02PM -0800, Internet-Drafts@ietf.org wrote: >> A New Internet-Draft is available from the on-line Internet-Drafts direc= tories. >> This draft is a work item of the DNS Extensions Working Group of the IET= F. >> >> >> =A0 =A0 =A0 Title =A0 =A0 =A0 =A0 =A0 : Problem Statement: DNS Resolutio= n of Aliased Names >> =A0 =A0 =A0 Author(s) =A0 =A0 =A0 : S. Woolf, X. Lee >> =A0 =A0 =A0 Filename =A0 =A0 =A0 =A0: draft-ietf-dnsext-aliasing-require= ments-00.txt >> =A0 =A0 =A0 Pages =A0 =A0 =A0 =A0 =A0 : 20 >> =A0 =A0 =A0 Date =A0 =A0 =A0 =A0 =A0 =A0: 2011-02-22 >> >> This document attempts to describe a set of issues that arises from >> the desire to treat a set or group of names as "aliases" of each >> other, "bundled," "variants," or "the same," which is problematic in >> terms of corresponding behavior for DNS labels and FQDNs. >> >> With the emergence of internationalized domain names, among other >> potential use cases, two or more names that users will regard as >> having identical meaning may sometimes require corresponding behavior >> in the underlying infrastructure, possibly in the DNS itself. =A0It's >> not clear how to accommodate this required behavior of such names in >> DNS resolution; in particular, it's not clear when they are best >> accommodated in registry practices for generating names for lookup in >> the DNS, existing DNS protocol elements and behavior, existing >> application-layer mechanisms and practices, or some set of protocol >> elements or behavior not yet defined. =A0This document attempts to >> describe some of these cases and the behavior of some of the possible >> solutions discussed to date. >> >> A URL for this Internet-Draft is: >> http://www.ietf.org/internet-drafts/draft-ietf-dnsext-aliasing-requireme= nts-00.txt >> >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ >> >> Below is the data which will enable a MIME compliant mail reader >> implementation to automatically retrieve the ASCII version of the >> Internet-Draft. > > >> _______________________________________________ >> dnsext mailing list >> dnsext@ietf.org >> https://www.ietf.org/mailman/listinfo/dnsext > > _______________________________________________ > dnsext mailing list > dnsext@ietf.org > https://www.ietf.org/mailman/listinfo/dnsext > From Ed.Lewis@neustar.biz Wed Feb 23 11:03:39 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 33B843A6943 for ; Wed, 23 Feb 2011 11:03:39 -0800 (PST) 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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MgrV+h45D0NB for ; Wed, 23 Feb 2011 11:03:38 -0800 (PST) Received: from stora.ogud.com (stora.ogud.com [66.92.146.20]) by core3.amsl.com (Postfix) with ESMTP id DAC453A6956 for ; Wed, 23 Feb 2011 11:03:37 -0800 (PST) Received: from Work-Laptop-2.local (gatt.md.ogud.com [10.20.30.6]) by stora.ogud.com (8.14.4/8.14.4) with ESMTP id p1NJ4pXa037419; Wed, 23 Feb 2011 14:04:52 -0500 (EST) (envelope-from Ed.Lewis@neustar.biz) Received: from [10.31.200.118] by Work-Laptop-2.local (PGP Universal service); Wed, 23 Feb 2011 14:04:24 -0500 X-PGP-Universal: processed; by Work-Laptop-2.local on Wed, 23 Feb 2011 14:04:24 -0500 Mime-Version: 1.0 Message-Id: In-Reply-To: <4D622624.90303@ogud.com> References: <4D622624.90303@ogud.com> Date: Wed, 23 Feb 2011 14:04:15 -0500 To: namedroppers@ops.ietf.org, 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] WG opinion on draft : Improvements to DNS Resolvers, for Resiliency, Robustness, and Responsiveness X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 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, 23 Feb 2011 19:03:39 -0000 At 3:45 -0500 2/21/11, Olafur Gudmundsson wrote: >The chairs have received a request to Last call this draft. >http://tools.ietf.org/html/draft-vixie-dnsext-resimprove-00 Some comments on the document. # 1. Introduction # # 1.1. Iterative caching DNS resolvers can be both compliant and # interoperable without also being optimal. Indeed a wide range of # optimizations, mechanisms, and outright "tricks" can be employed # without affecting correctness or interopability. Such optimizations # could be recommended but never required. The first use of the word "optimal" is a problem. First, is there really a definition by which an "iterative caching" resolver can be deemed compliant? Second, is there any way to measure the degree to which it is optimal. This is a wording nit. I'd suggest something along this line: 1.1. Iterative caching DNS resolvers can be interoperable with other servers yet vary in speed of obtaining an answer, safety in believing answers, efficient in use of computing resources, and so on. Interoperability is of the utmost importance, but there are some useful optimizations that deserve to be documented. (A rough reworking. The point is to remove comparative words, like "optimal" and "compliant," when there's nothing being compared.) # 1.3. Three practices are described here: # # A. Revalidating a delegation when a parent NS RRset TTL expires. What does it mean to "validate" a delegation? We have a definition of validation in the context of DNSSEC. I am sure this is different. # B. Stopping a downward cache search when an NXDOMAIN is encountered. I'm not so sure this is a good one. It goes against RFC 2308. # C. Upgrading the credibility of NS RRsets upon delegation events. A mistake I've made many times: the term is "trustworthiness," not credibility. See RFC 2181, 5.4.1. Ranking data. # 3. Stopping Downward Cache Search on NXDOMAIN # # 3.1. In virtually all existing resolvers, a cached NXDOMAIN is not # considered "proof" that there can be no child domains underneath. # This is due to an ambiguity in RFC 1034 that failed to distinguish # empty nonterminal domain names from nonexistent names. For DNSSEC, # the IETF had to distinguish this case, but the implication on non- # DNSSEC resolvers wasn't fully realized. FWIW, the ambiguity was addressed in RFC 4592 to fix wild cards, not DNSSEC. # 3.2. When searching downward in its cache, an iterative caching DNS # resolver should stop searching if it encounters a cached NXDOMAIN. # The response to the triggering query should be NXDOMAIN. # # 3.3. When an iterative caching DNS resolver stores an NXDOMAIN in its # cache, all names and RRsets at or below that node should be deleted # since they will have become unreachable. This is in conflict with RFC 2308, section 5: RFC A negative answer that resulted from a name error (NXDOMAIN) should RFC be cached such that it can be retrieved and returned in response to RFC another query for the same that resulted in the RFC cached negative response. This says that the cached NXDOMAIN only applies to the FQDN itself, not it's domain. Ok, ok, that's just paper fighting paper, but this switch in requirements has to be addressed. And I have a sneaking suspicion that this optimization isn't all that good of an idea. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis NeuStar You can leave a voice message at +1-571-434-5468 Me to infant son: "Waah! Waah! Is that all you can say? Waah?" Son: "Waah!" From hallam@gmail.com Wed Feb 23 11:59:42 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 863443A6A57 for ; Wed, 23 Feb 2011 11:59:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.562 X-Spam-Level: X-Spam-Status: No, score=-3.562 tagged_above=-999 required=5 tests=[AWL=0.036, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1Oc1OWgUxQmK for ; Wed, 23 Feb 2011 11:59:41 -0800 (PST) Received: from mail-bw0-f44.google.com (mail-bw0-f44.google.com [209.85.214.44]) by core3.amsl.com (Postfix) with ESMTP id 50E2D3A6A3A for ; Wed, 23 Feb 2011 11:59:41 -0800 (PST) Received: by bwz13 with SMTP id 13so548925bwz.31 for ; Wed, 23 Feb 2011 12:00:28 -0800 (PST) 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=GJJaqDzkwAmzXigzJII4TH0Yuq4WHPUkRgc353DfyqY=; b=BQte9m6K1I8UWxSbYTo6Cu98qH0yRVyUnbRESPecL/t6EtIXkGFxt59EJlpxaLV21r IU9ZNrlLhVd8fhDdtXBoh/0k4YVx4AVoD8yvC4u//ucaEhsM/IohXiHfJa1NVnR87DSo R9dYytDQAockPAv/uZ8RPG81uUN1KGV58GSvM= 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=TEi0nLr8Qg9NWvQrW68S4R+yNdHlEqIVfhw02T3EuKlcWvHLfbhQ7qA4oDAZsegAc2 7jnt9c1vlTg5bjOV6Tf2XfVf16QUyUf/dYMzMZbwzVAq4ceLyOtZVLmJGgEHsecW0Hz9 I7tJhjkQgP6tB+ojjdu9Z0WzJsJSu3UowRNfE= MIME-Version: 1.0 Received: by 10.204.24.135 with SMTP id v7mr3772436bkb.99.1298491227991; Wed, 23 Feb 2011 12:00:27 -0800 (PST) Received: by 10.204.14.139 with HTTP; Wed, 23 Feb 2011 12:00:27 -0800 (PST) In-Reply-To: References: <20110216165921.GW96213@shinkuro.com> <3B90ED2E-980D-4B01-889F-447D66D0B58D@insensate.co.uk> <20110216174011.GZ96213@shinkuro.com> <20110218143653.GC84482@bikeshed.isc.org> <20110218151209.GF66684@shinkuro.com> <4D5EEE09.4080405@dougbarton.us> <20110218222950.GL74065@shinkuro.com> <4D5F270F.20401@abenaki.wabanaki.net> <199C7B2B4228461FB024E59A990DB46D@ics.forth.gr> <4D641DB6.4090705@necom830.hpcl.titech.ac.jp> <20110222205617.GS53815@shinkuro.com> <4D64489B.7020901@necom830.hpcl.titech.ac.jp> <713D992A-1DB9-4F72-9D18-8E923AD51D8D@icsi.berkeley.edu> Date: Wed, 23 Feb 2011 15:00:27 -0500 Message-ID: From: Phillip Hallam-Baker To: Tony Finch Content-Type: multipart/alternative; boundary=00032555ae826370f9049cf88c4f Cc: dnsext@ietf.org Subject: Re: [dnsext] we need help to make names the same, was draft-yao-dnsext-identical-resolution-02 comment X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 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, 23 Feb 2011 19:59:42 -0000 --00032555ae826370f9049cf88c4f Content-Type: text/plain; charset=ISO-8859-1 On Wed, Feb 23, 2011 at 5:30 AM, Tony Finch wrote: > On Tue, 22 Feb 2011, Phillip Hallam-Baker wrote: > > > If you are going to do [online signing], you might as well do a key > > exchange inline as well as we do in TLS. One key exchange can then be > > leveraged across multiple connections using kerberos style tickets (see > > DPLS for an example). > > That gives you channel security whereas DNSSEC gives you data origin > authentication. They are not the same things. True, but data origin authentication is probably the wrong model for a DNS security scheme. If we are going to consider changing the model of DNSSEC, which is what moving to online signatures would entail, then the whole architecture is back on the table. -- Website: http://hallambaker.com/ --00032555ae826370f9049cf88c4f Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Wed, Feb 23, 2011 at 5:30 AM, Tony Fi= nch <dot@dotat.at&= gt; wrote:
On Tue, 22 Feb 2011, Phillip Hallam-Baker wrote:

> If you are going to do [online signing], you might as well do a key
> exchange inline as well as we do in TLS. One key exc= hange can then be
> leveraged across multiple connections using kerberos style tickets (se= e
> DPLS for an example).

That gives you channel security whereas DNSSEC gives you data origin<= br> authentication. They are not the same things.

True, but data origin authentication is probably the wrong model for a D= NS security scheme.

If we are going to consider ch= anging the model of DNSSEC, which is what moving to online signatures would= entail, then the whole architecture is back on the table.=A0


--00032555ae826370f9049cf88c4f-- From nweaver@ICSI.Berkeley.EDU Wed Feb 23 13:48:16 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 567763A6912 for ; Wed, 23 Feb 2011 13:48:16 -0800 (PST) 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=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ue-xpRIPz6N1 for ; Wed, 23 Feb 2011 13:48:15 -0800 (PST) Received: from taffy.ICSI.Berkeley.EDU (taffy.ICSI.Berkeley.EDU [192.150.187.26]) by core3.amsl.com (Postfix) with ESMTP id 79A973A67F1 for ; Wed, 23 Feb 2011 13:48:15 -0800 (PST) Received: from albook.hsd1.ca.comcast.net (c-67-164-126-174.hsd1.ca.comcast.net [67.164.126.174]) (Authenticated sender: nweaver) by taffy.ICSI.Berkeley.EDU (Postfix) with ESMTP id 19FD836A035; Wed, 23 Feb 2011 13:49:03 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Nicholas Weaver In-Reply-To: Date: Wed, 23 Feb 2011 13:49:02 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <4CC95816-8225-4CAE-897F-3F13F965BCEE@ICSI.Berkeley.EDU> References: <20110216165921.GW96213@shinkuro.com> <3B90ED2E-980D-4B01-889F-447D66D0B58D@insensate.co.uk> <20110216174011.GZ96213@shinkuro.com> <20110218143653.GC84482@bikeshed.isc.org> <20110218151209.GF66684@shinkuro.com> <4D5EEE09.4080405@dougbarton.us> <20110218222950.GL74065@shinkuro.com> <4D5F270F.20401@abenaki.wabanaki.net> <199C7B2B4228461FB024E59A990DB46D@ics.forth.gr> <4D641DB6.4090705@necom830.hpcl.titech.ac.jp> <20110222205617.GS53815@shinkuro.com> <4D64489B.7020901@necom830.hpcl.titech.ac.jp> <713D992A-1DB9-4F72-9D18-8E923AD51D8D@icsi.berkeley.edu> To: Phillip Hallam-Baker X-Mailer: Apple Mail (2.1082) Cc: Nicholas Weaver , dnsext@ietf.org Subject: Re: [dnsext] we need help to make names the same, was draft-yao-dnsext-identical-resolution-02 comment X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 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, 23 Feb 2011 21:48:16 -0000 On Feb 23, 2011, at 12:00 PM, Phillip Hallam-Baker wrote: >=20 >=20 > On Wed, Feb 23, 2011 at 5:30 AM, Tony Finch wrote: > On Tue, 22 Feb 2011, Phillip Hallam-Baker wrote: >=20 > > If you are going to do [online signing], you might as well do a key > > exchange inline as well as we do in TLS. One key exchange can then = be > > leveraged across multiple connections using kerberos style tickets = (see > > DPLS for an example). >=20 > That gives you channel security whereas DNSSEC gives you data origin > authentication. They are not the same things. >=20 > True, but data origin authentication is probably the wrong model for a = DNS security scheme. >=20 > If we are going to consider changing the model of DNSSEC, which is = what moving to online signatures would entail, then the whole = architecture is back on the table.=20 Online signatures work within the existing DNSSEC model, you just need = to be willing to pay the computational cost in the cases where it is = necessary (eg, mixed-casing non-ascii) From d3e3e3@gmail.com Wed Feb 23 14:25:15 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E29A63A6953 for ; Wed, 23 Feb 2011 14:25:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.245 X-Spam-Level: X-Spam-Status: No, score=-104.245 tagged_above=-999 required=5 tests=[AWL=-0.646, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id taSTKr1u9jUt for ; Wed, 23 Feb 2011 14:25:15 -0800 (PST) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by core3.amsl.com (Postfix) with ESMTP id D4F013A68FD for ; Wed, 23 Feb 2011 14:25:14 -0800 (PST) Received: by wyb42 with SMTP id 42so3179767wyb.31 for ; Wed, 23 Feb 2011 14:26:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:from:date :message-id:subject:to:content-type; bh=JMMSVpt/OKeDohw0iIjxnveSZmpRHuDcPQZZgdXdWnM=; b=Y3qNdzGaTU7QOlkzm3FZE80eiEosJ8U29V9b/a9iMaUG9iI1fhhmSaYjI3b1oT6Q1/ tmm3NKujrk1bB2Y0XXpqlxsgWkRD/HgfhA6TUvrq/XmewlK0qDz/YzjMmLNl3ntlFOsD GT6tXbsULB8bonKukY/ECn0MyMNjFCg6EELy4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :content-type; b=luHExTTCFJEksH7DyIh1zfq8Ru+X1dvzwA6XCPyt782cXE1dUc7Ja68VgdtwgMkRBV xjkAiLtXR+d0hy47wHG7zWyClbiP1bt0WAK4CBYNo5B5k9uU89+ftoEQQyANEKOGiL4s N5B/txxq2BgSLk+tVBk7f6m6L2vUOR4E1BKto= Received: by 10.227.10.134 with SMTP id p6mr5068wbp.180.1298499962310; Wed, 23 Feb 2011 14:26:02 -0800 (PST) MIME-Version: 1.0 Received: by 10.227.68.140 with HTTP; Wed, 23 Feb 2011 14:25:41 -0800 (PST) In-Reply-To: References: <20110216165921.GW96213@shinkuro.com> <3B90ED2E-980D-4B01-889F-447D66D0B58D@insensate.co.uk> <20110216174011.GZ96213@shinkuro.com> <20110218143653.GC84482@bikeshed.isc.org> <20110218151209.GF66684@shinkuro.com> <4D5EEE09.4080405@dougbarton.us> <20110218222950.GL74065@shinkuro.com> <4D5F270F.20401@abenaki.wabanaki.net> <199C7B2B4228461FB024E59A990DB46D@ics.forth.gr> <4D641DB6.4090705@necom830.hpcl.titech.ac.jp> <20110222205617.GS53815@shinkuro.com> <4D64489B.7020901@necom830.hpcl.titech.ac.jp> <713D992A-1DB9-4F72-9D18-8E923AD51D8D@icsi.berkeley.edu> From: Donald Eastlake Date: Wed, 23 Feb 2011 14:25:41 -0800 Message-ID: To: dnsext@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Subject: Re: [dnsext] we need help to make names the same, was draft-yao-dnsext-identical-resolution-02 comment X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 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, 23 Feb 2011 22:25:16 -0000 Hi, On Wed, Feb 23, 2011 at 12:00 PM, Phillip Hallam-Baker wrote: > > > On Wed, Feb 23, 2011 at 5:30 AM, Tony Finch wrote: >> >> On Tue, 22 Feb 2011, Phillip Hallam-Baker wrote: >> >> > If you are going to do [online signing], you might as well do a key >> > exchange inline as well as we do in TLS. One key exchange can then be >> > leveraged across multiple connections using kerberos style tickets (see >> > DPLS for an example). >> >> That gives you channel security whereas DNSSEC gives you data origin >> authentication. They are not the same things. > > True, but data origin authentication is probably the wrong model for a DNS > security scheme. Why? Is your goal to make it easy for some entity not the authority for a zone to forge data in that zone? > If we are going to consider changing the model of DNSSEC, which is what > moving to online signatures would entail, then the whole architecture is > back on the table. Total nonsense. The on or off line signing question is pretty minor and completely orthogonal to the channel versus origin authentication question. As soon as you have a zone with dynamic update, your are shoved in the direction of on-line signing, it doesn't take mixed case non-ascii. Donald From mohta@necom830.hpcl.titech.ac.jp Wed Feb 23 15:36:13 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4706E3A694E for ; Wed, 23 Feb 2011 15:36:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.096 X-Spam-Level: X-Spam-Status: No, score=-0.096 tagged_above=-999 required=5 tests=[AWL=-0.006, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2Cx6Cwu77luW for ; Wed, 23 Feb 2011 15:36:12 -0800 (PST) Received: from necom830.hpcl.titech.ac.jp (necom830.hpcl.titech.ac.jp [131.112.32.132]) by core3.amsl.com (Postfix) with SMTP id 0EB463A692C for ; Wed, 23 Feb 2011 15:36:11 -0800 (PST) Received: (qmail 35614 invoked from network); 23 Feb 2011 23:49:08 -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; 23 Feb 2011 23:49:08 -0000 Message-ID: <4D6599DF.70607@necom830.hpcl.titech.ac.jp> Date: Thu, 24 Feb 2011 08:35:59 +0900 From: Masataka Ohta User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; ja; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: Nicholas Weaver References: <20110216165921.GW96213@shinkuro.com> <3B90ED2E-980D-4B01-889F-447D66D0B58D@insensate.co.uk> <20110216174011.GZ96213@shinkuro.com> <20110218143653.GC84482@bikeshed.isc.org> <20110218151209.GF66684@shinkuro.com> <4D5EEE09.4080405@dougbarton.us> <20110218222950.GL74065@shinkuro.com> <4D5F270F.20401@abenaki.wabanaki.net> <199C7B2B4228461FB024E59A990DB46D@ics.forth.gr> <4D641DB6.4090705@necom830.hpcl.titech.ac.jp> <20110222205617.GS53815@shinkuro.com> <4D64489B.7020901@necom830.hpcl.titech.ac.jp> <713D992A-1DB9-4F72-9D18-8E923AD51D8D@icsi.berkeley.edu> <4D647551.5060602@necom830.hpcl.titech.ac.jp> <4D649C0B.40905@necom830.hpcl.titech.ac.jp> <24BA1B5B-5FA3-4A94-8174-B82066702D57@ICSI.Berkeley.EDU> In-Reply-To: <24BA1B5B-5FA3-4A94-8174-B82066702D57@ICSI.Berkeley.EDU> Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit Cc: dnsext@ietf.org Subject: Re: [dnsext] we need help to make names the same, was draft-yao-dnsext-identical-resolution-02 comment X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 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, 23 Feb 2011 23:36:13 -0000 Nicholas Weaver wrote: >> Considering the following statement in RFC5507 (April 2009): >> >> DNS queries over TCP are not subject >> to this length limitation, but TCP imposes significantly higher per- >> query overhead on name servers than UDP. >> >> dynamic generation is not feasible at all. > That is a statement in the RFC I find a bit of a red herring: > I personally find that the DNS community's fear of > computation made sense 15 years ago, I gave you a reference. > but we are in > the days where 1U servers are massively powerful (8+ > core 1U servers are reasonable) and, more importantly, > we understand how to make huge cluster servers that can > RELIABLY scale to entire data centers. We know how RSA-768 was attacked. >> If it were vastly harder we should be using 520b key, if 512b >> key was good enough 15 years ago. > > No, we should have ALWAYS been using 2048B RSA keys and 256B > symmetric keys and 512B hashes. The reality is that they changed, even though there was no progress on integer factorization algorithm since 1996. Masataka Ohta From marka@isc.org Wed Feb 23 16:30:44 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 166BD3A697D for ; Wed, 23 Feb 2011 16:30:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[AWL=0.700, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d9iIzO+51040 for ; Wed, 23 Feb 2011 16:30:43 -0800 (PST) Received: from mx.ams1.isc.org (mx.ams1.isc.org [IPv6:2001:500:60::65]) by core3.amsl.com (Postfix) with ESMTP id B179D3A659A for ; Wed, 23 Feb 2011 16:30:42 -0800 (PST) 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 BE5E55F983B; Thu, 24 Feb 2011 00:31:15 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (drugs.dv.isc.org [IPv6:2001:470:1f00:820:ea06:88ff:fef3:4f9c]) (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 D2ED4216C22; Thu, 24 Feb 2011 00:31:13 +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 7DFB0AD98A4; Thu, 24 Feb 2011 11:31:09 +1100 (EST) To: Paul Vixie From: Mark Andrews References: <4D622624.90303@ogud.com> <4D63907A.8010700@nlnetlabs.nl> <82zkpnyt3z.fsf@mid.bfk.de> <22348.1298455916@nsa.vix.com> <82ei6zyqqz.fsf@mid.bfk.de> <39328.1298474414@nsa.vix.com> In-reply-to: Your message of "Wed, 23 Feb 2011 15:20:14 -0000." <39328.1298474414@nsa.vix.com> Date: Thu, 24 Feb 2011 11:31:09 +1100 Message-Id: <20110224003109.7DFB0AD98A4@drugs.dv.isc.org> Cc: dnsext@ietf.org Subject: Re: [dnsext] WG opinion on draft : Improvements to DNS Resolvers, for Resiliency, Robustness, and Responsiveness X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 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, 24 Feb 2011 00:30:44 -0000 In message <39328.1298474414@nsa.vix.com>, Paul Vixie writes: > > From: Florian Weimer > > Date: Wed, 23 Feb 2011 10:44:36 +0000 > > > > > while i'd like the DNSSEC solution you propose to also be done, i note > > > that RBLDNSD operators are among the most technically adept name server > > > operators in the history of the internet. a campaign to get this > > > software patched and to get upgrades installed would have a very short > > > tail (shorter than the BIND4 AXFR example cited earlier). > > > > For a while, I've been sitting on another rbldnsd/resolver interaction > > bug and have been given the run-around so far. I'm not convinced that > > deploying new code is simple. > > sometimes it takes a code fork if the author is no longer supporting a thing > . > > > > this does seem to me worth doing since i'm not expecting all zones > > > to be signed and since the specification with respect to empty > > > non-terminals was never unclear. > > > > If it wasn't unclear, why did almost everyone implement the old behavior? > > who is everyone? i don't think bind or nominum or microsoft's or > american internet's (now cisco's) authority servers have ever sent > nxdomain on an empty non-terminal, and for a long time that was 100% > of the market. nlnetlabs nsd and verisign atlas both understood the > spec in this regard also. The early DNSSEC RFCs specified that NXDOMAIN was to be returned and named did. It took some arguing by me, internally and then to dnsext, to get that reversed. While this is listed as a bug it was a protocol bug which was then corrected in code. 1416. [bug] Empty node should return NOERROR NODATA, not NXDOMAIN. [RT #4715] > the behaviour everyone implemented was on the initiator side, wherein > they did not stop a downward traversal on a cached nxdomain, even with > an rfc 2308 proof in cache, thus shortcutting iteration and forwarding. > the specification was not ambiguous on this point; it was utterly silent. > however, given that the authority server's behaviour (send NOERROR with > ANCOUNT=0) has always been unambiguous, this silence looks like a missed > implication to me rather than omission by intent. > _______________________________________________ > 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 vixie@isc.org Wed Feb 23 20:44:31 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DE3533A6801 for ; Wed, 23 Feb 2011 20:44:31 -0800 (PST) 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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qQUQeo5yZWfn for ; Wed, 23 Feb 2011 20:44:31 -0800 (PST) Received: from nsa.vix.com (unknown [IPv6:2001:4f8:3:bb:230:48ff:fe5a:2f38]) by core3.amsl.com (Postfix) with ESMTP id C45FF3A67C1 for ; Wed, 23 Feb 2011 20:44:30 -0800 (PST) Received: from nsa.vix.com (localhost [127.0.0.1]) by nsa.vix.com (Postfix) with ESMTP id BE817A1019 for ; Thu, 24 Feb 2011 04:45:17 +0000 (UTC) (envelope-from vixie@isc.org) From: Paul Vixie To: dnsext@ietf.org In-Reply-To: Your message of "Wed, 23 Feb 2011 14:04:15 EST." References: <4D622624.90303@ogud.com> X-Mailer: MH-E 8.2; nmh 1.2; XEmacs 21.4 (patch 22) Date: Thu, 24 Feb 2011 04:45:17 +0000 Message-ID: <87981.1298522717@nsa.vix.com> Subject: Re: [dnsext] WG opinion on draft : Improvements to DNS Resolvers, for Resiliency, Robustness, and Responsiveness X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 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, 24 Feb 2011 04:44:32 -0000 > Date: Wed, 23 Feb 2011 14:04:15 -0500 > From: Edward Lewis > > # A. Revalidating a delegation when a parent NS RRset TTL expires. > > What does it mean to "validate" a delegation? We have a definition of > validation in the context of DNSSEC. I am sure this is different. in this context it means making sure the delegation still exists. > # B. Stopping a downward cache search when an NXDOMAIN is encountered. > > I'm not so sure this is a good one. It goes against RFC 2308. see below. > # 3.2. When searching downward in its cache, an iterative caching DNS > # resolver should stop searching if it encounters a cached NXDOMAIN. > # The response to the triggering query should be NXDOMAIN. > # > # 3.3. When an iterative caching DNS resolver stores an NXDOMAIN in its > # cache, all names and RRsets at or below that node should be deleted > # since they will have become unreachable. > > This is in conflict with RFC 2308, section 5: > > RFC A negative answer that resulted from a name error (NXDOMAIN) should > RFC be cached such that it can be retrieved and returned in response to > RFC another query for the same that resulted in the > RFC cached negative response. > > This says that the cached NXDOMAIN only applies to the FQDN itself, not > it's domain. Ok, ok, that's just paper fighting paper, but this switch in > requirements has to be addressed. it does not say "only", which would have been overprescriptive, and the resimprove proposal could be seen as a 2308 amendment to the effect that in addition to what 2308 says, and is not in conflict with it. if so then it would make resimprove a standards track document not a bcp. > And I have a sneaking suspicion that this optimization isn't all that good > of an idea. please say more when your suspicions become less sneaky? From brian.peter.dickson@gmail.com Wed Feb 23 21:35:26 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 075EB3A69C5 for ; Wed, 23 Feb 2011 21:35:26 -0800 (PST) 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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TKvlENvIJCYQ for ; Wed, 23 Feb 2011 21:35:23 -0800 (PST) Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by core3.amsl.com (Postfix) with ESMTP id 979233A69BE for ; Wed, 23 Feb 2011 21:35:22 -0800 (PST) Received: by fxm15 with SMTP id 15so193649fxm.31 for ; Wed, 23 Feb 2011 21:36:10 -0800 (PST) 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=ll9OvEH4fGp46ArQ14vsZ7aIjdaFCAXdfz9Jr21zcd4=; b=Zcic1MbGRcCTp5jUTXWUl7AERNSWlQ0HVFuAii7g5rbaohP6pJLyAiuPqIGBHKbwXe OtTL7+7RxDPGwiXbL0Q41ir+7mmMIaTX09DLj02Rz8p8k62nefOjD6b05f9Kejh7/fS7 aNzKaOjpb/tHjPYduAfYprzg307sCosSMPL7E= 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=iaFO9RuAA6OAdXHaHZZBZ67TOWIjgaxsLbMpsUrTL1VSBtKO5wnSsvC9EJ1N7ZyxDf dtMmastKdOEMUT+H2jhyuZI8iZZU5uVA7IDVIUhulXhC/7rkEXsGj8BHPW1tEvk26M2h r1FivVvkdAjb/qAyvrx4snoAndpIkYTF8Jya0= MIME-Version: 1.0 Received: by 10.223.114.209 with SMTP id f17mr423286faq.136.1298525770567; Wed, 23 Feb 2011 21:36:10 -0800 (PST) Received: by 10.223.107.132 with HTTP; Wed, 23 Feb 2011 21:36:10 -0800 (PST) In-Reply-To: <87981.1298522717@nsa.vix.com> References: <4D622624.90303@ogud.com> <87981.1298522717@nsa.vix.com> Date: Thu, 24 Feb 2011 01:36:10 -0400 Message-ID: From: Brian Dickson To: Paul Vixie Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: dnsext@ietf.org Subject: Re: [dnsext] WG opinion on draft : Improvements to DNS Resolvers, for Resiliency, Robustness, and Responsiveness X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 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, 24 Feb 2011 05:35:26 -0000 I have some questions, which this discussion has caused me to consider... (I apologize if they are answered in some RFC or another already, and/or they may need to be addressed in some future -bis document if they don't belong here.) On Thu, Feb 24, 2011 at 12:45 AM, Paul Vixie wrote: >> Date: Wed, 23 Feb 2011 14:04:15 -0500 >> From: Edward Lewis >> >> # =A0 =A0 =A0A. Revalidating a delegation when a parent NS RRset TTL exp= ires. >> >> What does it mean to "validate" a delegation? =A0We have a definition of >> validation in the context of DNSSEC. =A0I am sure this is different. > > in this context it means making sure the delegation still exists. Delegations come from referrals and authority sections thereof... (restating the obvious.) There is an odd corner case to consider, but I'm not sure if it's been considered, and I think it is something which is slightly more likely to occur nowadays than in the distant past: Suppose a nameserver serves both a particular zone, and a great(^n)-grandchild zone. (E.g. a nameserver serving some TLD, and simultaneously doing DNS hosting for third parties.) Suppose also, that some intermediate zone(s), great(^n-1)-grandchild, parent of the great(^n)-grandchild zone, is *not* served by this nameserver,. but is delegated elsewhere. That "other" server then delegates back to "this" server, for the great(^n)-grandchild zone. An iterative resolver, directed to this (TLD) server by the root server(s), when querying for the great(^n)-grandchild zone, gets back an answer for the great(^n)-grandchild *directly* (no passing "go"), including that zone's authority data. It gets that without ever chaining through the delegations from the TLD through the great(^n-1)-grandchild zone(s). (Obviously in the DNSSEC case, there would need to be explicit DS chasing and proofs included in serving the answer, if DO=3D1 on the client query.) Should not the iterative resolver look for the intermediate referrals, if they aren't already in the cache? I think it *needs* those to "validate" the delegation... (i.e. for the optimization of the present proposal.) Have I lost everyone yet? >> # =A0 =A0 =A0B. Stopping a downward cache search when an NXDOMAIN is enc= ountered. >> >> I'm not so sure this is a good one. =A0It goes against RFC 2308. > > see below. > >> # =A0 3.2. When searching downward in its cache, an iterative caching DN= S >> # =A0 resolver should stop searching if it encounters a cached NXDOMAIN. >> # =A0 The response to the triggering query should be NXDOMAIN. >> # >> # =A0 3.3. When an iterative caching DNS resolver stores an NXDOMAIN in = its >> # =A0 cache, all names and RRsets at or below that node should be delete= d >> # =A0 since they will have become unreachable. >> >> This is in conflict with RFC 2308, section 5: >> >> RFC A negative answer that resulted from a name error (NXDOMAIN) should >> RFC be cached such that it can be retrieved and returned in response to >> RFC another query for the same that resulted in the >> RFC cached negative response. >> >> This says that the cached NXDOMAIN only applies to the FQDN itself, not >> it's domain. =A0Ok, ok, that's just paper fighting paper, but this switc= h in >> requirements has to be addressed. > > it does not say "only", which would have been overprescriptive, and the > resimprove proposal could be seen as a 2308 amendment to the effect that > in addition to what 2308 says, and is not in conflict with it. =A0if so t= hen > it would make resimprove a standards track document not a bcp. > >> And I have a sneaking suspicion that this optimization isn't all that go= od >> of an idea. > > please say more when your suspicions become less sneaky? Here's a sneaky-by-proxy observation and/or question: Consider a query for "foo.bar.no-chickens.example.net.". Suppose that "no-chickens.example.net." does not exist (NXDOMAIN and no descendants). The authority server for example.net returns "NXDOMAIN", which applies to the FQDN of the original query (and gets cached there only), "foo.bar.no-chickens.example.net." I don't think there's anything in the answer that indicates *where* in the FQDN, while matching downward, that there was an NXDOMAIN. For optimization purposes, it would be good (I think) to establish the "best" place to put an NXDOMAIN. I.e. Query downward from the zone apex, iteratively, until an NXDOMAIN is found. QTYPE =3D NS is benign and/or informative. This should be in parallel, since it isn't needed for answering the original query. (While it might be "interesting" to somehow signal this in the first NXDOMAIN answer, I can't imagine how to do this without breaking lots of software... like, all of it. E.g. what would happen if the answer section (also) included the "shorter" NXDOMAIN FQDN, e.g. "no-chickens.example.net", with RTYPE =3D ANY instead of matching the QTYPE?) Putting the NXDOMAIN as close to the root of the DNS tree as possible is a clear optimization, since subsequent queries for any sibling of the first query, wouldn't succeed. It doesn't change the number of NXDOMAINs required from the current state, it just moves the NXDOMAIN to a new node. And, it not only reduces (theoretical) load to the authority server, it also prevents lots of leaf NXDOMAINs from populating the cache, below the "real" place that the NXDOMAIN should be. (It even lowers the impact on the cache, as the "match downwards" will terminate sooner.) I'm sure there's a more succinct way to word this, for adding text to the document. Brian From vixie@isc.org Thu Feb 24 00:17:06 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E8AF13A6961 for ; Thu, 24 Feb 2011 00:17:06 -0800 (PST) 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=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RXI2eSJlAERH for ; Thu, 24 Feb 2011 00:17:06 -0800 (PST) Received: from nsa.vix.com (unknown [IPv6:2001:4f8:3:bb:230:48ff:fe5a:2f38]) by core3.amsl.com (Postfix) with ESMTP id EE6AA3A6A0C for ; Thu, 24 Feb 2011 00:17:05 -0800 (PST) Received: from nsa.vix.com (localhost [127.0.0.1]) by nsa.vix.com (Postfix) with ESMTP id 7401CA1059 for ; Thu, 24 Feb 2011 08:17:53 +0000 (UTC) (envelope-from vixie@isc.org) From: Paul Vixie To: dnsext@ietf.org In-Reply-To: Your message of "Wed, 23 Feb 2011 15:48:24 GMT." <82y656u4zb.fsf@mid.bfk.de> References: <4D622624.90303@ogud.com> <4D63907A.8010700@nlnetlabs.nl> <82zkpnyt3z.fsf@mid.bfk.de> <22348.1298455916@nsa.vix.com> <82ei6zyqqz.fsf@mid.bfk.de> <39328.1298474414@nsa.vix.com> <82y656u4zb.fsf@mid.bfk.de> X-Mailer: MH-E 8.2; nmh 1.2; XEmacs 21.4 (patch 22) Date: Thu, 24 Feb 2011 08:17:53 +0000 Message-ID: <99663.1298535473@nsa.vix.com> Subject: Re: [dnsext] WG opinion on draft : Improvements to DNS Resolvers, for Resiliency, Robustness, and Responsiveness X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 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, 24 Feb 2011 08:17:07 -0000 > From: Florian Weimer > Date: Wed, 23 Feb 2011 15:48:24 +0000 > > > who is everyone? i don't think bind or nominum or microsoft's or > > american internet's (now cisco's) authority servers have ever sent > > nxdomain on an empty non-terminal, and for a long time that was 100% > > of the market. > > The handling of empty non-terminals was changed in BIND 9.2.3, > probably prompted by the standardization work on DNSSECbis. According > to the CHANGES file, this is RT #4715 in your bug tracker. as marka has explained, this was a dnssec protocol bug, which bind9 tracked. > > nlnetlabs nsd and verisign atlas both understood the spec in this > > regard also. > > Actually, ATLAS sent NXDOMAIN instead of NODATA for existing, > non-delegated names with a missing RRset (that is, empty terminals) at > one point in the not too-distant past. I don't remember if they > implemented the old BIND behavior, too, but it would be odd to send > NXDOMAIN for empty terminals, and NODATA for empty non-terminals. --- > Off-list, I was told that my terminology is off, which is true. > Please read "empty RRsets" for "empty terminals". either way this is unrelated to empty nonterminals, which atlas never had to deal with anyway, i should not have mentioned it. --- > Date: Wed, 23 Feb 2011 12:52:56 -0400 > From: Brian Dickson > ... > - it shows that regardless of deployment scope, there should be > pressure to fix broken deployments, rather than to ankylose (rigidly > anchor, forever) that broken-ness into the specifications (IMHO) right. From dougb@dougbarton.us Thu Feb 24 00:35:38 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6B7C43A6A15 for ; Thu, 24 Feb 2011 00:35:38 -0800 (PST) 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=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wt7o8lVgP42U for ; Thu, 24 Feb 2011 00:35:37 -0800 (PST) Received: from mail2.fluidhosting.com (mx22.fluidhosting.com [204.14.89.5]) by core3.amsl.com (Postfix) with ESMTP id E8C203A69E4 for ; Thu, 24 Feb 2011 00:35:36 -0800 (PST) Received: (qmail 24098 invoked by uid 399); 24 Feb 2011 08:36:20 -0000 Received: from router.ka9q.net (HELO doug-optiplex.ka9q.net) (dougb@dougbarton.us@75.60.237.91) by mail2.fluidhosting.com with ESMTPAM; 24 Feb 2011 08:36:20 -0000 X-Originating-IP: 75.60.237.91 X-Sender: dougb@dougbarton.us Message-ID: <4D661882.2020403@dougbarton.us> Date: Thu, 24 Feb 2011 00:36:18 -0800 From: Doug Barton Organization: http://SupersetSolutions.com/ User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.13) Gecko/20110129 Thunderbird/3.1.7 MIME-Version: 1.0 To: dnsext@ietf.org References: <20110223001502.31614.56353.idtracker@localhost> In-Reply-To: <20110223001502.31614.56353.idtracker@localhost> X-Enigmail-Version: 1.1.2 OpenPGP: id=1A1ABC84 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [dnsext] I-D Action:draft-ietf-dnsext-aliasing-requirements-00.txt X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 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, 24 Feb 2011 08:35:38 -0000 I think this is a great draft, and it expresses both the parameters of the problem and the requirements for a solution in the way that I understand them (for whatever that's worth). Doug On 02/22/2011 16:15, Internet-Drafts@ietf.org wrote: > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the DNS Extensions Working Group of the IETF. > > > Title : Problem Statement: DNS Resolution of Aliased Names > Author(s) : S. Woolf, X. Lee > Filename : draft-ietf-dnsext-aliasing-requirements-00.txt > Pages : 20 > Date : 2011-02-22 > > This document attempts to describe a set of issues that arises from > the desire to treat a set or group of names as "aliases" of each > other, "bundled," "variants," or "the same," which is problematic in > terms of corresponding behavior for DNS labels and FQDNs. > > With the emergence of internationalized domain names, among other > potential use cases, two or more names that users will regard as > having identical meaning may sometimes require corresponding behavior > in the underlying infrastructure, possibly in the DNS itself. It's > not clear how to accommodate this required behavior of such names in > DNS resolution; in particular, it's not clear when they are best > accommodated in registry practices for generating names for lookup in > the DNS, existing DNS protocol elements and behavior, existing > application-layer mechanisms and practices, or some set of protocol > elements or behavior not yet defined. This document attempts to > describe some of these cases and the behavior of some of the possible > solutions discussed to date. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-dnsext-aliasing-requirements-00.txt > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. > > > > _______________________________________________ > dnsext mailing list > dnsext@ietf.org > https://www.ietf.org/mailman/listinfo/dnsext -- 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 vixie@isc.org Thu Feb 24 00:43:45 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 871E73A6A15 for ; Thu, 24 Feb 2011 00:43:45 -0800 (PST) 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=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DRuS6XVv2S2G for ; Thu, 24 Feb 2011 00:43:44 -0800 (PST) Received: from nsa.vix.com (unknown [IPv6:2001:4f8:3:bb:230:48ff:fe5a:2f38]) by core3.amsl.com (Postfix) with ESMTP id 7F8E63A6A34 for ; Thu, 24 Feb 2011 00:43:44 -0800 (PST) Received: from nsa.vix.com (localhost [127.0.0.1]) by nsa.vix.com (Postfix) with ESMTP id 5806FA1063 for ; Thu, 24 Feb 2011 08:44:33 +0000 (UTC) (envelope-from vixie@isc.org) From: Paul Vixie To: dnsext@ietf.org In-Reply-To: Your message of "Thu, 24 Feb 2011 01:36:10 -0400." References: <4D622624.90303@ogud.com> <87981.1298522717@nsa.vix.com> X-Mailer: MH-E 8.2; nmh 1.2; XEmacs 21.4 (patch 22) Date: Thu, 24 Feb 2011 08:44:33 +0000 Message-ID: <1585.1298537073@nsa.vix.com> Subject: Re: [dnsext] WG opinion on draft : Improvements to DNS Resolvers, for Resiliency, Robustness, and Responsiveness X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 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, 24 Feb 2011 08:43:45 -0000 > Date: Thu, 24 Feb 2011 01:36:10 -0400 > From: Brian Dickson > > > in this context it means making sure the delegation still exists. > > There is an odd corner case to consider, but I'm not sure if it's been > considered, and I think it is something which is slightly more likely > to occur nowadays than in the distant past: > > Suppose a nameserver serves both a particular zone, and a > great(^n)-grandchild zone. > (E.g. a nameserver serving some TLD, and simultaneously doing DNS > hosting for third parties.) > Suppose also, that some intermediate zone(s), great(^n-1)-grandchild, > parent of the great(^n)-grandchild zone, is *not* served by this > nameserver,. but is delegated elsewhere. That "other" server then > delegates back to "this" server, for the great(^n)-grandchild zone. > > An iterative resolver, directed to this (TLD) server by the root > server(s), when querying for the great(^n)-grandchild zone, gets back > an answer for the great(^n)-grandchild *directly* (no passing "go"), > including that zone's authority data. > It gets that without ever chaining through the delegations from the > TLD through the great(^n-1)-grandchild zone(s). that's fine. > (Obviously in the DNSSEC case, there would need to be explicit DS > chasing and proofs included in serving the answer, if DO=1 on the > client query.) yes. > Should not the iterative resolver look for the intermediate referrals, > if they aren't already in the cache? > I think it *needs* those to "validate" the delegation... (i.e. for the > optimization of the present proposal.) no. resimprove does not propose any change to the delegation model. if a cached ns rrset is received from the servers for the closest bailiwick then known (for example, from a server for the root zone or a server for a tld zone) then the 1034/1035 assumption (wrong though it may be, as shown by your example) is that there are no zone cuts between the bailiwick and the referral, and this assumption is still valid for a resimprove implementation. --- on another topic: > Consider a query for "foo.bar.no-chickens.example.net.". > > Suppose that "no-chickens.example.net." does not exist (NXDOMAIN and > no descendants). > > The authority server for example.net returns "NXDOMAIN", which applies > to the FQDN of the original query (and gets cached there only), > "foo.bar.no-chickens.example.net." > > I don't think there's anything in the answer that indicates *where* in > the FQDN, while matching downward, that there was an NXDOMAIN. right. > For optimization purposes, it would be good (I think) to establish the > "best" place to put an NXDOMAIN. > I.e. Query downward from the zone apex, iteratively, until an NXDOMAIN > is found. QTYPE = NS is benign and/or informative. This should be in > parallel, since it isn't needed for answering the original query. that's way more traffic and complexity than we're proposing in resimprove. > Putting the NXDOMAIN as close to the root of the DNS tree as possible > is a clear optimization, since subsequent queries for any sibling of > the first query, wouldn't succeed. agreed but that would be a protocol change which we're not proposing here. in effect, this is what i took florian to mean when he suggested that a caching recursive name server be able to synthesize nxdomain based on a cached and secure NSEC or NSEC3. that's a good idea but it's beyond the scope of the resimprove proposal. From fanf2@hermes.cam.ac.uk Thu Feb 24 02:06:22 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D3D453A6A56 for ; Thu, 24 Feb 2011 02:06:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.349 X-Spam-Level: X-Spam-Status: No, score=-6.349 tagged_above=-999 required=5 tests=[AWL=0.250, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VQ4bJpwuPGcj for ; Thu, 24 Feb 2011 02:06:21 -0800 (PST) Received: from ppsw-51.csi.cam.ac.uk (ppsw-51.csi.cam.ac.uk [131.111.8.151]) by core3.amsl.com (Postfix) with ESMTP id 84B593A695C for ; Thu, 24 Feb 2011 02:06:21 -0800 (PST) X-Cam-AntiVirus: no malware found X-Cam-SpamDetails: not scanned X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ Received: from hermes-1.csi.cam.ac.uk ([131.111.8.51]:51141) by ppsw-51.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.158]:25) with esmtpa (EXTERNAL:fanf2) id 1PsY6G-0004vj-Xx (Exim 4.72) (return-path ); Thu, 24 Feb 2011 10:07:08 +0000 Received: from fanf2 (helo=localhost) by hermes-1.csi.cam.ac.uk (hermes.cam.ac.uk) with local-esmtp id 1PsY6G-0004tS-Gf (Exim 4.67) (return-path ); Thu, 24 Feb 2011 10:07:08 +0000 Date: Thu, 24 Feb 2011 10:07:08 +0000 From: Tony Finch X-X-Sender: fanf2@hermes-1.csi.cam.ac.uk To: Nicholas Weaver In-Reply-To: <4CC95816-8225-4CAE-897F-3F13F965BCEE@ICSI.Berkeley.EDU> Message-ID: References: <20110216165921.GW96213@shinkuro.com> <3B90ED2E-980D-4B01-889F-447D66D0B58D@insensate.co.uk> <20110216174011.GZ96213@shinkuro.com> <20110218143653.GC84482@bikeshed.isc.org> <20110218151209.GF66684@shinkuro.com> <4D5EEE09.4080405@dougbarton.us> <20110218222950.GL74065@shinkuro.com> <4D5F270F.20401@abenaki.wabanaki.net> <199C7B2B4228461FB024E59A990DB46D@ics.forth.gr> <4D641DB6.4090705@necom830.hpcl.titech.ac.jp> <20110222205617.GS53815@shinkuro.com> <4D64489B.7020901@necom830.hpcl.titech.ac.jp> <713D992A-1DB9-4F72-9D18-8E923AD51D8D@icsi.berkeley.edu> <4CC95816-8225-4CAE-897F-3F13F965BCEE@ICSI.Berkeley.EDU> User-Agent: Alpine 2.00 (LSU 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: Tony Finch Cc: dnsext@ietf.org Subject: Re: [dnsext] we need help to make names the same, was draft-yao-dnsext-identical-resolution-02 comment X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 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, 24 Feb 2011 10:06:22 -0000 On Wed, 23 Feb 2011, Nicholas Weaver wrote: > On Feb 23, 2011, at 12:00 PM, Phillip Hallam-Baker wrote: > > > > True, but data origin authentication is probably the wrong model for a > > DNS security scheme. If you want to argue that, please get in your time machine and go back to 1993. > > If we are going to consider changing the model of DNSSEC, which is > > what moving to online signatures would entail, then the whole > > architecture is back on the table. > > Online signatures work within the existing DNSSEC model, you just need > to be willing to pay the computational cost in the cases where it is > necessary (eg, mixed-casing non-ascii) You can predict in advance the maximum size of the signature cache you will need (since it's the same size as a pre-signed zone) and once the cache is populated the work you need to do is exactly the same as for re-signing a static zone. There are some cases where the maximum cache is unfeasibly huge, for example pool.ntp.org, in which case you might be able to get away with a smaller cache (which implies more computational work) or a more restricted data model. See also http://www.ietf.org/mail-archive/web/dnsext/current/msg08593.html and Colm's follow-up. Tony. -- f.anthony.n.finch http://dotat.at/ Shannon, Rockall, Malin, Hebrides: Southwest 6 to gale 8, occasionally severe gale 9 in Rockall, perhaps severe gale 9 later in Hebrides. Very rough or high, occasionally very high in northwest Rockall and northwest Hebrides. Occasional rain. Moderate or poor. From bortzmeyer@nic.fr Thu Feb 24 02:36:39 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 151B53A6407 for ; Thu, 24 Feb 2011 02:36:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.649 X-Spam-Level: X-Spam-Status: No, score=-109.649 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, J_CHICKENPOX_37=0.6, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mGn4qd0NnCRd for ; Thu, 24 Feb 2011 02:36:35 -0800 (PST) Received: from mx2.nic.fr (mx2.nic.fr [IPv6:2001:660:3003:2::4:11]) by core3.amsl.com (Postfix) with ESMTP id 2AA653A6A6F for ; Thu, 24 Feb 2011 02:36:33 -0800 (PST) Received: from mx2.nic.fr (localhost [127.0.0.1]) by mx2.nic.fr (Postfix) with SMTP id 8B12A1C0117; Thu, 24 Feb 2011 11:37:22 +0100 (CET) Received: from relay1.nic.fr (relay1.nic.fr [192.134.4.162]) by mx2.nic.fr (Postfix) with ESMTP id 72F171C0116; Thu, 24 Feb 2011 11:37:22 +0100 (CET) Received: from bortzmeyer.nic.fr (batilda.nic.fr [192.134.4.69]) by relay1.nic.fr (Postfix) with ESMTP id 67BF35680D3; Thu, 24 Feb 2011 11:37:22 +0100 (CET) Date: Thu, 24 Feb 2011 11:37:22 +0100 From: Stephane Bortzmeyer To: Suzanne Woolf Message-ID: <20110224103722.GA28031@nic.fr> References: <20110223001502.31614.56353.idtracker@localhost> <20110223114720.GA10740@bikeshed.isc.org> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20110223114720.GA10740@bikeshed.isc.org> X-Operating-System: Debian GNU/Linux 6.0 X-Kernel: Linux 2.6.32-5-686 i686 Organization: NIC France X-URL: http://www.nic.fr/ User-Agent: Mutt/1.5.20 (2009-06-14) Cc: dnsext@ietf.org Subject: Re: [dnsext] I-D Action:draft-ietf-dnsext-aliasing-requirements-00.txt X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 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, 24 Feb 2011 10:36:39 -0000 On Wed, Feb 23, 2011 at 11:47:20AM +0000, Suzanne Woolf wrote a message of 69 lines which said: > Per the announcement to the list last night, the -00 of the > "aliases" problem statement has been posted to the i-d repository. Well, thanks to the authors, it is a very necessary document and I appreciate that two courageous persons decided to actually work on it. This being said, I'm not terribly happy with the result. IMHO, such a document should be used to help people understand the issues before claiming "We need variants in the DNS" and I'm afraid it is too complicated at this stage to fill this role. More specifically: The document does not mention clearly that the starting point is a difference of expectations between normal humans and IETF members. Normal humans assume that some names are identical (color.example == colour.example, café.fr == cafe.fr, wells-fargo.com = wellsfargo.com, ibm.example = IBM.Example, etc) and the DNS does not deliver what they want. IETF participants know that my last example works and not the other three but, when you try to explain that to normal humans, they don't understand and they are right. It should be stated from the beginning that we simply cannot provide a DNS behaviour that will be seen by normal users as "natural" and "unsurprising" (because of the complexity of the rules and their language-dependant character). So, we should warn users, not try to create mechanisms that will *always* fall short of their expectations. Second, the document seems to assume that the problem is mostly, if not exclusively, an IDN thing. As the examples above (and the examples of phishing sites) show, this is far from true. In registries which are still discussing IDN registration (like .FR, see ), some people keep telling that IDN are complicated and we should not allow them because of this complication. But the examples above show that IDN are not the only issue. It would be better if the document clearly stated that. (Another french story: in .FR, the law - not the registry policies - says that city names are reserved to the city council, and this is done in a dash-independent way: saint-quentin.fr and saintquentin.fr are therefore part of the same "bundle". Since the law is only for cities, not for corporations, saint-gobain.fr and saintgobain.fr are still distinct. Imagine the user confusion!) The case (pun intended) of case-insensitivity is a complex one. It is obviously impossible to change the rules now but the document says several times that the case-insensitive rule is a good one, which is not obvious. The case-insensitivity rule is not perfect (in French, Poussin is a painter and poussin a bird) and users legitimally ask "why case is not important but a stupid dash is?". The document's only negative remark about case-insensitivity is about its use in compression (section 2.3.1), which seems to me an useless detail (because only implementers see it). I suggest to drop this sentence about compression: the biggest lack of consistency is not in compression, it is in the fact that DNS is fuzzy on some criteria (case) and strict in others (dash, spelling). The document mentions several times (for instance 3.1.1) the perceived need to be able to distinguish if a name is a member of a bundle. This need is not explicitely stated in the Proposed Requirments section (4) and is questionable. What is the rationale for this unstated requirment? After all, unless you use DNSSEC, I do not think there is today a way to tell if a name was generated by a wildcard expansion (if you want to test, tell me if real-name1.office--enregistrement.fr is real or synthetic). The section on Applications (3.3) apparently does not mention the fact that many application protocols (HTTP and SMTP are two obvious examples) need to be configured to recognize the bundle. (Which is a strong argument against a new DNS solution, since it will be useless anyway.) Technical nit: I find no mention of RFC 3403 which seems a (corner) case where even a purely DNS solution would be a problem if a rule uses the original domain name for rewriting. Editorial nit: the reference to the IDNA standard is now RFC 5890. From hallam@gmail.com Thu Feb 24 04:44:09 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 77A5E3A6AB6 for ; Thu, 24 Feb 2011 04:44:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.563 X-Spam-Level: X-Spam-Status: No, score=-3.563 tagged_above=-999 required=5 tests=[AWL=0.035, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t8llXi1u6pFi for ; Thu, 24 Feb 2011 04:44:07 -0800 (PST) Received: from mail-bw0-f44.google.com (mail-bw0-f44.google.com [209.85.214.44]) by core3.amsl.com (Postfix) with ESMTP id 63AE53A6878 for ; Thu, 24 Feb 2011 04:44:07 -0800 (PST) Received: by bwz13 with SMTP id 13so1185008bwz.31 for ; Thu, 24 Feb 2011 04:44:56 -0800 (PST) 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=bt3+rCyjI3VuLAokTSnlfDLDx9OuTppQnVBe4iOQYPk=; b=mIbnxPqLEpaErImKBd7wnSBszFDCE2sjBDJE9s9OuF+I+FsprTg+iLKvCw6cC6PZtB cK31COqj0WvLIYK9iKs0SyuxpD1gkyJlztQhpMWyReaaamMUETXQ3an1EWzjNMSn2Q2E TVV+Ht7cgWvg8djALOtdJ9PPecqVGAOpSeT04= 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=BacCFLSPWeQUlcKNv7KrjP6oRLjbaGFe455xirlfyB3mhvA6GPABoxfyBrkyhh9weH pOJhVHv3NQNvzoWjbAE1w3Od8Ds6KXqIb8I9g7WH/bjqdiR1K//od0dRuaSJRPA//o7V SEdWwUy1NTYchyNhQLQ4vD/1hZqCbSmgnfTjk= MIME-Version: 1.0 Received: by 10.204.7.213 with SMTP id e21mr705198bke.47.1298551495267; Thu, 24 Feb 2011 04:44:55 -0800 (PST) Received: by 10.204.14.139 with HTTP; Thu, 24 Feb 2011 04:44:55 -0800 (PST) In-Reply-To: References: <20110216165921.GW96213@shinkuro.com> <3B90ED2E-980D-4B01-889F-447D66D0B58D@insensate.co.uk> <20110216174011.GZ96213@shinkuro.com> <20110218143653.GC84482@bikeshed.isc.org> <20110218151209.GF66684@shinkuro.com> <4D5EEE09.4080405@dougbarton.us> <20110218222950.GL74065@shinkuro.com> <4D5F270F.20401@abenaki.wabanaki.net> <199C7B2B4228461FB024E59A990DB46D@ics.forth.gr> <4D641DB6.4090705@necom830.hpcl.titech.ac.jp> <20110222205617.GS53815@shinkuro.com> <4D64489B.7020901@necom830.hpcl.titech.ac.jp> <713D992A-1DB9-4F72-9D18-8E923AD51D8D@icsi.berkeley.edu> <4CC95816-8225-4CAE-897F-3F13F965BCEE@ICSI.Berkeley.EDU> Date: Thu, 24 Feb 2011 07:44:55 -0500 Message-ID: From: Phillip Hallam-Baker To: Tony Finch Content-Type: multipart/alternative; boundary=00151750e552991892049d069442 Cc: dnsext@ietf.org Subject: Re: [dnsext] we need help to make names the same, was draft-yao-dnsext-identical-resolution-02 comment X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 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, 24 Feb 2011 12:44:09 -0000 --00151750e552991892049d069442 Content-Type: text/plain; charset=ISO-8859-1 On Thu, Feb 24, 2011 at 5:07 AM, Tony Finch wrote: > On Wed, 23 Feb 2011, Nicholas Weaver wrote: > > On Feb 23, 2011, at 12:00 PM, Phillip Hallam-Baker wrote: > > > > > > True, but data origin authentication is probably the wrong model for a > > > DNS security scheme. > > If you want to argue that, please get in your time machine and go back to > 1993. > Why would I need a time machine? You still don't have anyone actually using DNSSEC for production? That snark might be justified if this was a system that was being deployed and used, but the original premise of the question was that it was necessary to revisit the design of DNSSEC in major ways to solve the 'same resolution' problem. > > If we are going to consider changing the model of DNSSEC, which is > > > what moving to online signatures would entail, then the whole > > > architecture is back on the table. > > > > Online signatures work within the existing DNSSEC model, you just need > > to be willing to pay the computational cost in the cases where it is > > necessary (eg, mixed-casing non-ascii) > > You can predict in advance the maximum size of the signature cache you > will need (since it's the same size as a pre-signed zone) and once the > cache is populated the work you need to do is exactly the same as for > re-signing a static zone. There are some cases where the maximum cache is > unfeasibly huge, for example pool.ntp.org, in which case you might be able > to get away with a smaller cache (which implies more computational work) > or a more restricted data model. > That would be a totally bizarre response to a requirement that is nonsense. If we had a time machine and could go back to 1983, making the DNS support this particular requirement might make sense. But unlike DNSSEC, the DNS is deployed and used. -- Website: http://hallambaker.com/ --00151750e552991892049d069442 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Thu, Feb 24, 2011 at 5:07 AM, Tony Finch <dot@dotat.at> wrote:
On Wed, 23 Feb 2011, Nicholas Weaver wrote:
> On Feb 23, 2011, at 12:00 PM, Phillip Hallam-Baker wrote:
> >
> > True, but data origin authentication is p= robably the wrong model for a
> > DNS security scheme.

If you want to argue that, please get in your time machine and go bac= k to
1993.

Why would I need a time machine? You still don't have anyone actually= using DNSSEC for production?

That snark might be justified if this was a system that was being deployed = and used, but the original premise of the question was that it was necessar= y to revisit the design of DNSSEC in major ways to solve the 'same reso= lution' problem.


<= br>
> > If we are going to consider changing the model of DNSSEC, which i= s
> > what moving to online signatures would entail, then the whole
> > architecture is back on the table.
>
> Online signatures work within the existing DNSSEC model, you just need=
> to be willing to pay the computational cost in the cases where it is > necessary (eg, mixed-casing non-ascii)

You can predict in advance the maximum size of the signature cache yo= u
will need (since it's the same size as a pre-signed zone) and once the<= br> cache is populated the work you need to do is exactly the same as for
re-signing a static zone. There are some cases where the maximum cache is unfeasibly huge, for example pool.ntp.org, in which case you might be able
to get away with a smaller cache (which implies more computational work) or a more restricted data model.

That w= ould be a totally bizarre response to a requirement that is nonsense.
=

If we had a time machine and could go back to 1983, mak= ing the DNS support this particular requirement might make sense.

But unlike DNSSEC, the DNS is deployed and used.
<= div>=A0
--
Website: http= ://hallambaker.com/

--00151750e552991892049d069442-- From fanf2@hermes.cam.ac.uk Thu Feb 24 04:47:15 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7E9453A68AF for ; Thu, 24 Feb 2011 04:47:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.377 X-Spam-Level: X-Spam-Status: No, score=-6.377 tagged_above=-999 required=5 tests=[AWL=0.222, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zxPyhgGHHTf9 for ; Thu, 24 Feb 2011 04:47:14 -0800 (PST) Received: from ppsw-50.csi.cam.ac.uk (ppsw-50.csi.cam.ac.uk [131.111.8.150]) by core3.amsl.com (Postfix) with ESMTP id 180AB3A6878 for ; Thu, 24 Feb 2011 04:47:13 -0800 (PST) X-Cam-AntiVirus: no malware found X-Cam-SpamDetails: not scanned X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ Received: from hermes-1.csi.cam.ac.uk ([131.111.8.51]:54191) by ppsw-50.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.157]:25) with esmtpa (EXTERNAL:fanf2) id 1Psabw-00089a-sZ (Exim 4.72) (return-path ); Thu, 24 Feb 2011 12:48:00 +0000 Received: from fanf2 (helo=localhost) by hermes-1.csi.cam.ac.uk (hermes.cam.ac.uk) with local-esmtp id 1Psabw-000177-TG (Exim 4.67) (return-path ); Thu, 24 Feb 2011 12:48:00 +0000 Date: Thu, 24 Feb 2011 12:48:00 +0000 From: Tony Finch X-X-Sender: fanf2@hermes-1.csi.cam.ac.uk To: Brian Dickson In-Reply-To: Message-ID: References: <4D622624.90303@ogud.com> <87981.1298522717@nsa.vix.com> User-Agent: Alpine 2.00 (LSU 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: Tony Finch Cc: dnsext@ietf.org Subject: Re: [dnsext] WG opinion on draft : Improvements to DNS Resolvers, for Resiliency, Robustness, and Responsiveness X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 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, 24 Feb 2011 12:47:15 -0000 On Thu, 24 Feb 2011, Brian Dickson wrote: > > There is an odd corner case to consider, but I'm not sure if it's been > considered, and I think it is something which is slightly more likely > to occur nowadays than in the distant past: > > Suppose a nameserver serves both a particular zone, and a > great(^n)-grandchild zone. > (E.g. a nameserver serving some TLD, and simultaneously doing DNS > hosting for third parties.) > Suppose also, that some intermediate zone(s), great(^n-1)-grandchild, > parent of the great(^n)-grandchild zone, is *not* served by this > nameserver,. but is delegated elsewhere. That "other" server then > delegates back to "this" server, for the great(^n)-grandchild zone. > > An iterative resolver, directed to this (TLD) server by the root > server(s), when querying for the great(^n)-grandchild zone, gets back > an answer for the great(^n)-grandchild *directly* (no passing "go"), > including that zone's authority data. > It gets that without ever chaining through the delegations from the > TLD through the great(^n-1)-grandchild zone(s). See for example audns.net.au. I seem to remember the Australian 1LD / 2LD nameserver situation being rather tangly until some time relatively recently, though I can't right now find any documents describing the changes. Tony. -- f.anthony.n.finch http://dotat.at/ Portland, Plymouth, North Biscay: Southerly or southwesterly 4 or 5, occasionally 6 later. Moderate or rough. Occasional rain, drizzle, fog patches. Moderate or poor, occasionally very poor. From fanf2@hermes.cam.ac.uk Thu Feb 24 04:51:20 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 521433A6ADC for ; Thu, 24 Feb 2011 04:51:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.399 X-Spam-Level: X-Spam-Status: No, score=-6.399 tagged_above=-999 required=5 tests=[AWL=0.200, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 93hzhE0THulX for ; Thu, 24 Feb 2011 04:51:18 -0800 (PST) Received: from ppsw-51.csi.cam.ac.uk (ppsw-51.csi.cam.ac.uk [131.111.8.151]) by core3.amsl.com (Postfix) with ESMTP id CA6E83A6ADA for ; Thu, 24 Feb 2011 04:51:17 -0800 (PST) X-Cam-AntiVirus: no malware found X-Cam-SpamDetails: not scanned X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ Received: from hermes-1.csi.cam.ac.uk ([131.111.8.51]:48102) by ppsw-51.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.158]:25) with esmtpa (EXTERNAL:fanf2) id 1Psafs-00021o-Xe (Exim 4.72) (return-path ); Thu, 24 Feb 2011 12:52:04 +0000 Received: from fanf2 (helo=localhost) by hermes-1.csi.cam.ac.uk (hermes.cam.ac.uk) with local-esmtp id 1Psafs-0001rT-DT (Exim 4.67) (return-path ); Thu, 24 Feb 2011 12:52:04 +0000 Date: Thu, 24 Feb 2011 12:52:04 +0000 From: Tony Finch X-X-Sender: fanf2@hermes-1.csi.cam.ac.uk To: Phillip Hallam-Baker In-Reply-To: Message-ID: References: <20110216165921.GW96213@shinkuro.com> <3B90ED2E-980D-4B01-889F-447D66D0B58D@insensate.co.uk> <20110216174011.GZ96213@shinkuro.com> <20110218143653.GC84482@bikeshed.isc.org> <20110218151209.GF66684@shinkuro.com> <4D5EEE09.4080405@dougbarton.us> <20110218222950.GL74065@shinkuro.com> <4D5F270F.20401@abenaki.wabanaki.net> <199C7B2B4228461FB024E59A990DB46D@ics.forth.gr> <4D641DB6.4090705@necom830.hpcl.titech.ac.jp> <20110222205617.GS53815@shinkuro.com> <4D64489B.7020901@necom830.hpcl.titech.ac.jp> <713D992A-1DB9-4F72-9D18-8E923AD51D8D@icsi.berkeley.edu> <4CC95816-8225-4CAE-897F-3F13F965BCEE@ICSI.Berkeley.EDU> User-Agent: Alpine 2.00 (LSU 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: Tony Finch Cc: dnsext@ietf.org Subject: Re: [dnsext] we need help to make names the same, was draft-yao-dnsext-identical-resolution-02 comment X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 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, 24 Feb 2011 12:51:20 -0000 On Thu, 24 Feb 2011, Phillip Hallam-Baker wrote: > > Why would I need a time machine? You still don't have anyone actually using > DNSSEC for production? Speak for yourself. We're using it in cam.ac.uk and so are our friends at ic.ac.uk. Large amounts of cz is signed. > That would be a totally bizarre response to a requirement that is nonsense. Why is data origin authentication of dynamic replies nonsense? Tony. -- f.anthony.n.finch http://dotat.at/ Viking, North Utsire, South Utsire: Southeasterly 7 to severe gale 9, occasionally storm 10 in north Viking at first. Rough or very rough, occasionally high in north Viking. Rain or snow. Moderate or poor. Light icing except Viking. From hallam@gmail.com Thu Feb 24 05:07:49 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E50403A6AFE for ; Thu, 24 Feb 2011 05:07:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.564 X-Spam-Level: X-Spam-Status: No, score=-3.564 tagged_above=-999 required=5 tests=[AWL=0.034, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2fNtPf33IwBU for ; Thu, 24 Feb 2011 05:07:48 -0800 (PST) Received: from mail-bw0-f44.google.com (mail-bw0-f44.google.com [209.85.214.44]) by core3.amsl.com (Postfix) with ESMTP id 3358E3A6AF9 for ; Thu, 24 Feb 2011 05:07:48 -0800 (PST) Received: by bwz13 with SMTP id 13so1206136bwz.31 for ; Thu, 24 Feb 2011 05:08:37 -0800 (PST) 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=zZ3kVXS5z+7Dv6Y0/U+hJLM0tw8+iyYwJU477V9U8oQ=; b=AJp4cOzD4Qo8yTETFTKkI5L1u1lIfuBYvfeJHT7XzCtrvnUR1HQhHJzkMkj8HFn0mV 6EDtaB373CtT5T+wE5HpcYgaUKGjvRi10aGZKtRxBF8Quc0huF2T52safEkV8/jTfhPP qXq27RXkHUqGgIP9J2sDakss6R3GIs8iCSIKY= 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=hSoMZ3eQ6TPkvxQyHJ/LFfIA/CcHc4PsD8JerMeoXL3o+HuZ6T7C5IO9CdvxITfpO3 CZGd0ZF0Mr8Yo0lgMPnH3MU9tmD67f3Pzl533HzfvJhBXxn96cO3Y4/e7rABnkLXnUFQ Lcz/0RLQpyKoo39DQugfyrfyCHXHKDTKMjqpA= MIME-Version: 1.0 Received: by 10.204.7.213 with SMTP id e21mr733865bke.47.1298552917183; Thu, 24 Feb 2011 05:08:37 -0800 (PST) Received: by 10.204.14.139 with HTTP; Thu, 24 Feb 2011 05:08:37 -0800 (PST) In-Reply-To: References: <20110216165921.GW96213@shinkuro.com> <3B90ED2E-980D-4B01-889F-447D66D0B58D@insensate.co.uk> <20110216174011.GZ96213@shinkuro.com> <20110218143653.GC84482@bikeshed.isc.org> <20110218151209.GF66684@shinkuro.com> <4D5EEE09.4080405@dougbarton.us> <20110218222950.GL74065@shinkuro.com> <4D5F270F.20401@abenaki.wabanaki.net> <199C7B2B4228461FB024E59A990DB46D@ics.forth.gr> <4D641DB6.4090705@necom830.hpcl.titech.ac.jp> <20110222205617.GS53815@shinkuro.com> <4D64489B.7020901@necom830.hpcl.titech.ac.jp> <713D992A-1DB9-4F72-9D18-8E923AD51D8D@icsi.berkeley.edu> Date: Thu, 24 Feb 2011 08:08:37 -0500 Message-ID: From: Phillip Hallam-Baker To: Donald Eastlake Content-Type: multipart/alternative; boundary=00151750e55259ce83049d06e909 Cc: dnsext@ietf.org Subject: Re: [dnsext] we need help to make names the same, was draft-yao-dnsext-identical-resolution-02 comment X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 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, 24 Feb 2011 13:07:50 -0000 --00151750e55259ce83049d06e909 Content-Type: text/plain; charset=ISO-8859-1 On Wed, Feb 23, 2011 at 5:25 PM, Donald Eastlake wrote: > Hi, > > On Wed, Feb 23, 2011 at 12:00 PM, Phillip Hallam-Baker > wrote: > > > > > > On Wed, Feb 23, 2011 at 5:30 AM, Tony Finch wrote: > >> > >> On Tue, 22 Feb 2011, Phillip Hallam-Baker wrote: > >> > >> > If you are going to do [online signing], you might as well do a key > >> > exchange inline as well as we do in TLS. One key exchange can then be > >> > leveraged across multiple connections using kerberos style tickets > (see > >> > DPLS for an example). > >> > >> That gives you channel security whereas DNSSEC gives you data origin > >> authentication. They are not the same things. > > > > True, but data origin authentication is probably the wrong model for a > DNS > > security scheme. > > Why? Is your goal to make it easy for some entity not the authority > for a zone to forge data in that zone? Data origin authentication is very expensive. If the use cases only require channel authentication, that is going to be more practical. > > If we are going to consider changing the model of DNSSEC, which is what > > moving to online signatures would entail, then the whole architecture is > > back on the table. > > Total nonsense. The on or off line signing question is pretty minor > and completely orthogonal to the channel versus origin authentication > question. As soon as you have a zone with dynamic update, your are > shoved in the direction of on-line signing, it doesn't take mixed case > non-ascii. The original poster was being imprecise. DNSSEC already has an 'online' signature model in that the only practical way to sign a zone is to have the signing keys connected to the Internet. What is being proposed here is really an inline signature scheme in which the signatures are generated within the DNS request-response loop. It would require every DNS server to have signature capability, not just the zone master. It would require the signatures to be generated on demand in response to attacker generated queries. It would be a total change of the security model. I think that it would be unwise to make such a change to the DNS infrastructure in order to support a requirement that is probably nonsense. -- Website: http://hallambaker.com/ --00151750e55259ce83049d06e909 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Wed, Feb 23, 2011 at 5:25 PM, Donald = Eastlake <d3e3e3@g= mail.com> wrote:
Hi,

On Wed, Feb 23, 2011 at 12:00 PM, Phillip Hallam-Baker <hallam@gmail.com> wrote:
>
>
> On Wed, Feb 23, 2011 at 5:30 AM, Tony Finch <dot@dotat.at> wrote:
>>
>> On Tue, 22 Feb 2011, Phillip Hallam-Baker wrote:
>>
>> > If you are going to do [online signing], you might as well do= a key
>> > exchange inline as well as we do in TLS. One key exchange can= then be
>> > leveraged across multiple connections using kerberos style ti= ckets (see
>> > DPLS for an example).
>>
>> That gives you channel security whereas DNSSEC gives you data orig= in
>> authentication. They are not the same things.
>
> True, but data origin authentication is probably the wrong model for a= DNS
> security scheme.

Why? Is your goal to make it easy for some entity not the authority for a zone to forge data in that zone?

Data= origin authentication is very expensive. If the use cases only require cha= nnel authentication, that is going to be more practical.

=A0
> If we are going to consider changing the model of DNSSEC, which is wha= t
> moving to online signatures would entail, then the whole architecture = is
> back on the table.

Total nonsense. The on or off line signing question is pretty minor and completely orthogonal to the channel versus origin authentication
question. As soon as you have a zone with dynamic update, your are
shoved in the direction of on-line signing, it doesn't take mixed case<= br> non-ascii.

The original poster was being im= precise. DNSSEC already has an 'online' signature model in that the= only practical way to sign a zone is to have the signing keys connected to= the Internet.=A0

What is being proposed here is really an inline signatu= re scheme in which the signatures are generated within the DNS request-resp= onse loop. It would require every DNS server to have signature capability, = not just the zone master. It would require the signatures to be generated o= n demand in response to attacker generated queries.

It would be a total change of the security model.
=


I think that it would be unwise to make = such a change to the DNS infrastructure in order to support a requirement t= hat is probably nonsense.


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

--00151750e55259ce83049d06e909-- From hallam@gmail.com Thu Feb 24 05:17:26 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BD1473A6806 for ; Thu, 24 Feb 2011 05:17:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.565 X-Spam-Level: X-Spam-Status: No, score=-3.565 tagged_above=-999 required=5 tests=[AWL=0.033, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l7XExX9A7Eep for ; Thu, 24 Feb 2011 05:17:25 -0800 (PST) Received: from mail-bw0-f44.google.com (mail-bw0-f44.google.com [209.85.214.44]) by core3.amsl.com (Postfix) with ESMTP id 4792C3A6ADE for ; Thu, 24 Feb 2011 05:17:25 -0800 (PST) Received: by bwz13 with SMTP id 13so1215597bwz.31 for ; Thu, 24 Feb 2011 05:18:14 -0800 (PST) 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=OIs26NreKAJfdYW9wacDCmHFXVuJjC4OKbtSaD+CVT4=; b=Ex2Uy98FmSTaqyCPByknPvXN+UAIv399Ne06C+jBfpl0PL4ur4llcjM1pbW94MR2De GYFbiNEDR6BCtb+A6RgaRN2wnhmhoeL9yHavaCZ0ls5x/Fl77HkkDTYwe3EHGl0IQLF5 pz8ugNPTpE5eV5ASaBwjS6vhOCYdBuODuP3uo= 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=Uqrk/RvLWgRmBfRcgSiZR1ru96VDQIPNHszsrymddXXEoDe28oAGQly7Poprr6wgSO KsATguWA9YqZzLbnDLJAzelultzZZZ9O6AXWfJbUTAdqeLhfOZUbKdCvlMigGFO7eMDY z7Rocmf4vqipYeadPxjS/BXrs3drJ5l35exmU= MIME-Version: 1.0 Received: by 10.204.72.194 with SMTP id n2mr733727bkj.128.1298553469867; Thu, 24 Feb 2011 05:17:49 -0800 (PST) Received: by 10.204.14.139 with HTTP; Thu, 24 Feb 2011 05:17:49 -0800 (PST) In-Reply-To: References: <20110216165921.GW96213@shinkuro.com> <3B90ED2E-980D-4B01-889F-447D66D0B58D@insensate.co.uk> <20110216174011.GZ96213@shinkuro.com> <20110218143653.GC84482@bikeshed.isc.org> <20110218151209.GF66684@shinkuro.com> <4D5EEE09.4080405@dougbarton.us> <20110218222950.GL74065@shinkuro.com> <4D5F270F.20401@abenaki.wabanaki.net> <199C7B2B4228461FB024E59A990DB46D@ics.forth.gr> <4D641DB6.4090705@necom830.hpcl.titech.ac.jp> <20110222205617.GS53815@shinkuro.com> <4D64489B.7020901@necom830.hpcl.titech.ac.jp> <713D992A-1DB9-4F72-9D18-8E923AD51D8D@icsi.berkeley.edu> <4CC95816-8225-4CAE-897F-3F13F965BCEE@ICSI.Berkeley.EDU> Date: Thu, 24 Feb 2011 08:17:49 -0500 Message-ID: From: Phillip Hallam-Baker To: Tony Finch Content-Type: multipart/alternative; boundary=001636d34b9f4b17d1049d070a55 Cc: dnsext@ietf.org Subject: Re: [dnsext] we need help to make names the same, was draft-yao-dnsext-identical-resolution-02 comment X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 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, 24 Feb 2011 13:17:26 -0000 --001636d34b9f4b17d1049d070a55 Content-Type: text/plain; charset=ISO-8859-1 On Thu, Feb 24, 2011 at 7:52 AM, Tony Finch wrote: > On Thu, 24 Feb 2011, Phillip Hallam-Baker wrote: > > > > Why would I need a time machine? You still don't have anyone actually > using > > DNSSEC for production? > > Speak for yourself. We're using it in cam.ac.uk and so are our friends at > ic.ac.uk. Large amounts of cz is signed. Generating signatures is one thing. You don't have a deployment until you have people verifying the signatures and the results affect their behavior. > > That would be a totally bizarre response to a requirement that is > nonsense. > > Why is data origin authentication of dynamic replies nonsense? I was referring to the original requirement driving this proposal, making 'names resolve the same'. -- Website: http://hallambaker.com/ --001636d34b9f4b17d1049d070a55 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Thu, Feb 24, 2011 at 7:52 AM, Tony Fi= nch <dot@dotat.at&= gt; wrote:
On Thu, 24 Feb 2011, Phillip Hallam-Baker wrote:
>
> Why would I need a time machine? You still don't have anyone actua= lly using
> DNSSEC for production?

Speak for yourself. We're using it in cam.ac.uk and so are our friends at
ic.ac.uk. Large amounts o= f cz is signed.

Generating signatures is on= e thing.

You don't have a deployment until you= have people verifying the signatures and the results affect their behavior= .

=A0
> That would be a totally bizarre response to a requirement that is nons= ense.

Why is data origin authentication of dynamic replies nonsense?

I was referring to the original requirement drivi= ng this proposal, making 'names resolve the same'.


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

--001636d34b9f4b17d1049d070a55-- From fanf2@hermes.cam.ac.uk Thu Feb 24 05:31:48 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C63B63A6B13 for ; Thu, 24 Feb 2011 05:31:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.417 X-Spam-Level: X-Spam-Status: No, score=-6.417 tagged_above=-999 required=5 tests=[AWL=0.182, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rFGDRreov9La for ; Thu, 24 Feb 2011 05:31:46 -0800 (PST) Received: from ppsw-52.csi.cam.ac.uk (ppsw-52.csi.cam.ac.uk [131.111.8.152]) by core3.amsl.com (Postfix) with ESMTP id A89113A6B2E for ; Thu, 24 Feb 2011 05:31:44 -0800 (PST) X-Cam-AntiVirus: no malware found X-Cam-SpamDetails: not scanned X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ Received: from hermes-1.csi.cam.ac.uk ([131.111.8.51]:40657) by ppsw-52.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.159]:25) with esmtpa (EXTERNAL:fanf2) id 1PsbJ1-0004i6-Fk (Exim 4.72) (return-path ); Thu, 24 Feb 2011 13:32:31 +0000 Received: from fanf2 (helo=localhost) by hermes-1.csi.cam.ac.uk (hermes.cam.ac.uk) with local-esmtp id 1PsbJ1-0000bF-S0 (Exim 4.67) (return-path ); Thu, 24 Feb 2011 13:32:31 +0000 Date: Thu, 24 Feb 2011 13:32:31 +0000 From: Tony Finch X-X-Sender: fanf2@hermes-1.csi.cam.ac.uk To: Phillip Hallam-Baker In-Reply-To: Message-ID: References: <20110216165921.GW96213@shinkuro.com> <20110218143653.GC84482@bikeshed.isc.org> <20110218151209.GF66684@shinkuro.com> <4D5EEE09.4080405@dougbarton.us> <20110218222950.GL74065@shinkuro.com> <4D5F270F.20401@abenaki.wabanaki.net> <199C7B2B4228461FB024E59A990DB46D@ics.forth.gr> <4D641DB6.4090705@necom830.hpcl.titech.ac.jp> <20110222205617.GS53815@shinkuro.com> <4D64489B.7020901@necom830.hpcl.titech.ac.jp> <713D992A-1DB9-4F72-9D18-8E923AD51D8D@icsi.berkeley.edu> <4CC95816-8225-4CAE-897F-3F13F965BCEE@ICSI.Berkeley.EDU> User-Agent: Alpine 2.00 (LSU 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: Tony Finch Cc: dnsext@ietf.org Subject: Re: [dnsext] we need help to make names the same, was draft-yao-dnsext-identical-resolution-02 comment X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 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, 24 Feb 2011 13:31:49 -0000 On Thu, 24 Feb 2011, Phillip Hallam-Baker wrote: > > You don't have a deployment until you have people verifying the signatures > and the results affect their behavior. Like our central DNS resolvers and my mail relays' resolvers? The .gov DNSSEC mandate is broken in the way you describe. I have no idea if they plan to fix it. Tony. -- f.anthony.n.finch http://dotat.at/ Trafalgar: Variable 3 or 4. Moderate or rough. Fair. Moderate or good. From nweaver@ICSI.Berkeley.EDU Thu Feb 24 05:36:16 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2F8C03A6B20 for ; Thu, 24 Feb 2011 05:36:16 -0800 (PST) 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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uhZFKVSDGRDw for ; Thu, 24 Feb 2011 05:36:15 -0800 (PST) Received: from taffy.ICSI.Berkeley.EDU (taffy.ICSI.Berkeley.EDU [192.150.187.26]) by core3.amsl.com (Postfix) with ESMTP id 31F723A6B1C for ; Thu, 24 Feb 2011 05:36:15 -0800 (PST) Received: from albook.hsd1.ca.comcast.net (c-67-164-126-174.hsd1.ca.comcast.net [67.164.126.174]) (Authenticated sender: nweaver) by taffy.ICSI.Berkeley.EDU (Postfix) with ESMTP id 0064436A58B; Thu, 24 Feb 2011 05:37:01 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Nicholas Weaver In-Reply-To: Date: Thu, 24 Feb 2011 05:37:02 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <8657EF4A-A08D-46E5-8917-553AE377CAD8@ICSI.Berkeley.EDU> References: <20110216165921.GW96213@shinkuro.com> <3B90ED2E-980D-4B01-889F-447D66D0B58D@insensate.co.uk> <20110216174011.GZ96213@shinkuro.com> <20110218143653.GC84482@bikeshed.isc.org> <20110218151209.GF66684@shinkuro.com> <4D5EEE09.4080405@dougbarton.us> <20110218222950.GL74065@shinkuro.com> <4D5F270F.20401@abenaki.wabanaki.net> <199C7B2B4228461FB024E59A990DB46D@ics.forth.gr> <4D641DB6.4090705@necom830.hpcl.titech.ac.jp> <20110222205617.GS53815@shinkuro.com> <4D64489B.7020901@necom830.hpcl.titech.ac.jp> <713D992A-1DB9-4F72-9D18-8E923AD51D8D@icsi.berkeley.edu> <4CC95816-8225-4CAE-897F-3F13F965BCEE@ICSI.Berkeley.EDU> To: Phillip Hallam-Baker X-Mailer: Apple Mail (2.1082) Cc: Nicholas Weaver , dnsext@ietf.org Subject: Re: [dnsext] we need help to make names the same, was draft-yao-dnsext-identical-resolution-02 comment X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 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, 24 Feb 2011 13:36:16 -0000 On Feb 24, 2011, at 5:17 AM, Phillip Hallam-Baker wrote: >=20 >=20 > On Thu, Feb 24, 2011 at 7:52 AM, Tony Finch wrote: > On Thu, 24 Feb 2011, Phillip Hallam-Baker wrote: > > > > Why would I need a time machine? You still don't have anyone = actually using > > DNSSEC for production? >=20 > Speak for yourself. We're using it in cam.ac.uk and so are our friends = at > ic.ac.uk. Large amounts of cz is signed. >=20 > Generating signatures is one thing. >=20 > You don't have a deployment until you have people verifying the = signatures and the results affect their behavior. All Comcast customers who've opted out of the NXDOMAIN wildcarding are = behind resolvers that validate DNSSEC. nweaver% dig www.dnssec-failed.org ; <<>> DiG 9.6.0-APPLE-P2 <<>> www.dnssec-failed.org ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 36205 ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0 ;; QUESTION SECTION: ;www.dnssec-failed.org. IN A ;; Query time: 47 msec ;; SERVER: 192.168.1.1#53(192.168.1.1) ;; WHEN: Thu Feb 24 05:35:42 2011 ;; MSG SIZE rcvd: 39 nweaver% dig +cd www.dnssec-failed.org ; <<>> DiG 9.6.0-APPLE-P2 <<>> +cd www.dnssec-failed.org ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 1844 ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0 ;; QUESTION SECTION: ;www.dnssec-failed.org. IN A ;; ANSWER SECTION: www.dnssec-failed.org. 7200 IN A 68.87.64.48 ;; Query time: 15 msec ;; SERVER: 192.168.1.1#53(192.168.1.1) ;; WHEN: Thu Feb 24 05:35:48 2011 ;; MSG SIZE rcvd: 55 From hallam@gmail.com Thu Feb 24 05:44:09 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A39033A6B23 for ; Thu, 24 Feb 2011 05:44:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.566 X-Spam-Level: X-Spam-Status: No, score=-3.566 tagged_above=-999 required=5 tests=[AWL=0.032, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tz0vo5en5ZfM for ; Thu, 24 Feb 2011 05:44:08 -0800 (PST) Received: from mail-bw0-f44.google.com (mail-bw0-f44.google.com [209.85.214.44]) by core3.amsl.com (Postfix) with ESMTP id D13023A6806 for ; Thu, 24 Feb 2011 05:44:07 -0800 (PST) Received: by bwz13 with SMTP id 13so1240630bwz.31 for ; Thu, 24 Feb 2011 05:44:56 -0800 (PST) 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=n7YJY4TBvoYVv+pf11t3adwD8/KReq3ni3AzZgj5Ni8=; b=LZ0c2o0CTATsRfW+eZdDEvpVyKwcCeB6tqgkA/IWF8qHiFO778TUU0L5n1c9fqF9nR EzX0KcmgTxMtghc+WiReioTbxBaK7aZy2L9twOkxvZIZMdXdptlaTUbh8k3K6z88omLj 3x4dU2uINTRfK66yqDyIFq4A+l5GlINH0nwro= 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=rLo87T6L27CpjcPIf1hhKysq6HDNdPVVVeTq1atGTVN6Wjd7Peod6GkO5uDc5HqCT5 aFCpt2F4Sx7eeKDE8bSCWKSpwvWC/ZV95H0AXbaRAdz89kQywfdmantpWfkh8FQr3/eJ iGTW9QfLXFsKuBwKpURCY/zJMT68sKTtquAPI= MIME-Version: 1.0 Received: by 10.204.7.213 with SMTP id e21mr778755bke.47.1298555094667; Thu, 24 Feb 2011 05:44:54 -0800 (PST) Received: by 10.204.14.139 with HTTP; Thu, 24 Feb 2011 05:44:54 -0800 (PST) In-Reply-To: <8657EF4A-A08D-46E5-8917-553AE377CAD8@ICSI.Berkeley.EDU> References: <20110216165921.GW96213@shinkuro.com> <3B90ED2E-980D-4B01-889F-447D66D0B58D@insensate.co.uk> <20110216174011.GZ96213@shinkuro.com> <20110218143653.GC84482@bikeshed.isc.org> <20110218151209.GF66684@shinkuro.com> <4D5EEE09.4080405@dougbarton.us> <20110218222950.GL74065@shinkuro.com> <4D5F270F.20401@abenaki.wabanaki.net> <199C7B2B4228461FB024E59A990DB46D@ics.forth.gr> <4D641DB6.4090705@necom830.hpcl.titech.ac.jp> <20110222205617.GS53815@shinkuro.com> <4D64489B.7020901@necom830.hpcl.titech.ac.jp> <713D992A-1DB9-4F72-9D18-8E923AD51D8D@icsi.berkeley.edu> <4CC95816-8225-4CAE-897F-3F13F965BCEE@ICSI.Berkeley.EDU> <8657EF4A-A08D-46E5-8917-553AE377CAD8@ICSI.Berkeley.EDU> Date: Thu, 24 Feb 2011 08:44:54 -0500 Message-ID: From: Phillip Hallam-Baker To: Nicholas Weaver Content-Type: multipart/alternative; boundary=00151750e5522393b2049d076b22 Cc: dnsext@ietf.org Subject: Re: [dnsext] we need help to make names the same, was draft-yao-dnsext-identical-resolution-02 comment X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 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, 24 Feb 2011 13:44:09 -0000 --00151750e5522393b2049d076b22 Content-Type: text/plain; charset=ISO-8859-1 So you are saying that it is TOO LATE to make a change that would have major impact on the practice of domain management? It really has to be one or the other. Either it is too late to make major change or its all on the table. Or alternatively, the proposed use case may not justify a major change. On Thu, Feb 24, 2011 at 8:37 AM, Nicholas Weaver wrote: > > On Feb 24, 2011, at 5:17 AM, Phillip Hallam-Baker wrote: > > > > > > > On Thu, Feb 24, 2011 at 7:52 AM, Tony Finch wrote: > > On Thu, 24 Feb 2011, Phillip Hallam-Baker wrote: > > > > > > Why would I need a time machine? You still don't have anyone actually > using > > > DNSSEC for production? > > > > Speak for yourself. We're using it in cam.ac.uk and so are our friends > at > > ic.ac.uk. Large amounts of cz is signed. > > > > Generating signatures is one thing. > > > > You don't have a deployment until you have people verifying the > signatures and the results affect their behavior. > > All Comcast customers who've opted out of the NXDOMAIN wildcarding are > behind resolvers that validate DNSSEC. > > > nweaver% dig www.dnssec-failed.org > > ; <<>> DiG 9.6.0-APPLE-P2 <<>> www.dnssec-failed.org > ;; global options: +cmd > ;; Got answer: > ;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 36205 > ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0 > > ;; QUESTION SECTION: > ;www.dnssec-failed.org. IN A > > ;; Query time: 47 msec > ;; SERVER: 192.168.1.1#53(192.168.1.1) > ;; WHEN: Thu Feb 24 05:35:42 2011 > ;; MSG SIZE rcvd: 39 > > > nweaver% dig +cd www.dnssec-failed.org > > ; <<>> DiG 9.6.0-APPLE-P2 <<>> +cd www.dnssec-failed.org > ;; global options: +cmd > ;; Got answer: > ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 1844 > ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0 > > ;; QUESTION SECTION: > ;www.dnssec-failed.org. IN A > > ;; ANSWER SECTION: > www.dnssec-failed.org. 7200 IN A 68.87.64.48 > > ;; Query time: 15 msec > ;; SERVER: 192.168.1.1#53(192.168.1.1) > ;; WHEN: Thu Feb 24 05:35:48 2011 > ;; MSG SIZE rcvd: 55 > > -- Website: http://hallambaker.com/ --00151750e5522393b2049d076b22 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable So you are saying that it is TOO LATE to make a change th= at would have major impact on the practice of domain management?

It really has to be one or the other. Either it is too late = to make major change or its all on the table.=A0

<= br>
Or alternatively, the proposed use case may not justify a maj= or change.


On Thu, Feb 24, 2011 a= t 8:37 AM, Nicholas Weaver <nweaver@icsi.berkeley.edu> wrote:

On Feb 24, 2011, at 5:17 AM, Phillip Hallam-Baker wrote:

>
>
> On Thu, Feb 24, 2011 at 7:52 AM, Tony Finch <dot@dotat.at> wrote:
> On Thu, 24 Feb 2011, Phillip Hallam-Baker wrote:
> >
> > Why would I need a time machine? You still don't have anyone = actually using
> > DNSSEC for production?
>
> Speak for yourself. We're using it in cam.ac.uk and so are our friends at
> ic.ac.uk. Large amou= nts of cz is signed.
>
> Generating signatures is one thing.
>
> You don't have a deployment until you have people verifying the si= gnatures and the results affect their behavior.

All Comcast customers who've opted out of the NXDOMAIN wildcardin= g are behind resolvers that validate DNSSEC.


nweaver% dig www= .dnssec-failed.org

; <<>> DiG 9.6.0-APPLE-P2 <<>> www.dnssec-failed.org
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 36205
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;www.dnssec-fail= ed.org. =A0 =A0 =A0 =A0 IN =A0 =A0 =A0A

;; Query time: 47 msec
;; SERVER: 192.168.1.1#53(192.168.1.1)
;; WHEN: Thu Feb 24 05:35:42 2011
;; MSG SIZE =A0rcvd: 39


nweaver% dig +cd www.dnssec-failed.org

; <<>> DiG 9.6.0-APPLE-P2 <<>> +cd www.dnssec-failed.org
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 1844
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;www.dnssec-fail= ed.org. =A0 =A0 =A0 =A0 IN =A0 =A0 =A0A

;; ANSWER SECTION:
www.dnssec-faile= d.org. =A07200 =A0 =A0IN =A0 =A0 =A0A =A0 =A0 =A0 68.87.64.48

;; Query time: 15 msec
;; SERVER: 192.168.1.1#53(192.168.1.1)
;; WHEN: Thu Feb 24 05:35:48 2011
;; MSG SIZE =A0rcvd: 55




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

--00151750e5522393b2049d076b22-- From nweaver@ICSI.Berkeley.EDU Thu Feb 24 05:51:58 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 31BA33A6B26 for ; Thu, 24 Feb 2011 05:51:58 -0800 (PST) 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=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qzBBGqfTMFIS for ; Thu, 24 Feb 2011 05:51:56 -0800 (PST) Received: from taffy.ICSI.Berkeley.EDU (taffy.ICSI.Berkeley.EDU [192.150.187.26]) by core3.amsl.com (Postfix) with ESMTP id DAA1E3A6B1F for ; Thu, 24 Feb 2011 05:51:56 -0800 (PST) Received: from albook.hsd1.ca.comcast.net (c-67-164-126-174.hsd1.ca.comcast.net [67.164.126.174]) (Authenticated sender: nweaver) by taffy.ICSI.Berkeley.EDU (Postfix) with ESMTP id AD4FA36A58B; Thu, 24 Feb 2011 05:52:45 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Nicholas Weaver In-Reply-To: Date: Thu, 24 Feb 2011 05:52:46 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <39EBBA76-22F1-4935-9300-B0078B229793@ICSI.Berkeley.EDU> References: <20110216165921.GW96213@shinkuro.com> <3B90ED2E-980D-4B01-889F-447D66D0B58D@insensate.co.uk> <20110216174011.GZ96213@shinkuro.com> <20110218143653.GC84482@bikeshed.isc.org> <20110218151209.GF66684@shinkuro.com> <4D5EEE09.4080405@dougbarton.us> <20110218222950.GL74065@shinkuro.com> <4D5F270F.20401@abenaki.wabanaki.net> <199C7B2B4228461FB024E59A990DB46D@ics.forth.gr> <4D641DB6.4090705@necom830.hpcl.titech.ac.jp> <20110222205617.GS53815@shinkuro.com> <4D64489B.7020901@necom830.hpcl.titech.ac.jp> <713D992A-1DB9-4F72-9D18-8E923AD51D8D@icsi.berkeley.edu> <4CC95816-8225-4CAE-897F-3F13F965BCEE@ICSI.Berkeley.EDU> <8657EF4A-A08D-46E5-8917-553AE377CAD8@ICSI.Berkeley.EDU> To: Phillip Hallam-Baker X-Mailer: Apple Mail (2.1082) Cc: Nicholas Weaver , dnsext@ietf.org Subject: Re: [dnsext] we need help to make names the same, was draft-yao-dnsext-identical-resolution-02 comment X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 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, 24 Feb 2011 13:51:58 -0000 On Feb 24, 2011, at 5:44 AM, Phillip Hallam-Baker wrote: > So you are saying that it is TOO LATE to make a change that would have = major impact on the practice of domain management? I'm stating that your "nobody validates DNSSEC" claim is demonstrably = false. > It really has to be one or the other. Either it is too late to make = major change or its all on the table.=20 >=20 > Or alternatively, the proposed use case may not justify a major = change. OR the notion of online signature generation is not a change at all, but = is something already supported in the protocol [1] and supported by at = least two implementations. [1] Where does the protocol require that signature generation is = off-line? =20 The key feature for data integrity is that the validating party is NOT = necessarily the party contacting the authority.= From ebw@abenaki.wabanaki.net Thu Feb 24 06:33:21 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 96BF33A69FC for ; Thu, 24 Feb 2011 06:33:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.322 X-Spam-Level: X-Spam-Status: No, score=-2.322 tagged_above=-999 required=5 tests=[AWL=0.277, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3ODSL6a+lX8o for ; Thu, 24 Feb 2011 06:33:20 -0800 (PST) Received: from abenaki.wabanaki.net (abenaki.wabanaki.net [65.99.1.133]) by core3.amsl.com (Postfix) with ESMTP id A95E43A69FA for ; Thu, 24 Feb 2011 06:33:20 -0800 (PST) Received: from limpet.local (cpe-67-255-5-237.twcny.res.rr.com [67.255.5.237]) by abenaki.wabanaki.net (8.14.4/8.14.4) with ESMTP id p1OClTx2058584 for ; Thu, 24 Feb 2011 07:47:30 -0500 (EST) (envelope-from ebw@abenaki.wabanaki.net) Message-ID: <4D666C5A.9060700@abenaki.wabanaki.net> Date: Thu, 24 Feb 2011 09:34:02 -0500 From: Eric Brunner-Williams Organization: wampumpeag User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: dnsext@ietf.org References: <20110216165921.GW96213@shinkuro.com> <20110218222950.GL74065@shinkuro.com> <4D5F270F.20401@abenaki.wabanaki.net> <199C7B2B4228461FB024E59A990DB46D@ics.forth.gr> <4D641DB6.4090705@necom830.hpcl.titech.ac.jp> <20110222205617.GS53815@shinkuro.com> <4D64489B.7020901@necom830.hpcl.titech.ac.jp> <713D992A-1DB9-4F72-9D18-8E923AD51D8D@icsi.berkeley.edu> <4CC95816-8225-4CAE-897F-3F13F965BCEE@ICSI.Berkeley.EDU> <8657EF4A-A08D-46E5-8917-553AE377CAD8@ICSI.Berkeley.EDU> <39EBBA76-22F1-4935-9300-B0078B229793@ICSI.Berkeley.EDU> In-Reply-To: <39EBBA76-22F1-4935-9300-B0078B229793@ICSI.Berkeley.EDU> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [dnsext] we need help to make names the same, was draft-yao-dnsext-identical-resolution-02 comment X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 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, 24 Feb 2011 14:33:21 -0000 On 2/24/11 8:52 AM, Nicholas Weaver wrote: > > On Feb 24, 2011, at 5:44 AM, Phillip Hallam-Baker wrote: > >> So you are saying that it is TOO LATE to make a change that would have major impact on the practice of domain management? > > I'm stating that your "nobody validates DNSSEC" claim is demonstrably false. have you both agreed what "nobody" means? does it mean zero validation, not even by superman in his fortress of solitude, somewhere in the antarctic, or does it mean that no competition authority is likely to consider a claim based upon current market share data? yogi bera used to say things like "nobody goes there". to interpret that as having no human visitiation, like mars, would be ... creative. -e From anicoll@cert.org Thu Feb 24 06:55:43 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E571F3A6A21 for ; Thu, 24 Feb 2011 06:55:43 -0800 (PST) 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=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nv1M3-ki7kfg for ; Thu, 24 Feb 2011 06:55:42 -0800 (PST) Received: from plainfield.sei.cmu.edu (plainfield.sei.cmu.edu [192.58.107.45]) by core3.amsl.com (Postfix) with ESMTP id 2AE083A6B3C for ; Thu, 24 Feb 2011 06:55:34 -0800 (PST) Received: from pawpaw.sei.cmu.edu (pawpaw.sei.cmu.edu [10.64.21.22]) by plainfield.sei.cmu.edu (8.13.8/8.13.8/1294) with ESMTP id p1OEuEmQ005199; Thu, 24 Feb 2011 09:56:14 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cert.org; s=jthatj15xw2j; t=1298559374; bh=glh9XSTtUEBqC0Rkmy4xNJNFJBORcVB6IWFM98lRXQw=; h=From:To:CC:Date:Subject:Message-ID:References:In-Reply-To: Content-Type:Content-Transfer-Encoding:MIME-Version:Sender: Reply-To; b=V9qvKqgWTQ+5W08O62WV4Z0A9Ii2xrnaSvrk/oonJ06iBiZSYO+rHRIso9/m3EmgZ X8d6UCgPWxO+vxouS1aX5rnMDAP//ZuPoADNuRBdXhog1FWiQD8FOTOwnxh1vnqX/X Rq025hUp5Wfkb606Dl/FF3YaymPxAJHK6RZ/YMpw= Received: from owa.sei.cmu.edu (vader.sei.cmu.edu [10.64.28.14]) by pawpaw.sei.cmu.edu (8.13.8/8.13.8/1348) with ESMTP id p1OEuEgQ022090; Thu, 24 Feb 2011 09:56:14 -0500 Received: from EXCHANGE.sei.cmu.edu ([10.64.28.13]) by vader.sei.cmu.edu ([10.64.28.14]) with mapi; Thu, 24 Feb 2011 09:56:14 -0500 From: Alex Nicoll To: Tony Finch , Phillip Hallam-Baker Date: Thu, 24 Feb 2011 09:56:12 -0500 Thread-Topic: [dnsext] we need help to make names the same, was draft-yao-dnsext-identical-resolution-02 comment Thread-Index: AcvUJ1BPAd9Q8Q5cR7mL1b82iETCnQAC0QZA Message-ID: References: <20110216165921.GW96213@shinkuro.com> <20110218143653.GC84482@bikeshed.isc.org> <20110218151209.GF66684@shinkuro.com> <4D5EEE09.4080405@dougbarton.us> <20110218222950.GL74065@shinkuro.com> <4D5F270F.20401@abenaki.wabanaki.net> <199C7B2B4228461FB024E59A990DB46D@ics.forth.gr> <4D641DB6.4090705@necom830.hpcl.titech.ac.jp> <20110222205617.GS53815@shinkuro.com> <4D64489B.7020901@necom830.hpcl.titech.ac.jp> <713D992A-1DB9-4F72-9D18-8E923AD51D8D@icsi.berkeley.edu> <4CC95816-8225-4CAE-897F-3F13F965BCEE@ICSI.Berkeley.EDU> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "dnsext@ietf.org" Subject: Re: [dnsext] we need help to make names the same, was draft-yao-dnsext-identical-resolution-02 comment X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 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, 24 Feb 2011 14:55:44 -0000 -----Original Message----- From: dnsext-bounces@ietf.org [mailto:dnsext-bounces@ietf.org] On Behalf Of= Tony Finch Sent: Thursday, February 24, 2011 8:33 AM To: Phillip Hallam-Baker Cc: dnsext@ietf.org Subject: Re: [dnsext] we need help to make names the same, was draft-yao-dn= sext-identical-resolution-02 comment [Alex Nicoll] >The .gov DNSSEC mandate is broken in the way you describe. I= have no idea if they plan to fix it. Completely unofficial answer to Tony's statement: Yes, several different folks are working on it. As with all things .gov, t= here's a political and technical angle, and both are being worked. -Alex From fanf2@hermes.cam.ac.uk Thu Feb 24 07:05:26 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0A1BA3A6B36 for ; Thu, 24 Feb 2011 07:05:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.432 X-Spam-Level: X-Spam-Status: No, score=-6.432 tagged_above=-999 required=5 tests=[AWL=0.167, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j1bEEgodvJ6w for ; Thu, 24 Feb 2011 07:05:25 -0800 (PST) Received: from ppsw-52.csi.cam.ac.uk (ppsw-52.csi.cam.ac.uk [131.111.8.152]) by core3.amsl.com (Postfix) with ESMTP id F17193A6A1C for ; Thu, 24 Feb 2011 07:05:24 -0800 (PST) X-Cam-AntiVirus: no malware found X-Cam-SpamDetails: not scanned X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ Received: from hermes-1.csi.cam.ac.uk ([131.111.8.51]:48279) by ppsw-52.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.159]:25) with esmtpa (EXTERNAL:fanf2) id 1Pscli-00036H-D8 (Exim 4.72) (return-path ); Thu, 24 Feb 2011 15:06:14 +0000 Received: from fanf2 (helo=localhost) by hermes-1.csi.cam.ac.uk (hermes.cam.ac.uk) with local-esmtp id 1Pscli-0001DY-1r (Exim 4.67) (return-path ); Thu, 24 Feb 2011 15:06:14 +0000 Date: Thu, 24 Feb 2011 15:06:14 +0000 From: Tony Finch X-X-Sender: fanf2@hermes-1.csi.cam.ac.uk To: Alex Nicoll In-Reply-To: Message-ID: References: <20110216165921.GW96213@shinkuro.com> <4D5F270F.20401@abenaki.wabanaki.net> <199C7B2B4228461FB024E59A990DB46D@ics.forth.gr> <4D641DB6.4090705@necom830.hpcl.titech.ac.jp> <20110222205617.GS53815@shinkuro.com> <4D64489B.7020901@necom830.hpcl.titech.ac.jp> <713D992A-1DB9-4F72-9D18-8E923AD51D8D@icsi.berkeley.edu> <4CC95816-8225-4CAE-897F-3F13F965BCEE@ICSI.Berkeley.EDU> User-Agent: Alpine 2.00 (LSU 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: Tony Finch Cc: "dnsext@ietf.org" Subject: Re: [dnsext] we need help to make names the same, was draft-yao-dnsext-identical-resolution-02 comment X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 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, 24 Feb 2011 15:05:26 -0000 On Thu, 24 Feb 2011, Alex Nicoll wrote: > > Yes, several different folks are working on [.gov DNSSEC validation]. Good news :-) > As with all things .gov, there's a political and technical angle, and > both are being worked. Good luck! Tony. -- f.anthony.n.finch http://dotat.at/ South Biscay, Southeast FitzRoy: Variable 4. Moderate or rough. Fair. Moderate or good, occasionally poor. From nweaver@ICSI.Berkeley.EDU Thu Feb 24 08:59:48 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A12193A677E for ; Thu, 24 Feb 2011 08:59:48 -0800 (PST) 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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L4hK3AeBxbNG for ; Thu, 24 Feb 2011 08:59:47 -0800 (PST) Received: from taffy.ICSI.Berkeley.EDU (taffy.ICSI.Berkeley.EDU [192.150.187.26]) by core3.amsl.com (Postfix) with ESMTP id C9D283A65A5 for ; Thu, 24 Feb 2011 08:59:47 -0800 (PST) Received: from gala.icir.org (gala.ICIR.org [192.150.187.49]) (Authenticated sender: nweaver) by taffy.ICSI.Berkeley.EDU (Postfix) with ESMTP id 14BD136A58D; Thu, 24 Feb 2011 09:00:38 -0800 (PST) References: <20110216165921.GW96213@shinkuro.com> <3B90ED2E-980D-4B01-889F-447D66D0B58D@insensate.co.uk> <20110216174011.GZ96213@shinkuro.com> <20110218143653.GC84482@bikeshed.isc.org> <20110218151209.GF66684@shinkuro.com> <4D5EEE09.4080405@dougbarton.us> <20110218222950.GL74065@shinkuro.com> <4D5F270F.20401@abenaki.wabanaki.net> <199C7B2B4228461FB024E59A990DB46D@ics.forth.gr> <4D641DB6.4090705@necom830.hpcl.titech.ac.jp> <20110222205617.GS53815@shinkuro.com> <4D64489B.7020901@necom830.hpcl.titech.ac.jp> <713D992A-1DB9-4F72-9D18-8E923AD51D8D@icsi.berkeley.edu> <4CC95816-8225-4CAE-897F-3F13F965BCEE@ICSI.Berkeley.EDU> <8657EF4A-A08D-46E5-8917-553AE377CAD8@ICSI.Berkeley.EDU> <39EBBA76-22F1-4935-9300-B0078B229793@ICSI.Berkeley.EDU> In-Reply-To: <39EBBA76-22F1-4935-9300-B0078B229793@ICSI.Berkeley.EDU> Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii Message-Id: <5A100E65-FB09-4556-AA5A-BF9FE0468DDA@ICSI.Berkeley.EDU> Content-Transfer-Encoding: quoted-printable From: Nicholas Weaver Date: Thu, 24 Feb 2011 09:00:37 -0800 To: Nicholas Weaver X-Mailer: Apple Mail (2.1082) Cc: dnsext@ietf.org Subject: [dnsext] does making names the same NEED protocol changes at all? X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 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, 24 Feb 2011 16:59:48 -0000 On Feb 24, 2011, at 5:52 AM, Nicholas Weaver wrote: >=20 > On Feb 24, 2011, at 5:44 AM, Phillip Hallam-Baker wrote: >=20 >> So you are saying that it is TOO LATE to make a change that would = have major impact on the practice of domain management? >=20 > I'm stating that your "nobody validates DNSSEC" claim is demonstrably = false. More precisely, there is a large ISP, Comcast, where ALL users who've = opted out of NXDOMAIN wildcarding are behind DNSSEC validating = resolvers. I would call this a significant operational deployment of = DNSSEC validation. However, back to the original topic: why does case insensitivity for = non-ASCII NEED protocol changes? Can't it be done with just authority = changes for only those authorities needing case insensitive non-ASCII = names (rather than a protocol change which needs universal changes to = the resolvers) The authority has a standard mapping for case insensitivity in the = language in question. =20 a: If its the terminal authority for a name, it just runs the mapping = and returns the value (if necessary, generating a DNSSEC signature on = the fly if its an uncached mapping). b: If the authority is not a terminal, and it knows that the authority = directly beneath it for a name support case insensitivity, it just runs = the mapping and returns the appropriate value (if necessary, generating = a DNSSEC signature on the fly if its an uncached mapping). c: If the authority is not a terminal, and it does NOT know that the = authority directly beneath it supports case insensitivity, it runs the = mapping to generate a canonicalized DNAME or CNAME (as appropriate) with = TTL=3D0 and, if necessary, generates the appropriate signature. Cases A and B Just Work (tm). =20 Case C will work as well because you don't have the CNAME + DNAME = problem because the TTL is 0. Case C may reduce caching and also = increase latency, but that is ONLY network load on the authority not = computation load (because the DNSSEC signature is cached), and creates = an incentive for the authority directly beneath to support = case-insensitive names. NO DNS protocol changes are required, everything is provisioning and = authority side changes. By maintaining a cache of signed data, the reality is although it = supports effectively exponential case-recasing, the ones which are = actually used get in the cache. If the cache is well structured and = sticky, a computational DOS won't be able to evict valid entries = (limiting its effect to only new BizArrE caSeS of TyPogRaphy) From hallam@gmail.com Thu Feb 24 09:16:23 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C032E3A67AF for ; Thu, 24 Feb 2011 09:16:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.566 X-Spam-Level: X-Spam-Status: No, score=-3.566 tagged_above=-999 required=5 tests=[AWL=0.032, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 42Iod+XTWPDo for ; Thu, 24 Feb 2011 09:16:22 -0800 (PST) Received: from mail-bw0-f44.google.com (mail-bw0-f44.google.com [209.85.214.44]) by core3.amsl.com (Postfix) with ESMTP id 0B6EC3A677E for ; Thu, 24 Feb 2011 09:16:21 -0800 (PST) Received: by bwz13 with SMTP id 13so1468133bwz.31 for ; Thu, 24 Feb 2011 09:17:11 -0800 (PST) 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=gQhauXZfF3oHWcggRWJfIVLjpcXtiGAMN7n6hrzNW2c=; b=W/G/h2uRe+9KlnwxrtDo3mi2G9ql2fyMbykBb5Gt/ThyaVFnSj4qJySLEnMTJmkC1Q l52PAorLP+olByHsvArbVt+vjVjiACPqv2vU5s0mETFry/prQ/oy2QR9/xy1syixwjr5 ibxs/o3SYQSDIGrXd+qyhenOgojeSfLLSVW/c= 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=O/q8NBtHj8ldqpJ8AIL21knNUEyt31JMawROnoUI2RpXIuBJWuSS6mHRiQFxkUqWSY f/INhe5VklUlCWPkP0UQBJSjIVWd1IXp0F6Fr334g7WvKDFIWfPlO0oSn+Q5I9Sb32jN vG7Ud5fxc+e8GXCNhZR/c/m58R9Sv2ONltv4o= MIME-Version: 1.0 Received: by 10.204.52.136 with SMTP id i8mr1051201bkg.74.1298567830204; Thu, 24 Feb 2011 09:17:10 -0800 (PST) Received: by 10.204.14.139 with HTTP; Thu, 24 Feb 2011 09:17:10 -0800 (PST) In-Reply-To: <5A100E65-FB09-4556-AA5A-BF9FE0468DDA@ICSI.Berkeley.EDU> References: <20110216165921.GW96213@shinkuro.com> <3B90ED2E-980D-4B01-889F-447D66D0B58D@insensate.co.uk> <20110216174011.GZ96213@shinkuro.com> <20110218143653.GC84482@bikeshed.isc.org> <20110218151209.GF66684@shinkuro.com> <4D5EEE09.4080405@dougbarton.us> <20110218222950.GL74065@shinkuro.com> <4D5F270F.20401@abenaki.wabanaki.net> <199C7B2B4228461FB024E59A990DB46D@ics.forth.gr> <4D641DB6.4090705@necom830.hpcl.titech.ac.jp> <20110222205617.GS53815@shinkuro.com> <4D64489B.7020901@necom830.hpcl.titech.ac.jp> <713D992A-1DB9-4F72-9D18-8E923AD51D8D@icsi.berkeley.edu> <4CC95816-8225-4CAE-897F-3F13F965BCEE@ICSI.Berkeley.EDU> <8657EF4A-A08D-46E5-8917-553AE377CAD8@ICSI.Berkeley.EDU> <39EBBA76-22F1-4935-9300-B0078B229793@ICSI.Berkeley.EDU> <5A100E65-FB09-4556-AA5A-BF9FE0468DDA@ICSI.Berkeley.EDU> Date: Thu, 24 Feb 2011 12:17:10 -0500 Message-ID: From: Phillip Hallam-Baker To: Nicholas Weaver Content-Type: multipart/alternative; boundary=001636c5bc0f3c7086049d0a6254 Cc: dnsext@ietf.org Subject: Re: [dnsext] does making names the same NEED protocol changes at all? X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 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, 24 Feb 2011 17:16:23 -0000 --001636c5bc0f3c7086049d0a6254 Content-Type: text/plain; charset=ISO-8859-1 The problem here comes in that the downstream server needs to be prepared to support the scheme. And there can be multiple levels of ambiguity so the cache requirement grows exponentially with each level. I am starting to get a really bad feeling about the resolve the same requirement. Is the objective here really to make things work better or did the authorities that raised this in ICANN have a rather different agenda? On Thu, Feb 24, 2011 at 12:00 PM, Nicholas Weaver wrote: > > On Feb 24, 2011, at 5:52 AM, Nicholas Weaver wrote: > > > > > On Feb 24, 2011, at 5:44 AM, Phillip Hallam-Baker wrote: > > > >> So you are saying that it is TOO LATE to make a change that would have > major impact on the practice of domain management? > > > > I'm stating that your "nobody validates DNSSEC" claim is demonstrably > false. > > More precisely, there is a large ISP, Comcast, where ALL users who've opted > out of NXDOMAIN wildcarding are behind DNSSEC validating resolvers. I would > call this a significant operational deployment of DNSSEC validation. > > > > However, back to the original topic: why does case insensitivity for > non-ASCII NEED protocol changes? Can't it be done with just authority > changes for only those authorities needing case insensitive non-ASCII names > (rather than a protocol change which needs universal changes to the > resolvers) > > > The authority has a standard mapping for case insensitivity in the language > in question. > > a: If its the terminal authority for a name, it just runs the mapping and > returns the value (if necessary, generating a DNSSEC signature on the fly if > its an uncached mapping). > > b: If the authority is not a terminal, and it knows that the authority > directly beneath it for a name support case insensitivity, it just runs the > mapping and returns the appropriate value (if necessary, generating a DNSSEC > signature on the fly if its an uncached mapping). > > c: If the authority is not a terminal, and it does NOT know that the > authority directly beneath it supports case insensitivity, it runs the > mapping to generate a canonicalized DNAME or CNAME (as appropriate) with > TTL=0 and, if necessary, generates the appropriate signature. > > > Cases A and B Just Work (tm). > > Case C will work as well because you don't have the CNAME + DNAME problem > because the TTL is 0. Case C may reduce caching and also increase latency, > but that is ONLY network load on the authority not computation load (because > the DNSSEC signature is cached), and creates an incentive for the authority > directly beneath to support case-insensitive names. > > > NO DNS protocol changes are required, everything is provisioning and > authority side changes. > > > By maintaining a cache of signed data, the reality is although it supports > effectively exponential case-recasing, the ones which are actually used get > in the cache. If the cache is well structured and sticky, a computational > DOS won't be able to evict valid entries (limiting its effect to only new > BizArrE caSeS of TyPogRaphy) > > -- Website: http://hallambaker.com/ --001636c5bc0f3c7086049d0a6254 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable The problem here comes in that the downstream server needs to be prepared t= o support the scheme. And there can be multiple levels of ambiguity so the = cache requirement grows exponentially with each level.

I am sta= rting to get a really bad feeling about the resolve the same requirement. I= s the objective here really to make things work better or did the authoriti= es that raised this in ICANN have a rather different agenda?




On Thu, Feb 24, 2011 at 12:00 PM, Nicholas Weaver &= lt;nweaver@icsi.berkeley.edu> wrote:

On Feb 24, 2011, at 5:52 AM, Nicholas Weaver wrote:

>
> On Feb 24, 2011, at 5:44 AM, Phillip Hallam-Baker wrote:
>
>> So you are saying that it is TOO LATE to make a change that would = have major impact on the practice of domain management?
>
> I'm stating that your "nobody validates DNSSEC" claim is= demonstrably false.

More precisely, there is a large ISP, Comcast, where ALL users who've o= pted out of NXDOMAIN wildcarding are behind DNSSEC validating resolvers. = =A0I would call this a significant operational deployment of DNSSEC validat= ion.



However, back to the original topic: why does case insensitivity for non-AS= CII NEED protocol changes? =A0Can't it be done with just authority chan= ges for only those authorities needing case insensitive non-ASCII names (ra= ther than a protocol change which needs universal changes to the resolvers)=


The authority has a standard mapping for case insensitivity in the language= in question.

a: If its the terminal authority for a name, it just runs the mapping and r= eturns the value (if necessary, generating a DNSSEC signature on the fly if= its an uncached mapping).

b: =A0If the authority is not a terminal, and it knows that the authority d= irectly beneath it for a name support case insensitivity, it just runs the = mapping and returns the appropriate value (if necessary, generating a DNSSE= C signature on the fly if its an uncached mapping).

c: =A0If the authority is not a terminal, and it does NOT know that the aut= hority directly beneath it supports case insensitivity, it runs the mapping= to generate a canonicalized DNAME or CNAME (as appropriate) with TTL=3D0 a= nd, if necessary, generates the appropriate signature.


Cases A and B Just Work (tm).

Case C will work as well because you don't have the CNAME + DNAME probl= em because the TTL is 0. =A0Case C may reduce caching and also increase lat= ency, but that is ONLY network load on the authority not computation load (= because the DNSSEC signature is cached), and creates an incentive for the a= uthority directly beneath to support case-insensitive names.


NO DNS protocol changes are required, everything is provisioning and author= ity side changes.


By maintaining a cache of signed data, the reality is although it supports = effectively exponential case-recasing, the ones which are actually used get= in the cache. =A0If the cache is well structured and sticky, a computation= al DOS won't be able to evict valid entries (limiting its effect to onl= y new BizArrE caSeS of TyPogRaphy)




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

--001636c5bc0f3c7086049d0a6254-- From nweaver@ICSI.Berkeley.EDU Thu Feb 24 12:31:43 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D43223A683F for ; Thu, 24 Feb 2011 12:31:43 -0800 (PST) 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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yG9PARda2SKG for ; Thu, 24 Feb 2011 12:31:43 -0800 (PST) Received: from taffy.ICSI.Berkeley.EDU (taffy.ICSI.Berkeley.EDU [192.150.187.26]) by core3.amsl.com (Postfix) with ESMTP id 0E6863A6832 for ; Thu, 24 Feb 2011 12:31:43 -0800 (PST) Received: from gala.icir.org (gala.ICIR.org [192.150.187.49]) (Authenticated sender: nweaver) by taffy.ICSI.Berkeley.EDU (Postfix) with ESMTP id B3F4936A033; Thu, 24 Feb 2011 12:32:33 -0800 (PST) References: <20110216165921.GW96213@shinkuro.com> <3B90ED2E-980D-4B01-889F-447D66D0B58D@insensate.co.uk> <20110216174011.GZ96213@shinkuro.com> <20110218143653.GC84482@bikeshed.isc.org> <20110218151209.GF66684@shinkuro.com> <4D5EEE09.4080405@dougbarton.us> <20110218222950.GL74065@shinkuro.com> <4D5F270F.20401@abenaki.wabanaki.net> <199C7B2B4228461FB024E59A990DB46D@ics.forth.gr> <4D641DB6.4090705@necom830.hpcl.titech.ac.jp> <20110222205617.GS53815@shinkuro.com> <4D64489B.7020901@necom830.hpcl.titech.ac.jp> <713D992A-1DB9-4F72-9D18-8E923AD51D8D@icsi.berkeley.edu> <4CC95816-8225-4CAE-897F-3F13F965BCEE@ICSI.Berkeley.EDU> <8657EF4A-A08D-46E5-8917-553AE377CAD8@ICSI.Berkeley.EDU> <39EBBA76-22F1-4935-9300-B0078B229793@ICSI.Berkeley.EDU> <5A100E65-FB09-4556-AA5A-BF9FE0468DDA@ICSI.Berkeley.EDU> In-Reply-To: Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii Message-Id: <23E65304-CE46-46E7-BBF2-D246EC830E53@ICSI.Berkeley.EDU> Content-Transfer-Encoding: quoted-printable From: Nicholas Weaver Date: Thu, 24 Feb 2011 12:32:33 -0800 To: Phillip Hallam-Baker X-Mailer: Apple Mail (2.1082) Cc: Nicholas Weaver , dnsext@ietf.org Subject: Re: [dnsext] does making names the same NEED protocol changes at all? X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 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, 24 Feb 2011 20:31:43 -0000 On Feb 24, 2011, at 9:17 AM, Phillip Hallam-Baker wrote: > The problem here comes in that the downstream server needs to be = prepared to support the scheme. And there can be multiple levels of = ambiguity so the cache requirement grows exponentially with each level. Why? That would be case C: A 0 TTL CNAME or DNAME is synthesized, so = there is no support needed down the chain. And again, caching and similar requirements do not grow exponentially IN = PRACTICE: How much bigger would your ASCII DNS cache be if you included every = capitalization variant as a separate cache entry? People don't TyPE = liKE THis, but DNS supports people TyPEiNG lIKe thIS for ASCII. =20 You'd end up with WWW.google.com, www.Google.COM, and the like, but you = won't end up with wWw.goOgLe.cOM in the cache. The problem only occurs if the downstream resolver has a different set = of normalization rules, but developing and specifying such a standard is = outside the purvue of DNS: we aren't the language experts. But given a = standard normalization, no resolver or protocol changes are needed, and = only authorities which support such normalizations need to change. = Additionally, since the upsteam authorities do need to know the state of = the downstream authorities, they can ensure that the normalization is = agreed to. From dougb@dougbarton.us Thu Feb 24 12:35:58 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4ED733A683F for ; Thu, 24 Feb 2011 12:35:58 -0800 (PST) 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, J_CHICKENPOX_37=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mpna4NgKV9iY for ; Thu, 24 Feb 2011 12:35:56 -0800 (PST) Received: from mail2.fluidhosting.com (mx22.fluidhosting.com [204.14.89.5]) by core3.amsl.com (Postfix) with ESMTP id 9D3243A67AB for ; Thu, 24 Feb 2011 12:35:56 -0800 (PST) Received: (qmail 2192 invoked by uid 399); 24 Feb 2011 20:34:10 -0000 Received: from router.ka9q.net (HELO doug-optiplex.ka9q.net) (dougb@dougbarton.us@75.60.237.91) by mail2.fluidhosting.com with ESMTPAM; 24 Feb 2011 20:34:10 -0000 X-Originating-IP: 75.60.237.91 X-Sender: dougb@dougbarton.us Message-ID: <4D66C0C1.1090909@dougbarton.us> Date: Thu, 24 Feb 2011 12:34:09 -0800 From: Doug Barton Organization: http://SupersetSolutions.com/ User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.13) Gecko/20110129 Thunderbird/3.1.7 MIME-Version: 1.0 To: Stephane Bortzmeyer References: <20110223001502.31614.56353.idtracker@localhost> <20110223114720.GA10740@bikeshed.isc.org> <20110224103722.GA28031@nic.fr> In-Reply-To: <20110224103722.GA28031@nic.fr> X-Enigmail-Version: 1.1.2 OpenPGP: id=1A1ABC84 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: dnsext@ietf.org Subject: Re: [dnsext] I-D Action:draft-ietf-dnsext-aliasing-requirements-00.txt X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 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, 24 Feb 2011 20:35:58 -0000 On 02/24/2011 02:37, Stephane Bortzmeyer wrote: > On Wed, Feb 23, 2011 at 11:47:20AM +0000, > Suzanne Woolf wrote > a message of 69 lines which said: > >> Per the announcement to the list last night, the -00 of the >> "aliases" problem statement has been posted to the i-d repository. > > Well, thanks to the authors, it is a very necessary document and I > appreciate that two courageous persons decided to actually work on it. > > This being said, I'm not terribly happy with the result. IMHO, such a > document should be used to help people understand the issues before > claiming "We need variants in the DNS" and I'm afraid it is too > complicated at this stage to fill this role. So it's too complicated, but you want to add to it? :) > More specifically: > > The document does not mention clearly that the starting point is a > difference of expectations between normal humans and IETF > members. I certainly don't think we need to draw the dichotomy quite that way. :) > Normal humans assume that some names are identical > (color.example == colour.example, café.fr == cafe.fr, wells-fargo.com > = wellsfargo.com, ibm.example = IBM.Example, etc) and the DNS does not > deliver what they want. IETF participants know that my last example > works and not the other three but, when you try to explain that to > normal humans, they don't understand and they are right. It should be > stated from the beginning that we simply cannot provide a DNS > behaviour that will be seen by normal users as "natural" and > "unsurprising" (because of the complexity of the rules and their > language-dependant character). So, we should warn users, not try to > create mechanisms that will *always* fall short of their expectations. I agree that more examples would help improve the readability of the document for the non-tech folks, and there will be quite a few of them who will be reading/interested in this document. I disagree however that the logical conclusion of "the problem is a difficult one" is "therefore we should do nothing." I think this document makes a good start at laying out the problems, and should be expanded to make it more clear where solutions are possible in the DNS layer, and for which problems solutions will have to come from other layers. > Second, the document seems to assume that the problem is mostly, if > not exclusively, an IDN thing. As the examples above (and the examples > of phishing sites) show, this is far from true. In registries which > are still discussing IDN registration (like .FR, see > ), > some people keep telling that IDN are complicated and we should not > allow them because of this complication. But the examples above show > that IDN are not the only issue. It would be better if the document > clearly stated that. (Another french story: in .FR, the law - not the > registry policies - says that city names are reserved to the city > council, and this is done in a dash-independent way: saint-quentin.fr > and saintquentin.fr are therefore part of the same "bundle". Since the > law is only for cities, not for corporations, saint-gobain.fr and > saintgobain.fr are still distinct. Imagine the user confusion!) Registry policy could help with this user confusion. If only we knew someone in a position to help with that ... > The case (pun intended) of case-insensitivity is a complex one. It is > obviously impossible to change the rules now but the document says > several times that the case-insensitive rule is a good one, which is > not obvious. The case-insensitivity rule is not perfect (in French, > Poussin is a painter and poussin a bird) and users legitimally ask > "why case is not important but a stupid dash is?". The document's only > negative remark about case-insensitivity is about its use in > compression (section 2.3.1), which seems to me an useless detail > (because only implementers see it). I suggest to drop this sentence > about compression: the biggest lack of consistency is not in > compression, it is in the fact that DNS is fuzzy on some criteria > (case) and strict in others (dash, spelling). That would have value for the non-technical audience of the document, yes. > The document mentions several times (for instance 3.1.1) the perceived > need to be able to distinguish if a name is a member of a bundle. This > need is not explicitely stated in the Proposed Requirments section (4) > and is questionable. What is the rationale for this unstated > requirment? My understanding is that it is to help application developers to be able to auto-configure things to handle multiple variants. I think this is a good idea, and you made a good catch in noting that it's not in Section 4. > The section on Applications (3.3) apparently does not mention the fact > that many application protocols (HTTP and SMTP are two obvious > examples) need to be configured to recognize the bundle. (Which is a > strong argument against a new DNS solution, since it will be useless > anyway.) I believe that the common case will be that there are few enough variants that users who wish to use them all will simply configure them. This is already the case for "the same" domain in multiple TLDs, or non-IDN "variants" (of which your dash examples are a great case in point), and IS already the case for those who have chosen to provision the IDN variants they've been delegated. There is nothing about providing a DNS solution to the variant problem which makes _using_ the variants harder (or for the most part, different) and we have at least the chance to make life easier. To that end, the security and/or application section(s) of the document could probably use a mention of name-based virtual hosting for http. It would also be nice to provide a discussion of the fact that HTML5 + DNSSEC + CERT has a chance to replace hostname-based SSL certs altogether, but given that I'm fuzzy on the details and don't have the time to do the research to provide text consider it only the whispiest of hints of a suggestion. :) 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 george.barwood@blueyonder.co.uk Thu Feb 24 14:29:00 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E30AF3A680D for ; Thu, 24 Feb 2011 14:28:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.766 X-Spam-Level: X-Spam-Status: No, score=0.766 tagged_above=-999 required=5 tests=[AWL=0.171, BAYES_00=-2.599, HELO_EQ_BLUEYON=1.4, MIME_BASE64_BLANKS=0.041, MIME_BASE64_TEXT=1.753] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W8tMhz1s4Skn for ; Thu, 24 Feb 2011 14:28:58 -0800 (PST) Received: from smtp-out3.blueyonder.co.uk (smtp-out3.blueyonder.co.uk [195.188.213.6]) by core3.amsl.com (Postfix) with ESMTP id C03693A6808 for ; Thu, 24 Feb 2011 14:28:57 -0800 (PST) Received: from [172.23.170.145] (helo=anti-virus03-08) by smtp-out3.blueyonder.co.uk with smtp (Exim 4.52) id 1Psjgx-0000Rj-0h; Thu, 24 Feb 2011 22:29:47 +0000 Received: from [92.238.99.235] (helo=GeorgeLaptop) by asmtp-out4.blueyonder.co.uk with smtp (Exim 4.72) (envelope-from ) id 1Psjgh-0004dL-As; Thu, 24 Feb 2011 22:29:31 +0000 Message-ID: <0440B44C7532424EA1D0FE7ED79447EF@local> From: "George Barwood" To: "Suzanne Woolf" , References: <20110223001502.31614.56353.idtracker@localhost> <20110223114720.GA10740@bikeshed.isc.org> Date: Thu, 24 Feb 2011 22:30:03 -0000 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.5994 Subject: Re: [dnsext] I-DAction:draft-ietf-dnsext-aliasing-requirements-00.txt X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 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, 24 Feb 2011 22:29:00 -0000 VGhlIGRyYWZ0IGdldHMgdG8gdGhlIGhlYXJ0IG9mIHRoZSBpc3N1ZSBoZXJlDQoNCiAgIE9uZSBh c3BlY3Qgb2YgdGhpcyBpcw0KICAgdGhlIG5vdGlvbiBvciBleHBlY3RhdGlvbiB0aGF0IG11bHRp cGxlIHNldHMgb2YgbmFtZXMgbWF5IGJlIHNpbWlsYXINCiAgIHRvIGEgaHVtYW4gdXNlciwgYW5k IGV4cGVjdGVkIHRvIGJlaGF2ZSAidGhlIHNhbWUiIG9yIGFzICJhbGlhc2VzIiBvZg0KICAgb25l IGFub3RoZXIsIGFjcm9zcyBtdWx0aXBsZSBzZXJ2aWNlcyBhbmQgaW50ZXJhY3Rpb25zLg0KDQpJ dCBzZWVtcyB0byBtZSB0aGF0IGluIGZhY3QgdGhlIG51bWJlciBvZiB2YXJpYXRpb25zIG9mIGEg Y29tcGxldGUgbmFtZSB3aWxsIGJlIHF1aXRlIHNtYWxsIGluIHByYWN0aWNlLg0KDQpUaGVyZSB3 aWxsIGJlIGN1bHR1cmFsIGNvbnZlbnRpb25zIGZvciB0aGUgY29ycmVjdCAic3BlbGxpbmciLCBp biBzb21lIGNhc2VzIHRoZXJlIG1heSBiZSBhIGZldyBhbHRlcm5hdGl2ZSBjb252ZW50aW9ucy4N Cg0KSXQncyBub3QgaGFyZCB0byBoYW5kbGUgYSBtb2RlcmF0ZSBudW1iZXIgb2YgdmFyaWF0aW9u cyBpbiBETlMgOiBpdCBtYXkgaW1wb3NlIHNvbWUgYWRkaXRpb25hbCBvdmVyaGVhZCwgYnV0IHNl bnNpYmxlIHRvb2xzIGZvciBhZG1pbmlzdGVyaW5nIGRvbWFpbnMgYW5kIHJlZ2lzdHJhdGlvbnMg c2hvdWxkIG1pbmltaXNlIHRoaXMuDQoNCkFnYWluIGF0IHRoZSBhcHBsaWNhdGlvbiBsZXZlbCwg cHJvcGVyIHRvb2xzIGZvciBoYW5kbGluZyB2YXJpYXRpb25zIGFyZSBxdWl0ZSBzdHJhaWdodGZv cndhcmQgLSBpdCBzaG91bGQgYmUgc3RyYWlnaHRmb3J3YXJkIHRvIGNvbmZpZ3VyZSB3ZWIsIGVt YWlsIGFuZCBvdGhlciBzZXJ2ZXJzIHRvIHJlY29nbmlzZSBzdGFuZGFyZCB2YXJpYXRpb25zLg0K DQpXaGVyZSB0aGUgZHJhZnQgc3RhdGVzOg0KDQogICBIb3dldmVyZXIsIGl0IGlzIG5vdA0KICAg Y2xlYXIgaG93IG11Y2ggb2YgdGhlIHVzZXIgYW5kIG9wZXJhdG9yIHJlcXVpcmVtZW50cyBmb3Ig ImFsaWFzZXMiDQogICBjYW4gYmUgbWV0IGJ5IG1lY2hhbmlzbXMgZm9yIHByb3Zpc2lvbmluZyBE TlMgem9uZXMsIGF0IGFjY2VwdGFibGUgY29zdC4NCg0KSSBkb24ndCBiZWxpZXZlIHRoZSBjb3N0 cyBhcmUgYWN0dWFsbHkgdW5hY2NlcHRhYmxlIGF0IGFsbC4NCg0KQmVzaWRlcywgdXNlcnMgdGhl c2UgZGF5cyBkbyBub3QgdHlwZSBkb21haW4gbmFtZXMgdmVyeSBvZnRlbiAtIHdoZW4gbG9va2lu ZyBmb3IgYW4gd2Vic2l0ZSB3ZSB1c3VhbGx5IHVzZSBzZWFyY2ggZW5naW5lcy4gT25lIG1pZ2h0 IGdpdmUgYW4gZW1haWwgYWRkcmVzcyBvdmVyIHRoZSBwaG9uZSwgYnV0IHRoaXMgaXMgbm90IGFu IGV2ZXJ5ZGF5IGV2ZW50Lg0KDQpTbyBJIHRoaW5rIHRoZSBjdXJyZW50IHNpdHVhdGlvbiBpcyBu b3QgYXMgYmFkIGFzIGhhcyBiZWVuIGltcGxpZWQsIGFuZCB0aGVyZWZvcmUgaXQgaXMgb25seSB3 b3J0aHdoaWxlIHB1cnN1aW5nIHRlY2huaWNhbCBjaGFuZ2VzIHRvIHRoZSBETlMgc3RhbmRhcmQg aWYgdGhlIGNvc3RzIG9mIHN1Y2ggY2hhbmdlcyBhcmUgbG93LCB3aGljaCBJIGRvdWJ0Lg0KDQpH ZW9yZ2UNCg== From alex@alex.org.uk Fri Feb 25 04:47:27 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 033E43A69A8 for ; Fri, 25 Feb 2011 04:47:27 -0800 (PST) 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=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vx5AlEg9OkAV for ; Fri, 25 Feb 2011 04:47:26 -0800 (PST) Received: from mail.avalus.com (mail.avalus.com [89.16.176.221]) by core3.amsl.com (Postfix) with ESMTP id E7ECF3A69A7 for ; Fri, 25 Feb 2011 04:47:25 -0800 (PST) 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 38B57C5641A; Fri, 25 Feb 2011 12:48:16 +0000 (GMT) Date: Fri, 25 Feb 2011 12:48:15 +0000 From: Alex Bligh To: Phillip Hallam-Baker , Nicholas Weaver Message-ID: <6AD400292B2C771C7FE70E8F@Ximines.local> In-Reply-To: References: <20110216165921.GW96213@shinkuro.com> <3B90ED2E-980D-4B01-889F-447D66D0B58D@insensate.co.uk> <20110216174011.GZ96213@shinkuro.com> <20110218143653.GC84482@bikeshed.isc.org> <20110218151209.GF66684@shinkuro.com> <4D5EEE09.4080405@dougbarton.us> <20110218222950.GL74065@shinkuro.com> <4D5F270F.20401@abenaki.wabanaki.net> <199C7B2B4228461FB024E59A990DB46D@ics.forth.gr> <4D641DB6.4090705@necom830.hpcl.titech.ac.jp> <20110222205617.GS53815@shinkuro.com> <4D64489B.7020901@necom830.hpcl.titech.ac.jp> <713D992A-1DB9-4F72-9D18-8E923AD51D8D@icsi.berkeley.edu> <4CC95816-8225-4CAE-897F-3F13F965BCEE@ICSI.Berkeley.EDU> <8657EF4A-A08D-46E5-8917-553AE377CAD8@ICSI.Berkeley.EDU> <39EBBA76-22F1-4935-9300-B0078B229793@ICSI.Berkeley.EDU> <5A100E65-FB09-4556-AA5A-BF9FE0468DDA@ICSI.Berkeley.EDU> 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] does making names the same NEED protocol changes at all? X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 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: Fri, 25 Feb 2011 12:47:27 -0000 --On 24 February 2011 12:17:10 -0500 Phillip Hallam-Baker wrote: > I am starting to get a really bad feeling about the resolve the same > requirement. Is the objective here really to make things work better or > did the authorities that raised this in ICANN have a rather different > agenda? We asked (effectively) that, and reply there came none. I think there may have been a little naivety involved, and someone rather hopefully thought a simple "fix in DNS" could make domain names in n different TLDs (which they thought of as 1 TLD with n different representations) "work the same". Several hundred messages here plus a non-trivial I-D just to set out the requirements, suggests that at the very least, the problem is not as simple as first thought. I understand what ICANN is wanting to do (particularly since the "one ccTLD per nation" requirement is long standing), and suggest the answer is "give up the aliasing requirement or enforce it by contract with your TLDs". I also think I understand what the registries are trying to do, and suggest the answer is "enforce this within your business processes" (i.e. make registration of any of a bundle of identical names block out all further registrations other than by the same registrant, and let the same registrant insert NS records etc. for any other domain in the same bundle, perhaps up to some local policy limit). I can understand why synthesis might be useful here, but I can also understand why registries don't like it. I also think I understand what the rest of the world might want to do, and my answer is "use CNAME/DNAME", plus possibly synthesis. However, what we don't yet have is a coherent statement of the problem (save for the I-D just out which I have yet to read), which means we don't have coherent explanation of why it is so difficult to solve (and, IMHO, a bad idea if it requires protocol changes). This is why I should go and read the I-D. -- Alex Bligh From woolf@isc.org Fri Feb 25 05:32:33 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9D99F3A69BA for ; Fri, 25 Feb 2011 05:32:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.711 X-Spam-Level: X-Spam-Status: No, score=-2.711 tagged_above=-999 required=5 tests=[AWL=-0.111, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VEuCniPwrAkE for ; Fri, 25 Feb 2011 05:32:32 -0800 (PST) Received: from mx.ams1.isc.org (mx.ams1.isc.org [IPv6:2001:500:60::65]) by core3.amsl.com (Postfix) with ESMTP id B2EC33A69BB for ; Fri, 25 Feb 2011 05:32:31 -0800 (PST) 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 19D9C5F98E1; Fri, 25 Feb 2011 13:33:05 +0000 (UTC) (envelope-from woolf@isc.org) Received: by bikeshed.isc.org (Postfix, from userid 10265) id 884D3216C22; Fri, 25 Feb 2011 13:33:03 +0000 (UTC) Date: Fri, 25 Feb 2011 13:33:03 +0000 From: Suzanne Woolf To: Alex Bligh Message-ID: <20110225133303.GC80235@bikeshed.isc.org> References: <4CC95816-8225-4CAE-897F-3F13F965BCEE@ICSI.Berkeley.EDU> <8657EF4A-A08D-46E5-8917-553AE377CAD8@ICSI.Berkeley.EDU> <39EBBA76-22F1-4935-9300-B0078B229793@ICSI.Berkeley.EDU> <5A100E65-FB09-4556-AA5A-BF9FE0468DDA@ICSI.Berkeley.EDU> <6AD400292B2C771C7FE70E8F@Ximines.local> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <6AD400292B2C771C7FE70E8F@Ximines.local> User-Agent: Mutt/1.4.2.3i Cc: dnsext@ietf.org Subject: Re: [dnsext] does making names the same NEED protocol changes at all? X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 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, 25 Feb 2011 13:32:33 -0000 On Fri, Feb 25, 2011 at 12:48:15PM +0000, Alex Bligh wrote: > --On 24 February 2011 12:17:10 -0500 Phillip Hallam-Baker > wrote: > > >I am starting to get a really bad feeling about the resolve the same > >requirement. Is the objective here really to make things work better or > >did the authorities that raised this in ICANN have a rather different > >agenda? > > We asked (effectively) that, and reply there came none. ICANN has announced a proposed study project that stands some chance of allowing it to arrive at its own position on what's entailed around "variants" or "sameness". It appears that they are admitting they don't know what they want, or whether it's got anything to do with the DNS, so they're starting from the policy perspective and working (perhaps) towards the technical. See: http://www.icann.org/en/public-comment/public-comment-201104-en.htm#idn-varianttld (NB: I serve as a non-voting liaison to the ICANN Board of Directors from one of its technical Advisory Committees, the Root Server System Advisory Committee. However, I don't speak for ICANN, particularly not on this issue; took on the aliases draft with no support or prompting from ICANN and with the support of my employer, ISC; and have been trying for quite some time now to get ICANN to speak for itself.) > I think there may have been a little naivety involved, and someone rather > hopefully thought a simple "fix in DNS" could make domain names in n > different TLDs (which they thought of as 1 TLD with n different > representations) "work the same". Several hundred messages here plus a > non-trivial I-D just to set out the requirements, suggests that at the very > least, the problem is not as simple as first thought. Can't comment on what ICANN thought (see above). But I'll note that part of how we got where we are was that the WG found itself with several proposals for technology to solve a simple, obvious problem that no one could state here, either. In other words, there may have been plenty of naivety to go around :-) (including my own, I claim no special wisdom) > I also think I understand what the registries are trying to do, and suggest > the answer is "enforce this within your business processes" (i.e. make > registration of any of a bundle of identical names block out all further > registrations other than by the same registrant, and let the same > registrant insert NS records etc. for any other domain in the same bundle, > perhaps up to some local policy limit). I can understand why synthesis > might be useful here, but I can also understand why registries don't like > it. > > I also think I understand what the rest of the world might want to > do, and my answer is "use CNAME/DNAME", plus possibly synthesis. This is a very fair and important point-- that we're actually talking about two different perspectives here, what registries want and what application writers want. One of the things we have to settle is how much they're talking about "the same thing"(!) -- i.e. how much their concepts of what needs to be done overlap. If all we're looking at is what registries need, we have to separate the policy requirement to have a way to determine that a set of objects should be treated as "the same" (not our business) from the operational or technical requirements for a mechanism by which to instantiate what that means (maybe our business). To the first (registry) question, I'm hoping for more text on variant-related use cases, which is why I'm hopeful about ICANN's new project. But when you read the draft, you'll see a proposed requirement that for any action the WG takes, it's necessary but not sufficient to address the registry consideration, per some comments on the list about a week ago. It's extremely important to get reactions to that requirement from the full range of WG participants. I've talked to some people (some of whom have posted here) who seem to be saying that parallel provisioning by the domain registry is not enough for their purposes, because the fact that the objects so created are only related inside the registry and to some assumed set of users is not enough-- that it would be useful to them to have a service-independent, application-accessible way to create a property or attribute of a set of names that we could call "sameness" or "aliases-of". If true, it provides a motivation for looking hard at a requirement that parallel provisioning doesn't meet (your second prong). However, it's been extremely difficult to get clarity on this, and it's one of the things most important to get right for the draft. Either way, we also need to settle exactly how CNAME/DNAME fall short, if they do. The current draft takes a stab at that but it may need more development. > However, what we don't yet have is a coherent statement of the problem > (save for the I-D just out which I have yet to read), which means we don't > have coherent explanation of why it is so difficult to solve (and, IMHO, a > bad idea if it requires protocol changes). This is why I should go and read > the I-D. Please do, looking forward to your comments. best, Suzanne From ajs@shinkuro.com Fri Feb 25 06:29:54 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 58F2E3A68D4 for ; Fri, 25 Feb 2011 06:29:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.584 X-Spam-Level: X-Spam-Status: No, score=-102.584 tagged_above=-999 required=5 tests=[AWL=0.015, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ulSSpWvFhF1I for ; Fri, 25 Feb 2011 06:29:53 -0800 (PST) Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by core3.amsl.com (Postfix) with ESMTP id 8C7EF3A67EC for ; Fri, 25 Feb 2011 06:29:53 -0800 (PST) Received: from crankycanuck.ca (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 F1ACF1ECB408 for ; Fri, 25 Feb 2011 14:30:44 +0000 (UTC) Date: Fri, 25 Feb 2011 09:30:43 -0500 From: Andrew Sullivan To: dnsext@ietf.org Message-ID: <20110225143043.GB74938@shinkuro.com> References: <4CC95816-8225-4CAE-897F-3F13F965BCEE@ICSI.Berkeley.EDU> <8657EF4A-A08D-46E5-8917-553AE377CAD8@ICSI.Berkeley.EDU> <39EBBA76-22F1-4935-9300-B0078B229793@ICSI.Berkeley.EDU> <5A100E65-FB09-4556-AA5A-BF9FE0468DDA@ICSI.Berkeley.EDU> <6AD400292B2C771C7FE70E8F@Ximines.local> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <6AD400292B2C771C7FE70E8F@Ximines.local> User-Agent: Mutt/1.5.18 (2008-05-17) Subject: Re: [dnsext] does making names the same NEED protocol changes at all? X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 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, 25 Feb 2011 14:29:54 -0000 No hat, I think. On Fri, Feb 25, 2011 at 12:48:15PM +0000, Alex Bligh wrote: > per nation" requirement is long standing), and suggest the answer is "give > up the aliasing requirement or enforce it by contract with your TLDs". Two things: 1. The issue before us is not merely a TLD or near-TLD one. If we work as though it is, then we're not doing our jobs. 2. Notwithstanding the above, there are some delegation relationships that are less fraught than others. There are all sorts of prickly layer-9+ issues implicit in talking about a contract between a private US corporation and the sovereign power of foreign nations, and I think we maybe want to avoid exploring that warren. A -- Andrew Sullivan ajs@shinkuro.com Shinkuro, Inc. From hallam@gmail.com Fri Feb 25 08:48:47 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 50D0A3A6774 for ; Fri, 25 Feb 2011 08:48:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.567 X-Spam-Level: X-Spam-Status: No, score=-3.567 tagged_above=-999 required=5 tests=[AWL=0.031, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l7LqDZjzR5+e for ; Fri, 25 Feb 2011 08:48:46 -0800 (PST) Received: from mail-bw0-f44.google.com (mail-bw0-f44.google.com [209.85.214.44]) by core3.amsl.com (Postfix) with ESMTP id 823AE3A63EB for ; Fri, 25 Feb 2011 08:48:45 -0800 (PST) Received: by bwz13 with SMTP id 13so2469729bwz.31 for ; Fri, 25 Feb 2011 08:49:37 -0800 (PST) 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=3xsMlZ29QTy0TjlRwX3EmtzKIxx6F65ygvxnzOWY8FI=; b=YHwMGNUjc1PmrIS2eQVYDS276MrTW9PgDcqvbWifg/6EBUdtvMmUOAFONvG2Q9t+Ad GyRw99JGDNiMw2NzuJ/z4hKvzUPB9a2flIJsruWYtDl/1gXYrAmyTjgjnu7kk7RlV4OE NyTzNupXPnzuL/bi043VUrl/9w8Q/K8HR4ZOE= 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=t0U5GqrvyP4312Oop3O0XS9q7I85Vw/ABwZOtFnCzoutgcpLoO72ZwD3GuYfgIr3u8 tDFLpewLcolg7TcAE5l885zU4+68b0r2G7uYM+DQUwK8hQ4OCeJBNGpTLtRLY537AzH4 GWeA7OTY/2LlUnF6TVi8I3s/3CqyhVyM85qyY= MIME-Version: 1.0 Received: by 10.204.73.160 with SMTP id q32mr2224551bkj.155.1298652575908; Fri, 25 Feb 2011 08:49:35 -0800 (PST) Received: by 10.204.14.139 with HTTP; Fri, 25 Feb 2011 08:49:35 -0800 (PST) In-Reply-To: <20110225143043.GB74938@shinkuro.com> References: <4CC95816-8225-4CAE-897F-3F13F965BCEE@ICSI.Berkeley.EDU> <8657EF4A-A08D-46E5-8917-553AE377CAD8@ICSI.Berkeley.EDU> <39EBBA76-22F1-4935-9300-B0078B229793@ICSI.Berkeley.EDU> <5A100E65-FB09-4556-AA5A-BF9FE0468DDA@ICSI.Berkeley.EDU> <6AD400292B2C771C7FE70E8F@Ximines.local> <20110225143043.GB74938@shinkuro.com> Date: Fri, 25 Feb 2011 11:49:35 -0500 Message-ID: From: Phillip Hallam-Baker To: Andrew Sullivan Content-Type: multipart/alternative; boundary=0016e6d96d0a7944ff049d1e1d11 Cc: dnsext@ietf.org Subject: Re: [dnsext] does making names the same NEED protocol changes at all? X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 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, 25 Feb 2011 16:48:47 -0000 --0016e6d96d0a7944ff049d1e1d11 Content-Type: text/plain; charset=ISO-8859-1 I suspect that the point of these requirements is precisely the fact that they cannot be met within the current architecture. I am seeing people rushing to change the security model of DNSSEC to support this requirement, but I doubt that is going to be sufficient. Let me be clear here, I do not believe that any contributor to this discussion is acting improperly or following a hidden agenda. But I do strongly suspect that the problem is intentionally put in such a manner as to collectively yank our chain. This is the bring me a rock school (no wrong one) school of management. And the rock will continue to be the wrong one until such time as we propose creating a hole in the infrastructure that serves the underlying agenda. It seems rather surreal to be having a dialogue about how to make locating Web sites easier when the parties behind the proposal are devoting vast resources to make access to the 'wrong' sites as hard as possible. The anual market for censorship equipment and technology is in the billions of dollars and most of that technology is being made by companies whose names are really well known in IETF. Oddly enough, the companies that are involved in that particular market do not attract a tenth of the scrutiny that CAs attract. I am not aware of any CA having mis-issued except unintentionally or as a result of coercion. Yet the sales of equipment designed for the purpose of enabling censorship are made with full knowledge of their purpose. Here is an idea, let us table this whole discussion until after we solve the problem of how to make the Internet accessible without let or hindrance from any point on the planet with minimal communications connectivity. The proposal that I made at the start of this discussion for a 'Did you Mean' record is easily sufficient to address legitimate usability concerns in this respect. If we wanted to go further we could define a record that specifies transliteration mappings within a domain. But at the moment I am rather more interested in the prospects for running NNTP over USB key and wifi enabled mobile devices as transport. On Fri, Feb 25, 2011 at 9:30 AM, Andrew Sullivan wrote: > No hat, I think. > > On Fri, Feb 25, 2011 at 12:48:15PM +0000, Alex Bligh wrote: > > > per nation" requirement is long standing), and suggest the answer is > "give > > up the aliasing requirement or enforce it by contract with your TLDs". > > Two things: > > 1. The issue before us is not merely a TLD or near-TLD one. If we > work as though it is, then we're not doing our jobs. > > 2. Notwithstanding the above, there are some delegation relationships > that are less fraught than others. There are all sorts of prickly > layer-9+ issues implicit in talking about a contract between a private > US corporation and the sovereign power of foreign nations, and I think > we maybe want to avoid exploring that warren. > > A > > -- > Andrew Sullivan > ajs@shinkuro.com > Shinkuro, Inc. > _______________________________________________ > dnsext mailing list > dnsext@ietf.org > https://www.ietf.org/mailman/listinfo/dnsext > -- Website: http://hallambaker.com/ --0016e6d96d0a7944ff049d1e1d11 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I suspect that the point of these requirements is precisely the fact that t= hey cannot be met within the current architecture.

I am = seeing people rushing to change the security model of DNSSEC to support thi= s requirement, but I doubt that is going to be sufficient.

Let me be clear here, I do not believe that any contrib= utor to this discussion is acting improperly or following a hidden agenda. = But I do strongly suspect that the problem is intentionally put in such a m= anner as to collectively yank our chain.=A0

This is the bring me a rock school (no wrong one) schoo= l of management. And the rock will continue to be the wrong one until such = time as we propose creating a hole in the infrastructure that serves the un= derlying agenda.


It seems rather surreal to be having a d= ialogue about how to make locating Web sites easier when the parties behind= the proposal are devoting vast resources to make access to the 'wrong&= #39; sites as hard as possible.

The anual market for censorship equipment and technolog= y is in the billions of dollars and most of that technology is being made b= y companies whose names are really well known in IETF.

Oddly enough, the companies that are involved in that particular marke= t do not attract a tenth of the scrutiny that CAs attract. I am not aware o= f any CA having mis-issued except unintentionally or as a result of coercio= n. Yet the sales of equipment designed for the purpose of enabling censorsh= ip are made with full knowledge of their purpose.


Here is an idea, let us table this whole= discussion until after we solve the problem of how to make the Internet ac= cessible without let or hindrance from any point on the planet with minimal= communications connectivity.

The proposal that I made at the start of this discussio= n for a 'Did you Mean' record is easily sufficient to address legit= imate usability concerns in this respect. If we wanted to go further we cou= ld define a record that specifies transliteration mappings within a domain.= =A0

But at the moment I am rather more interested in the pr= ospects for running NNTP over USB key and wifi enabled mobile devices as tr= ansport.


On Fri, Feb 25, 2011 at 9:30 AM, Andrew Sullivan <ajs@shinkuro.com> wrote:
<= blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px= #ccc solid;padding-left:1ex;"> No hat, I think.

On Fri, Feb 25, 2011 at 12:48:15PM +0000, Alex Bligh wrote:

> per nation" requirement is long standing)= , and suggest the answer is "give
> up the aliasing requirement or enforce it by contract with your TLDs&q= uot;.

Two things:

1. =A0The issue before us is not merely a TLD or near-TLD one. =A0If we
work as though it is, then we're not doing our jobs.

2. =A0Notwithstanding the above, there are some delegation relationships that are less fraught than others. =A0There are all sorts of prickly
layer-9+ issues implicit in talking about a contract between a private
US corporation and the sovereign power of foreign nations, and I think
we maybe want to avoid exploring that warren.

A

--
Andrew Sullivan
ajs@shinkuro.com
Shinkuro, Inc.
_______________________________________________
dnsext mailing list
dnsext@ietf.org
= https://www.ietf.org/mailman/listinfo/dnsext



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

--0016e6d96d0a7944ff049d1e1d11-- From fanf2@hermes.cam.ac.uk Fri Feb 25 09:08:59 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9AD2B3A683C for ; Fri, 25 Feb 2011 09:08:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.445 X-Spam-Level: X-Spam-Status: No, score=-6.445 tagged_above=-999 required=5 tests=[AWL=0.154, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FV80ETy0Pdjb for ; Fri, 25 Feb 2011 09:08:58 -0800 (PST) Received: from ppsw-41.csi.cam.ac.uk (ppsw-41.csi.cam.ac.uk [131.111.8.141]) by core3.amsl.com (Postfix) with ESMTP id 7C42E3A679F for ; Fri, 25 Feb 2011 09:08:57 -0800 (PST) X-Cam-AntiVirus: no malware found X-Cam-SpamDetails: not scanned X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ Received: from hermes-1.csi.cam.ac.uk ([131.111.8.51]:34765) by ppsw-41.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.156]:25) with esmtpa (EXTERNAL:fanf2) id 1Pt1Ar-0004LF-Qj (Exim 4.72) (return-path ); Fri, 25 Feb 2011 17:09:49 +0000 Received: from fanf2 (helo=localhost) by hermes-1.csi.cam.ac.uk (hermes.cam.ac.uk) with local-esmtp id 1Pt1Ar-0000nK-8r (Exim 4.67) (return-path ); Fri, 25 Feb 2011 17:09:49 +0000 Date: Fri, 25 Feb 2011 17:09:49 +0000 From: Tony Finch X-X-Sender: fanf2@hermes-1.csi.cam.ac.uk To: Phillip Hallam-Baker In-Reply-To: Message-ID: References: <4CC95816-8225-4CAE-897F-3F13F965BCEE@ICSI.Berkeley.EDU> <8657EF4A-A08D-46E5-8917-553AE377CAD8@ICSI.Berkeley.EDU> <39EBBA76-22F1-4935-9300-B0078B229793@ICSI.Berkeley.EDU> <5A100E65-FB09-4556-AA5A-BF9FE0468DDA@ICSI.Berkeley.EDU> <6AD400292B2C771C7FE70E8F@Ximines.local> <20110225143043.GB74938@shinkuro.com> User-Agent: Alpine 2.00 (LSU 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: Tony Finch Cc: dnsext@ietf.org Subject: Re: [dnsext] does making names the same NEED protocol changes at all? X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 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, 25 Feb 2011 17:08:59 -0000 On Fri, 25 Feb 2011, Phillip Hallam-Baker wrote: > I suspect that the point of these requirements is precisely the fact that > they cannot be met within the current architecture. A lot of the argument is because we aren't sure that that is true. Can the requirements be met with improved provisioning technology and no protocol changes? > I am seeing people rushing to change the security model of DNSSEC to support > this requirement, but I doubt that is going to be sufficient. Online signing is not a change to the DNSSEC security model. Tony. -- f.anthony.n.finch http://dotat.at/ Forties, Cromarty, Forth: Southwest 5 to 7 veering northwest 4 or 5. Moderate or rough. Occasional rain. Moderate or good, occasionally poor. From alex@alex.org.uk Fri Feb 25 09:09:43 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6AA873A67A5 for ; Fri, 25 Feb 2011 09:09:43 -0800 (PST) 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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RZmgrK-Y1ATf for ; Fri, 25 Feb 2011 09:09:42 -0800 (PST) Received: from mail.avalus.com (mail.avalus.com [89.16.176.221]) by core3.amsl.com (Postfix) with ESMTP id 9CBEF3A68B1 for ; Fri, 25 Feb 2011 09:09:42 -0800 (PST) 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 6E270C5689E; Fri, 25 Feb 2011 17:10:34 +0000 (GMT) Date: Fri, 25 Feb 2011 17:10:33 +0000 From: Alex Bligh To: Phillip Hallam-Baker , Andrew Sullivan Message-ID: <80A68CE9DB8143C58F73EADA@Ximines.local> In-Reply-To: References: <4CC95816-8225-4CAE-897F-3F13F965BCEE@ICSI.Berkeley.EDU> <8657EF4A-A08D-46E5-8917-553AE377CAD8@ICSI.Berkeley.EDU> <39EBBA76-22F1-4935-9300-B0078B229793@ICSI.Berkeley.EDU> <5A100E65-FB09-4556-AA5A-BF9FE0468DDA@ICSI.Berkeley.EDU> <6AD400292B2C771C7FE70E8F@Ximines.local> <20110225143043.GB74938@shinkuro.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: dnsext@ietf.org Subject: Re: [dnsext] does making names the same NEED protocol changes at all? X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 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: Fri, 25 Feb 2011 17:09:43 -0000 --On 25 February 2011 11:49:35 -0500 Phillip Hallam-Baker wrote: > Here is an idea, let us table this whole discussion until after we solve > the problem of how to make the Internet accessible without let or > hindrance from any point on the planet with minimal communications > connectivity. Perhaps I am being thick here, but I don't see anything but the most tenuous connection between internet censorship and IDN variant support in DNS. I'm in general in favour the solution to this problem being "not to fix it", but I think we owe people a better rationale for this than "some IDN users censor internet traffic" which I suspect might be the link you are making. -- Alex Bligh From hallam@gmail.com Fri Feb 25 09:42:39 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 20C953A6814 for ; Fri, 25 Feb 2011 09:42:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.568 X-Spam-Level: X-Spam-Status: No, score=-3.568 tagged_above=-999 required=5 tests=[AWL=0.030, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H-rEAZjPIOpY for ; Fri, 25 Feb 2011 09:42:37 -0800 (PST) Received: from mail-bw0-f44.google.com (mail-bw0-f44.google.com [209.85.214.44]) by core3.amsl.com (Postfix) with ESMTP id 5CDD93A679F for ; Fri, 25 Feb 2011 09:42:37 -0800 (PST) Received: by bwz13 with SMTP id 13so2523653bwz.31 for ; Fri, 25 Feb 2011 09:43:29 -0800 (PST) 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=D31qS9Lawr0MmxD8bMG6HkhrtaJUqt+xZRx8vPMW9Os=; b=Z3NeEFn9kqe/qpPFzKyqZbd3HDJdwGKB/lD3xFhJ9tX5yzhdJA51TZeLT6FHFHZ40/ Xq8ezHWWjCPTu8o8lOPZvYevLrKT9eee5t2YY7d9Hx4024mUdUMJK5j59kbkgP+vXlAx rhIFr2ykjP749P38mSmYvVR/szvV4nbxoZ/MQ= 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=PBdnuWkzTo2MnUzish+qOH9U38dboA9l7b97823zprBvXisVmA0M9Zw82vs8pvyr+G l70NGfT0GfNOkkVGZqJy9yiHle6Z+o2mMH8hv4UYJOWY0A7yijsZsagzfgLYxHyyDY+v hgMj7xCEBQO7j6db/zS30zThsRB82waqTv4/o= MIME-Version: 1.0 Received: by 10.204.73.160 with SMTP id q32mr2274792bkj.155.1298655809379; Fri, 25 Feb 2011 09:43:29 -0800 (PST) Received: by 10.204.14.139 with HTTP; Fri, 25 Feb 2011 09:43:29 -0800 (PST) In-Reply-To: References: <4CC95816-8225-4CAE-897F-3F13F965BCEE@ICSI.Berkeley.EDU> <8657EF4A-A08D-46E5-8917-553AE377CAD8@ICSI.Berkeley.EDU> <39EBBA76-22F1-4935-9300-B0078B229793@ICSI.Berkeley.EDU> <5A100E65-FB09-4556-AA5A-BF9FE0468DDA@ICSI.Berkeley.EDU> <6AD400292B2C771C7FE70E8F@Ximines.local> <20110225143043.GB74938@shinkuro.com> Date: Fri, 25 Feb 2011 12:43:29 -0500 Message-ID: From: Phillip Hallam-Baker To: Tony Finch Content-Type: multipart/alternative; boundary=0016e6d96d0a341da5049d1ede21 Cc: dnsext@ietf.org Subject: Re: [dnsext] does making names the same NEED protocol changes at all? X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 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, 25 Feb 2011 17:42:39 -0000 --0016e6d96d0a341da5049d1ede21 Content-Type: text/plain; charset=ISO-8859-1 Requiring slaves to be signers is a major change to the security model. In the current architecture it is sufficient to have online keys at a hidden master. The hidden master can be placed behind a firewall that rejects inbound requests. In the proposed architecture every DNS server has to have signing capability. It is not possible to prep the zone at the hidden master and then push the data out. The keys are not only online, they are reacting to queries prepared by potential attackers. >From a risk analysis point of view these changes are very significant indeed. On Fri, Feb 25, 2011 at 12:09 PM, Tony Finch wrote: > On Fri, 25 Feb 2011, Phillip Hallam-Baker wrote: > > > I suspect that the point of these requirements is precisely the fact that > > they cannot be met within the current architecture. > > A lot of the argument is because we aren't sure that that is true. Can the > requirements be met with improved provisioning technology and no protocol > changes? > > > I am seeing people rushing to change the security model of DNSSEC to > support > > this requirement, but I doubt that is going to be sufficient. > > Online signing is not a change to the DNSSEC security model. > > Tony. > -- > f.anthony.n.finch http://dotat.at/ > Forties, Cromarty, Forth: Southwest 5 to 7 veering northwest 4 or 5. > Moderate > or rough. Occasional rain. Moderate or good, occasionally poor. > -- Website: http://hallambaker.com/ --0016e6d96d0a341da5049d1ede21 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Requiring slaves to be signers is a major change to the security model.
In the current architecture it is sufficient to have online= keys at a hidden master. The hidden master can be placed behind a firewall= that rejects inbound requests.

In the proposed architecture every DNS server has to ha= ve signing capability. It is not possible to prep the zone at the hidden ma= ster and then push the data out. The keys are not only online, they are rea= cting to queries prepared by potential attackers.


From a risk analysis point of view these= changes are very significant indeed.=A0


On Fri, Feb 25, 2011 at 12:09 PM, Tony Finch &= lt;dot@dotat.at> wrote:
On Fri, 25 Feb 2011, Phil= lip Hallam-Baker wrote:

> I suspect that the point of these requirements is precisely the fact t= hat
> they cannot be met within the current architecture.

A lot of the argument is because we aren't sure that that is true= . Can the
requirements be met with improved provisioning technology and no protocol changes?

> I am seeing people rushing to change the security model of DNSSEC to s= upport
> this requirement, but I doubt that is going to be sufficient.

Online signing is not a change to the DNSSEC security model.

Tony.
--
f.anthony.n.finch =A0<dot@dotat.at&g= t; =A0http://dotat.at/ Forties, Cromarty, Forth: Southwest 5 to 7 veering northwest 4 or 5. Modera= te
or rough. Occasional rain. Moderate or good, occasionally poor.



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

--0016e6d96d0a341da5049d1ede21-- From ajs@shinkuro.com Fri Feb 25 09:45:38 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 875043A69F4 for ; Fri, 25 Feb 2011 09:45:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.584 X-Spam-Level: X-Spam-Status: No, score=-102.584 tagged_above=-999 required=5 tests=[AWL=0.015, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ccSb9MQXPLKO for ; Fri, 25 Feb 2011 09:45:37 -0800 (PST) Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by core3.amsl.com (Postfix) with ESMTP id DCBD83A6814 for ; Fri, 25 Feb 2011 09:45:32 -0800 (PST) Received: from crankycanuck.ca (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 396741ECB408 for ; Fri, 25 Feb 2011 17:46:25 +0000 (UTC) Date: Fri, 25 Feb 2011 12:46:23 -0500 From: Andrew Sullivan To: dnsext@ietf.org Message-ID: <20110225174623.GP74938@shinkuro.com> References: <8657EF4A-A08D-46E5-8917-553AE377CAD8@ICSI.Berkeley.EDU> <39EBBA76-22F1-4935-9300-B0078B229793@ICSI.Berkeley.EDU> <5A100E65-FB09-4556-AA5A-BF9FE0468DDA@ICSI.Berkeley.EDU> <6AD400292B2C771C7FE70E8F@Ximines.local> <20110225143043.GB74938@shinkuro.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.18 (2008-05-17) Subject: Re: [dnsext] does making names the same NEED protocol changes at all? X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 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, 25 Feb 2011 17:45:38 -0000 On Fri, Feb 25, 2011 at 12:43:29PM -0500, Phillip Hallam-Baker wrote: > Requiring slaves to be signers is a major change to the security model. Depending on how you implement this, it might be. But anyway, this is why we are doing a requirements analysis _before_ we start planning how to solve these problems, since it isn't obvious at least to me that what you describe above is a requirement in any case. A -- Andrew Sullivan ajs@shinkuro.com Shinkuro, Inc. From hallam@gmail.com Fri Feb 25 09:57:14 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7567A3A67F2 for ; Fri, 25 Feb 2011 09:57:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.568 X-Spam-Level: X-Spam-Status: No, score=-3.568 tagged_above=-999 required=5 tests=[AWL=0.030, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3MMOUr2VA9ek for ; Fri, 25 Feb 2011 09:57:13 -0800 (PST) Received: from mail-bw0-f44.google.com (mail-bw0-f44.google.com [209.85.214.44]) by core3.amsl.com (Postfix) with ESMTP id 0F4A33A67ED for ; Fri, 25 Feb 2011 09:57:12 -0800 (PST) Received: by bwz13 with SMTP id 13so2536974bwz.31 for ; Fri, 25 Feb 2011 09:58:05 -0800 (PST) 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=NUaq4hzCHTIyJTtvfL/HOXp3/e+0KJzWdkO9NyEIYig=; b=PNV8ZjuU50Sh/EnoShBGswvMB+9MtHdZZNpMABv1azkz8dhpwtuyn6P2pesXgig742 G17UoRHt91PlRtNj90INMSSEMzmudiO2Tg7ElYPjtFeaf/YzOGUCmanuLwKSjqS/6zBc n0Kg5qPQB5dv8Om6N199znlEKI0Zz9kMW6lU4= 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=QncwnOUJGFXoPqMXHM07I5IcPyx3B71ViWcw+gPSAFVjsJ2SSFOvrUMz2BUYO56LMO 9dq0q9Cj3Z6IO5ojWHyM2QSAvT2F7lHvZj4a37ju/Jy0ZSMu/1fznLeZE57yISbPHisU UPPE1VgrPHcurO+UjBSe9YuN3OHQmk2VKTrf0= MIME-Version: 1.0 Received: by 10.204.100.82 with SMTP id x18mr2308108bkn.20.1298656684635; Fri, 25 Feb 2011 09:58:04 -0800 (PST) Received: by 10.204.14.139 with HTTP; Fri, 25 Feb 2011 09:58:04 -0800 (PST) In-Reply-To: <20110225174623.GP74938@shinkuro.com> References: <8657EF4A-A08D-46E5-8917-553AE377CAD8@ICSI.Berkeley.EDU> <39EBBA76-22F1-4935-9300-B0078B229793@ICSI.Berkeley.EDU> <5A100E65-FB09-4556-AA5A-BF9FE0468DDA@ICSI.Berkeley.EDU> <6AD400292B2C771C7FE70E8F@Ximines.local> <20110225143043.GB74938@shinkuro.com> <20110225174623.GP74938@shinkuro.com> Date: Fri, 25 Feb 2011 12:58:04 -0500 Message-ID: From: Phillip Hallam-Baker To: Andrew Sullivan Content-Type: multipart/alternative; boundary=001485f773785f74d8049d1f1281 Cc: dnsext@ietf.org Subject: Re: [dnsext] does making names the same NEED protocol changes at all? X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 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, 25 Feb 2011 17:57:14 -0000 --001485f773785f74d8049d1f1281 Content-Type: text/plain; charset=ISO-8859-1 On Fri, Feb 25, 2011 at 12:46 PM, Andrew Sullivan wrote: > On Fri, Feb 25, 2011 at 12:43:29PM -0500, Phillip Hallam-Baker wrote: > > Requiring slaves to be signers is a major change to the security model. > > Depending on how you implement this, it might be. But anyway, this is > why we are doing a requirements analysis _before_ we start planning > how to solve these problems, since it isn't obvious at least to me > that what you describe above is a requirement in any case. True, but what I was originally complaining about was the rush to put this on the table in the first place and then I was reacting to the statements to the effect that this is no big deal. As a provider of DNS services I think that we have to have a very clear requirement that any proposed solution not impact the deployments of DNSSEC currently taking place. Requiring servers be capable of signing inline would represent a major architectural change. It would have a major impact on the cost of deployment. At the moment I can put a DNS slave pretty much anywhere. If I need more capacity I can simply rent it as required at commodity rates. If every slave has to be a signer then I either have to engage in some very expensive engineering effort or I have to locate every slave in a Tier 6 secure facility. -- Website: http://hallambaker.com/ --001485f773785f74d8049d1f1281 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Fri, Feb 25, 2011 at 12:46 PM, Andrew= Sullivan <ajs@shi= nkuro.com> wrote:
On Fri, Feb 25, 2011 at 12:43:29PM -0500, Phillip Hallam-= Baker wrote:
> Requiring slaves to be signers is a major change to the security model= .

Depending on how you implement this, it might be. =A0But anyway, this= is
why we are doing a requirements analysis _before_ we start planning
how to solve these problems, since it isn't obvious at least to me
that what you describe above is a requirement in any case.

True, but what I was originally complaining about was the r= ush to put this on the table in the first place and then I was reacting to = the statements to the effect that this is no big deal.

As a provider of DNS services I think that we have to h= ave a very clear requirement that any proposed solution not impact the depl= oyments of DNSSEC currently taking place. Requiring servers be capable of s= igning inline would represent a major architectural change. It would have a= major impact on the cost of deployment.


At the moment I can put a DNS slave pret= ty much anywhere. If I need more capacity I can simply rent it as required = at commodity rates.
=A0
If every slave has to be a sign= er then I either have to engage in some very expensive engineering effort o= r I have to locate every slave in a Tier 6 secure facility.=A0

--
Website: ht= tp://hallambaker.com/

--001485f773785f74d8049d1f1281-- From fanf2@hermes.cam.ac.uk Fri Feb 25 10:05:37 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B81AD3A69F8 for ; Fri, 25 Feb 2011 10:05:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.456 X-Spam-Level: X-Spam-Status: No, score=-6.456 tagged_above=-999 required=5 tests=[AWL=0.143, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c+xjDghbjh7H for ; Fri, 25 Feb 2011 10:05:36 -0800 (PST) Received: from ppsw-51.csi.cam.ac.uk (ppsw-51.csi.cam.ac.uk [131.111.8.151]) by core3.amsl.com (Postfix) with ESMTP id A46843A67F4 for ; Fri, 25 Feb 2011 10:05:36 -0800 (PST) X-Cam-AntiVirus: no malware found X-Cam-SpamDetails: not scanned X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ Received: from hermes-1.csi.cam.ac.uk ([131.111.8.51]:47167) by ppsw-51.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.158]:25) with esmtpa (EXTERNAL:fanf2) id 1Pt23h-0001mC-WZ (Exim 4.72) for dnsext@ietf.org (return-path ); Fri, 25 Feb 2011 18:06:29 +0000 Received: from fanf2 (helo=localhost) by hermes-1.csi.cam.ac.uk (hermes.cam.ac.uk) with local-esmtp id 1Pt23h-0001u6-2U (Exim 4.67) for dnsext@ietf.org (return-path ); Fri, 25 Feb 2011 18:06:29 +0000 Date: Fri, 25 Feb 2011 18:06:29 +0000 From: Tony Finch X-X-Sender: fanf2@hermes-1.csi.cam.ac.uk To: dnsext@ietf.org In-Reply-To: <20110225174623.GP74938@shinkuro.com> Message-ID: References: <8657EF4A-A08D-46E5-8917-553AE377CAD8@ICSI.Berkeley.EDU> <39EBBA76-22F1-4935-9300-B0078B229793@ICSI.Berkeley.EDU> <5A100E65-FB09-4556-AA5A-BF9FE0468DDA@ICSI.Berkeley.EDU> <6AD400292B2C771C7FE70E8F@Ximines.local> <20110225143043.GB74938@shinkuro.com> <20110225174623.GP74938@shinkuro.com> User-Agent: Alpine 2.00 (LSU 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: Tony Finch Subject: Re: [dnsext] does making names the same NEED protocol changes at all? X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 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, 25 Feb 2011 18:05:37 -0000 On Fri, 25 Feb 2011, Andrew Sullivan wrote: > On Fri, Feb 25, 2011 at 12:43:29PM -0500, Phillip Hallam-Baker wrote: > > Requiring slaves to be signers is a major change to the security model. > > Depending on how you implement this, it might be. I don't think any of the proposals actually require online signing, so Phill is arguing against a straw man. So far as I can tell the main question is, what is the question and is BNAME the answer? Tony. -- f.anthony.n.finch http://dotat.at/ Thames, Dover, Wight, Portland, Plymouth, North Biscay: Southwesterly veering westerly, 4 or 5 increasing 5 to 7, perhaps gale 8 later. Moderate or rough, occasionally very rough in Plymouth and Biscay. Occasional rain, fog patches. Moderate, occasionally very poor. From mgraff@isc.org Fri Feb 25 10:12:18 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B0B643A67F4 for ; Fri, 25 Feb 2011 10:12:18 -0800 (PST) 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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lYl+qHxO5xyk for ; Fri, 25 Feb 2011 10:12:17 -0800 (PST) Received: from mx.ams1.isc.org (mx.ams1.isc.org [IPv6:2001:500:60::65]) by core3.amsl.com (Postfix) with ESMTP id 7BA6B3A67F2 for ; Fri, 25 Feb 2011 10:12:17 -0800 (PST) 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 B6E6D5F98B6 for ; Fri, 25 Feb 2011 18:12:55 +0000 (UTC) (envelope-from mgraff@isc.org) Received: from bigmac.home.flame.org (unknown [IPv6:2001:470:b8d7:13:21d:4fff:fe47:6790]) (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 99F89216C33 for ; Fri, 25 Feb 2011 18:12:53 +0000 (UTC) (envelope-from mgraff@isc.org) Message-ID: <4D67F124.7080801@isc.org> Date: Fri, 25 Feb 2011 12:12:52 -0600 From: Michael Graff User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.13) Gecko/20101207 Lightning/1.0b2 Thunderbird/3.1.7 MIME-Version: 1.0 To: dnsext@ietf.org References: <8657EF4A-A08D-46E5-8917-553AE377CAD8@ICSI.Berkeley.EDU> <39EBBA76-22F1-4935-9300-B0078B229793@ICSI.Berkeley.EDU> <5A100E65-FB09-4556-AA5A-BF9FE0468DDA@ICSI.Berkeley.EDU> <6AD400292B2C771C7FE70E8F@Ximines.local> <20110225143043.GB74938@shinkuro.com> <20110225174623.GP74938@shinkuro.com> In-Reply-To: X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [dnsext] does making names the same NEED protocol changes at all? X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 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, 25 Feb 2011 18:12:18 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 2011-02-25 12:06 PM, Tony Finch wrote: > So far as I can tell the main question is, what is the question and is > BNAME the answer? I'd ask this differently. "Is BNAME the only answer?" or perhaps "the BEST answer?" No matter how I travel down the path, from reading all the email to date, I still maintain in my own thoughts that BNAME is one possible solution, but that the cost of pushing a protocol change down to the clients is painful in light of DNSSEC deployment and the breakage that BNAME will create there. The solution I've heard is that we roll the DNSSEC algorithm numbers. This is a non-scalable solution and means we have other, bigger issues to contend with. We can't continue to use DNSSEC algorithm numbers as a DNS version number like we did to some extent for NSEC3. No matter how I approach this problem, I see the solution in my mind. This solution is that no protocol changes are needed for this, and that it all comes down to an improvement in the configuration and publication of delegation points, and zone file contents. - --Michael -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk1n8SQACgkQLdqv0r6eD6aYygCdHuV06JOVx1zrckqDSGKEZ8Ok OvsAoItxcAzwAQc1VZxujFb0F2ElmBRh =aQ99 -----END PGP SIGNATURE----- From nweaver@icsi.berkeley.edu Fri Feb 25 10:33:33 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 387913A67D1 for ; Fri, 25 Feb 2011 10:33:33 -0800 (PST) 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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XBQe3qyEGXrE for ; Fri, 25 Feb 2011 10:33:32 -0800 (PST) Received: from taffy.ICSI.Berkeley.EDU (taffy.ICSI.Berkeley.EDU [192.150.187.26]) by core3.amsl.com (Postfix) with ESMTP id 543383A67B0 for ; Fri, 25 Feb 2011 10:33:32 -0800 (PST) Received: from [192.168.5.170] (unknown [64.134.235.223]) (Authenticated sender: nweaver) by taffy.ICSI.Berkeley.EDU (Postfix) with ESMTP id 47F8E36A017; Fri, 25 Feb 2011 10:34:25 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Nicholas Weaver In-Reply-To: Date: Fri, 25 Feb 2011 10:34:22 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4CC95816-8225-4CAE-897F-3F13F965BCEE@ICSI.Berkeley.EDU> <8657EF4A-A08D-46E5-8917-553AE377CAD8@ICSI.Berkeley.EDU> <39EBBA76-22F1-4935-9300-B0078B229793@ICSI.Berkeley.EDU> <5A100E65-FB09-4556-AA5A-BF9FE0468DDA@ICSI.Berkeley.EDU> <6AD400292B2C771C7FE70E8F@Ximines.local> <20110225143043.GB74938@shinkuro.com> To: Phillip Hallam-Baker X-Mailer: Apple Mail (2.1082) Cc: dnsext@ietf.org Subject: Re: [dnsext] does making names the same NEED protocol changes at all? X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 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, 25 Feb 2011 18:33:33 -0000 On Feb 25, 2011, at 9:43 AM, Phillip Hallam-Baker wrote: > Requiring slaves to be signers is a major change to the security = model. There is NOTHING which prevents such slaves from forwarding the = dynamically signed requests to the master and caching the results and = forwarding it on. From ajs@shinkuro.com Fri Feb 25 10:47:50 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A7A573A677E for ; Fri, 25 Feb 2011 10:47:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.585 X-Spam-Level: X-Spam-Status: No, score=-102.585 tagged_above=-999 required=5 tests=[AWL=0.014, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TQaPhseVXPSm for ; Fri, 25 Feb 2011 10:47:49 -0800 (PST) Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by core3.amsl.com (Postfix) with ESMTP id 79E493A66B4 for ; Fri, 25 Feb 2011 10:47:48 -0800 (PST) Received: from crankycanuck.ca (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 C56B71ECB408 for ; Fri, 25 Feb 2011 18:48:40 +0000 (UTC) Date: Fri, 25 Feb 2011 13:48:39 -0500 From: Andrew Sullivan To: dnsext@ietf.org Message-ID: <20110225184838.GS74938@shinkuro.com> References: <39EBBA76-22F1-4935-9300-B0078B229793@ICSI.Berkeley.EDU> <5A100E65-FB09-4556-AA5A-BF9FE0468DDA@ICSI.Berkeley.EDU> <6AD400292B2C771C7FE70E8F@Ximines.local> <20110225143043.GB74938@shinkuro.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.18 (2008-05-17) Subject: Re: [dnsext] does making names the same NEED protocol changes at all? X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 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, 25 Feb 2011 18:47:50 -0000 No hat On Fri, Feb 25, 2011 at 10:34:22AM -0800, Nicholas Weaver wrote: > > There is NOTHING which prevents such slaves from forwarding the dynamically signed requests to the master and caching the results and forwarding it on. Except, of course, that it would be insane, since that would turn the master into a potential single point of failure for any lookup in the zone. A significant reason for the success of the DNS is its loose consistency and resulting resilience to failure. Any scheme which replaces that with a single server is doomed to failure. A -- Andrew Sullivan ajs@shinkuro.com Shinkuro, Inc. From nweaver@icsi.berkeley.edu Fri Feb 25 10:50:59 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E57483A69FB for ; Fri, 25 Feb 2011 10:50:58 -0800 (PST) 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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TexxcNk55Gan for ; Fri, 25 Feb 2011 10:50:58 -0800 (PST) Received: from taffy.ICSI.Berkeley.EDU (taffy.ICSI.Berkeley.EDU [192.150.187.26]) by core3.amsl.com (Postfix) with ESMTP id 2FC553A67C1 for ; Fri, 25 Feb 2011 10:50:58 -0800 (PST) Received: from [192.168.5.170] (unknown [64.134.235.223]) (Authenticated sender: nweaver) by taffy.ICSI.Berkeley.EDU (Postfix) with ESMTP id 1F40336A017; Fri, 25 Feb 2011 10:51:51 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Nicholas Weaver In-Reply-To: <20110225184838.GS74938@shinkuro.com> Date: Fri, 25 Feb 2011 10:51:48 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: <39EBBA76-22F1-4935-9300-B0078B229793@ICSI.Berkeley.EDU> <5A100E65-FB09-4556-AA5A-BF9FE0468DDA@ICSI.Berkeley.EDU> <6AD400292B2C771C7FE70E8F@Ximines.local> <20110225143043.GB74938@shinkuro.com> <20110225184838.GS74938@shinkuro.com> To: Andrew Sullivan X-Mailer: Apple Mail (2.1082) Cc: dnsext@ietf.org Subject: Re: [dnsext] does making names the same NEED protocol changes at all? X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 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, 25 Feb 2011 18:50:59 -0000 On Feb 25, 2011, at 10:48 AM, Andrew Sullivan wrote: > No hat >=20 > On Fri, Feb 25, 2011 at 10:34:22AM -0800, Nicholas Weaver wrote: >>=20 >> There is NOTHING which prevents such slaves from forwarding the = dynamically signed requests to the master and caching the results and = forwarding it on. >=20 > Except, of course, that it would be insane, since that would turn the > master into a potential single point of failure for any lookup in the > zone. A significant reason for the success of the DNS is its loose > consistency and resulting resilience to failure. Any scheme which > replaces that with a single server is doomed to failure. It is ONLY a point of failure for NeW MiXED CasINGs which appear. Old = ones remain cached. And unlike other schemes, does NOT require any changes to resolvers. = Any proposal which requires changes to resolvers rather than just = authorities which want to support non-ascii mixed case is IMO, a = non-starter. From brian.peter.dickson@gmail.com Fri Feb 25 11:01:23 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 305E93A67F8 for ; Fri, 25 Feb 2011 11:01:23 -0800 (PST) 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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2CwDpguTiAX3 for ; Fri, 25 Feb 2011 11:01:22 -0800 (PST) Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by core3.amsl.com (Postfix) with ESMTP id E95493A66B4 for ; Fri, 25 Feb 2011 11:01:21 -0800 (PST) Received: by fxm15 with SMTP id 15so2025157fxm.31 for ; Fri, 25 Feb 2011 11:02:14 -0800 (PST) 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=MjMJArKjm8d9XjrIJIkTZvOcetgJ3QfPWs8vWsgkXJc=; b=UU/sFCqCmNIN3si9s0C7xU6L3PkTqz8WdgeKTy9cLQ1K0M5dBuLvAjN6bDVdjA1FeB PZ8ZVEo9e+mmnkT90aG32X1aYrvkyFptKT6ewPk9FX0D5mBQfyHb+dWPp9ubGtAlkh2L 8WUTE2I42uaegwiw+9SwNJ2jJ1oZLi9XyrnTc= 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=g00NiAbOjlzqcwkqtZ4Tbv+U/ON6kmKfaLNzuc/mhBq0m9dt0Mr9uCGKKwx9mPE7QP jnfFPE+4n3gFyJVSMVWH9hG4mBfQtFEcogv0JLSJiuq1/p1slNetWi0NKzmH5YAB2Bzr MPjtDhpkeH7GpqiMzeoia352BZUlvnUpMHlUw= MIME-Version: 1.0 Received: by 10.223.96.66 with SMTP id g2mr3114174fan.61.1298660534300; Fri, 25 Feb 2011 11:02:14 -0800 (PST) Received: by 10.223.107.132 with HTTP; Fri, 25 Feb 2011 11:02:14 -0800 (PST) In-Reply-To: References: <39EBBA76-22F1-4935-9300-B0078B229793@ICSI.Berkeley.EDU> <5A100E65-FB09-4556-AA5A-BF9FE0468DDA@ICSI.Berkeley.EDU> <6AD400292B2C771C7FE70E8F@Ximines.local> <20110225143043.GB74938@shinkuro.com> <20110225184838.GS74938@shinkuro.com> Date: Fri, 25 Feb 2011 15:02:14 -0400 Message-ID: From: Brian Dickson To: Nicholas Weaver Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: dnsext@ietf.org Subject: Re: [dnsext] does making names the same NEED protocol changes at all? X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 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, 25 Feb 2011 19:01:23 -0000 On Fri, Feb 25, 2011 at 2:51 PM, Nicholas Weaver wrote: > > On Feb 25, 2011, at 10:48 AM, Andrew Sullivan wrote: > >> No hat >> >> On Fri, Feb 25, 2011 at 10:34:22AM -0800, Nicholas Weaver wrote: >>> >>> There is NOTHING which prevents such slaves from forwarding the dynamic= ally signed requests to the master and caching the results and forwarding i= t on. >> >> Except, of course, that it would be insane, since that would turn the >> master into a potential single point of failure for any lookup in the >> zone. =A0A significant reason for the success of the DNS is its loose >> consistency and resulting resilience to failure. =A0Any scheme which >> replaces that with a single server is doomed to failure. > > It is ONLY a point of failure for NeW MiXED CasINGs which appear. =A0Old = ones remain cached. > > And unlike other schemes, does NOT require any changes to resolvers. =A0A= ny proposal which requires changes to resolvers rather than just authoritie= s which want to support non-ascii mixed case is IMO, a non-starter. I think it is useful to be precise in scoping exactly what changes we're talking about. Specifically, when it comes to DNSSEC and signatures, there are several individual cases, whose deployed implementation may or may not require changes, depending on the specific proposal(s): - validating iterative resolvers - non-validating, DNSSEC-aware iterative resolvers (is there such a thing?) - DNSSEC-unaware iterative resolvers - validating stub resolvers - non-validating, DNSSEC-aware stub resolvers (CD=3D1) (who talk to validating iterative resolvers) - DNSSEC-unaware resolvers (who may be talking to any of the above sorts of iterative resolvers) The tails on each of these is of (drastically, IMHO) different lengths. And, the behavior in the cases of unmodified instances of the above, in the face of modified authority server answers (new RRtypes, new DNSSEC RRTYPEs, new DNSSEC validation logic), may differ too. (Bogus vs Insecure is a huge difference.) Let's hold off on passing judgement until: - the requirements doc is cleaned up and accepted (or not) - proposals are available for evaluation, and/or have been read and commented on. (ObContent - my somewhat stale DS2 draft is on-topic, I hope, and could use some reviewers and feedback, even if it is not yet time to propose adopting it for WG consideration. Applies only to validating resolvers (of both kinds) and authority servers who want to use it, and is benign/fail-safe-ish, with "insecure" rather than "bogus" when the validator does not understand it.) Brian From ajs@shinkuro.com Fri Feb 25 11:20:09 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3B8DF3A67E2 for ; Fri, 25 Feb 2011 11:20:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.585 X-Spam-Level: X-Spam-Status: No, score=-103.585 tagged_above=-999 required=5 tests=[AWL=1.014, BAYES_00=-2.599, GB_I_LETTER=-2, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nDwsJ-5Rys+g for ; Fri, 25 Feb 2011 11:20:08 -0800 (PST) Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by core3.amsl.com (Postfix) with ESMTP id 42BAF3A6840 for ; Fri, 25 Feb 2011 11:20:08 -0800 (PST) Received: from crankycanuck.ca (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 CC0741ECB408 for ; Fri, 25 Feb 2011 19:21:00 +0000 (UTC) Date: Fri, 25 Feb 2011 14:20:59 -0500 From: Andrew Sullivan To: dnsext@ietf.org Message-ID: <20110225192058.GU74938@shinkuro.com> References: <5A100E65-FB09-4556-AA5A-BF9FE0468DDA@ICSI.Berkeley.EDU> <6AD400292B2C771C7FE70E8F@Ximines.local> <20110225143043.GB74938@shinkuro.com> <20110225184838.GS74938@shinkuro.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.18 (2008-05-17) Subject: Re: [dnsext] does making names the same NEED protocol changes at all? X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 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, 25 Feb 2011 19:20:09 -0000 No hat. On Fri, Feb 25, 2011 at 10:51:48AM -0800, Nicholas Weaver wrote: > It is ONLY a point of failure for NeW MiXED CasINGs which appear. Old ones remain cached. > I'm not exactly sure how you decided that mixed case was a problem we were going to solve anyway, but let me disabuse you of this. In the interests of allowing people to think about the issues, I haven't shut down the case discussion, but maybe I should have. It's not something we actually need to solve. First, remember that we're actually trying to solve problems in the DNS generally, and not to solve particular linguistic issues, since we don't have the expertise for that. (Indeed, that we're wasting time exploring this rathole is evidence of it, since a large number of the "variant" cases for which we might need a solution don't have anything to do with case. Chinese, to pick the obvious example, isn't even alphabetic.) Now, there simply is no problem in English: mixed case already matches. The rest of the possible target cases occur under IDNA. And in IDNA, there is no problem of case. IDNA2003 maps all upper case to lower case, and does the lookup. Under IDNA2008, upper case is simply DISALLOWED, so it never gets looked up. It is presumed (but not actually part of the protocol) that applications will do locale-appropriate case conversion prior to lookup. (Note that there are important subtleties involved here that I am quickly waving away as detail, but which matter up in the application layer. For instance, downcasing, upcasing, and normalization for comparison might yield different and, to anglophones, surprising results.) There are problems which happen to have their expression in the results of case conversion. In Greek, there is one GREEK CAPITAL LETTER SIGMA, but GREEK SMALL LETTER FINAL SIGMA and GREEK SMALL LETTER SIGMA. In upper case a sigma in the final position will be the identical Unicode code point to an upper case medial form sigma; but when they are downcased, one of those should become one code point and the other should become another code point. This _is_ a problem. People might try to look up a label, [GREEKLETTERS][GREEK CAPITAL LETTER SIGMA]. Now you need to have [greekletters][GREEK SMALL LETTER FINAL SIGMA] and [greekletters][GREEK SMALL LETTER SIGMA] mapped to one another transparently, because it is unpredictable what will actually be the U-label that gets converted to the A-label before it gets looked up when the application maps [GREEKLETTERS][GREEK CAPITAL LETTER SIGMA]. (Or rather, it might be. The applications might actually all do this correctly, for all anyone knows.) But as you can see, we can discuss all of that without recourse to the specifics of the language, since the actual issue is that a zone administrator knows a label to label mapping of the items. Clearer now? A -- Andrew Sullivan ajs@shinkuro.com Shinkuro, Inc. From Ed.Lewis@neustar.biz Fri Feb 25 11:40:32 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EF6663A6831 for ; Fri, 25 Feb 2011 11:40:31 -0800 (PST) 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=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AwnGUE0mqslU for ; Fri, 25 Feb 2011 11:40:31 -0800 (PST) Received: from stora.ogud.com (stora.ogud.com [66.92.146.20]) by core3.amsl.com (Postfix) with ESMTP id 099DE3A6A16 for ; Fri, 25 Feb 2011 11:40:30 -0800 (PST) Received: from Work-Laptop-2.local (gatt.md.ogud.com [10.20.30.6]) by stora.ogud.com (8.14.4/8.14.4) with ESMTP id p1PJfHQb056302; Fri, 25 Feb 2011 14:41:18 -0500 (EST) (envelope-from Ed.Lewis@neustar.biz) Received: from [10.31.200.114] by Work-Laptop-2.local (PGP Universal service); Fri, 25 Feb 2011 14:41:23 -0500 X-PGP-Universal: processed; by Work-Laptop-2.local on Fri, 25 Feb 2011 14:41:23 -0500 Mime-Version: 1.0 Message-Id: Date: Fri, 25 Feb 2011 14:41:15 -0500 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: [dnsext] Fwd: RFC 2308 & RFC 4035 X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 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, 25 Feb 2011 19:40:32 -0000 I have a question referring to two sections in two RFCs, prompted by the resimprove draft. RFC 4035: 5.4. Authenticated Denial of Existence ... o If the requested RR name matches the owner name of an authenticated NSEC RR, then the NSEC RR's type bit map field lists all RR types present at that owner name, and a resolver can prove that the requested RR type does not exist by checking for the RR type in the bit map. ... And in RFC 2308: 5 - Caching Negative Answers ... A negative answer that resulted from a no data error (NODATA) should be cached such that it can be retrieved and returned in response to another query for the same that resulted in the cached negative response. Let's aay this happens: at 10am a cache receives a response to a query for example.tld./IN/A that says example.tld. 3600 NSEC3 a.example.tld. SOA NS DNSKEY RRSIG NSEC at 10:15am the cache gets a query for example.tld./IN/AAAA. Should the cache rely with a NoData response or should it try to query for the AAAA? If the answer to the previous is "it should rely on the cached NSEC:" What if I said that at 10:10am, the authority was updated with a new zone that had an AAAA RRset at the apex? -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis NeuStar You can leave a voice message at +1-571-434-5468 Me to infant son: "Waah! Waah! Is that all you can say? Waah?" Son: "Waah!" From george.barwood@blueyonder.co.uk Fri Feb 25 12:07:03 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2074B3A67FB for ; Fri, 25 Feb 2011 12:07:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.745 X-Spam-Level: X-Spam-Status: No, score=0.745 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, HELO_EQ_BLUEYON=1.4, MIME_BASE64_BLANKS=0.041, MIME_BASE64_TEXT=1.753] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L-73frec8K3r for ; Fri, 25 Feb 2011 12:07:02 -0800 (PST) Received: from smtp-out5.blueyonder.co.uk (smtp-out5.blueyonder.co.uk [195.188.213.8]) by core3.amsl.com (Postfix) with ESMTP id 141853A6A1E for ; Fri, 25 Feb 2011 12:07:01 -0800 (PST) Received: from [172.23.170.144] (helo=anti-virus03-07) by smtp-out5.blueyonder.co.uk with smtp (Exim 4.52) id 1Pt3xB-0007B2-Vm; Fri, 25 Feb 2011 20:07:53 +0000 Received: from [92.238.99.235] (helo=GeorgeLaptop) by asmtp-out3.blueyonder.co.uk with smtp (Exim 4.72) (envelope-from ) id 1Pt3wy-00060a-Cu; Fri, 25 Feb 2011 20:07:40 +0000 Message-ID: <976A5FBE345E43FDA7A17D7148B96189@local> From: "George Barwood" To: , "Edward Lewis" References: Date: Fri, 25 Feb 2011 20:08:24 -0000 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.5994 Cc: ed.lewis@neustar.biz Subject: Re: [dnsext] Fwd: RFC 2308 & RFC 4035 X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 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, 25 Feb 2011 20:07:03 -0000 DQotLS0tLSBPcmlnaW5hbCBNZXNzYWdlIC0tLS0tIA0KRnJvbTogIkVkd2FyZCBMZXdpcyIgPEVk Lkxld2lzQG5ldXN0YXIuYml6Pg0KVG86IDxkbnNleHRAaWV0Zi5vcmc+DQpDYzogPGVkLmxld2lz QG5ldXN0YXIuYml6Pg0KU2VudDogRnJpZGF5LCBGZWJydWFyeSAyNSwgMjAxMSA3OjQxIFBNDQpT dWJqZWN0OiBbZG5zZXh0XSBGd2Q6IFJGQyAyMzA4ICYgUkZDIDQwMzUNCg0KDQo+SSBoYXZlIGEg cXVlc3Rpb24gcmVmZXJyaW5nIHRvIHR3byBzZWN0aW9ucyBpbiB0d28gUkZDcywgcHJvbXB0ZWQg YnkgDQo+IHRoZSByZXNpbXByb3ZlIGRyYWZ0Lg0KPiANCj4gUkZDIDQwMzU6DQo+IDUuNC4gIEF1 dGhlbnRpY2F0ZWQgRGVuaWFsIG9mIEV4aXN0ZW5jZQ0KPiAuLi4NCj4gICAgbyAgSWYgdGhlIHJl cXVlc3RlZCBSUiBuYW1lIG1hdGNoZXMgdGhlIG93bmVyIG5hbWUgb2YgYW4NCj4gICAgICAgYXV0 aGVudGljYXRlZCBOU0VDIFJSLCB0aGVuIHRoZSBOU0VDIFJSJ3MgdHlwZSBiaXQgbWFwIGZpZWxk IGxpc3RzDQo+ICAgICAgIGFsbCBSUiB0eXBlcyBwcmVzZW50IGF0IHRoYXQgb3duZXIgbmFtZSwg YW5kIGEgcmVzb2x2ZXIgY2FuIHByb3ZlDQo+ICAgICAgIHRoYXQgdGhlIHJlcXVlc3RlZCBSUiB0 eXBlIGRvZXMgbm90IGV4aXN0IGJ5IGNoZWNraW5nIGZvciB0aGUgUlINCj4gICAgICAgdHlwZSBp biB0aGUgYml0IG1hcC4gIC4uLg0KPiANCj4gQW5kIGluIFJGQyAyMzA4Og0KPiA1IC0gQ2FjaGlu ZyBOZWdhdGl2ZSBBbnN3ZXJzDQo+IC4uLg0KPiAgICBBIG5lZ2F0aXZlIGFuc3dlciB0aGF0IHJl c3VsdGVkIGZyb20gYSBubyBkYXRhIGVycm9yIChOT0RBVEEpIHNob3VsZA0KPiAgICBiZSBjYWNo ZWQgc3VjaCB0aGF0IGl0IGNhbiBiZSByZXRyaWV2ZWQgYW5kIHJldHVybmVkIGluIHJlc3BvbnNl IHRvDQo+ICAgIGFub3RoZXIgcXVlcnkgZm9yIHRoZSBzYW1lIDxRTkFNRSwgUVRZUEUsIFFDTEFT Uz4gdGhhdCByZXN1bHRlZCBpbg0KPiAgICB0aGUgY2FjaGVkIG5lZ2F0aXZlIHJlc3BvbnNlLg0K PiANCj4gTGV0J3MgYWF5IHRoaXMgaGFwcGVuczoNCj4gDQo+IGF0IDEwYW0gYSBjYWNoZSByZWNl aXZlcyBhIHJlc3BvbnNlIHRvIGEgcXVlcnkgZm9yIGV4YW1wbGUudGxkLi9JTi9BIHRoYXQgc2F5 cw0KPiANCj4gZXhhbXBsZS50bGQuICAgMzYwMCAgICBOU0VDMyAgIGEuZXhhbXBsZS50bGQuICBT T0EgTlMgRE5TS0VZIFJSU0lHIE5TRUMNCj4gDQo+IGF0IDEwOjE1YW0gdGhlIGNhY2hlIGdldHMg YSBxdWVyeSBmb3IgZXhhbXBsZS50bGQuL0lOL0FBQUEuDQo+IA0KPiBTaG91bGQgdGhlIGNhY2hl IHJlbHkgd2l0aCBhIE5vRGF0YSByZXNwb25zZSBvciBzaG91bGQgaXQgdHJ5IHRvIA0KPiBxdWVy eSBmb3IgdGhlIEFBQUE/DQo+IA0KPiBJZiB0aGUgYW5zd2VyIHRvIHRoZSBwcmV2aW91cyBpcyAi aXQgc2hvdWxkIHJlbHkgb24gdGhlIGNhY2hlZCBOU0VDOiIgDQo+IFdoYXQgaWYgSSBzYWlkIHRo YXQgYXQgMTA6MTBhbSwgdGhlIGF1dGhvcml0eSB3YXMgdXBkYXRlZCB3aXRoIGEgbmV3IA0KPiB6 b25lIHRoYXQgaGFkIGFuIEFBQUEgUlJzZXQgYXQgdGhlIGFwZXg/DQoNCkkgdGhpbmsgdGhpcyBp cyBhZGRyZXNzZWQgYnkNCg0KaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvcmZjNDAzNSNzZWN0 aW9uLTQuNQ0KDQo8PA0KICAgSW4gdGhlb3J5LCBhIHJlc29sdmVyIGNvdWxkIHVzZSB3aWxkY2Fy ZHMgb3IgTlNFQyBSUnMgdG8gZ2VuZXJhdGUNCiAgIHBvc2l0aXZlIGFuZCBuZWdhdGl2ZSByZXNw b25zZXMgKHJlc3BlY3RpdmVseSkgdW50aWwgdGhlIFRUTCBvcg0KICAgc2lnbmF0dXJlcyBvbiB0 aGUgcmVjb3JkcyBpbiBxdWVzdGlvbiBleHBpcmUuICBIb3dldmVyLCBpdCBzZWVtcw0KICAgcHJ1 ZGVudCBmb3IgcmVzb2x2ZXJzIHRvIGF2b2lkIGJsb2NraW5nIG5ldyBhdXRob3JpdGF0aXZlIGRh dGEgb3INCiAgIHN5bnRoZXNpemluZyBuZXcgZGF0YSBvbiB0aGVpciBvd24uICBSZXNvbHZlcnMg dGhhdCBmb2xsb3cgdGhpcw0KICAgcmVjb21tZW5kYXRpb24gd2lsbCBoYXZlIGEgbW9yZSBjb25z aXN0ZW50IHZpZXcgb2YgdGhlIG5hbWVzcGFjZS4NCj4+DQoNCkdlb3JnZQ0KDQoNCj4gLS0gDQo+ IC09LT0tPS09LT0tPS09LT0tPS09LT0tPS09LT0tPS09LT0tPS09LT0tPS09LT0tPS09LT0tPS09 LT0tPS09LT0tPS09LT0tPS09LQ0KPiBFZHdhcmQgTGV3aXMgICAgICAgICAgICAgDQo+IE5ldVN0 YXIgICAgICAgICAgICAgICAgICAgIFlvdSBjYW4gbGVhdmUgYSB2b2ljZSBtZXNzYWdlIGF0ICsx LTU3MS00MzQtNTQ2OA0KPiANCj4gTWUgdG8gaW5mYW50IHNvbjogIldhYWghIFdhYWghIElzIHRo YXQgYWxsIHlvdSBjYW4gc2F5PyAgV2FhaD8iDQo+IFNvbjogIldhYWghIg0KPiBfX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiBkbnNleHQgbWFpbGluZyBs aXN0DQo+IGRuc2V4dEBpZXRmLm9yZw0KPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xp c3RpbmZvL2Ruc2V4dA== From Ed.Lewis@neustar.biz Fri Feb 25 12:23:52 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D3B7A3A6A28 for ; Fri, 25 Feb 2011 12:23:52 -0800 (PST) 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=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9zRfdCsYqo99 for ; Fri, 25 Feb 2011 12:23:51 -0800 (PST) Received: from stora.ogud.com (stora.ogud.com [66.92.146.20]) by core3.amsl.com (Postfix) with ESMTP id 64B543A6A26 for ; Fri, 25 Feb 2011 12:23:51 -0800 (PST) Received: from Work-Laptop-2.local (gatt.md.ogud.com [10.20.30.6]) by stora.ogud.com (8.14.4/8.14.4) with ESMTP id p1PKOaPg056701; Fri, 25 Feb 2011 15:24:36 -0500 (EST) (envelope-from Ed.Lewis@neustar.biz) Received: from [10.31.200.114] by Work-Laptop-2.local (PGP Universal service); Fri, 25 Feb 2011 15:24:43 -0500 X-PGP-Universal: processed; by Work-Laptop-2.local on Fri, 25 Feb 2011 15:24:43 -0500 Mime-Version: 1.0 Message-Id: In-Reply-To: <976A5FBE345E43FDA7A17D7148B96189@local> References: <976A5FBE345E43FDA7A17D7148B96189@local> Date: Fri, 25 Feb 2011 15:24:33 -0500 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: Edward Lewis , dnsext@ietf.org Subject: Re: [dnsext] Fwd: RFC 2308 & RFC 4035 X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 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, 25 Feb 2011 20:23:52 -0000 At 20:08 +0000 2/25/11, George Barwood wrote: >I think this is addressed by > >http://tools.ietf.org/html/rfc4035#section-4.5 > ><< > In theory, a resolver could use wildcards or NSEC RRs to generate > positive and negative responses (respectively) until the TTL or > signatures on the records in question expire. However, it seems > prudent for resolvers to avoid blocking new authoritative data or > synthesizing new data on their own. Resolvers that follow this > recommendation will have a more consistent view of the namespace. Good observation. Question to those who've written caches, what strategy seemed best. It's passages like the quoted that should be firmed up when and if DNSSEC is ever a Draft Standard/Full Standard. And getting back to the resimprove draft, I'd wager that a BCP shouldn't disagree with a Standards Track document. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis NeuStar You can leave a voice message at +1-571-434-5468 Me to infant son: "Waah! Waah! Is that all you can say? Waah?" Son: "Waah!" From brian.peter.dickson@gmail.com Fri Feb 25 12:47:53 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2A2BB3A6A3B for ; Fri, 25 Feb 2011 12:47:53 -0800 (PST) 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, J_CHICKENPOX_56=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n-+7rwDW1S2s for ; Fri, 25 Feb 2011 12:47:52 -0800 (PST) Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by core3.amsl.com (Postfix) with ESMTP id 044763A6830 for ; Fri, 25 Feb 2011 12:47:51 -0800 (PST) Received: by fxm15 with SMTP id 15so2128665fxm.31 for ; Fri, 25 Feb 2011 12:48:44 -0800 (PST) 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=I+DGuVYQ9gzMhb7vKgAHPz1tnFQU762u4mOTsmUGZZ0=; b=dur4x120M0JrmThtapni/eOaD0+3vzabR1hbNLRDYQvN45q4MQHtkuP0MithFwrcDP wetJzhPvCOmGCGML6zlz0fk0jya/clBkLcH5E4uEUQ4l/dlYZceHgvo7FjYVdBb/m2Zn xL5ytpvNu9FfUB/3NQT02CNC5qYCPKdpi9kNY= 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=hKu1xicJY0jiMzpkEx/mNWQdinvOIM1I48VgauFCQygEe79Q4iLrrZV1DFcoQnj11O ETEv5OArVlXi1g+4GTAef+jzTV922wMu+2dNG6tXgGwLCGOZOy31rubI6PVSH6zJiaVF MaW664Oy0v6a/s6oqx8w5/MDy0qTKPN5T7tps= MIME-Version: 1.0 Received: by 10.223.83.144 with SMTP id f16mr3246014fal.4.1298666923292; Fri, 25 Feb 2011 12:48:43 -0800 (PST) Received: by 10.223.107.132 with HTTP; Fri, 25 Feb 2011 12:48:43 -0800 (PST) In-Reply-To: References: <976A5FBE345E43FDA7A17D7148B96189@local> Date: Fri, 25 Feb 2011 16:48:43 -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: RFC 2308 & RFC 4035 X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 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, 25 Feb 2011 20:47:53 -0000 On Fri, Feb 25, 2011 at 4:24 PM, Edward Lewis wrote: > At 20:08 +0000 2/25/11, George Barwood wrote: > >> I think this is addressed by >> >> http://tools.ietf.org/html/rfc4035#section-4.5 >> >> << >> =A0 In theory, a resolver could use wildcards or NSEC RRs to generate >> =A0 positive and negative responses (respectively) until the TTL or >> =A0 signatures on the records in question expire. =A0However, it seems >> =A0 prudent for resolvers to avoid blocking new authoritative data or >> =A0 synthesizing new data on their own. =A0Resolvers that follow this >> =A0 recommendation will have a more consistent view of the namespace. However, this is immediately following (in 4.5): 2. NSEC RRs received to prove the non-existence of a name could be reused by a security-aware resolver to prove the non-existence of any name in the name range it spans. So, I'd say there are two distinct cases: - the NSEC *might* be used to deny the existence of a double (QNAME,QCLASS) in the range (e.g. if "next domain name" were b.example.net, and the QNAME were a.example.net) - the NSEC is used to deny the existence of an RRTYPE not listed in the NSE= C The former falls in the "it seems prudent" category. The latter, I think, does not, in which case, using the NSEC to generate a NODATA answer is appropriate. It would never be *wrong* to query the authority server, but it might be unnecessary, e.g. 99.9999% of the time. There is one other conflict, I think, which could occur - if an NSEC is cached, but an RRTYPE not found in the NSEC, is also cached at the same QNAME,QCLASS. Is that bad or broken? (Should adding/removing an RRTYPE, or adding/removing a name, result in selective re-generation of NSEC/NSEC3 records and their signatures)? Does it matter which order the two responses arrive? (If it does, I think that indicates that there's a protocol problem....) Should it trigger discarding or non-caching of the NSEC record? (I think not, modulo the question on re-generation/re-signing NSEC/NSEC3 data) > Good observation. =A0Question to those who've written caches, what strate= gy > seemed best. > > It's passages like the quoted that should be firmed up when and if DNSSEC= is > ever a Draft Standard/Full Standard. > > And getting back to the resimprove draft, I'd wager that a BCP shouldn't > disagree with a Standards Track document. Agree. Brian From ted.ietf@gmail.com Fri Feb 25 13:07:00 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6FBF33A6A40 for ; Fri, 25 Feb 2011 13:07:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.644 X-Spam-Level: X-Spam-Status: No, score=-3.644 tagged_above=-999 required=5 tests=[AWL=-0.045, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Seng+KRKkQ4O for ; Fri, 25 Feb 2011 13:06:59 -0800 (PST) Received: from mail-qy0-f179.google.com (mail-qy0-f179.google.com [209.85.216.179]) by core3.amsl.com (Postfix) with ESMTP id 398D03A6A4C for ; Fri, 25 Feb 2011 13:06:59 -0800 (PST) Received: by qyk7 with SMTP id 7so1630283qyk.10 for ; Fri, 25 Feb 2011 13:07:52 -0800 (PST) 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=XDophiYpAnnxEkphtX1eKh99nUK87ByEgyEV19whlKo=; b=ETQleatcyB0f6q/2FhzutFl5EAcbNeI8aW7nob0NjvFklfUoLXxbygrw/AJOXCWmGC 2KOk1RiqyK+o8H8Zhqw3OgElXFff3gtdZmOgHPTHopaUcFGEdl9nM1Hz5y+5cbuJWz72 EVFgRL2gnM/yrJh/XN+kZ4MhDE9GBeLqepwvk= 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=aZnUZZGCYbO1HawFSwZzn5w4A7O7ikTV1GRLrEiaVc+fKloXko4jShJe56M+0/NtiP FqBv9L/TMhwuC4elJNUE6z5zE1R1g68vPVvVjVj1nOBATtPyjh+9rK9T64XuYId6fp5x UPSLwcoSysPOLZU4U88bLQtL9WpL5OUIwxdIQ= MIME-Version: 1.0 Received: by 10.229.86.7 with SMTP id q7mr2197120qcl.262.1298668072071; Fri, 25 Feb 2011 13:07:52 -0800 (PST) Received: by 10.229.98.210 with HTTP; Fri, 25 Feb 2011 13:07:51 -0800 (PST) In-Reply-To: <20110225192058.GU74938@shinkuro.com> References: <5A100E65-FB09-4556-AA5A-BF9FE0468DDA@ICSI.Berkeley.EDU> <6AD400292B2C771C7FE70E8F@Ximines.local> <20110225143043.GB74938@shinkuro.com> <20110225184838.GS74938@shinkuro.com> <20110225192058.GU74938@shinkuro.com> Date: Fri, 25 Feb 2011 13:07:51 -0800 Message-ID: From: Ted Hardie To: Andrew Sullivan Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: dnsext@ietf.org Subject: Re: [dnsext] does making names the same NEED protocol changes at all? X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 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, 25 Feb 2011 21:07:00 -0000 On Fri, Feb 25, 2011 at 11:20 AM, Andrew Sullivan wrote: > But as you can see, we can discuss all of that without recourse to the > specifics of the language, since the actual issue is that a zone > administrator knows a label to label mapping of the items. > > Dearly as I would love to agree with you, I fear I cannot. The actual issue is that humans interpolate well and canonicalize badly. We're exploring how to mesh the untidy reality that colour/color, =E4=B8=AD=E5=9C= =8B=EF=BC=8F=E4=B8=AD=E5=9B=BD=EF=BC=8C and a host of other examples are "the same" to those humans but not to an exact much look-up protocol. There are several classes of solutions we can envision. On is a referral from variants to canonical forms (like DNAME/CNAME and its synthetic friends). That works fine from a protocol perspective, but it requires there to be a single "real" label and variants which only point to it. Some zones don't want that result, for both political and practical reasons. Another is one in which there is no DNS change at all, but zone synchronization methods that ensure that the records at one label and those at another are in sync. This avoids declaring one to be "real", but has a very large potential cost in terms of applications which will not match them as the DNS is, in essence, declaring them to be distinct. Another is to create a "canonical + supported variants" approach. That would involve both mapping variants to a single label and storing at that label some information about what the zone maintainer considered variants, so that applications and local caches could treat them the same. The security properties of this approach are, to put it mildly, interesting, but for variants all within a single administrative domain, it is possibly workable. The operational consequences are also pretty daunting unless the record stores a pointer to some well-known representation of the normalization rules rather the variants themselves. This is a case where people want to treat DNS labels as human-friendly strings. They are asking us how far down that road we can go without breaking fundamental bits of the DNS's design and deployment. So far, I hear "we can give you referrals to canonical forms, you can give yourself synchronized zones, and we may be able to achieve a method that stores variant information with a canonical form". The label to label mapping problem is pretty clearly solved somewhere in that set, but it is not at all sure that the "humans interpolate well, but canonicalize badly" problem is or can be. Just my two cents, Ted Hardie From Ed.Lewis@neustar.biz Fri Feb 25 13:23:29 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C544E3A6A51 for ; Fri, 25 Feb 2011 13:23:29 -0800 (PST) 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=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8fKi0FL8E0aM for ; Fri, 25 Feb 2011 13:23:20 -0800 (PST) Received: from stora.ogud.com (stora.ogud.com [66.92.146.20]) by core3.amsl.com (Postfix) with ESMTP id 26F7D3A6A43 for ; Fri, 25 Feb 2011 13:23:09 -0800 (PST) Received: from Work-Laptop-2.local (gatt.md.ogud.com [10.20.30.6]) by stora.ogud.com (8.14.4/8.14.4) with ESMTP id p1PLNsap057163; Fri, 25 Feb 2011 16:23:55 -0500 (EST) (envelope-from Ed.Lewis@neustar.biz) Received: from [10.31.200.114] by Work-Laptop-2.local (PGP Universal service); Fri, 25 Feb 2011 16:24:00 -0500 X-PGP-Universal: processed; by Work-Laptop-2.local on Fri, 25 Feb 2011 16:24:00 -0500 Mime-Version: 1.0 Message-Id: In-Reply-To: References: <976A5FBE345E43FDA7A17D7148B96189@local> Date: Fri, 25 Feb 2011 16:14:07 -0500 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] Fwd: RFC 2308 & RFC 4035 X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 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, 25 Feb 2011 21:23:30 -0000 At 16:48 -0400 2/25/11, Brian Dickson wrote: >Does it matter which order the two responses arrive? (If it does, I >think that indicates that there's a protocol problem....) Order does matter, but that is not a problem in the protocol. The DNS, prior to DNSSEC, had no concept of absolute (wall-clock) time for any reason. Using UDP furthers the problem of trying to sequence the actions that occur in the system. There was a conversation during the DNSSEC development years on whether the expiration/inception times could be used to try to sequence the values in an RRset, but this failed to come to fruition, partly because there is no guarantee that, for instance InceptionTime1>InceptionTime2 ==> ExpirationTime1>ExpirationTIme2. Since then we've been wary of letting wall-clock time creep into DNS. To stop replay attacks, we need it but that's as far as it should really go. This is why I once barked when someone did a survey of the clocks on authority servers - they shouldn't need to know the time of day. What I meant to say is that the DNS protocol has the property that it is impossible to determine the sequence of messages in the system. If we built in some way to "make order unimportant" we'd severely crimp the protocol's scalability. (All that locking and synchronization and all.) The topic I am trying to tease out here is the question of how much "authority" is given to caches in generating answers. The protocol is very conservative on this, as evidenced in RFC 2308's description of negative caching. Again DNSSEC has tempted us to open this up, as quoted in the passages in the thread. >Should it trigger discarding or non-caching of the NSEC record? (I >think not, modulo the question on re-generation/re-signing NSEC/NSEC3 >data) In the sense that code rules and specs walk, it would be good to get opinions from those who have written caches. (I asked before, this isn't another nudge, I just want to emphasize this isn't mean to be a discussion over words in a static document.) -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis NeuStar You can leave a voice message at +1-571-434-5468 Me to infant son: "Waah! Waah! Is that all you can say? Waah?" Son: "Waah!" From vixie@isc.org Fri Feb 25 14:52:22 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6C84E3A6A62 for ; Fri, 25 Feb 2011 14:52:22 -0800 (PST) X-Quarantine-ID: X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER, Duplicate header field: "Cc" 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=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SOm6VwBvGbqI for ; Fri, 25 Feb 2011 14:52:20 -0800 (PST) Received: from nsa.vix.com (unknown [IPv6:2001:4f8:3:bb:230:48ff:fe5a:2f38]) by core3.amsl.com (Postfix) with ESMTP id C7A473A6A4E for ; Fri, 25 Feb 2011 14:52:19 -0800 (PST) Received: from nsa.vix.com (localhost [127.0.0.1]) by nsa.vix.com (Postfix) with ESMTP id A4AE7A1058; Fri, 25 Feb 2011 22:53:11 +0000 (UTC) (envelope-from vixie@isc.org) From: Paul Vixie To: Edward Lewis In-Reply-To: Your message of "Fri, 25 Feb 2011 15:24:33 EST." References: <976A5FBE345E43FDA7A17D7148B96189@local> X-Mailer: MH-E 8.2; nmh 1.2; XEmacs 21.4 (patch 22) Date: Fri, 25 Feb 2011 22:53:11 +0000 Message-ID: <37601.1298674391@nsa.vix.com> Cc: dnsext@ietf.org Subject: Re: [dnsext] Fwd: RFC 2308 & RFC 4035 X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 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, 25 Feb 2011 22:52:22 -0000 > Date: Fri, 25 Feb 2011 15:24:33 -0500 > From: Edward Lewis > ... > And getting back to the resimprove draft, I'd wager that a BCP shouldn't > disagree with a Standards Track document. right. hwoever, resimprove does not deal with NSEC or DNSSEC issues at all. From marka@isc.org Fri Feb 25 16:31:32 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 540B83A6A94 for ; Fri, 25 Feb 2011 16:31:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[AWL=0.622, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WcqGKtbXr0pq for ; Fri, 25 Feb 2011 16:31:31 -0800 (PST) Received: from mx.pao1.isc.org (mx.pao1.isc.org [IPv6:2001:4f8:0:2::2b]) by core3.amsl.com (Postfix) with ESMTP id B7CF23A6A92 for ; Fri, 25 Feb 2011 16:31:30 -0800 (PST) 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 05D16C9421; Sat, 26 Feb 2011 00:32:17 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (drugs.dv.isc.org [IPv6:2001:470:1f00:820:ea06:88ff:fef3:4f9c]) (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 7A936216C22; Sat, 26 Feb 2011 00:32:16 +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 0E1BFAFA28D; Sat, 26 Feb 2011 11:32:14 +1100 (EST) To: Edward Lewis From: Mark Andrews References: In-reply-to: Your message of "Fri, 25 Feb 2011 14:41:15 CDT." Date: Sat, 26 Feb 2011 11:32:13 +1100 Message-Id: <20110226003214.0E1BFAFA28D@drugs.dv.isc.org> Cc: dnsext@ietf.org Subject: Re: [dnsext] Fwd: RFC 2308 & RFC 4035 X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 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, 26 Feb 2011 00:31:32 -0000 In message , Edward Lewis writes: > I have a question referring to two sections in two RFCs, prompted by > the resimprove draft. > > RFC 4035: > 5.4. Authenticated Denial of Existence > ... > o If the requested RR name matches the owner name of an > authenticated NSEC RR, then the NSEC RR's type bit map field lists > all RR types present at that owner name, and a resolver can prove > that the requested RR type does not exist by checking for the RR > type in the bit map. ... > > And in RFC 2308: > 5 - Caching Negative Answers > ... > A negative answer that resulted from a no data error (NODATA) should > be cached such that it can be retrieved and returned in response to > another query for the same that resulted in > the cached negative response. > > Let's aay this happens: > > at 10am a cache receives a response to a query for example.tld./IN/A that say > s > > example.tld. 3600 NSEC3 a.example.tld. SOA NS DNSKEY RRSIG NSEC > > at 10:15am the cache gets a query for example.tld./IN/AAAA. > > Should the cache rely with a NoData response or should it try to > query for the AAAA? > > If the answer to the previous is "it should rely on the cached NSEC:" > What if I said that at 10:10am, the authority was updated with a new > zone that had an AAAA RRset at the apex? Nothing worse than having asked for the AAAA record at 10:00 am. The zone administrator has to assume that AAAA queries will have been made prior to adding the AAAA records. This will almost certainly be the case if there were A queries. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From wouter@nlnetlabs.nl Sat Feb 26 00:05:18 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CDBCD3A6937 for ; Sat, 26 Feb 2011 00:05:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.752 X-Spam-Level: X-Spam-Status: No, score=-1.752 tagged_above=-999 required=5 tests=[AWL=-0.848, BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, J_CHICKENPOX_55=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AELJYzVSvPV7 for ; Sat, 26 Feb 2011 00:05:10 -0800 (PST) Received: from rotring.dds.nl (rotring.dds.nl [85.17.178.138]) by core3.amsl.com (Postfix) with ESMTP id E2F673A692D for ; Sat, 26 Feb 2011 00:05:09 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by rotring.dds.nl (Postfix) with ESMTP id 16FF158B43 for ; Sat, 26 Feb 2011 09:06:03 +0100 (CET) Received: from [192.168.254.2] (195-241-9-117.adsl.dds.nl [195.241.9.117]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by rotring.dds.nl (Postfix) with ESMTPSA id 042E958B44 for ; Sat, 26 Feb 2011 09:05:56 +0100 (CET) Message-ID: <4D68B464.8040409@nlnetlabs.nl> Date: Sat, 26 Feb 2011 09:05:56 +0100 From: "W.C.A. Wijngaards" User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.16) Gecko/20101125 SUSE/3.0.11 Thunderbird/3.0.11 MIME-Version: 1.0 To: dnsext@ietf.org References: In-Reply-To: X-Enigmail-Version: 1.0.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: clamav-milter 0.96.5 at rotring X-Virus-Status: Clean Subject: Re: [dnsext] Fwd: RFC 2308 & RFC 4035 X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 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, 26 Feb 2011 08:05:18 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi Ed, On 02/25/2011 08:41 PM, Edward Lewis wrote: > I have a question referring to two sections in two RFCs, prompted by the > resimprove draft. > Let's aay this happens: > > at 10am a cache receives a response to a query for example.tld./IN/A > that says > > example.tld. 3600 NSEC3 a.example.tld. SOA NS DNSKEY RRSIG NSEC > > at 10:15am the cache gets a query for example.tld./IN/AAAA. > > Should the cache rely with a NoData response or should it try to query > for the AAAA? I think they should use the passage quoted by George. NSECs are used for exactly the qname,qtype,qclass that solicited them (NODATA and NXDOMAIN). > If the answer to the previous is "it should rely on the cached NSEC:" > What if I said that at 10:10am, the authority was updated with a new > zone that had an AAAA RRset at the apex? - From an efficiency point, using cached NSECs helps; but for caches the nxdomain and nodata traffic is a lot smaller than e.g. for roots. Best regards, Wouter -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.15 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org/ iEYEARECAAYFAk1otGQACgkQkDLqNwOhpPghXACfXunnU5hAj20WTbjbVTTXmRWC Z2EAn3+XUuyESnIuigYwLuEfSas3ngOE =JN8C -----END PGP SIGNATURE----- From alex@alex.org.uk Sat Feb 26 05:07:05 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5F7F03A6857 for ; Sat, 26 Feb 2011 05:07:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.849 X-Spam-Level: X-Spam-Status: No, score=-0.849 tagged_above=-999 required=5 tests=[AWL=-1.750, BAYES_00=-2.599, J_CHICKENPOX_33=0.6, J_CHICKENPOX_55=0.6, MANGLED_LOAN=2.3, OBSCURED_EMAIL=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SinLmrt1qBKe for ; Sat, 26 Feb 2011 05:07:03 -0800 (PST) Received: from mail.avalus.com (mail.avalus.com [89.16.176.221]) by core3.amsl.com (Postfix) with ESMTP id 0F0E23A6841 for ; Sat, 26 Feb 2011 05:07:02 -0800 (PST) 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 7BEADC562CA; Sat, 26 Feb 2011 13:07:55 +0000 (GMT) Date: Sat, 26 Feb 2011 13:07:54 +0000 From: Alex Bligh To: Suzanne Woolf , dnsext@ietf.org Message-ID: In-Reply-To: <20110223114720.GA10740@bikeshed.isc.org> References: <20110223001502.31614.56353.idtracker@localhost> <20110223114720.GA10740@bikeshed.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 Subject: Re: [dnsext] I-D Action:draft-ietf-dnsext-aliasing-requirements-00.txt X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 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: Sat, 26 Feb 2011 13:07:05 -0000 Suzanne, --On 23 February 2011 11:47:20 +0000 Suzanne Woolf wrote: > Your comments are sought. It was pushed out this week to keep the > discussion here going. I think this is a very useful draft. My main comment is that I had expected the draft to concentrate more on what types of behaviour were requirements from a functionality point of view (rather than a not breaking stuff point of view). We know how to not break stuff (don't fix things). But we don't actually yet know what the proposed required behaviour is. Some requirements conflict. I'd sort of presumed we'd have a table of requirements (both sorts) vs. potential solutions. See below for detailed comments. -- Alex Bligh --- draft-ietf-dnsext-aliasing-requirements-00.txt 2011-02-23 00:08:14.000000000 +0000 +++ draft-ietf-dnsext-aliasing-requirements-00-amb-comments.txt 2011-02-26 13:01:45.000000000 +0000 @@ -22,6 +22,16 @@ potential use cases, two or more names that users will regard as having identical meaning may sometimes require corresponding behavior in the underlying infrastructure, possibly in the DNS itself. It's + +AB: Is the desired property really 'corresponding behaviour in the +AB: underlying *infrastructure*' or 'corresponding behaviour in the +AB: applications used by those users'. I suspect it is the latter and +AB: this is a critical distinction. I don't think your average user +AB: can see how the underlying infrastructure works. If the result at +AB: the user experience level is the same, that should be good enough. +AB: Indeed BNAME type approaches seek to replicate the behaviour at +AB: user level using a different infrastructure. + not clear how to accommodate this required behavior of such names in DNS resolution; in particular, it's not clear when they are best accommodated in registry practices for generating names for lookup in @@ -177,13 +187,28 @@ assumptions about how "names" or "words" work. One aspect of this is the notion or expectation that multiple sets of names may be similar to a human user, and expected to behave "the same" or as "aliases" of - one another, across multiple services and interactions. The DNS was + one another, across multiple services and interactions. The DNS was originally designed with the implicit expectation that names would be based on - ASCII characters, and the "similarity" or "sameness" property doesn't + ASCII characters, and the "similarity" or "sameness" property did not seem to arise terribly often in the names people originally wanted to use in the DNS; thus the requirements of identical resolution of "aliased" or "bundled" names hasn't figured prominently as an attribute that needed to be accommodated in the generation or lookup + +AB: Perhaps add something like: "The DNS was originally designed from the +AB: perspective of those using ASCII characters only, and (to a great +AB: extent) labels consisting only of characters 0-9, A-Z, a-z and -. +AB: An early decision was made to treat character case as insignificant +AB: in lookups (one form of bundling), but to treat the presence of +AB: hyphens as significant (another form of bundling). This currently +AB: leads to situations where some names users might consider should +AB: perform identically do not perform identically (e.g. a-b.example.com +AB: and ab.example.com), whereas other pairs do perform identically +AB: (e.g. AB.EXAMPLE.COM and ab.example.com). A user who does recognise +AB: the significance of dots in names, or TLDs may have yet greater +AB: expectations of DNS to resolve seemingly similar names, none of +AB: which are ever likely to be met." + of DNS names. However, with the standardization of internationalized domain names protocols (ref: IDNA and IDNAbis), more and more internationalized domain name labels [RFC3490] are appearing in DNS @@ -193,17 +218,27 @@ users consider "the same" in some languages. Accordingly, Internet users hope for such labels to behave in DNS contexts as they expect the corresponding human constructs to behave, regardless of the - specific service (smtp, http, etc.) involved.. + specific service (smtp, http, etc.) involved. + +AB: Perhaps it is necessary to distinguish between these expectations +AB: and the expectations of users we already fail to meet with +AB: regards to case and hyphens, dots etc. as set out above. The general issues of what "the same" means, or of defining "variants" in human scripts as codified in Unicode (or anywhere else) are well outside the scope of the DNS or the expertise of most of the people who work on it. They are matters for philosophers and + +AB: This is actually a key difference between the original design +AB: decision re case insensitivity etc. and IDNA. + applications developers, respectively. However, to the extent that these issues can be specified as involving the resolution of names in the DNS, it's reasonable to describe those expectations and attempt to accommodate them. +AB: Section break here on existing methods? + There is some existing technology defined in the DNS for behavior that can be described as one name behaving "the same" as another. For a single node in the DNS tree, CNAME can be used to map one name @@ -215,7 +250,7 @@ that combines the characteristics of CNAME and DNAME is not currently defined in the DNS. - If existing protocol does not meet the zone administrator's need to + If the existing protocol does not meet the zone administrator's need to be able to treat one label, name, or zone as "the same" as another, @@ -400,6 +435,30 @@ 2.2. Identical DNS Resolution for Bundled DNS Names To some extent, the desired behavior can be described: "identical DNS + +AB: Are you trying to describe one particular form of desired behaviour +AB: (i.e. do you mean "this form of desired behaviour") or stating +AB: that this is *the* desired behaviour. If the latter, I think this +AB: is 'yet to be proven'. We have the example of SSL web sites +AB: where it's (probably) precisely the opposite of the desired behaviour, +AB: as currently, protocol developments aside, a different certificate is +AB: needed for each variant, and each of those needs a different IP +AB: address. Enforcing identical resolution (particularly at the TLD +AB: level) between (say) TLDX and TLDY is likely to mean that the +AB: operator of secure.example.TLDX has no choice but for +AB: secure.example.TLDY to resolve to the same IP address, which will +AB: inevitably lead to a security warning on the browser of the human +AB: who thinks these two are identical - this is almost certainly +AB: worse than (say) a redirect. +AB: +AB: [Later]: I see some of this is handled under 2.4 and 3.3, but reading +AB: this in order doesn't make much sense. There is a bit of horse-before +AB: cart here in that the draft seems to start by saying "identical +AB: DNS resolution is useful" then quite a long while later (3.3) +AB: say "actually, it may not be". Is the better approach not to say +AB: "similar end user behaviour is the goal" and the question then +AB: is "how can that be achieved?" + resolution" means that the process of resolving two domain names will end with the same result, in most cases the same IP address. In the history of DNS protocol development, there have been two attempts to @@ -423,7 +482,7 @@ variants, and in fact their characteristics differ widely, but it's possible to define some. For example, the definition of variant characters in the JET Guidelines [RFC3743], intended for use with the - CJK language/script communities, is roughly this: One conceptual + CJK language/script communities, is roughly this: one conceptual character can be identified with several different Code Points in character sets for computer use. In UNICODE definitions of some scripts, including Han (chinese), some characters can be identified @@ -434,6 +493,14 @@ (similarity in appearance is not required by the definition but often occurs). +AB: it is probably worth stating that "It is inevitable that no character +AB: variant rule is ever likely to encompass all characters of similar +AB: appearance, as this may be undesirable (consider lower case l, upper +AB: case I and number 1 in some fonts), and is likely to be too complex +AB: in a unicode environment. No aliasing scheme will solve the problem +AB: of protecting users and domain registrants from domain names that +AB: are crafted to look the same as another, but are in fact different." + With the introduction of IDNs in the DNS, perhaps most prominently in the root zone, decisions about how to deal with IDN variants is a significant challenge ahead of us. We describe here a couple of @@ -455,6 +522,17 @@ (U+4E2D U+570B) are in the root today. The first one (U+4E2D U+56FD) can be considered the "original" IDN TLD and the second one (U+4E2D U+570B) can be considered the IDN TLD "variant". Ideally, it should + +AB: This is begging the question. Would it really be ideal? Assume +AB: all the problems at the NS layer were solved and looking up +AB: foo.bar.china1 gave the same result for foo.bar.china2, for +AB: all values of foo.bar. This would then give the problem +AB: with SSL certificates (and, no doubt other application layer +AB: protocols). The problem is that applications using DNS +AB: also need to recognise the fact that the two are variants. +AB: So either you need to add this to the "However:" bit below, +AB: or not assume that this is in fact idea. + be possible to treat the original IDN TLD and its IDN TLD variant as "identical" for purposes of DNS resolution, in a way similar to the case mapping most DNS users take for granted, in which the uppercase @@ -475,6 +553,22 @@ share some operational experience around implementation of registry policy regarding managing multiple DNS trees as "the same" +AB: I think the Chinese problem is actually more complex than you +AB: make out. I believe you have described the 'chinese TLD' +AB: prolem, rather than the general problem of 'Simplified and +AB: Traditional Chinese' which is how the section is headed. The +AB: section could thus be renamed - in which case one should note +AB: that the TLD problem alone could be solved by registry policy +AB: (as you mention with Greek, below). However, whilst I may have +AB: misunderstood, I thought the 'simplified and traditional +AB: chinese' problem was that variant ideograms could occur anywhere +AB: within the domain name, and the mapping between them was not +AB: done on a per (unicode) character basis, i.e. AB might be +AB: equivalent to PQ, and CD to RS, but that doesn't necessarily +AB: mean AD is equivalent to PS. Similar, EF might be equivalent +AB: to U (one character) and GH to VWX (three characters). Saying that, +AB: my limited understanding of this problem is second hand. + 2.3.2. An example: Greek In Greek, almost every word has the "tonos" accent sign, but where it @@ -494,8 +588,11 @@ "the same word," in a sense very much like the case insensitivity that native users of Latin script take for granted in the DNS. - - +AB: Perhaps mention that here or elsewhere it might be possible to +AB: address these problems at the presentation layer, i.e. entirely +AB: outside DNS (or arguably at nameprep stage). For instance, tonos +AB: characters could be stripped and final sigmas rewritten as +AB: normal sigmas. This is not ideal, but is one angle of attack. @@ -519,7 +616,7 @@ for zones maintained in parallel but for less work. However, we later assert a proposed requirement that synthesizing the same record as a query would have obtained from an enumerated parallel tree isn't - enough-- that the property of association or "sameness" we're + enough; the property of association or "sameness" we're creating with specific mechanisms needs to be useful in some specific way to the consumer of the data. @@ -572,6 +669,18 @@ the use of DNS records or other mechanisms not really intended for the purpose, leads to confusion and inconsistency. +AB: I wonder if it is worth mentioning that canonicalisation of a name +AB: may be either a useful, or an undesirable process. Taking the +AB: simplified Chinese example, or Arabic, some brands may wish to +AB: appear (including in the browser bar, or in email addresses) written +AB: one way, rather than another. On a web site this could be achieved +AB: through a meta reload. On email by accepting all inbound email +AB: variants but only using one outbound. Here, a variant solution +AB: which canonicalised a single variant to a canonical version would +AB: be useful (like a CNAME that doesn't actually get looked up except +AB: by the application). In other circumstances, there has been +AB: a desire expressed for all variants to be treated as equal +AB: citizens. 3. Operational Considerations @@ -601,7 +710,21 @@ technology; it can be done, and is done today, entirely with provisioning logic and registry policy. +AB: Note this isn't only a registry solution. It could be done by +AB: users too (e.g. through a zonefile preprocessor that was +AB: run prior to signing of the zone). + However, it doubles the work and the number of records required. If + +AB: I'm not sure it does double the work (presumably it's done +AB: programmatically) but the effect on the number of records could +AB: be far worse than doubling. Taking an example where 2 characters +AB: are variants of eachother, the number of variants could be +AB: as much as 2^((63-4)/(bytes per character)), i.e. huge. This +AB: would therefore require limiting the number of supported +AB: variants in the registry, either by policy or by economic +AB: means + provisioning isn't done carefully, errors can arise, leaving inconsistencies. And provisioning multiple trees does nothing to link the resulting names directly; there is no property of @@ -626,6 +749,12 @@ maintained in parallel and possibly available for audit by the authority over example.com, depending on its delegation policy. +AB: That may be a desirable feature as opposed to a limitation. For +AB: the reasons given above (SSL example) it may well be that the +AB: need for ensuring sameness is only in the zones managed by the +AB: registry and not for the child zones for which it is not +AB: authoritative. + 3.1.2. Impact of special mechanisms Once we begin to consider mechanisms for maintaining parallel zones @@ -695,6 +824,10 @@ An example used more than once in discussion is provided by SSL, as a protocol that uses domain names without necessarily using the DNS protocol per se. SSL certificates are tied to one domain name. It + +AB: my understanding (and I am not an expert) is that this is changing, +AB: but certificates supporting more than one are not widely supported. + would be helpful to applications to have a non-protocol-specific way to identify securely cases where multiple domain names can be canonicalized to the domain name used for an SSL certificate. @@ -749,17 +882,67 @@ as they may be, it's not clear where the incentives would lie to deploy it. This is particularly a concern for implementors and application developers. + +AB: I am not sure this is a reasonable requirement. After all, IDN +AB: itself would have failed this test, as it is 'more overhead' +AB: than LDH zones. The 'incentive to deploy' is presumably that +AB: customers want it. May be add the word "disproportionate' before +AB: 'overhead' within the first line. + 4. Any mechanism proposed MAY require new RRtypes and special processing for them. 5. Any mechanism proposed MUST NOT only reduce costs of generating and providing authoritative service for DNS zones. It would be too easy to reduce costs on the authority server provider while adding costs elsewhere, particularly in terms of complexity. + +AB: The first sentence here is ambiguous and says something different +AB: from the second. A solution which increased costs for everyone +AB: satisfy this criteria on one reading. Proposed text for +AB: first sentence: +AB: "Any mechanism proposed MUST NOT, in order to reduce cost for +AB: generating and providing authoritative service for DNS zones, +AB: disproportionately increase costs elsewhere, particularly +AB: in terms of complexity" + Given the central importance of DNS service to Internet operations, any change undertaken to lower the cost to providers may be useful, but should not simply shift costs to DNS users, whether applications or end users. +AB: These are all, I think, impact requirements, i.e. "don't break +AB: things". I think we also need to set out requirements in terms +AB: of positive functionality. +AB: +AB: Here are some things that have been suggested are requirements. +AB: I don't know whether they actually are requirements. +AB: +AB: * Ability for any variant name to resolve to the same records +AB: +AB: * Ability to do the above automatedly (i.e. without manually +AB: duplicating all records for variant names) +AB: +AB: * Ability to have exceptions to the above +AB: +AB: * Ability to work at TLD, registry and end registrant level +AB: +AB: * Ability to enforce sameness on child zones as well as parents +AB: (recursive sameness), i.e. more than that the child zones +AB: just have the same NS records +AB: +AB: * Ability for RRs within children of two "same" zones to differ +AB: (non-recursive sameness) - that's exactly the opposite to the +AB: above and is driven by the SSL/application layer point +AB: +AB: * Ability to support an arbitrarily large number of DNs per +AB: bundle +AB: +AB: * Ability for an application to be able to canonicalize a name +AB: i.e. for the application to be able to determine the canonical +AB: name not just get an IP address back. +AB: +AB: * Ability for all variant names to be treated as 'equal citizens' +AB: (no one canonical variant) 5. Possible Solutions @@ -773,6 +956,20 @@ other, or in preventing the use of such variants as might be considered confusing or dangerous. +AB: At the risk of generating more work, I think it might be useful +AB: to list some mechanisms which result in no protocol work +AB: here, so that we have a proper taxonomy of all requirements. +AB: I am sure there will be some need to produce a matrix of solutions +AB: versus conformity with requirements, and for that we need to +AB: have a common language of what potential solutions mean. The +AB: ones not listed here that I can immediately think of are: +AB: - online synthesis +AB: - the "I think you mean" record, allowing a canonicalizing pointer +AB: at the application level, and returning NXDOMAIN to anyone +AB: not supporting it (I think someone else had a better name) +AB: - manual provisioning / zonefile preprocessing +AB: - rewrite DN at application / nameprep stage + In addition, there are new proposals for DNS protocol to support "aliases" in the DNS as part of the desired behavior of "variant" names: Names direction[BNAME], and "Zone clone". @@ -867,6 +1064,9 @@ compatibility to avoid harm to implementations that expect, and use, the old behavior. +AB: I think it would be fair to make CNAME+DNAME a separate proposal +AB: as they have different characteristics (subtle breakage vs. new RRs) + 5.2. Zone Clone The proposal of "zone clone" or "dns shadow", is an alternative From Ed.Lewis@neustar.biz Sat Feb 26 07:50:42 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B05783A6924 for ; Sat, 26 Feb 2011 07:50:41 -0800 (PST) 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=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N91KJCWIVfAB for ; Sat, 26 Feb 2011 07:50:41 -0800 (PST) Received: from stora.ogud.com (stora.ogud.com [66.92.146.20]) by core3.amsl.com (Postfix) with ESMTP id BC9693A682C for ; Sat, 26 Feb 2011 07:50:40 -0800 (PST) Received: from Work-Laptop-2.local (gatt.md.ogud.com [10.20.30.6]) by stora.ogud.com (8.14.4/8.14.4) with ESMTP id p1QFpSHc063532; Sat, 26 Feb 2011 10:51:29 -0500 (EST) (envelope-from Ed.Lewis@neustar.biz) Received: from [192.168.1.103] by Work-Laptop-2.local (PGP Universal service); Sat, 26 Feb 2011 10:51:34 -0500 X-PGP-Universal: processed; by Work-Laptop-2.local on Sat, 26 Feb 2011 10:51:34 -0500 Mime-Version: 1.0 Message-Id: In-Reply-To: <20110226003214.0E1BFAFA28D@drugs.dv.isc.org> References: <20110226003214.0E1BFAFA28D@drugs.dv.isc.org> Date: Sat, 26 Feb 2011 10:50:32 -0500 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] Fwd: RFC 2308 & RFC 4035 X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 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, 26 Feb 2011 15:50:42 -0000 At 11:32 +1100 2/26/11, Mark Andrews wrote: >Nothing worse than having asked for the AAAA record at 10:00 am. >The zone administrator has to assume that AAAA queries will have >been made prior to adding the AAAA records. This will almost >certainly be the case if there were A queries. I think my question wasn't understood. Do cache implementers use the fact that the proof of no A record coincidently shows there is also no AAAA record when processing a subsequent AAAA query. (Meaning, there's no other entry for the AAAA alredy in the cache.) If a cache does do this kind of proof by inference, what does the implementer think about the situation in which there is a "race condition" - that the proof of non-existence has been obviated by actions outside of it's sphere? (Like the subsequent adding of the AAAA set in the authority. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis NeuStar You can leave a voice message at +1-571-434-5468 Me to infant son: "Waah! Waah! Is that all you can say? Waah?" Son: "Waah!" From marka@isc.org Sat Feb 26 15:42:03 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9776D3A6960 for ; Sat, 26 Feb 2011 15:42:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.213 X-Spam-Level: X-Spam-Status: No, score=-2.213 tagged_above=-999 required=5 tests=[AWL=-0.214, BAYES_00=-2.599, J_CHICKENPOX_37=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Jcl+2rgwt27b for ; Sat, 26 Feb 2011 15:42:02 -0800 (PST) Received: from mx.ams1.isc.org (mx.ams1.isc.org [IPv6:2001:500:60::65]) by core3.amsl.com (Postfix) with ESMTP id A26993A67F2 for ; Sat, 26 Feb 2011 15:42:02 -0800 (PST) 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 3A2F15F9863; Sat, 26 Feb 2011 23:42:44 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (c211-30-172-21.carlnfd1.nsw.optusnet.com.au [211.30.172.21]) (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 D4702216C1E; Sat, 26 Feb 2011 23:42:41 +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 9E59DB00438; Sun, 27 Feb 2011 10:42:37 +1100 (EST) To: Edward Lewis From: Mark Andrews References: <20110226003214.0E1BFAFA28D@drugs.dv.isc.org> In-reply-to: Your message of "Sat, 26 Feb 2011 10:50:32 CDT." Date: Sun, 27 Feb 2011 10:42:37 +1100 Message-Id: <20110226234237.9E59DB00438@drugs.dv.isc.org> Cc: dnsext@ietf.org Subject: Re: [dnsext] Fwd: RFC 2308 & RFC 4035 X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 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, 26 Feb 2011 23:42:03 -0000 In message , Edward Lewis writes: > At 11:32 +1100 2/26/11, Mark Andrews wrote: > >Nothing worse than having asked for the AAAA record at 10:00 am. > >The zone administrator has to assume that AAAA queries will have > >been made prior to adding the AAAA records. This will almost > >certainly be the case if there were A queries. > > I think my question wasn't understood. > > Do cache implementers use the fact that the proof of no A record > coincidently shows there is also no AAAA record when processing a > subsequent AAAA query. (Meaning, there's no other entry for the AAAA > alredy in the cache.) > > If a cache does do this kind of proof by inference, what does the > implementer think about the situation in which there is a "race > condition" - that the proof of non-existence has been obviated by > actions outside of it's sphere? (Like the subsequent adding of the > AAAA set in the authority. We do this for NXDOMAIN today. If we ask for A foo.example and get back a NXDOMAIN then the cache gets asked for AAAA foo.example we use that NXDOMAIN. Using the NSEC/NSEC3 that matches the really no different. The much more interesting question is infering NXDOMAIN for a we havn't asked for. Named already does this when looking for DLV records when validating but is expected by all parties involved. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From johnl@iecc.com Sat Feb 26 21:04:06 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BC7EF3A69AE for ; Sat, 26 Feb 2011 21:04:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.658 X-Spam-Level: X-Spam-Status: No, score=-110.658 tagged_above=-999 required=5 tests=[AWL=0.541, 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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7MhVpisXzCJb for ; Sat, 26 Feb 2011 21:04:05 -0800 (PST) Received: from gal.iecc.com (gal.iecc.com [64.57.183.53]) by core3.amsl.com (Postfix) with ESMTP id 749C23A68E5 for ; Sat, 26 Feb 2011 21:04:04 -0800 (PST) Received: (qmail 50072 invoked from network); 27 Feb 2011 05:05:00 -0000 Received: from mail1.iecc.com (64.57.183.56) by mail1.iecc.com with QMQP; 27 Feb 2011 05:05:00 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:subject:in-reply-to:cc:mime-version:content-type:content-transfer-encoding:vbr-info; s=b97.4d69db7c.k1102; i=johnl@user.iecc.com; bh=7qq9FhHGeryC4hYpfv/0Qpzd4aL9GliSS6bEaDncBcY=; b=ZGiKNr1XghsQNMqj76AEO6XGH5t1RhGIrgLSWTutu8Z81J7XitdbzJqtTyTqbDNzAjhqaFyidm84modM3lTVgyVfXr+Z8fW2Z+i8fEVJmHKYMN9mQFXhp13y9oEJffuamsp8umVC4uF3j+kcyMRRD/9X3H4bHCV2No2kpJH4ork= VBR-Info: md=iecc.com; mc=all; mv=dwl.spamhaus.org Date: 27 Feb 2011 05:05:00 -0000 Message-ID: <20110227050500.2966.qmail@joyce.lan> From: John Levine To: dnsext@ietf.org In-Reply-To: Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 7bit Subject: Re: [dnsext] slave signing, was does making names the same NEED protocol changes at all? X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 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, 27 Feb 2011 05:04:06 -0000 >Requiring slaves to be signers is a major change to the security model. Maybe, but this isn't the only place it's an issue. IPv6 rDNS is a can of worms that I'd prefer not to open here, but making forward and reverse DNS match on consumer IPv6 is another problem that has no straightforward solution. One of the possiblities that keeps coming up is stunt servers that synthesize the records as needed, which obviously means that if they do DNSSEC they need to have the signing keys. R's, John From wouter@nlnetlabs.nl Sun Feb 27 02:59:26 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5C8EE3A69E8 for ; Sun, 27 Feb 2011 02:59:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.469 X-Spam-Level: X-Spam-Status: No, score=-1.469 tagged_above=-999 required=5 tests=[AWL=-0.565, BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, J_CHICKENPOX_37=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MTeOnjkugStf for ; Sun, 27 Feb 2011 02:59:25 -0800 (PST) Received: from rotring.dds.nl (rotring.dds.nl [85.17.178.138]) by core3.amsl.com (Postfix) with ESMTP id 1F1613A677C for ; Sun, 27 Feb 2011 02:59:25 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by rotring.dds.nl (Postfix) with ESMTP id B848F58B4E for ; Sun, 27 Feb 2011 12:00:21 +0100 (CET) Received: from [192.168.254.2] (195-241-9-117.adsl.dds.nl [195.241.9.117]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by rotring.dds.nl (Postfix) with ESMTPSA id 2945658485 for ; Sun, 27 Feb 2011 12:00:16 +0100 (CET) Message-ID: <4D6A2EBF.6010806@nlnetlabs.nl> Date: Sun, 27 Feb 2011 12:00:15 +0100 From: "W.C.A. Wijngaards" User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.16) Gecko/20101125 SUSE/3.0.11 Thunderbird/3.0.11 MIME-Version: 1.0 To: dnsext@ietf.org References: <20110226003214.0E1BFAFA28D@drugs.dv.isc.org> <20110226234237.9E59DB00438@drugs.dv.isc.org> In-Reply-To: <20110226234237.9E59DB00438@drugs.dv.isc.org> X-Enigmail-Version: 1.0.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: clamav-milter 0.96.5 at rotring X-Virus-Status: Clean Subject: Re: [dnsext] Fwd: RFC 2308 & RFC 4035 X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 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, 27 Feb 2011 10:59:26 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, On 02/27/2011 12:42 AM, Mark Andrews wrote: >> I think my question wasn't understood. >> >> Do cache implementers use the fact that the proof of no A record >> coincidently shows there is also no AAAA record when processing a >> subsequent AAAA query. (Meaning, there's no other entry for the AAAA >> alredy in the cache.) >> >> If a cache does do this kind of proof by inference, what does the >> implementer think about the situation in which there is a "race >> condition" - that the proof of non-existence has been obviated by >> actions outside of it's sphere? (Like the subsequent adding of the >> AAAA set in the authority. > > We do this for NXDOMAIN today. If we ask for A foo.example and get > back a NXDOMAIN then the cache gets asked for AAAA foo.example we > use that NXDOMAIN. Using the NSEC/NSEC3 that matches the > really no different. > > The much more interesting question is infering NXDOMAIN for a > we havn't asked for. Named already does this when > looking for DLV records when validating but is expected by all > parties involved. Unbound does not use this, also not for NXDOMAINs and other types. We infer NXDOMAINs and NODATA for DLV records, like named does, because the RFC says so. Qtype DS is also inferred from NSECs, an artifact of the implementation. It should never have the problem that you describe because if the domain suddenly got signed, you would get the DS with the referral, and having an old referral means that exactly what Mark said earlier 'there was a referral query 10 minutes ago', otherwise you would not have the NS data anyway and get the DS information if you were to need new NS data. Best regards, Wouter -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.15 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org/ iEYEARECAAYFAk1qLr8ACgkQkDLqNwOhpPhinACgiMzWRLSc4VnK/X6eOOkuuy4n cXYAnR3oMs4g+YODyGtaGvckG/IFpQgm =ERnd -----END PGP SIGNATURE----- From hallam@gmail.com Sun Feb 27 04:45:51 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3BB653A6930 for ; Sun, 27 Feb 2011 04:45:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.57 X-Spam-Level: X-Spam-Status: No, score=-3.57 tagged_above=-999 required=5 tests=[AWL=0.028, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SoIzkE6PIz-D for ; Sun, 27 Feb 2011 04:45:50 -0800 (PST) Received: from mail-bw0-f44.google.com (mail-bw0-f44.google.com [209.85.214.44]) by core3.amsl.com (Postfix) with ESMTP id C8EF53A68F6 for ; Sun, 27 Feb 2011 04:45:49 -0800 (PST) Received: by bwz13 with SMTP id 13so3547187bwz.31 for ; Sun, 27 Feb 2011 04:46:46 -0800 (PST) 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=WxsTcCKviytzmduW4bOgiqmq5tRwxaTGnbZ+Jdp3Xcg=; b=Ee7vtHxbWv4o0Ly1pSKJrUnettIekWYFuxBPqp8PEnPdMgr4JZhFSln+Af5XeoEtz7 4INVMxTQJhgnQ9OnnCnuRbR0k2VOceXBKIVBDn/HYCKYHVWRHRbkDGS7AehBXLxCt7wl go2d+UG/z3lLdC3DHwh597cpiJGVZRvppipQk= 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=AXrY9wBmYVRoIddAIx07/fWjEDgo1PHd6ccZBNHcQM5hX5YiCkGFdti8XzDumlUh2j S284xtIOVsqp5iP9I3PAUfLoUGKb0ZunL7R509NWvsklhxgEsmFSgUscSB6VXIBSPxNm rpSeeomHl2ZOnSl2ueqGOGW+v8tRHroOUN63o= MIME-Version: 1.0 Received: by 10.204.48.77 with SMTP id q13mr142630bkf.128.1298810806297; Sun, 27 Feb 2011 04:46:46 -0800 (PST) Received: by 10.204.14.139 with HTTP; Sun, 27 Feb 2011 04:46:46 -0800 (PST) In-Reply-To: <20110227050500.2966.qmail@joyce.lan> References: <20110227050500.2966.qmail@joyce.lan> Date: Sun, 27 Feb 2011 07:46:46 -0500 Message-ID: From: Phillip Hallam-Baker To: John Levine Content-Type: multipart/alternative; boundary=0016e6d778cebd64fe049d42f45b Cc: dnsext@ietf.org Subject: Re: [dnsext] slave signing, was does making names the same NEED protocol changes at all? X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 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, 27 Feb 2011 12:45:51 -0000 --0016e6d778cebd64fe049d42f45b Content-Type: text/plain; charset=ISO-8859-1 Two questions come to mind 1) How is key publication going to be effected for rDNS-SEC? Have we actually got a plan for deployment? 2) If we have a viable plan for deployment of rDNS-SEC, why would we not plan to use that as the PKI for BGPSEC? It may make sense to employ a hybrid PKI since DNSSEC responses are transitory and there is a bootstrap issue. But this makes more sense to me than experimenting with novel X.509 features. On Sun, Feb 27, 2011 at 12:05 AM, John Levine wrote: > >Requiring slaves to be signers is a major change to the security model. > > Maybe, but this isn't the only place it's an issue. > > IPv6 rDNS is a can of worms that I'd prefer not to open here, but > making forward and reverse DNS match on consumer IPv6 is another > problem that has no straightforward solution. One of the possiblities > that keeps coming up is stunt servers that synthesize the records as > needed, which obviously means that if they do DNSSEC they need to have > the signing keys. > > R's, > John > -- Website: http://hallambaker.com/ --0016e6d778cebd64fe049d42f45b Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Two questions come to mind

1) How is key publication goi= ng to be effected for rDNS-SEC?

Have we actually g= ot a plan for deployment?


2) If we = have a viable plan for deployment of rDNS-SEC, why would we not plan to use= that as the PKI for BGPSEC?

It may make sense to employ a hybrid PKI since DNSSEC r= esponses are transitory and there is a bootstrap issue. But this makes more= sense to me than experimenting with novel X.509 features.


On Sun, Feb 27, 2011 at 12:05 AM,= John Levine <johnl@= iecc.com> wrote:
>Requiring slaves to be signers is a major change to the security model.=

Maybe, but this isn't the only place it's an issue.

IPv6 rDNS is a can of worms that I'd prefer not to open here, but
making forward and reverse DNS match on consumer IPv6 is another
problem that has no straightforward solution. =A0One of the possiblities that keeps coming up is stunt servers that synthesize the records as
needed, which obviously means that if they do DNSSEC they need to have
the signing keys.

R's,
John



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

--0016e6d778cebd64fe049d42f45b-- From Ed.Lewis@neustar.biz Sun Feb 27 06:43:14 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9CD713A6938 for ; Sun, 27 Feb 2011 06:43:14 -0800 (PST) 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=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_37=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mq0qX89FWSm4 for ; Sun, 27 Feb 2011 06:43:13 -0800 (PST) Received: from stora.ogud.com (stora.ogud.com [66.92.146.20]) by core3.amsl.com (Postfix) with ESMTP id 951283A692E for ; Sun, 27 Feb 2011 06:43:13 -0800 (PST) Received: from hway-t500.cis.neustar.com (gatt.md.ogud.com [10.20.30.6]) by stora.ogud.com (8.14.4/8.14.4) with ESMTP id p1REi3ep070458; Sun, 27 Feb 2011 09:44:04 -0500 (EST) (envelope-from Ed.Lewis@neustar.biz) Received: from [192.168.128.192] by hway-t500.cis.neustar.com (PGP Universal service); Sun, 27 Feb 2011 09:44:11 -0500 X-PGP-Universal: processed; by hway-t500.cis.neustar.com on Sun, 27 Feb 2011 09:44:11 -0500 Mime-Version: 1.0 Message-Id: In-Reply-To: <20110226234237.9E59DB00438@drugs.dv.isc.org> References: <20110226003214.0E1BFAFA28D@drugs.dv.isc.org> <20110226234237.9E59DB00438@drugs.dv.isc.org> Date: Sun, 27 Feb 2011 09:37:40 -0500 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] Fwd: RFC 2308 & RFC 4035 X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 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, 27 Feb 2011 14:43:14 -0000 At 10:42 +1100 2/27/11, Mark Andrews wrote: >We do this for NXDOMAIN today. If we ask for A foo.example and get >back a NXDOMAIN then the cache gets asked for AAAA foo.example we >use that NXDOMAIN. That's cool - it complies with NCACHE (in a part I didn't quote). I know you (as author know that, but I'm just saying it here. >Using the NSEC/NSEC3 that matches the >really no different. There's a bit if difference. I've been dealing with zones that are highly dynamic. Signing such zones can be a challenge. Besides the number of signatures needed for the positive answers, which is simply part of the workload is the generation and signing of the negative answers. The way that NCACHE is written today, a simplifying assumption can be made for the NSEC/3 bit map if the negative cache is really type specific, basically returning a bit map that says "I don't have *that*". If the negative cache is going to be name specific then the NSEC/3 has to state exactly what is there at the moment. I'm asking this in the sense that on paper I would only need to send back "I don't have that" but if the deployed code tries to be tighter, I have to craft bit maps for each combination. In addition to the provisioning and signing overhead, having to determine what's present "right now" will have to be done. Even if that is pulled off, negative caches could be subject to higher false-positive negative-cache hits when sets become available. This could be a case where over-tightening on the security checks is a bad thing. In this case, it isn't really the security, but the inferences made about the authority by the cache. >The much more interesting question is infering NXDOMAIN for a > we havn't asked for. Named already does this when >looking for DLV records when validating but is expected by all >parties involved. Again, this is forbidden in RFC 2308 but brought up in resimprove. I have to say there's something seductive about the idea, but it's like a siren's call to make caches take over being authorities. I think that's something that should be resisted. (And this also related to inferring across types at a name.) -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis NeuStar You can leave a voice message at +1-571-434-5468 Me to infant son: "Waah! Waah! Is that all you can say? Waah?" Son: "Waah!" From Ed.Lewis@neustar.biz Sun Feb 27 06:43:21 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F35A83A6938 for ; Sun, 27 Feb 2011 06:43:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.561 X-Spam-Level: X-Spam-Status: No, score=-102.561 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CNKQZrBYUKBD for ; Sun, 27 Feb 2011 06:43:20 -0800 (PST) Received: from stora.ogud.com (stora.ogud.com [66.92.146.20]) by core3.amsl.com (Postfix) with ESMTP id 015AB3A692E for ; Sun, 27 Feb 2011 06:43:19 -0800 (PST) Received: from hway-t500.cis.neustar.com (gatt.md.ogud.com [10.20.30.6]) by stora.ogud.com (8.14.4/8.14.4) with ESMTP id p1REi3er070458; Sun, 27 Feb 2011 09:44:11 -0500 (EST) (envelope-from Ed.Lewis@neustar.biz) Received: from [192.168.128.192] by hway-t500.cis.neustar.com (PGP Universal service); Sun, 27 Feb 2011 09:44:19 -0500 X-PGP-Universal: processed; by hway-t500.cis.neustar.com on Sun, 27 Feb 2011 09:44:19 -0500 Mime-Version: 1.0 Message-Id: In-Reply-To: <4D6A2EBF.6010806@nlnetlabs.nl> References: <20110226003214.0E1BFAFA28D@drugs.dv.isc.org> <20110226234237.9E59DB00438@drugs.dv.isc.org> <4D6A2EBF.6010806@nlnetlabs.nl> Date: Sun, 27 Feb 2011 09:40:38 -0500 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] Fwd: RFC 2308 & RFC 4035 X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 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, 27 Feb 2011 14:43:21 -0000 At 12:00 +0100 2/27/11, W.C.A. Wijngaards wrote: >Unbound does not use this, also not for NXDOMAINs and other types. > >We infer NXDOMAINs and NODATA for DLV records, like named does, because >the RFC says so. Thanks for the info. And, if the RFC says so...;) -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis NeuStar You can leave a voice message at +1-571-434-5468 Me to infant son: "Waah! Waah! Is that all you can say? Waah?" Son: "Waah!" From johnl@iecc.com Sun Feb 27 07:18:01 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0499F3A69FF for ; Sun, 27 Feb 2011 07:18:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.552 X-Spam-Level: X-Spam-Status: No, score=-110.552 tagged_above=-999 required=5 tests=[AWL=0.647, 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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NmllXIxkHF3u for ; Sun, 27 Feb 2011 07:18:00 -0800 (PST) Received: from gal.iecc.com (gal.iecc.com [64.57.183.53]) by core3.amsl.com (Postfix) with ESMTP id B8BE03A69FE for ; Sun, 27 Feb 2011 07:17:59 -0800 (PST) Received: (qmail 64685 invoked from network); 27 Feb 2011 15:18:56 -0000 Received: from mail1.iecc.com (64.57.183.56) by mail1.iecc.com with QMQP; 27 Feb 2011 15:18:56 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:subject:in-reply-to:cc:mime-version:content-type:content-transfer-encoding:vbr-info; s=17df.4d6a6b60.k1102; i=johnl@user.iecc.com; bh=jVaa+W6J/SIOGMkKZNjyxfbM2Btuh5/cf+wpBYW3WzA=; b=rNIiJfaMTfkywKcYnJbo4duWga+bv1Vy301KI0GOAw/knmCb10m1a+jF/70zc9CdnO0n5BSEPPwUYlTbLX/Cx9WeSq+HpwM3GVIZcDmWbMJddAAAxH2ZR2trZSfqYvLeM1sTCGfQ86CMswh4gS1t+sFPeXO9a9KS229/C07VlSc= VBR-Info: md=iecc.com; mc=all; mv=dwl.spamhaus.org Date: 27 Feb 2011 15:18:56 -0000 Message-ID: <20110227151856.6110.qmail@joyce.lan> From: John Levine To: dnsext@ietf.org In-Reply-To: Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 7bit Subject: Re: [dnsext] slave signing, was does making names the same NEED protocol changes at all? X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 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, 27 Feb 2011 15:18:01 -0000 >1) How is key publication going to be effected for rDNS-SEC? > >Have we actually got a plan for deployment? As far as I can tell, we don't have a plan for deployment of rDNS on IPv6, with or without DNSSEC. But like I said, I'd rather leave those worms in the can other than to note that dynamic generation and presumably signing of AAAA and PTR records may turn out to be one of the least bad options. We don't have a plan for IPv6 DNSBLs and DNSWLs either, but if it ends up being anything like what people do for IPv4 (an open question, due to DNS cache explosion problems) rbldnsd is going to have to sign on the fly, too. R's, John From hallam@gmail.com Sun Feb 27 09:06:36 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 067593A694D for ; Sun, 27 Feb 2011 09:06:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.571 X-Spam-Level: X-Spam-Status: No, score=-3.571 tagged_above=-999 required=5 tests=[AWL=0.028, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u0d+IWXdvXVp for ; Sun, 27 Feb 2011 09:06:35 -0800 (PST) Received: from mail-bw0-f44.google.com (mail-bw0-f44.google.com [209.85.214.44]) by core3.amsl.com (Postfix) with ESMTP id AECB03A6957 for ; Sun, 27 Feb 2011 09:06:34 -0800 (PST) Received: by bwz13 with SMTP id 13so3656689bwz.31 for ; Sun, 27 Feb 2011 09:07:32 -0800 (PST) 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=4+p884R3AWXsFo7xqUPjWoFUoNR3hPzsG8idNnGOWjQ=; b=kVG1G1Phw06xfEEkO1+4sFH1va4cfRJ+cNDYpbabl2NgcbjDk7O1juD3sRwuD1AVki yglUwRfgxvY1ryefpxVMG/4rl+2ayZHJSlm17DkOAVFFeDGHCuYMd4jMJnVKZT7PZBvL qGK0WkWnwUpB8XVu0qqL2JxJtJQz96zr2kf9Q= 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=s2t9jeS/LM5lIYZjl5/HxTiOw+V/d8d6/NPwbpnt37SUa2kYo6bXa0EO1hcnonLa2D 2iDEf5AjqF/Kd6gzt5R36cnG8jhiwbbOalQXKjugi2Tb/NXvevMkcoHJ7hus1dJdnMC2 ATqt/PxycHzjmVAGcIxxj8tcfzJhblE4yFxnQ= MIME-Version: 1.0 Received: by 10.204.65.83 with SMTP id h19mr3830121bki.101.1298826451671; Sun, 27 Feb 2011 09:07:31 -0800 (PST) Received: by 10.204.14.139 with HTTP; Sun, 27 Feb 2011 09:07:31 -0800 (PST) In-Reply-To: <20110227151856.6110.qmail@joyce.lan> References: <20110227151856.6110.qmail@joyce.lan> Date: Sun, 27 Feb 2011 12:07:31 -0500 Message-ID: From: Phillip Hallam-Baker To: John Levine Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: dnsext@ietf.org Subject: Re: [dnsext] slave signing, was does making names the same NEED protocol changes at all? X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 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, 27 Feb 2011 17:06:36 -0000 On Sun, Feb 27, 2011 at 10:18 AM, John Levine wrote: >>1) How is key publication going to be effected for rDNS-SEC? >> >>Have we actually got a plan for deployment? > > As far as I can tell, we don't have a plan for deployment of rDNS on > IPv6, with or without DNSSEC. =A0But like I said, I'd rather leave those > worms in the can other than to note that dynamic generation and > presumably signing of AAAA and PTR records may turn out to be one of > the least bad options. That is my suspicion. The technology is the easy part. Its the administrative model that concerns me. Or rather it is technology proposals that seem to assume that the administrative details are unimportant and can be filled in later. > We don't have a plan for IPv6 DNSBLs and DNSWLs either, but if it > ends up being anything like what people do for IPv4 (an open question, > due to DNS cache explosion problems) rbldnsd is going to have to sign > on the fly, too. This is the sort of issue that I would hope that the IAB spent time thinking about. One answer to this question could well be that the people who use blacklists have to develop their own technology designed for the purpose. --=20 Website: http://hallambaker.com/ From johnl@iecc.com Sun Feb 27 10:26:25 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6B3B13A6A1E for ; Sun, 27 Feb 2011 10:26:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.606 X-Spam-Level: X-Spam-Status: No, score=-110.606 tagged_above=-999 required=5 tests=[AWL=0.593, 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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T6gpSbLdki7c for ; Sun, 27 Feb 2011 10:26:24 -0800 (PST) Received: from gal.iecc.com (gal.iecc.com [64.57.183.53]) by core3.amsl.com (Postfix) with ESMTP id F22113A6A19 for ; Sun, 27 Feb 2011 10:26:23 -0800 (PST) Received: (qmail 5466 invoked from network); 27 Feb 2011 18:27:21 -0000 Received: from mail1.iecc.com (64.57.183.56) by mail1.iecc.com with QMQP; 27 Feb 2011 18:27:21 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:subject:in-reply-to:cc:mime-version:content-type:content-transfer-encoding:vbr-info; s=198a.4d6a9788.k1102; i=johnl@user.iecc.com; bh=aTsiwqJjIrAPyKpdYxlNog7TdN9sW8RR2UuJ4UR0Qb8=; b=AUeop+UOsnpMsGrlSG8ZeooiL85JThfVL57MANuypCZlwBQ+tndYAsDcFs3uXNVLcnd+bc+c5piy3AA06O0KTxW6ti9NUCvNCM8qdZ5BCDvCp+reMiUIxz/N+LpmhNCswjNRYsEfKmdH8tsnC1M/1fpHXhslZLFZm0puXdjaHkk= VBR-Info: md=iecc.com; mc=all; mv=dwl.spamhaus.org Date: 27 Feb 2011 18:27:20 -0000 Message-ID: <20110227182720.6537.qmail@joyce.lan> From: John Levine To: dnsext@ietf.org In-Reply-To: Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 7bit Subject: Re: [dnsext] the same in old days, was making names the same NEED protocol changes? X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 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, 27 Feb 2011 18:26:25 -0000 >So far as I can tell the main question is, what is the question and is >BNAME the answer? Looking back into the mists of history (that would be the 1980s for you old timers), for about the first decade of the DNS, servers didn't care what their names were. If you want to add a new name to a TELNET or FTP or SMTP or POP or IMAP server, just add an A or CNAME record and you're done. Even web servers didn't care about their names until HTTP 1.1 and HTTPS in the mid 1990s. Mail servers always knew what domains they could handle mail for, but the CNAME rule pushed alias resolution into mail clients. For most purposes, the client handed the name to the DNS, the DNS gave back an answer that let the client connect to the server, and that was it. But life now is not so simple. We have several major protocols, mail, http, and https, that pass domain names as part of the data stream that are not (currently at least) resolved by DNS queries. When I read a lot of the arguments here, particularly the ones about what TLD operators want, it's like being in a time warp. If it were still 1987, and the only problem were locating the server, then something like BNAME would probably do it. But it's not, if we don't also have a plan for the protocols with domain names in the data stream, it's a cruel joke on the users. If the question is how can we make one subtree an alias that resolves to the same DNS results as a canonical subtree AND allows the application servers to tell what names are aliases to a canonical name, BTREE is pretty close. The primary shortcoming I see is a security issue: anyone can set a BNAME to make a random name equivalent to one of mine. It's possible to handle this outside the DNS, by manually configuring the server to know what names it can handle, or hackery, e.g., only accept BNAMEs served from specific name servers that we trust. But that's not great for users, since they will see baffling error messages like "mail relay refused". So I'd also want some way for the canonical domain to state in the DNS what aliases it accepts. Regards, John Levine, johnl@iecc.com, Primary Perpetrator of "The Internet for Dummies", Please consider the environment before reading this e-mail. http://jl.ly From johnl@iecc.com Sun Feb 27 10:29:46 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1008E3A6A19 for ; Sun, 27 Feb 2011 10:29:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.652 X-Spam-Level: X-Spam-Status: No, score=-110.652 tagged_above=-999 required=5 tests=[AWL=0.547, 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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BsLLzWysWnvo for ; Sun, 27 Feb 2011 10:29:45 -0800 (PST) Received: from gal.iecc.com (gal.iecc.com [64.57.183.53]) by core3.amsl.com (Postfix) with ESMTP id D62333A6A00 for ; Sun, 27 Feb 2011 10:29:44 -0800 (PST) Received: (qmail 6090 invoked from network); 27 Feb 2011 18:30:42 -0000 Received: from mail1.iecc.com (64.57.183.56) by mail1.iecc.com with QMQP; 27 Feb 2011 18:30:42 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:subject:in-reply-to:cc:mime-version:content-type:content-transfer-encoding:vbr-info; s=19a4.4d6a9852.k1102; i=johnl@user.iecc.com; bh=+4cgJCEk4G/PPGRY+AxGpI0OzO2K0S/NwdutzS0frzY=; b=mowhlnOcFXgUzw3oTQovdHJmcsH7/qxTu2zF4clmW/IqjdTZcgexz4HBW3zXo1myzvA49w1mFfOTYe2NIAbHs1i+88TCSoe3Kww/VG7V6W9j25R8KYJDACkE7MUBfWqsLRh2F/puGK3blJoAU6fWKzgo8ztC4RmEtd0fWOp7tZs= VBR-Info: md=iecc.com; mc=all; mv=dwl.spamhaus.org Date: 27 Feb 2011 18:30:42 -0000 Message-ID: <20110227183042.6563.qmail@joyce.lan> From: John Levine To: dnsext@ietf.org In-Reply-To: <4D68B464.8040409@nlnetlabs.nl> Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 7bit Subject: Re: [dnsext] Fwd: RFC 2308 & RFC 4035 X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 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, 27 Feb 2011 18:29:46 -0000 >- From an efficiency point, using cached NSECs helps; but for caches the >nxdomain and nodata traffic is a lot smaller than e.g. for roots. Don't assume that. If the zone is a DNSBL, there will be a whole lot of nxdomain queries, particularly in an IPv6 world where spamware hops to a new IP on every message. R's, John From johnl@iecc.com Sun Feb 27 10:31:52 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9FBC13A6A27 for ; Sun, 27 Feb 2011 10:31:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.691 X-Spam-Level: X-Spam-Status: No, score=-110.691 tagged_above=-999 required=5 tests=[AWL=0.508, 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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9a1i-J3R+cwZ for ; Sun, 27 Feb 2011 10:31:51 -0800 (PST) Received: from gal.iecc.com (gal.iecc.com [64.57.183.53]) by core3.amsl.com (Postfix) with ESMTP id 9C2073A6A26 for ; Sun, 27 Feb 2011 10:31:51 -0800 (PST) Received: (qmail 6433 invoked from network); 27 Feb 2011 18:32:49 -0000 Received: from mail1.iecc.com (64.57.183.56) by mail1.iecc.com with QMQP; 27 Feb 2011 18:32:49 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:subject:in-reply-to:cc:mime-version:content-type:content-transfer-encoding:vbr-info; s=19bc.4d6a98d1.k1102; i=johnl@user.iecc.com; bh=fbmex9+J/CoZv2mwBCPDu76hV13U2l9CjM4F/79dtH8=; b=BlKzgseTClK0cQbQNun4mWzM6wsHytRiuoJzwkOgArS2l9NrFzfrkh33mlWXhtwA1xbECpTbDieUZ+JsN8JSju+aeomiaCZRo1QGZQ8yJzygcazDjFmWe1vzS3bRHxm4sz1YmESB3LMksftUwjo1swZi1DTe9eUgZ9Sf5VDpHb8= VBR-Info: md=iecc.com; mc=all; mv=dwl.spamhaus.org Date: 27 Feb 2011 18:32:49 -0000 Message-ID: <20110227183249.6587.qmail@joyce.lan> From: John Levine To: dnsext@ietf.org In-Reply-To: Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 7bit Subject: Re: [dnsext] slave signing, was does making names the same NEED protocol changes at all? X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 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, 27 Feb 2011 18:31:53 -0000 >> We don't have a plan for IPv6 DNSBLs and DNSWLs either, but if it >> ends up being anything like what people do for IPv4 (an open question, >> due to DNS cache explosion problems) rbldnsd is going to have to sign >> on the fly, too. > >This is the sort of issue that I would hope that the IAB spent time >thinking about. > >One answer to this question could well be that the people who use >blacklists have to develop their own technology designed for the >purpose. Over in the ASRG we're working on it. I have an alternate version of DNSBL/WLs organized like a b-tree that seems to have pretty good cache behavior, but it's surprisingly hard to get people to wrap their heads around the fact that there is a problem. R's, John From alex@alex.org.uk Sun Feb 27 10:32:07 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4E4D33A6A25 for ; Sun, 27 Feb 2011 10:32:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.307 X-Spam-Level: X-Spam-Status: No, score=-2.307 tagged_above=-999 required=5 tests=[AWL=0.292, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g2qySBM7qLLT for ; Sun, 27 Feb 2011 10:32:06 -0800 (PST) Received: from mail.avalus.com (mail.avalus.com [89.16.176.221]) by core3.amsl.com (Postfix) with ESMTP id 8A3953A6A00 for ; Sun, 27 Feb 2011 10:32:06 -0800 (PST) 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 BC945C56062; Sun, 27 Feb 2011 18:33:03 +0000 (GMT) Date: Sun, 27 Feb 2011 18:33:02 +0000 From: Alex Bligh To: John Levine , dnsext@ietf.org Message-ID: <552AB7D12FAB50296E795CF5@Ximines.local> In-Reply-To: <20110227182720.6537.qmail@joyce.lan> References: <20110227182720.6537.qmail@joyce.lan> 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 Subject: Re: [dnsext] the same in old days, was making names the same NEED protocol changes? X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 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: Sun, 27 Feb 2011 18:32:07 -0000 --On 27 February 2011 18:27:20 +0000 John Levine wrote: > The primary shortcoming I see is a > security issue: anyone can set a BNAME to make a random name > equivalent to one of mine. How does this differ from DNAME? -- Alex Bligh From johnl@iecc.com Sun Feb 27 10:36:21 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C2D313A6A37 for ; Sun, 27 Feb 2011 10:36:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.725 X-Spam-Level: X-Spam-Status: No, score=-110.725 tagged_above=-999 required=5 tests=[AWL=0.474, 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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wakHwjALA5Ij for ; Sun, 27 Feb 2011 10:36:20 -0800 (PST) Received: from gal.iecc.com (gal.iecc.com [64.57.183.53]) by core3.amsl.com (Postfix) with ESMTP id 6FE673A6A31 for ; Sun, 27 Feb 2011 10:36:19 -0800 (PST) Received: (qmail 7486 invoked from network); 27 Feb 2011 18:37:17 -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=1d3d.4d6a99dd.k1102; i=johnl@submit.iecc.com; bh=I5pzPs847yERQhqkXSI/xv0tGqf4qsNp+tbvDATmdLQ=; b=MvpKfCRjAiqKsmku3Njxsw1g4A2QNc3R5S5oik3G64jE8F/DwJRh6zWjSZvKOKt6pfgq+TdpFRXczyaqMKbRlI6Czk33VZ4BEIqZk4mtnrZGP5AGFEtVQxr9xaNd/3Q2XRXQoo2zHCHqkWC+Jwz4MKkL7+XFgDb4V2f9K4F4Qcc= VBR-Info: md=iecc.com; mc=all; mv=dwl.spamhaus.org Received: (ofmipd johnl@64.57.183.62) with (DHE-RSA-AES256-SHA encrypted) SMTP; 27 Feb 2011 18:36:55 -0000 Date: 27 Feb 2011 13:37:17 -0500 Message-ID: From: "John R. Levine" To: "Alex Bligh" In-Reply-To: <552AB7D12FAB50296E795CF5@Ximines.local> References: <20110227182720.6537.qmail@joyce.lan> <552AB7D12FAB50296E795CF5@Ximines.local> 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] the same in old days, was making names the same NEED protocol changes? X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 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, 27 Feb 2011 18:36:21 -0000 >> The primary shortcoming I see is a security issue: anyone can set a >> BNAME to make a random name equivalent to one of mine. > How does this differ from DNAME? Not in any important way I can see. But I'm not aware of any application servers that autoconfigure based on DNAME, either. Regards, John Levine, johnl@iecc.com, Primary Perpetrator of "The Internet for Dummies", Please consider the environment before reading this e-mail. http://jl.ly From johnl@iecc.com Sun Feb 27 11:14:45 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 88A083A6A2A for ; Sun, 27 Feb 2011 11:14:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.754 X-Spam-Level: X-Spam-Status: No, score=-110.754 tagged_above=-999 required=5 tests=[AWL=0.445, 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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9JvaXcEvBS-H for ; Sun, 27 Feb 2011 11:14:44 -0800 (PST) Received: from gal.iecc.com (gal.iecc.com [64.57.183.53]) by core3.amsl.com (Postfix) with ESMTP id 610F13A6A00 for ; Sun, 27 Feb 2011 11:14:44 -0800 (PST) Received: (qmail 13941 invoked from network); 27 Feb 2011 19:15:42 -0000 Received: from mail1.iecc.com (64.57.183.56) by mail1.iecc.com with QMQP; 27 Feb 2011 19:15:42 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:subject:in-reply-to:cc:mime-version:content-type:content-transfer-encoding:vbr-info; s=1aa9.4d6aa2de.k1102; i=johnl@user.iecc.com; bh=SBcYJmcJJePppzfslKxskfpEQZiDaIFypyLDSmT5K9U=; b=rRsp5oLMsem50LNySwuHpuNNLR6l9XEJ9xnpF7tdD80rA+GwrXem8zsZvPGT+vDeyELHwijfi77dHIgDuntFI18EpH/kKcXkBwAJA1V4/VVFKmcy+Fz0HHHDT3ofR8LHZypap57wNU3Tp/AfVZhW9cBparCZl0frTSE+3MudyZk= VBR-Info: md=iecc.com; mc=all; mv=dwl.spamhaus.org Date: 27 Feb 2011 19:15:42 -0000 Message-ID: <20110227191542.6824.qmail@joyce.lan> From: John Levine To: dnsext@ietf.org In-Reply-To: <4D66C0C1.1090909@dougbarton.us> Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 7bit Subject: Re: [dnsext] I-D Action:draft-ietf-dnsext-aliasing-requirements-00.txt X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 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, 27 Feb 2011 19:14:45 -0000 >My understanding is that it is to help application developers to be >able to auto-configure things to handle multiple variants. I think >this is a good idea, and you made a good catch in noting that it's >not in Section 4. Yes, I was going to point out the same thing. In the security section, I'd suggest adding something about who can make one domain an alias of another. Currently, anyone can point a CNAME or DNAME at anything, but since few applications currently autoconfigure based on CNAMEs, it's not a big deal. If autoconfiguration becomes common, the security issues are a lot more complex. Regards, John Levine, johnl@iecc.com, Primary Perpetrator of "The Internet for Dummies", Please consider the environment before reading this e-mail. http://jl.ly From vixie@isc.org Sun Feb 27 11:53:25 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4A92A3A67B5 for ; Sun, 27 Feb 2011 11:53:25 -0800 (PST) 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=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6R3wL+zqeeHB for ; Sun, 27 Feb 2011 11:53:24 -0800 (PST) Received: from nsa.vix.com (unknown [IPv6:2001:4f8:3:bb:230:48ff:fe5a:2f38]) by core3.amsl.com (Postfix) with ESMTP id 401873A67B0 for ; Sun, 27 Feb 2011 11:53:24 -0800 (PST) Received: from nsa.vix.com (localhost [127.0.0.1]) by nsa.vix.com (Postfix) with ESMTP id 9BC04A1058 for ; Sun, 27 Feb 2011 19:54:20 +0000 (UTC) (envelope-from vixie@isc.org) From: Paul Vixie To: dnsext@ietf.org In-Reply-To: Your message of "27 Feb 2011 18:30:42 GMT." <20110227183042.6563.qmail@joyce.lan> References: <20110227183042.6563.qmail@joyce.lan> X-Mailer: MH-E 8.2; nmh 1.2; XEmacs 21.4 (patch 22) Date: Sun, 27 Feb 2011 19:54:20 +0000 Message-ID: <91393.1298836460@nsa.vix.com> Subject: Re: [dnsext] Fwd: RFC 2308 & RFC 4035 X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 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, 27 Feb 2011 19:53:25 -0000 > Date: 27 Feb 2011 18:30:42 -0000 > From: John Levine > > ... If the zone is a DNSBL, there will be a whole lot of nxdomain > queries, particularly in an IPv6 world where spamware hops to a new IP > on every message. i expect that most dnsbl's who evolve into ipv6 will also evolve a /64 "wildcard" strategy to cope with malware-controllable low order bits. but i also agree that the importance of negative caching and synthetic nxdomains is usually underestimated and will rise as the network grows. (in an internet of things, most things searched for, will not exist, whereas in the internet of today, most queries are for a small set of not-existing objects.) From alex@alex.org.uk Sun Feb 27 11:55:13 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7BBD23A6A28 for ; Sun, 27 Feb 2011 11:55:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.349 X-Spam-Level: X-Spam-Status: No, score=-2.349 tagged_above=-999 required=5 tests=[AWL=0.250, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HSADvafyNgik for ; Sun, 27 Feb 2011 11:55:12 -0800 (PST) Received: from mail.avalus.com (mail.avalus.com [89.16.176.221]) by core3.amsl.com (Postfix) with ESMTP id A89AC3A67C1 for ; Sun, 27 Feb 2011 11:55:12 -0800 (PST) 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 1FA12C56062; Sun, 27 Feb 2011 19:56:09 +0000 (GMT) Date: Sun, 27 Feb 2011 19:56:09 +0000 From: Alex Bligh To: "John R. Levine" Message-ID: In-Reply-To: References: <20110227182720.6537.qmail@joyce.lan> <552AB7D12FAB50296E795CF5@Ximines.local> 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] the same in old days, was making names the same NEED protocol changes? X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 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: Sun, 27 Feb 2011 19:55:13 -0000 --On 27 February 2011 13:37:17 -0500 "John R. Levine" wrote: >>> The primary shortcoming I see is a security issue: anyone can set a >>> BNAME to make a random name equivalent to one of mine. > >> How does this differ from DNAME? > > Not in any important way I can see. But I'm not aware of any application > servers that autoconfigure based on DNAME, either. I think I'm being thick here. Doesn't the BNAME reference go the wrong way to autoconfigure a server based on it in a manner where there can be a security problem as a result? IE Mallory's BNAME record tells you which zone Mallory's zone is equivalent to. Mallory's BNAME record does not tell you which other zones (incl. Mallory's) are equivalent to yours. What would make your server query Mallory's BNAME record at config time anyway? -- Alex Bligh From johnl@iecc.com Sun Feb 27 11:59:15 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F2D323A67D6 for ; Sun, 27 Feb 2011 11:59:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.78 X-Spam-Level: X-Spam-Status: No, score=-110.78 tagged_above=-999 required=5 tests=[AWL=0.419, 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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tFuR6qsi3tsG for ; Sun, 27 Feb 2011 11:59:13 -0800 (PST) Received: from gal.iecc.com (gal.iecc.com [64.57.183.53]) by core3.amsl.com (Postfix) with ESMTP id 93B333A67C1 for ; Sun, 27 Feb 2011 11:59:13 -0800 (PST) Received: (qmail 21885 invoked from network); 27 Feb 2011 20:00:11 -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=557c.4d6aad4b.k1102; i=johnl@submit.iecc.com; bh=2W0iCZhbKNZiRXsuWsjW6HkrEC56WwdOUJkz0eGp+jc=; b=jAn1qRErgg4HtMMxGzrpgdKdHXqDo1tV8bP1ayJ7FQO2bJswUkNqUiKso8Qv58Q264MLGCNHe2iOwne/caUNBxF5I3VEKAhEG+VSlJajMsRdf29AQXy0B14kcldAF9UEPT2/8Fa+MBJHxODuRd77VYfhaO/8w5I48z33LYBhjAE= VBR-Info: md=iecc.com; mc=all; mv=dwl.spamhaus.org Received: (ofmipd johnl@64.57.183.62) with (DHE-RSA-AES256-SHA encrypted) SMTP; 27 Feb 2011 19:59:49 -0000 Date: 27 Feb 2011 15:00:10 -0500 Message-ID: From: "John R. Levine" To: "Alex Bligh" In-Reply-To: References: <20110227182720.6537.qmail@joyce.lan> <552AB7D12FAB50296E795CF5@Ximines.local> 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] the same in old days, was making names the same NEED protocol changes? X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 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, 27 Feb 2011 19:59:15 -0000 > I think I'm being thick here. Doesn't the BNAME reference go the > wrong way to autoconfigure a server based on it in a manner where > there can be a security problem as a result? You're quite right. SHADOW goes the right way, but requires a zone cut everywhere that there's aliases. I'm not seeing any particularly pretty ways to fix BNAME to tell which ones are approved. It's not unlike the rDNS problem. Regards, John Levine, johnl@iecc.com, Primary Perpetrator of "The Internet for Dummies", Please consider the environment before reading this e-mail. http://jl.ly From paf@cisco.com Sun Feb 27 12:07:34 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9B9DC3A67C1 for ; Sun, 27 Feb 2011 12:07:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.059 X-Spam-Level: X-Spam-Status: No, score=-10.059 tagged_above=-999 required=5 tests=[AWL=0.240, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B8nh9qNi3eWz for ; Sun, 27 Feb 2011 12:07:33 -0800 (PST) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by core3.amsl.com (Postfix) with ESMTP id 4D3013A67B0 for ; Sun, 27 Feb 2011 12:07:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=paf@cisco.com; l=2362; q=dns/txt; s=iport; t=1298837312; x=1300046912; h=mime-version:subject:from:in-reply-to:date: content-transfer-encoding:message-id:references:to; bh=urNk8I0GVPM/YKeq6Gio7LHHDW1ILrRGvfWWzTf2fnQ=; b=mUvJk7yrhUd7DWY+IC5lGV0+ZiwMmYeMTIlzvvAHHoF47grYhdkksp0z T3WiWX1JkU/iH532Jf5fggH6U9dNEh8S3sLiF7JfOmRMO0D5qm4tEln+e hBWt7o2zAsZISBUFV0pi3Co0mbsi1sg5gvQhsi+iJjiXC5HtJXoVZgZwV c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjgGACs+ak2Q/khMgWdsb2JhbACYMY4TFQEBFiIlnlKaTIVhBIwd X-IronPort-AV: E=Sophos;i="4.62,235,1297036800"; d="scan'208";a="20227954" Received: from ams-core-3.cisco.com ([144.254.72.76]) by ams-iport-2.cisco.com with ESMTP; 27 Feb 2011 20:08:31 +0000 Received: from ams3-vpn-dhcp629.cisco.com (ams3-vpn-dhcp629.cisco.com [10.61.66.117]) by ams-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p1RK8URE030327 for ; Sun, 27 Feb 2011 20:08:31 GMT Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1082) From: =?iso-8859-1?Q?Patrik_F=E4ltstr=F6m?= In-Reply-To: <20110227191542.6824.qmail@joyce.lan> Date: Sun, 27 Feb 2011 21:08:30 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <335963D7-3440-45E6-843C-38F419462792@cisco.com> References: <20110227191542.6824.qmail@joyce.lan> To: dnsext@ietf.org X-Mailer: Apple Mail (2.1082) Subject: Re: [dnsext] I-D Action:draft-ietf-dnsext-aliasing-requirements-00.txt X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 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, 27 Feb 2011 20:07:34 -0000 There are a few things I think makes this discussion hard...and that is = that the overall usability is a requirement in the usability, = manageability etc while what we talk about is "only" what we do in DNS. = What we should (and can) do in DNS must then match whatever application = layer/protocol behaviour, which in turn depends on how the protocol = works. What I *think* could be interesting is one of these things as very high = level issues to look at, that btw I think sort of is written in the = draft, but using DNS terminology ;-) 1. Aliases 1.1. If we today have two delegations, we do have a risk that one of the = delegations changes holder while the other does not. Can one of the two = be an alias to the other, and the two then bundled by policy in the = registry so we absolutely know one and only one holder controls the data = for the names (plural)? 1.2. If we today have two delegations, synchronization of the two = delegations imply provisioning systems must place the same records in = two zones. Can we solve the problem in different ways? 2. Support of more application layer aliases 2.1. In HTTP and a few other protocols, we have the ability to do a = redirect inside the application layer protocol itself. We do not have = that in all protocols. In other we have things like the MX records. Do = we with IDN etc need more of these, and do we need a mechanism in DNS = that "help" such redirect in a "lower" layer in the resolution = algorithm? 2.2. When using HTTP HOST header, and SSL where the DN of the cert is = matched with the domain name used, it is kind of problematic to match = the application layer with what originally was entered by the user. Is = there some need for DNS layer aliases that changes what later is matched = in the application layer comparisons? 3. Comparison algorithm 3.1. We can not change the matching algorithm in DNS 3.2. Given we can not change the matching algorithm in DNS, do we need = something in DNS that matches some new(?) matching algorithm in the = application layer so that the two together produce the result we are = after? 4. How do we ensure skilled apps people manage to work with skilled DNS = people so that the end result is optimal? (something IETF is not always = very good at...) Now beat me up! Patrik From johnl@iecc.com Sun Feb 27 12:12:46 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 05BC53A67E2 for ; Sun, 27 Feb 2011 12:12:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.804 X-Spam-Level: X-Spam-Status: No, score=-110.804 tagged_above=-999 required=5 tests=[AWL=0.395, 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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DL+5xaUoy4Qh for ; Sun, 27 Feb 2011 12:12:45 -0800 (PST) Received: from gal.iecc.com (gal.iecc.com [64.57.183.53]) by core3.amsl.com (Postfix) with ESMTP id C0F693A67FD for ; Sun, 27 Feb 2011 12:12:44 -0800 (PST) Received: (qmail 24409 invoked from network); 27 Feb 2011 20:13:43 -0000 Received: from mail1.iecc.com (64.57.183.56) by mail1.iecc.com with QMQP; 27 Feb 2011 20:13:43 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:vbr-info; s=1d03.4d6ab076.k1102; i=johnl@user.iecc.com; bh=7DYFSdddIcgQB5yBGxzuHXTZw0IBMVM2LCIK9PNQn7w=; b=pKVM7sx7dKLOvAHKYKH4DLHZIkQAtRkLCU6FZmfphcSgRXVVKztBOx8jnl+A4qbW3eVO7jW7qnxie07GQrvb6pknXeMFyVNDS+irsq9tJbGZNhgtyBT/c4cEX2YhJJ+fidFOM3Vu9+UgegowxKNtq8WSkkngnSWruxS5+5k75sk= VBR-Info: md=iecc.com; mc=all; mv=dwl.spamhaus.org Date: 27 Feb 2011 20:13:42 -0000 Message-ID: <20110227201342.7426.qmail@joyce.lan> From: John Levine To: dnsext@ietf.org In-Reply-To: <91393.1298836460@nsa.vix.com> Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 7bit Subject: Re: [dnsext] Fwd: RFC 2308 & RFC 4035 X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 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, 27 Feb 2011 20:12:46 -0000 >> ... If the zone is a DNSBL, there will be a whole lot of nxdomain >> queries, particularly in an IPv6 world where spamware hops to a new IP >> on every message. > >i expect that most dnsbl's who evolve into ipv6 will also evolve a /64 >"wildcard" strategy to cope with malware-controllable low order bits. I expect that WLs will be more important than BLs, but they both have the same cache blasting problem if there's a different query for every IP. >but i also agree that the importance of negative caching and synthetic >nxdomains is usually underestimated and will rise as the network grows. Right. R's, John From vixie@isc.org Sun Feb 27 12:58:11 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 34E983A6842 for ; Sun, 27 Feb 2011 12:58:11 -0800 (PST) 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=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p7W4cq-M-tfk for ; Sun, 27 Feb 2011 12:58:10 -0800 (PST) Received: from nsa.vix.com (unknown [IPv6:2001:4f8:3:bb:230:48ff:fe5a:2f38]) by core3.amsl.com (Postfix) with ESMTP id 5D8663A6828 for ; Sun, 27 Feb 2011 12:58:10 -0800 (PST) Received: from nsa.vix.com (localhost [127.0.0.1]) by nsa.vix.com (Postfix) with ESMTP id EC3C6A1059 for ; Sun, 27 Feb 2011 20:59:06 +0000 (UTC) (envelope-from vixie@isc.org) From: Paul Vixie To: dnsext@ietf.org In-Reply-To: Your message of "27 Feb 2011 20:13:42 GMT." <20110227201342.7426.qmail@joyce.lan> References: <20110227201342.7426.qmail@joyce.lan> X-Mailer: MH-E 8.2; nmh 1.2; XEmacs 21.4 (patch 22) Date: Sun, 27 Feb 2011 20:59:06 +0000 Message-ID: <95991.1298840346@nsa.vix.com> Subject: Re: [dnsext] Fwd: RFC 2308 & RFC 4035 X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 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, 27 Feb 2011 20:58:11 -0000 > Date: 27 Feb 2011 20:13:42 -0000 > From: John Levine > > >i expect that most dnsbl's who evolve into ipv6 will also evolve a /64 > >"wildcard" strategy to cope with malware-controllable low order bits. > > I expect that WLs will be more important than BLs, but they both have > the same cache blasting problem if there's a different query for every > IP. having been sued out of the reputation business early on, i know the whole of the sherman antitrust act as well as i know the vein pattern on the back of my hand. there's a lot more trouble waiting for a WL operator than for a BL operator. noting, IANAL and this is not a technical thread any more. From bortzmeyer@nic.fr Mon Feb 28 00:48:02 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8C8043A6AC6 for ; Mon, 28 Feb 2011 00:48:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.949 X-Spam-Level: X-Spam-Status: No, score=-109.949 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i8Np6zau2mss for ; Mon, 28 Feb 2011 00:48:01 -0800 (PST) Received: from mx2.nic.fr (mx2.nic.fr [IPv6:2001:660:3003:2::4:11]) by core3.amsl.com (Postfix) with ESMTP id 441B33A6A81 for ; Mon, 28 Feb 2011 00:48:01 -0800 (PST) Received: from mx2.nic.fr (localhost [127.0.0.1]) by mx2.nic.fr (Postfix) with SMTP id EEED11C0038; Mon, 28 Feb 2011 09:48:59 +0100 (CET) Received: from relay2.nic.fr (relay2.nic.fr [192.134.4.163]) by mx2.nic.fr (Postfix) with ESMTP id EA0CD1C0021; Mon, 28 Feb 2011 09:48:59 +0100 (CET) Received: from bortzmeyer.nic.fr (batilda.nic.fr [192.134.4.69]) by relay2.nic.fr (Postfix) with ESMTP id DE0617B0037; Mon, 28 Feb 2011 09:48:59 +0100 (CET) Date: Mon, 28 Feb 2011 09:48:59 +0100 From: Stephane Bortzmeyer To: Alex Bligh Message-ID: <20110228084859.GA6668@nic.fr> References: <20110223001502.31614.56353.idtracker@localhost> <20110223114720.GA10740@bikeshed.isc.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Operating-System: Debian GNU/Linux 6.0 X-Kernel: Linux 2.6.32-5-686 i686 Organization: NIC France X-URL: http://www.nic.fr/ User-Agent: Mutt/1.5.20 (2009-06-14) Cc: dnsext@ietf.org Subject: Re: [dnsext] I-D Action:draft-ietf-dnsext-aliasing-requirements-00.txt X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 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, 28 Feb 2011 08:48:02 -0000 On Sat, Feb 26, 2011 at 01:07:54PM +0000, Alex Bligh wrote a message of 402 lines which said: > > technology; it can be done, and is done today, entirely with > > provisioning logic and registry policy. > > +AB: Note this isn't only a registry solution. It could be done by > +AB: users too (e.g. through a zonefile preprocessor that was > +AB: run prior to signing of the zone). A registry can be at any level. See the IDN RFCs which use the word "registry" for "anything that manage a zone, whether the zone is .com or foobar.momandpop.example". From alex@alex.org.uk Mon Feb 28 01:25:40 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8927C3A6AE6 for ; Mon, 28 Feb 2011 01:25:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.38 X-Spam-Level: X-Spam-Status: No, score=-2.38 tagged_above=-999 required=5 tests=[AWL=0.219, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QyGIa43sRsR7 for ; Mon, 28 Feb 2011 01:25:39 -0800 (PST) Received: from mail.avalus.com (mail.avalus.com [89.16.176.221]) by core3.amsl.com (Postfix) with ESMTP id 826103A6908 for ; Mon, 28 Feb 2011 01:25:38 -0800 (PST) Received: from [192.168.100.89] (87-194-71-186.bethere.co.uk [87.194.71.186]) by mail.avalus.com (Postfix) with ESMTPSA id 031A4C56062; Mon, 28 Feb 2011 09:26:36 +0000 (GMT) Date: Mon, 28 Feb 2011 09:26:36 +0000 From: Alex Bligh To: Stephane Bortzmeyer Message-ID: <694623190672302366251A5F@nimrod.local> In-Reply-To: <20110228084859.GA6668@nic.fr> References: <20110223001502.31614.56353.idtracker@localhost> <20110223114720.GA10740@bikeshed.isc.org> <20110228084859.GA6668@nic.fr> 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] I-D Action:draft-ietf-dnsext-aliasing-requirements-00.txt X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 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: Mon, 28 Feb 2011 09:25:40 -0000 --On 28 February 2011 09:48:59 +0100 Stephane Bortzmeyer wrote: >> > technology; it can be done, and is done today, entirely with >> > provisioning logic and registry policy. >> >> +AB: Note this isn't only a registry solution. It could be done by >> +AB: users too (e.g. through a zonefile preprocessor that was >> +AB: run prior to signing of the zone). > > A registry can be at any level. See the IDN RFCs which use the word > "registry" for "anything that manage a zone, whether the zone is .com > or foobar.momandpop.example". I'm not sure that's the natural meaning of the term, nor that that's how the draft uses it, e.g. from Section 5 in the I-D > In > addition, as described briefly above, registry operators have a great > many techniques for applying policy to what names can be registered, but if we going to use "registry" to mean "zone manager", we should say so. Otherwise, we should just say "zone manager" where it's applicable to more than registries (meaning ones allowing third party registrations). -- Alex Bligh From paul.hoffman@vpnc.org Mon Feb 28 07:02:30 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 444133A69FB for ; Mon, 28 Feb 2011 07:02:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.483 X-Spam-Level: X-Spam-Status: No, score=-101.483 tagged_above=-999 required=5 tests=[AWL=0.563, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ly9wXbwI6+ow for ; Mon, 28 Feb 2011 07:02:29 -0800 (PST) Received: from hoffman.proper.com (Hoffman.Proper.COM [207.182.41.81]) by core3.amsl.com (Postfix) with ESMTP id 7D9873A6947 for ; Mon, 28 Feb 2011 07:02:29 -0800 (PST) Received: from MacBook-08.local (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 p1SF2DiP076676 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Mon, 28 Feb 2011 08:02:14 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Message-ID: <4D6BB8F5.7000505@vpnc.org> Date: Mon, 28 Feb 2011 07:02:13 -0800 From: Paul Hoffman User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: dnsext@ietf.org References: <20110223001502.31614.56353.idtracker@localhost> <20110223114720.GA10740@bikeshed.isc.org> <20110228084859.GA6668@nic.fr> <694623190672302366251A5F@nimrod.local> In-Reply-To: <694623190672302366251A5F@nimrod.local> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [dnsext] I-D Action:draft-ietf-dnsext-aliasing-requirements-00.txt X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 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, 28 Feb 2011 15:02:30 -0000 On 2/28/11 1:26 AM, Alex Bligh wrote: > > > --On 28 February 2011 09:48:59 +0100 Stephane Bortzmeyer > wrote: > >>> > technology; it can be done, and is done today, entirely with >>> > provisioning logic and registry policy. >>> >>> +AB: Note this isn't only a registry solution. It could be done by >>> +AB: users too (e.g. through a zonefile preprocessor that was >>> +AB: run prior to signing of the zone). >> >> A registry can be at any level. See the IDN RFCs which use the word >> "registry" for "anything that manage a zone, whether the zone is .com >> or foobar.momandpop.example". > > I'm not sure that's the natural meaning of the term, nor that > that's how the draft uses it, e.g. from Section 5 in the I-D > >> In >> addition, as described briefly above, registry operators have a great >> many techniques for applying policy to what names can be registered, > > but if we going to use "registry" to mean "zone manager", we should > say so. Otherwise, we should just say "zone manager" where it's > applicable to more than registries (meaning ones allowing third > party registrations). > There may be a difference between registries and zone managers, but it is not in the protocol. A registry has some interface with (normally) humans to receive information about the creation of new zones and the DNS-applicable data for existing zones; registries are also expected to do authorization and authentication of those (normally) humans. Zone managers only deal with zone data, (normally) given to them by the registry for the zones being administered. Normally, there isn't a distinction between the two entities, but in the case of this document, there is. It is the registry that would be responsible for determining the aliases for a zone and enumerating them to the zone administrator. The zone administrator simply does the right technical bits to make all the aliases work. In many cases, the two roles will be the same for aliasing, but for many cases, they will be completely different organizations. --Paul Hoffman From hallam@gmail.com Mon Feb 28 07:06:28 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C745F3A6A06 for ; Mon, 28 Feb 2011 07:06:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.571 X-Spam-Level: X-Spam-Status: No, score=-3.571 tagged_above=-999 required=5 tests=[AWL=0.028, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 98o8yNrc6EFe for ; Mon, 28 Feb 2011 07:06:26 -0800 (PST) Received: from mail-bw0-f44.google.com (mail-bw0-f44.google.com [209.85.214.44]) by core3.amsl.com (Postfix) with ESMTP id 7A6603A6C20 for ; Mon, 28 Feb 2011 07:06:26 -0800 (PST) Received: by bwz13 with SMTP id 13so4338135bwz.31 for ; Mon, 28 Feb 2011 07:07:26 -0800 (PST) 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=Xt5yk3SemtBIm1vYAyR8lNCD9JyBYvFQxmbY+UPy1uE=; b=osl9iWXUmz9ujxyWDWyciQjUnZkhRIfplRVv1gZDiJtqVfHhpzuGZjPKza4ke6H4dK wmFlTOwiGZVbe5oBKzHN915oHqvCi8vUoPGk6C2JXEPzTnAtP9prdPze2bGmZOBURr5Y ZV5sjFAphNmucnhG3o7Yzsiu5/c16wRUzHBKg= 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=r6ZX+3ah/ndGN8PV5yR3I8Y7u7zDY1B1z8P1SM/+EheYLVJT9mwGovCJkBWovQgbc6 MwpcMmoaY1ueePrl/sXvQtd6PR3XyaMQa1m5FVP2uf5lsPHJVRanZyGOdWFjzCFXQ4oh HHB71N2j0UkWoYF/jjL46gr5dMePOQty+uvc0= MIME-Version: 1.0 Received: by 10.204.7.213 with SMTP id e21mr4837867bke.47.1298905646082; Mon, 28 Feb 2011 07:07:26 -0800 (PST) Received: by 10.204.14.139 with HTTP; Mon, 28 Feb 2011 07:07:26 -0800 (PST) In-Reply-To: References: <20110227182720.6537.qmail@joyce.lan> <552AB7D12FAB50296E795CF5@Ximines.local> Date: Mon, 28 Feb 2011 10:07:26 -0500 Message-ID: From: Phillip Hallam-Baker To: "John R. Levine" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: dnsext@ietf.org Subject: Re: [dnsext] the same in old days, was making names the same NEED protocol changes? X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 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, 28 Feb 2011 15:06:29 -0000 John is completely right here and it really demonstrates the need to have application level input into this discussion. Modern application protocols bind to DNS names and NOT to IP addresses. As far as we are concerned a DNS name is the only essential part of the Internet architecture. Applications do not and should not care about IP addresses. The few protocols that do rely on IP addresses break on modern NAT-ed networks as a result unless there is specific protocol level fixup. So attempting to make two names resolve alike without change at either the application client or the application server is a fools errand. It is not going to work because that is simply not how the applications see the world. If someone wants a2.com to work in exactly the same way as a1.com, then either the application client has to know to substitute a1 for a2 when it makes the request or the application server has to know to redirect a2 to a1. The security model of Web applications is complex and convoluted enough as it is. We have had almost 20 years now of protocol extensions being thrown in by people whose idea of a security consideration is 'tell me why it might be bad, too late its deployed'. And this proposal seems to be more of the same. I know that there are some people who will have just written in their response to the above something along the lines 'well thats their issue' or 'well they should fix it'. And that is exactly the type of thinking that got us into this problem. Security is real easy when you decide the hard part is someone else's problem. If we are going to change the security model we have to change the application client or things are going to break. If we decide we can change the application client, this whole problem becomes pretty straightforward. Either adopt the 'did you mean' pointer style approach or allow domains to nominate mappings of one charset to another. On Sun, Feb 27, 2011 at 3:00 PM, John R. Levine wrote: >> I think I'm being thick here. Doesn't the BNAME reference go the >> wrong way to autoconfigure a server based on it in a manner where >> there can be a security problem as a result? > > You're quite right. =A0SHADOW goes the right way, but requires a zone cut > everywhere that there's aliases. > > I'm not seeing any particularly pretty ways to fix BNAME to tell which on= es > are approved. =A0It's not unlike the rDNS problem. > > Regards, > John Levine, johnl@iecc.com, Primary Perpetrator of "The Internet for > Dummies", > Please consider the environment before reading this e-mail. http://jl.ly > _______________________________________________ > dnsext mailing list > dnsext@ietf.org > https://www.ietf.org/mailman/listinfo/dnsext > --=20 Website: http://hallambaker.com/ From Ed.Lewis@neustar.biz Mon Feb 28 07:07:12 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B9E603A6C0A for ; Mon, 28 Feb 2011 07:07:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.566 X-Spam-Level: X-Spam-Status: No, score=-102.566 tagged_above=-999 required=5 tests=[AWL=0.033, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9Xlz+0vcAsG8 for ; Mon, 28 Feb 2011 07:07:12 -0800 (PST) Received: from stora.ogud.com (stora.ogud.com [66.92.146.20]) by core3.amsl.com (Postfix) with ESMTP id C2DF83A6A06 for ; Mon, 28 Feb 2011 07:07:11 -0800 (PST) Received: from Work-Laptop-2.local (gatt.md.ogud.com [10.20.30.6]) by stora.ogud.com (8.14.4/8.14.4) with ESMTP id p1SF85YJ078823; Mon, 28 Feb 2011 10:08:06 -0500 (EST) (envelope-from Ed.Lewis@neustar.biz) Received: from [10.31.200.120] by Work-Laptop-2.local (PGP Universal service); Mon, 28 Feb 2011 10:08:11 -0500 X-PGP-Universal: processed; by Work-Laptop-2.local on Mon, 28 Feb 2011 10:08:11 -0500 Mime-Version: 1.0 Message-Id: In-Reply-To: <91393.1298836460@nsa.vix.com> References: <20110227183042.6563.qmail@joyce.lan> <91393.1298836460@nsa.vix.com> Date: Mon, 28 Feb 2011 10:08:03 -0500 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] Fwd: RFC 2308 & RFC 4035 X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 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, 28 Feb 2011 15:07:12 -0000 At 19:54 +0000 2/27/11, Paul Vixie wrote: >but i also agree that the importance of negative caching and synthetic >nxdomains is usually underestimated and will rise as the network grows. The "importance" mentioned above has to be put into the context of the shift of "power" this represents, the shift from authority to caches. That has architectural implications. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis NeuStar You can leave a voice message at +1-571-434-5468 Me to infant son: "Waah! Waah! Is that all you can say? Waah?" Son: "Waah!" From ajs@shinkuro.com Mon Feb 28 09:33:06 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 230643A6B2F for ; Mon, 28 Feb 2011 09:33:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.607 X-Spam-Level: X-Spam-Status: No, score=-102.607 tagged_above=-999 required=5 tests=[AWL=-0.008, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SvWmclmXEvF7 for ; Mon, 28 Feb 2011 09:33:05 -0800 (PST) Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by core3.amsl.com (Postfix) with ESMTP id 5BAD73A6A1D for ; Mon, 28 Feb 2011 09:33:05 -0800 (PST) Received: from crankycanuck.ca (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 2B7C21ECB41D for ; Mon, 28 Feb 2011 17:34:05 +0000 (UTC) Date: Mon, 28 Feb 2011 12:34:03 -0500 From: Andrew Sullivan To: dnsext@ietf.org Message-ID: <20110228173403.GK80597@shinkuro.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.18 (2008-05-17) Subject: [dnsext] DNSEXT at IETF 80 X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 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, 28 Feb 2011 17:33:06 -0000 Colleagues, We have received a 1 hour slot at the IETF meeting in Prague. It is on Monday afternoon at 15:10. Conflicts: Grand Ballroom INT dnsext DNS Extensions WG Barcelona INT lwig Light-Weight Implementation Guidance Karlin I OPS paws Protocol to Access WS database BOF Roma RAI avtext Audio/Video Transport Extensions WG Karlin II & III RTG isis IS-IS for IP Internets WG We believe there is no reason for us to request rescheduling, but if you know of something, please let me know. The deadline for rescheduling requests is this afternoon. A -- Andrew Sullivan ajs@shinkuro.com Shinkuro, Inc. From ted.ietf@gmail.com Mon Feb 28 09:37:57 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 88F273A6A1D for ; Mon, 28 Feb 2011 09:37:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.637 X-Spam-Level: X-Spam-Status: No, score=-3.637 tagged_above=-999 required=5 tests=[AWL=-0.038, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uQ8HeV+4iElx for ; Mon, 28 Feb 2011 09:37:56 -0800 (PST) Received: from mail-qw0-f44.google.com (mail-qw0-f44.google.com [209.85.216.44]) by core3.amsl.com (Postfix) with ESMTP id 7DF623A6C3B for ; Mon, 28 Feb 2011 09:37:56 -0800 (PST) Received: by qwh6 with SMTP id 6so3369789qwh.31 for ; Mon, 28 Feb 2011 09:38:57 -0800 (PST) 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=I8q7wBluY+ygZG1aHafEvBgvLwa6Dip+k2FgukyU4oM=; b=C5ms3IspqLJMgsmaf8OfRzle98r5Y2hzlBiaRtORRZrs6PziM9WA0RhQnSwmM30oaz nT/mKAX3+w2B5S0oHaW/EthhlDWZ/ihcs6Iv8O0LmsgAqXFHhQ/2DlW7SkdBQPTrACno zqciqCbB24Q2xJw2Gu3jMYj8sx3IMzGpg0rw8= 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=SjcReROsGWIsr+x+A4RhbFnFinDwwFKr2qCyQBJ6mb3Cm49HnfduQPd5MCm0vaL0Ka qnEgvEnfQqTNFSfBfeeRqd0/3LvaStm4aEPbd4AVD4bqitGJVzRZvBIFg7js3zqqKzN/ kMhNh3swBaIv9NRBH42xvAoJyYvvdprsLI5/c= MIME-Version: 1.0 Received: by 10.229.189.20 with SMTP id dc20mr4447708qcb.231.1298914736991; Mon, 28 Feb 2011 09:38:56 -0800 (PST) Received: by 10.229.98.210 with HTTP; Mon, 28 Feb 2011 09:38:56 -0800 (PST) In-Reply-To: References: <20110227182720.6537.qmail@joyce.lan> <552AB7D12FAB50296E795CF5@Ximines.local> Date: Mon, 28 Feb 2011 09:38:56 -0800 Message-ID: From: Ted Hardie To: Phillip Hallam-Baker Content-Type: text/plain; charset=ISO-8859-1 Cc: "John R. Levine" , dnsext@ietf.org Subject: Re: [dnsext] the same in old days, was making names the same NEED protocol changes? X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 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, 28 Feb 2011 17:37:57 -0000 On Mon, Feb 28, 2011 at 7:07 AM, Phillip Hallam-Baker wrote: > So attempting to make two names resolve alike without change at either > the application client or the application server is a fools errand. I'm not sure how you see this split based on the text above. My personal take is that if you want two names be "treated the same" by an application, you can do one of three things: 1) Make one name refer to the other, transforming the problem of "treating the same" into "pointing to the canonical name". 2) Provide for all the names equally, so that the same resources are available at each name (this means not just things like name-to-address mappings but also certificates with the names used on them etc.). This is expensive and difficult, but there may be some methods to reduce the pain (subjectAltName, provisioning-based mirroring of resources, new protocol methods). I think a lot of the discussion so far has been of the "are there useful DNS mechanisms that could reduce this pain"? 3) Create a method that allows applications to know which names should be treated as equivalent. The difficulty here is primarily that any names which are not within the same administrative boundary cannot be treated as equivalent without the records related to both/N administrative boundaries confirming the equivalence. So the application would have to understand how to determine the administrative boundaries, check for the confirmation of equivalence, and then correctly apply whatever behaviors result from the two names being the same. This is far from trivial, as the applications/protocols may have no defined behavior for "treat these as the same". Knowing they are to be treated as equivalent doesn't help a lot for applications with no sense of what behavior should result. > is not going to work because that is simply not how the applications > see the world. > > > > If we decide we can change the application client, this whole problem > becomes pretty straightforward. Either adopt the 'did you mean' > pointer style approach or allow domains to nominate mappings of one > charset to another. > Please do not use "mappings of one charset to another" to represent this problem. At this point, we are all mostly talking about the Unicode character set and how to map labels derived from sequences of Unicode characters. regards, Ted Hardie From schlitt@world.std.com Mon Feb 28 09:41:02 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A37463A6A1D for ; Mon, 28 Feb 2011 09:41:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.953 X-Spam-Level: X-Spam-Status: No, score=-2.953 tagged_above=-999 required=5 tests=[AWL=-0.646, BAYES_00=-2.599, MISSING_HEADERS=1.292, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CXNDnrE2CehZ for ; Mon, 28 Feb 2011 09:41:02 -0800 (PST) Received: from TheWorld.com (pcls6.std.com [192.74.137.146]) by core3.amsl.com (Postfix) with ESMTP id BB8F33A6C06 for ; Mon, 28 Feb 2011 09:41:01 -0800 (PST) Received: from shell.TheWorld.com (root@shell01.theworld.com [192.74.137.71]) by TheWorld.com (8.13.6/8.13.6) with ESMTP id p1SHeuJt012460 for ; Mon, 28 Feb 2011 12:40:58 -0500 Received: from shell01.TheWorld.com (localhost.theworld.com [127.0.0.1]) by shell.TheWorld.com (8.13.6/8.12.8) with ESMTP id p1SHetpc7056733 for ; Mon, 28 Feb 2011 12:40:56 -0500 (EST) Received: from localhost (schlitt@localhost) by shell01.TheWorld.com (8.13.6/8.13.6/Submit) with ESMTP id p1SHetuu6892829 for ; Mon, 28 Feb 2011 12:40:55 -0500 (EST) X-Authentication-Warning: shell01.TheWorld.com: schlitt owned process doing -bs Date: Mon, 28 Feb 2011 12:40:55 -0500 From: Dan Schlitt X-X-Sender: schlitt@shell01.TheWorld.com cc: dnsext@ietf.org In-Reply-To: <335963D7-3440-45E6-843C-38F419462792@cisco.com> Message-ID: References: <20110227191542.6824.qmail@joyce.lan> <335963D7-3440-45E6-843C-38F419462792@cisco.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Subject: Re: [dnsext] I-D Action:draft-ietf-dnsext-aliasing-requirements-00.txt X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 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, 28 Feb 2011 17:41:02 -0000 Back when this discussion started a long time ago I thinkit was perhaps the first message that listed a number of possible approaches. One of them was a presentation layer in the DNS. The statement with this was that it had been rejected earlier and so need not be considered. As this long discussion has gone on with more problems than solutions I have often thought "now wouldn't that problem be better avoided with a presentation layer." Isn't the problem what domain name the user asks for and getting the right behaviour from the DNS. Isn't this a presentation problem and not a problem of the basic DNS? Weren't we told that we weren't dealing with "words" even though some things might look like words. This means that we don't have to deal with things like the difference between american english and british english. If this is actually an application layer problem isn't it reasonable to look for a way to fix it generally instead of expecting each application to do it for itself. This suggests placing something between the application and the DNS. Is there some way that the WG can get out of this pattern of going round and round over the same old territory? /dan -- Dan Schlitt schlitt@world.std.com From ebw@abenaki.wabanaki.net Mon Feb 28 10:08:33 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2BD593A6C3D for ; Mon, 28 Feb 2011 10:08:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.377 X-Spam-Level: X-Spam-Status: No, score=-2.377 tagged_above=-999 required=5 tests=[AWL=0.222, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QWk2Wt4VwrXy for ; Mon, 28 Feb 2011 10:08:32 -0800 (PST) Received: from abenaki.wabanaki.net (abenaki.wabanaki.net [65.99.1.133]) by core3.amsl.com (Postfix) with ESMTP id 2C7273A6C34 for ; Mon, 28 Feb 2011 10:08:32 -0800 (PST) Received: from limpet.local (cpe-67-255-5-237.twcny.res.rr.com [67.255.5.237]) by abenaki.wabanaki.net (8.14.4/8.14.4) with ESMTP id p1SGLtlS028110 for ; Mon, 28 Feb 2011 11:21:55 -0500 (EST) (envelope-from ebw@abenaki.wabanaki.net) Message-ID: <4D6BE4D6.3030103@abenaki.wabanaki.net> Date: Mon, 28 Feb 2011 13:09:26 -0500 From: Eric Brunner-Williams Organization: wampumpeag User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: dnsext@ietf.org References: <20110227182720.6537.qmail@joyce.lan> <552AB7D12FAB50296E795CF5@Ximines.local> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [dnsext] the same in old days, was making names the same NEED protocol changes? X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 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, 28 Feb 2011 18:08:33 -0000 >> If we decide we can change the application client, this whole problem >> becomes pretty straightforward. Either adopt the 'did you mean' >> pointer style approach or allow domains to nominate mappings of one >> charset to another. >> > Please do not use "mappings of one charset to another" to represent > this problem. At this point, we are all mostly talking about the > Unicode character set and how to map labels derived from sequences of > Unicode characters. well ... it is the case that we have distinct ranges of values, subsetting within the Unicode character repertoire, and have, or have considered, rules concerning labels composed of values from distinct regions. the latin vs arabic vs indic digit discussion is one example with three very modest subsets of that repertoire. should "mixing digits" be allowed, pro and con claims followed, invoking directionality or similarity, depending upon the choices of subsets to be . there are other examples. so it isn't incorrect to reference, though perhaps charset is misleading, mappings from one subset of values to another, in the same repertoire. the subsets may, or may not, be contiguous and disjoint, or consist of a common set, and two or more point-wise disjoint subsets of a single additional set (sc/tc). -e From vixie@isc.org Mon Feb 28 10:25:12 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 79AB83A6C1E for ; Mon, 28 Feb 2011 10:25:12 -0800 (PST) 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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K0fs4L3U-8JL for ; Mon, 28 Feb 2011 10:25:11 -0800 (PST) Received: from nsa.vix.com (unknown [IPv6:2001:4f8:3:bb:230:48ff:fe5a:2f38]) by core3.amsl.com (Postfix) with ESMTP id 0F99A3A6AA4 for ; Mon, 28 Feb 2011 10:25:11 -0800 (PST) Received: from nsa.vix.com (localhost [127.0.0.1]) by nsa.vix.com (Postfix) with ESMTP id 8803FA1059 for ; Mon, 28 Feb 2011 18:26:10 +0000 (UTC) (envelope-from vixie@isc.org) From: Paul Vixie To: dnsext@ietf.org In-Reply-To: Your message of "Mon, 28 Feb 2011 12:40:55 EST." References: <20110227191542.6824.qmail@joyce.lan> <335963D7-3440-45E6-843C-38F419462792@cisco.com> X-Mailer: MH-E 8.2; nmh 1.2; XEmacs 21.4 (patch 22) Date: Mon, 28 Feb 2011 18:26:10 +0000 Message-ID: <67832.1298917570@nsa.vix.com> Subject: Re: [dnsext] I-D Action:draft-ietf-dnsext-aliasing-requirements-00.txt X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 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, 28 Feb 2011 18:25:12 -0000 > Date: Mon, 28 Feb 2011 12:40:55 -0500 > From: Dan Schlitt > ... > Is there some way that the WG can get out of this pattern of going round > and round over the same old territory? yes. declare defeat. see Message-ID: <10710.1298046433@nsa.vix.com>. From alex@alex.org.uk Mon Feb 28 10:45:35 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6E05E3A6C27 for ; Mon, 28 Feb 2011 10:45:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.405 X-Spam-Level: X-Spam-Status: No, score=-2.405 tagged_above=-999 required=5 tests=[AWL=0.195, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DFlUtujylwYI for ; Mon, 28 Feb 2011 10:45:34 -0800 (PST) Received: from mail.avalus.com (mail.avalus.com [89.16.176.221]) by core3.amsl.com (Postfix) with ESMTP id 99D273A6C13 for ; Mon, 28 Feb 2011 10:45:33 -0800 (PST) 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 2B92FC56062; Mon, 28 Feb 2011 18:46:32 +0000 (GMT) Date: Mon, 28 Feb 2011 18:46:32 +0000 From: Alex Bligh To: Dan Schlitt Message-ID: In-Reply-To: References: <20110227191542.6824.qmail@joyce.lan> <335963D7-3440-45E6-843C-38F419462792@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: dnsext@ietf.org Subject: Re: [dnsext] I-D Action:draft-ietf-dnsext-aliasing-requirements-00.txt X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 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: Mon, 28 Feb 2011 18:45:35 -0000 --On 28 February 2011 12:40:55 -0500 Dan Schlitt wrote: > Back when this discussion started a long time ago I thinkit was perhaps > the first message that listed a number of possible approaches. One of > them was a presentation layer in the DNS. The statement with this was > that it had been rejected earlier and so need not be considered. > > As this long discussion has gone on with more problems than solutions I > have often thought "now wouldn't that problem be better avoided with a > presentation layer." I believe every possibility (including doing nothing) has been rejected at least once, so on that basis +1 to this being (re)considered at least to the extent of being included in the draft as a possibility. -- Alex Bligh From alex@alex.org.uk Mon Feb 28 10:46:17 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3AC303A6C60 for ; Mon, 28 Feb 2011 10:46:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.424 X-Spam-Level: X-Spam-Status: No, score=-2.424 tagged_above=-999 required=5 tests=[AWL=0.175, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lsx6lCyqZz1C for ; Mon, 28 Feb 2011 10:46:16 -0800 (PST) Received: from mail.avalus.com (mail.avalus.com [89.16.176.221]) by core3.amsl.com (Postfix) with ESMTP id 6998F3A6C49 for ; Mon, 28 Feb 2011 10:46:16 -0800 (PST) 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 6C990C56896; Mon, 28 Feb 2011 18:47:16 +0000 (GMT) Date: Mon, 28 Feb 2011 18:47:15 +0000 From: Alex Bligh To: Paul Vixie , dnsext@ietf.org Message-ID: <24A297B71A849B92039485E0@Ximines.local> In-Reply-To: <67832.1298917570@nsa.vix.com> References: <20110227191542.6824.qmail@joyce.lan> <335963D7-3440-45E6-843C-38F419462792@cisco.com> <67832.1298917570@nsa.vix.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 Subject: Re: [dnsext] I-D Action:draft-ietf-dnsext-aliasing-requirements-00.txt X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 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: Mon, 28 Feb 2011 18:46:17 -0000 --On 28 February 2011 18:26:10 +0000 Paul Vixie wrote: >> Is there some way that the WG can get out of this pattern of going round >> and round over the same old territory? > > yes. declare defeat. see Message-ID: <10710.1298046433@nsa.vix.com>. I think defeat has been rejected too :-) -- Alex Bligh From ajs@shinkuro.com Mon Feb 28 10:53:49 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2B5043A6C5C for ; Mon, 28 Feb 2011 10:53:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.607 X-Spam-Level: X-Spam-Status: No, score=-102.607 tagged_above=-999 required=5 tests=[AWL=-0.008, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4Qqvd7Db8P0H for ; Mon, 28 Feb 2011 10:53:45 -0800 (PST) Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by core3.amsl.com (Postfix) with ESMTP id 20A293A6C4C for ; Mon, 28 Feb 2011 10:53:45 -0800 (PST) Received: from crankycanuck.ca (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 581E31ECB41D for ; Mon, 28 Feb 2011 18:54:45 +0000 (UTC) Date: Mon, 28 Feb 2011 13:54:43 -0500 From: Andrew Sullivan To: dnsext@ietf.org Message-ID: <20110228185442.GN80597@shinkuro.com> References: <20110227191542.6824.qmail@joyce.lan> <335963D7-3440-45E6-843C-38F419462792@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.18 (2008-05-17) Subject: [dnsext] How to bring discussion to a close (was: I-D Action:draft-ietf-dnsext-aliasing-requirements-00.txt) X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 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, 28 Feb 2011 18:53:49 -0000 On Mon, Feb 28, 2011 at 06:46:32PM +0000, Alex Bligh wrote: > I believe every possibility (including doing nothing) has been > rejected at least once, so on that basis +1 to this being (re)considered > at least to the extent of being included in the draft as a possibility. I can't speak for others, but I have not rejected every possibility at least once; I have rather attempted to encourage some exploration of possiblities in the interests of getting the problem statement correct. The editors of the problem statement are in earnest request of text, so if you have observations that you think could be turned into useful parts of that document, I urge you to send it. I am told by the editors that there will be a -01 before IETF 80. Consistent with what we said when raising the possibility of not requesting a session at the Prague meeting, your chairs are eager to wind up discussion on the problem analysis. The only reason we requested the session in Prague was the renewed discussion of this topic. So we are quite keen to finish laying out the issues, ideally after the Prague session. At that point, we can ask properly whether we have proposals that will solve the problem as we understand it. Best, A -- Andrew Sullivan ajs@shinkuro.com Shinkuro, Inc. From ted.ietf@gmail.com Mon Feb 28 11:41:52 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 95A653A6A2A for ; Mon, 28 Feb 2011 11:41:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.335 X-Spam-Level: X-Spam-Status: No, score=-3.335 tagged_above=-999 required=5 tests=[AWL=-0.336, BAYES_00=-2.599, J_CHICKENPOX_57=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L4R00RfvZgdU for ; Mon, 28 Feb 2011 11:41:51 -0800 (PST) Received: from mail-qy0-f172.google.com (mail-qy0-f172.google.com [209.85.216.172]) by core3.amsl.com (Postfix) with ESMTP id A5F6B3A6A24 for ; Mon, 28 Feb 2011 11:41:51 -0800 (PST) Received: by qyk29 with SMTP id 29so2363488qyk.10 for ; Mon, 28 Feb 2011 11:42:52 -0800 (PST) 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=yfKdagJyhCpMDeQhgxovK/8J2mWcHgfN8yS7XOyR9V4=; b=PbW6kIanTcd1imPfoCbKTP+vbPkfwlpjc2T4IlkH4YJ0EccDjLpPHaBvK1ynlahv0z tv1Zyw902h7nueZVGlwEgwNYxJoUEsw4aEz/pAtN0BKEcYnv36GQUn+hJcQcnObGUu+R 1zyNMSxZ7261/WH4wlKDUVDCRESTZJ1WOVMmk= 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=Ib2GaEKpJGtWzh3d80p5W5eHKkbiXXQ9Y83pOb865m99CSYyrkUZlbK2Sfw9d3dZ1e ELu6MCTMFZFwAdF0DL/ld00QjUIg4rkvwXVis4gJ9aYnjF9go9g48lxfXcb/4Fw4Aqdo oQMLQvHt3qKXOMrZqT5ef+AF452HeamJf1yOY= MIME-Version: 1.0 Received: by 10.229.192.15 with SMTP id do15mr4582122qcb.155.1298922172346; Mon, 28 Feb 2011 11:42:52 -0800 (PST) Received: by 10.229.98.210 with HTTP; Mon, 28 Feb 2011 11:42:52 -0800 (PST) In-Reply-To: <4D6BE4D6.3030103@abenaki.wabanaki.net> References: <20110227182720.6537.qmail@joyce.lan> <552AB7D12FAB50296E795CF5@Ximines.local> <4D6BE4D6.3030103@abenaki.wabanaki.net> Date: Mon, 28 Feb 2011 11:42:52 -0800 Message-ID: From: Ted Hardie To: Eric Brunner-Williams Content-Type: text/plain; charset=ISO-8859-1 Cc: dnsext@ietf.org Subject: Re: [dnsext] the same in old days, was making names the same NEED protocol changes? X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 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, 28 Feb 2011 19:41:52 -0000 On Mon, Feb 28, 2011 at 10:09 AM, Eric Brunner-Williams wrote: >perhaps charset is misleading, I think at this point casting the "sameness" problem in terms of charset mapping is more than misleading. In IETF terms, a charset is a character repertoire in a particular encoding. The IDN effort can be seen as changing the character repertoire in a way that re-used the previous codepoints in a new encoding. That was hard enough for people to get their heads around. At the label level, .xn--fiqz9s and xn--fiqs8s being equivalent is no different from colour.example and color.example being "the same". Let's not confuse our terminology further, please. regards, Ted Hardie From ebw@abenaki.wabanaki.net Mon Feb 28 11:50:07 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 84C473A6C69 for ; Mon, 28 Feb 2011 11:50:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.414 X-Spam-Level: X-Spam-Status: No, score=-2.414 tagged_above=-999 required=5 tests=[AWL=0.185, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sPp0CQJsUsZT for ; Mon, 28 Feb 2011 11:50:06 -0800 (PST) Received: from abenaki.wabanaki.net (abenaki.wabanaki.net [65.99.1.133]) by core3.amsl.com (Postfix) with ESMTP id 2F8CF3A6C59 for ; Mon, 28 Feb 2011 11:50:05 -0800 (PST) Received: from limpet.local (cpe-67-255-5-237.twcny.res.rr.com [67.255.5.237]) by abenaki.wabanaki.net (8.14.4/8.14.4) with ESMTP id p1SI3OTF030305; Mon, 28 Feb 2011 13:03:25 -0500 (EST) (envelope-from ebw@abenaki.wabanaki.net) Message-ID: <4D6BFCA0.80806@abenaki.wabanaki.net> Date: Mon, 28 Feb 2011 14:50:56 -0500 From: Eric Brunner-Williams Organization: wampumpeag User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: Ted Hardie References: <20110227182720.6537.qmail@joyce.lan> <552AB7D12FAB50296E795CF5@Ximines.local> <4D6BE4D6.3030103@abenaki.wabanaki.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: dnsext@ietf.org Subject: Re: [dnsext] the same in old days, was making names the same NEED protocol changes? X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 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, 28 Feb 2011 19:50:07 -0000 do you seriously think phillip was contemplating playing shuttlecock with a pair of labels, one GB, one Big5? i didn't. From ajs@shinkuro.com Mon Feb 28 12:10:19 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0F9FD3A6C8A for ; Mon, 28 Feb 2011 12:10:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.607 X-Spam-Level: X-Spam-Status: No, score=-102.607 tagged_above=-999 required=5 tests=[AWL=-0.008, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yNGOoZMlsQe1 for ; Mon, 28 Feb 2011 12:10:18 -0800 (PST) Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by core3.amsl.com (Postfix) with ESMTP id 46D513A6C89 for ; Mon, 28 Feb 2011 12:10:18 -0800 (PST) Received: from crankycanuck.ca (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 C828E1ECB41D for ; Mon, 28 Feb 2011 20:11:18 +0000 (UTC) Date: Mon, 28 Feb 2011 15:11:17 -0500 From: Andrew Sullivan To: dnsext@ietf.org Message-ID: <20110228201116.GP80597@shinkuro.com> References: <20110227182720.6537.qmail@joyce.lan> <552AB7D12FAB50296E795CF5@Ximines.local> <4D6BE4D6.3030103@abenaki.wabanaki.net> <4D6BFCA0.80806@abenaki.wabanaki.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4D6BFCA0.80806@abenaki.wabanaki.net> User-Agent: Mutt/1.5.18 (2008-05-17) Subject: [dnsext] Terminological precision (was: the same in old days, was making names the same NEED protocol changes?) X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 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, 28 Feb 2011 20:10:19 -0000 On Mon, Feb 28, 2011 at 02:50:56PM -0500, Eric Brunner-Williams wrote: > do you seriously think phillip was contemplating playing shuttlecock > with a pair of labels, one GB, one Big5? Speaking as one who is going to have the happy task of determining consensus on this topic, but with no particular official role, I appreciate Ted's insistence on terminological precision. For instance, I foolishly failed to cut off a debate about mixed case lookup, which led to speculation about problems that nobody actually has. I was wrong to have let it go on, and I'd like to learn from that mistake by not making it again. Allowing discussions of more than one character set is actually going to be worse, because some people will forget that we're talking always about DNS labels, which either have no character set at all or else are US-ASCII (and likely LDH, at that). A -- Andrew Sullivan ajs@shinkuro.com Shinkuro, Inc. From ted.ietf@gmail.com Mon Feb 28 12:11:30 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 244C33A6C8F for ; Mon, 28 Feb 2011 12:11:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.612 X-Spam-Level: X-Spam-Status: No, score=-3.612 tagged_above=-999 required=5 tests=[AWL=-0.013, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ss7oFswDmq3F for ; Mon, 28 Feb 2011 12:11:18 -0800 (PST) Received: from mail-qw0-f44.google.com (mail-qw0-f44.google.com [209.85.216.44]) by core3.amsl.com (Postfix) with ESMTP id 11F953A6C85 for ; Mon, 28 Feb 2011 12:11:15 -0800 (PST) Received: by qwh6 with SMTP id 6so3499720qwh.31 for ; Mon, 28 Feb 2011 12:12:17 -0800 (PST) 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=/tmD8g/RRhVUTy+zTy2QoCXqV+c5dJAxsUNgpen4Z8Y=; b=ZCHNYkG/SvWF5/Xw2lwndpGS8gKf0LYWf1swBddKCF4N/Gmo3E5OloALpZxCg4sVOL TOtqp2W5khBRtpftLgf454vcaVO2K5lRc7nv61BGdD7yg4nGju5quVlLaiNy0Vrpc/Lo Jzrt+rpSW3VYvfY3M/VIsA2VDx57DDlOW2SIU= 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=h/s6iyR/x8viQ0GRfR4tKY/POdekRvs1hyBrXKshKu6tXSJu701dN5P2lnTvUpjPZN bBA1oQiEVPBv75KW8JUjknqEzUvtddVgLvQEP8v8whAas+3yKPkYxgusBvssuY5sT4rc ee65jkHI0oBB9bvwi6tFkuIRksKdhalU+QnYc= MIME-Version: 1.0 Received: by 10.229.220.133 with SMTP id hy5mr4614619qcb.269.1298923936770; Mon, 28 Feb 2011 12:12:16 -0800 (PST) Received: by 10.229.98.210 with HTTP; Mon, 28 Feb 2011 12:12:16 -0800 (PST) In-Reply-To: <4D6BFCA0.80806@abenaki.wabanaki.net> References: <20110227182720.6537.qmail@joyce.lan> <552AB7D12FAB50296E795CF5@Ximines.local> <4D6BE4D6.3030103@abenaki.wabanaki.net> <4D6BFCA0.80806@abenaki.wabanaki.net> Date: Mon, 28 Feb 2011 12:12:16 -0800 Message-ID: From: Ted Hardie To: Eric Brunner-Williams Content-Type: text/plain; charset=ISO-8859-1 Cc: dnsext@ietf.org Subject: Re: [dnsext] the same in old days, was making names the same NEED protocol changes? X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 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, 28 Feb 2011 20:11:32 -0000 On Mon, Feb 28, 2011 at 11:50 AM, Eric Brunner-Williams wrote: > do you seriously think phillip was contemplating playing shuttlecock with a > pair of labels, one GB, one Big5? > > i didn't. > Keeping the language consistent helps. That's all my request was intended for. regards, Ted Hardie From Niall.oReilly@ucd.ie Mon Feb 28 16:37:44 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 41DC73A6D02 for ; Mon, 28 Feb 2011 16:37:44 -0800 (PST) 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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9GYBhuKimTxb for ; Mon, 28 Feb 2011 16:37:38 -0800 (PST) Received: from smtp.ucd.ie (mgmtirp1.ucd.ie [137.43.231.111]) by core3.amsl.com (Postfix) with ESMTP id A8DEF3A6D06 for ; Mon, 28 Feb 2011 16:37:37 -0800 (PST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApIBAGrPa01TjVE0/2dsb2JhbAAMhBzNepBkgSeBV4FtdgSPUSY X-IronPort-AV: E=Sophos;i="4.62,244,1297036800"; d="scan'208";a="2732358" Received: from unknown (HELO [10.0.1.177]) ([83.141.81.52]) by smtp.ucd.ie with ESMTP/TLS/DHE-RSA-CAMELLIA256-SHA; 01 Mar 2011 00:38:36 +0000 Message-ID: <4D6C3FD3.7010801@ucd.ie> Date: Tue, 01 Mar 2011 00:37:39 +0000 From: Niall O'Reilly User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-IE.utf8; rv:1.9.2.13) Gecko/20101208 Thunderbird/3.1.7 MIME-Version: 1.0 To: dnsext@ietf.org References: <20110227191542.6824.qmail@joyce.lan> <335963D7-3440-45E6-843C-38F419462792@cisco.com> In-Reply-To: <335963D7-3440-45E6-843C-38F419462792@cisco.com> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Subject: Re: [dnsext] I-D Action:draft-ietf-dnsext-aliasing-requirements-00.txt X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 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, 01 Mar 2011 00:37:44 -0000 On 27/02/11 20:08, Patrik Fältström wrote: > There are a few things I think makes this discussion hard...and that > is that the overall usability is a requirement in the usability, > manageability etc while what we talk about is "only" what we do in > DNS. What we should (and can) do in DNS must then match whatever > application layer/protocol behaviour, which in turn depends on how > the protocol works. Or, should we look at the use cases at a higher level, and identify which components, including (but not limited to) the DNS, need to be adjusted to achieve the desired result? In this case, the question becomes no longer one of matching the DNS to how the other components actually work, but to how they will work in the future to support a coherent, rather than a fragmented, "aliasing" concept. I'm pretty sure that solving "the aliasing problem", whatever it is, cannot be done by adjusting only the DNS. > What I *think* could be interesting is one of these things as very > high level issues to look at, that btw I think sort of is written in the > draft, but using DNS terminology ;-) I'm not sure quite what you're saying. Expressing higher-level issues in DNS terminology can either help us to visualize those issues, or blind us to the non-DNS aspects; perhaps both of these effects occur at the same time. > 1. Aliases > > 1.1. If we today have two delegations, we do have a risk that one of > the delegations changes holder while the other does not. Can one of the > two be an alias to the other, and the two then bundled by policy in the > registry so we absolutely know one and only one holder controls the data > for the names (plural)? > > 1.2. If we today have two delegations, synchronization of the two > delegations imply provisioning systems must place the same records in > two zones. Can we solve the problem in different ways? I believe that this is one strong attraction of the BNAME concept. Performing pseudo-delegation in parallel with traditional delegation in the parent zone leaves the registrant/deleg[at]ee with just a canonical instance of the child zone to look after. But this only applies when there is a common (bundle of) parent zone(s). So, it would work for example[+/-final_sigma+/-tonos].gr, but not for the vixie.sf.ca.us/vix.com bundle mentioned in Paul's slides of almost a year ago. That this is so is not intrinsically problematic, as the motivations are different in each case. In the .gr (also .cn, IIUC) case, the motivation appears (to me) to arise from a desire on the part of the TLD registry to provide a coherent offering to customers (registrants) in support of what might be called "naturally arising" bundles. Paul's example is rather "bottom-up" than "top-down", and is driven by the customer rather than by the provider (or the provider's politico-regulatory circumstances). > 2. Support of more application layer aliases More in terms of quantity, or just "more coherent"? > 2.1. In HTTP and a few other protocols, we have the ability to do a > redirect inside the application layer protocol itself. We do not have > that in all protocols. In other we have things like the MX records. Do > we with IDN etc need more of these, and do we need a mechanism in DNS > that "help" such redirect in a "lower" layer in the resolution algorithm? SMTP has MX; others have SRV; HTTP is an outlier in that it avoids this kind of assistance from the DNS. It's a significant and pathological outlier because of the way HTTPS works. > 2.2. When using HTTP HOST header, and SSL where the DN of the cert > is matched with the domain name used, it is kind of problematic to match > the application layer with what originally was entered by the user. Is > there some need for DNS layer aliases that changes what later is matched > in the application layer comparisons? 2.3 (?) It may be worth examining the semantics of distinct, but seductively similar, elements in different URL schemes. For example, in the "mailto:" URL scheme, there is a "domain part" which is essentially a reference to a naming authority. In contrast, the "http:" scheme uses a superficially similar component strictly as a reference to a host. This is arguably an incoherence at the semantic level between the different URL schemes which, if resolved, could eliminate the difficulty which arises today from matching the DN of the cert to the "host" component of a URL whose scheme is "http:". I'm suggesting that this incoherence should be resolved by having the application exploit already available DNS mechanisms. New DNS-layer aliasing seems to be un-necessary. Re-writing the definition of the "http" URL scheme so that not only 'http' ':' '//' host [: port] '/' ... but also 'http' ':' '//' domain-part '/' ... would be allowed, might lead to a resolution based on SRV records. I suggest that this approach is worth following, and will be no more painful than transitions we have already chosen (or been forced) to face, as between A and MX, or between A and AAAA records. If we want the omelette, we can't insist on not breaking the eggs. With this approach the DN of the SSL cert would match the target host of each SRV record. > 3. Comparison algorithm > > 3.1. We can not change the matching algorithm in DNS > > 3.2. Given we can not change the matching algorithm in DNS, do we > need something in DNS that matches some new(?) matching algorithm in the > application layer so that the two together produce the result we are after? For example, in the case where the HTTP HOST header refers to a domain-part for which the server is not configured, the server might query the DNS for a matching [BCD]NAME record, and use the URL corresponding to the corresponding canonical name (which it could cache) as the key to its document store. Alternatively, in the same circumstances, the server could send the browser a "please canonicalize" error response. Either of these approaches, if feasible, would appear to eliminate the need to pre-configure an application server for all of the potential "equivalent keys" which might appear in an incoming request. > 4. How do we ensure skilled apps people manage to work with skilled > DNS people so that the end result is optimal? (something IETF is not > always very good at...) Pass ... 8-) IHTH, but I'm not at all sure. I think we're still in a brainstorming phase, so "off-the-wall" is (so I hope) not necessarily "bad". Niall