From marc.lampo@eurid.eu Thu Sep 1 00:23:10 2011 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AC07C21F8581 for ; Thu, 1 Sep 2011 00:23:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.443 X-Spam-Level: X-Spam-Status: No, score=-8.443 tagged_above=-999 required=5 tests=[AWL=0.707, BAYES_00=-2.599, MSGID_MULTIPLE_AT=1.449, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pwNEGQjSGdn2 for ; Thu, 1 Sep 2011 00:23:09 -0700 (PDT) Received: from barra.eurid.eu (mx.eurid.eu [212.190.206.103]) by ietfa.amsl.com (Postfix) with ESMTP id 786F121F8513 for ; Thu, 1 Sep 2011 00:23:08 -0700 (PDT) X-ASG-Debug-ID: 1314861875-0369494a379b3d0001-uIE7UK Received: from zimbra.eurid.eu (zcs-master.vt.eurid.eu [10.19.100.121]) by barra.eurid.eu with ESMTP id 7ZWV8Pyhx8cXaRBG; Thu, 01 Sep 2011 09:24:35 +0200 (CEST) X-Barracuda-Envelope-From: marc.lampo@eurid.eu X-ASG-Whitelist: Client Received: from localhost (localhost.localdomain [127.0.0.1]) by zimbra.eurid.eu (Postfix) with ESMTP id 3B552E408C; Thu, 1 Sep 2011 09:24:35 +0200 (CEST) X-Virus-Scanned: amavisd-new at techmail.eurid.eu Received: from zimbra.eurid.eu ([127.0.0.1]) by localhost (zimbra.eurid.eu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6XLJ0OQGPE4w; Thu, 1 Sep 2011 09:24:35 +0200 (CEST) Received: from zimbra.eurid.eu (zimbra.eurid.eu [10.19.100.120]) by zimbra.eurid.eu (Postfix) with ESMTP id 129F8E4079; Thu, 1 Sep 2011 09:24:35 +0200 (CEST) From: "Marc Lampo" To: "'Andrew Sullivan'" , References: <20110830162134.GB84494@shinkuro.com> In-Reply-To: <20110830162134.GB84494@shinkuro.com> Date: Thu, 1 Sep 2011 09:24:35 +0200 (CEST) X-ASG-Orig-Subj: RE: [dnsext] afasterinternet.com trial and draft-vandergaast-edns-client-subnet-00 Message-ID: <004201cc6878$39116fb0$ab344f10$@lampo@eurid.eu> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 X-Mailer: Zimbra 6.0.10_GA_2692 (ZimbraConnectorForOutlook/5.0.3064.18) Thread-Index: AcxnMOJRMUe+YHENS3K3ekEF7uJDYgBQo2ZA Content-Language: en-za X-Originating-IP: [172.20.1.97] X-Barracuda-Connect: zcs-master.vt.eurid.eu[10.19.100.121] X-Barracuda-Start-Time: 1314861875 X-Barracuda-URL: http://172.20.1.190:8000/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at eurid.eu Cc: dnsext@ietf.org Subject: Re: [dnsext] afasterinternet.com trial and draft-vandergaast-edns-client-subnet-00 X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Sep 2011 07:23:10 -0000 Hello, As one of the authors observed in a reaction to this posting, the publication of this draft went mostly unnoticed - I must admit I missed it as well ... But now that I have read it, I have one observation regarding the content (something I feel is missing) and one global, "architectural", remark. About the content : In my opinion the impact of DNSSEC is underestimated when the RFC refers to an "optimized reply". Assuming a service has multiple address records, optimization could mean - order the address records in such a way that the "most optimal address" is first, in the reply from authoritative name server to caching name server. (which assumes that that caching name server will not change the order again) --> (for DNSSEC) the RRset remains complete, corresponding RRSIG's can be used - only the "most optimal address for this client" is returned. --> (for DNSSEC) the RRset is *modified*, the RRSIG must be recalculated ! For an authoritative name server, implementing DNSSEC and this RFC, it probably implies that it must be able to calculate RRSIG's "on the fly"; Which implies that it must have access to the private part of DNSKEY's; Which implies that signing on a hidden master and distributing signed data to public slaves is not enough. Though I know some name server implementations implement "on the fly signing", I'm hesitant about the consequence of having to transport the private parts of DNSKEY's to all Internet facing name servers. For this RFC, I suggest some additional text is added to describe consequences of implementing both DNSSEC and this RFC. About the architecture : Although there is much merit in offering a public, resolving, service (for individual PC's), it is quite dangerous for companies to have their (internal) caching name service forward (only) to such a service ! A (slight) variation of Dan Kaminski's cache poisoning attack could really cause big Problems in such a setup. Without going in too much detail, 1) a forwarding name server must accept more additional data than a non-forwarding one ! Basically because it asks one question, expects one useable reply. 2) the window-of-opportunity for a cache poisoning attack is *seconds* !!! (with Dan Kaminsky : *fractions* of seconds : it closes when the reply from the auth NS arrives) The only (full proof) way for the forwarding name server to defend against this, is by validating (DNSSEC) received answers. To that purpose, the forwarding name server will need more info (like DS records). Which brings me to a demand to those organisations offering such a public, resolving, service : Please *do start* to implement DNSSEC *first*, so that at least this public name service knows where to look for DS records ! (you could leave the actual verification of signatures to your users - who wish to do so. In Bind syntax : options { ... dnssec-enable yes; // <-- name server knows where to look for for DS records dnssec-validation no; // <-- at your discretion to validate yourself, or not }; Kind regards, Marc Lampo Security Officer EURid Woluwelaan 150 1831 Diegem - Belgium marc.lampo@eurid.eu http://www.eurid.eu Want a .eu web address in your own language? Find out how so you don't miss out! From fanf2@hermes.cam.ac.uk Thu Sep 1 08:12:13 2011 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 65A5521F9900 for ; Thu, 1 Sep 2011 08:12:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.583 X-Spam-Level: X-Spam-Status: No, score=-6.583 tagged_above=-999 required=5 tests=[AWL=0.016, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GK1+-rMLFmxb for ; Thu, 1 Sep 2011 08:12:12 -0700 (PDT) Received: from ppsw-41.csi.cam.ac.uk (ppsw-41.csi.cam.ac.uk [131.111.8.141]) by ietfa.amsl.com (Postfix) with ESMTP id 44C5F21F9893 for ; Thu, 1 Sep 2011 08:12:11 -0700 (PDT) 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-2.csi.cam.ac.uk ([131.111.8.54]:48339) by ppsw-41.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.156]:25) with esmtpa (EXTERNAL:fanf2) id 1Qz8xU-0002sX-Sb (Exim 4.72) (return-path ); Thu, 01 Sep 2011 16:13:36 +0100 Received: from fanf2 (helo=localhost) by hermes-2.csi.cam.ac.uk (hermes.cam.ac.uk) with local-esmtp id 1Qz8xU-0006fI-RP (Exim 4.67) (return-path ); Thu, 01 Sep 2011 16:13:36 +0100 Date: Thu, 1 Sep 2011 16:13:36 +0100 From: Tony Finch X-X-Sender: fanf2@hermes-2.csi.cam.ac.uk To: Marc Lampo In-Reply-To: <004201cc6878$39116fb0$ab344f10$@lampo@eurid.eu> Message-ID: References: <20110830162134.GB84494@shinkuro.com> <004201cc6878$39116fb0$ab344f10$@lampo@eurid.eu> 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, draft-vandergaast-edns-client-subnet@tools.ietf.org Subject: Re: [dnsext] afasterinternet.com trial and draft-vandergaast-edns-client-subnet-00 X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Sep 2011 15:12:13 -0000 Marc Lampo wrote: > > For an authoritative name server, implementing DNSSEC and this RFC, > it probably implies that it must be able to calculate RRSIG's "on the > fly"; That isn't required. You can pre-calculate RRSIGs for multiple versions of the same RRset and arrange your stunt DNS server to serve up the most optimal version of the RRset depending on the client. No need for dynamic calculation. Tony. -- f.anthony.n.finch http://dotat.at/ Lundy, Fastnet: Southeast veering southwest 3 or 4, increasing 5 at times. Slight or moderate. Showers. Good, occasionally poor. From skjaidev@gmail.com Thu Sep 1 12:44:37 2011 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 872B421F96AF for ; Thu, 1 Sep 2011 12:44:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.977 X-Spam-Level: X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XPrGxsAx9ERi for ; Thu, 1 Sep 2011 12:44:36 -0700 (PDT) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by ietfa.amsl.com (Postfix) with ESMTP id 9CD7821F96A8 for ; Thu, 1 Sep 2011 12:44:36 -0700 (PDT) Received: by yxj17 with SMTP id 17so808619yxj.31 for ; Thu, 01 Sep 2011 12:46:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:reply-to:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type; bh=BZWdcHxWXSxyt8CPgn0AwUYxNoWmGz8IdfZgV8J6ZqE=; b=w8vr2oA1JD6X7jFXyQ1xI6JGknIxOVTrQdfJOxFMR3c7ORCBCHsQ+7c0WUUQgLuBrx mW1m62VhPTBMYLCLsBn9aC2FvAYmDLzG0GiBxqsSIAceV0gYGPPe4IDWp45qOBkAoHMQ LKVArFXmEyGnWmmZipMk5wtFqj0pQaNxdXClo= Received: by 10.42.109.208 with SMTP id m16mr193277icp.71.1314906370094; Thu, 01 Sep 2011 12:46:10 -0700 (PDT) MIME-Version: 1.0 Sender: skjaidev@gmail.com Received: by 10.231.37.134 with HTTP; Thu, 1 Sep 2011 12:45:50 -0700 (PDT) In-Reply-To: References: <20110830162134.GB84494@shinkuro.com> <7CA8194350F4804F8DF6CAF3@nimrod.local> <20110831005457.GA459@debian> From: Jaidev Sridhar Date: Thu, 1 Sep 2011 12:45:50 -0700 X-Google-Sender-Auth: HP3_Axfy84FPrFM8M_XOc25sgPU Message-ID: To: Wilmer van der Gaast Content-Type: text/plain; charset=ISO-8859-1 Cc: dnsext@ietf.org, draft-vandergaast-edns-client-subnet@tools.ietf.org Subject: Re: [dnsext] afasterinternet.com trial and draft-vandergaast-edns-client-subnet-00 X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: mail@jaidev.info List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Sep 2011 19:45:22 -0000 For some reason my original email never made it to the list. On Wed, Aug 31, 2011 at 07:18, Wilmer van der Gaast wrote: > > I just realised, after looking through our revision history, that we > haven't made any changes to the NAT section since edns-client-ip-00 > (i.e. January 2010). Since then we have made some changes to > transitive behaviour so there are definitely some contradictions to be > found here. > I agree. Rewording that section would make it more consistent with the rest of the document. > > The big-bad-NAT use case is also not a scenario we thought of so far. > It's also a pretty hard one to support without putting a lot of > additional intelligence into resolvers (i.e. a mapping of internal IP > addresses to their external equivalents). I'd like to know if any > implementor is actually willing to implement that. Again I agree that NAT implementations will probably not care about adding a edns-client-subnet option. However, my point was just that you shouldn't use language such as "intermediate devices MUST NOT add or change a edns-client-subnet option". Also, an intermediate device should have the option of zeroing the IP information (for instance: to enforce organizational privacy policies). -Jaidev -- The older a man gets, the farther he had to walk to school as a boy. From hallam@gmail.com Sat Sep 3 20:01:41 2011 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0CBC021F84F6 for ; Sat, 3 Sep 2011 20:01:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.453 X-Spam-Level: X-Spam-Status: No, score=-3.453 tagged_above=-999 required=5 tests=[AWL=0.145, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s3yFrt3nU4mM for ; Sat, 3 Sep 2011 20:01:39 -0700 (PDT) Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by ietfa.amsl.com (Postfix) with ESMTP id B2C6721F84F5 for ; Sat, 3 Sep 2011 20:01:39 -0700 (PDT) Received: by gyf3 with SMTP id 3so3237456gyf.31 for ; Sat, 03 Sep 2011 20:03:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=qRtt1hSLx68rnPR0xuViVF7rIm/bY3YCAY2hc9lqmD0=; b=nfjFpeWF0a61k6r8JxDCWE6EJYkHMnfpp+E96V8L5rWa5V8YK6LK1+R/WEveAZ1Sc3 Jxk11e39ilzLg59Kd13Q81lXykRs5536RF4Ug4r9KvgwFE92vQPMA4W9PEfRg1tBiRpU FbuWjFwe5k86rRr9jt6HTyZJyhPVoyjGZAoHg= MIME-Version: 1.0 Received: by 10.101.131.4 with SMTP id i4mr1855774ann.61.1315105397677; Sat, 03 Sep 2011 20:03:17 -0700 (PDT) Received: by 10.100.47.4 with HTTP; Sat, 3 Sep 2011 20:03:17 -0700 (PDT) In-Reply-To: <20110831114728.GA99123@shinkuro.com> References: <20110830162134.GB84494@shinkuro.com> <20110831031256.GA98758@shinkuro.com> <20110831114728.GA99123@shinkuro.com> Date: Sat, 3 Sep 2011 23:03:17 -0400 Message-ID: From: Phillip Hallam-Baker To: Andrew Sullivan Content-Type: multipart/alternative; boundary=001636c92a3f12204104ac14d6d6 Cc: dnsext@ietf.org Subject: Re: [dnsext] afasterinternet.com trial and draft-vandergaast-edns-client-subnet-00 X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Sep 2011 03:01:41 -0000 --001636c92a3f12204104ac14d6d6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable It occurs to me that this thread demonstrates that a Standard is NOT required. Nor has it ever been. Anyone who wants to can choose any code point and use it. If they have enough market presence they can make sure that nobody else wants that same code point. I do not agree with the need for a private use space. Private use just mean= s that each experiment will burn a minimum of one code point and if successfu= l will burn a second plue require a transition. We have been there with X-headers. They didn't really work. One of the problems with the DNS area is that there are far too many people who think that they have a veto point on the Internet and that is just not true (thank the deity). I am not trying to pick on the DNS area, just point out that it is not only governments who regard it as a chokepoint and thus the subject matter inevitably attracts people who think that it is their mission in life to protect the Internet from making the mistakes that they in their wisdom are uniquely capable of recognizing. I am willing to follow a process if an assignment process gives me a reasonable chance of getting an assignment on a reasonable schedule. By which I mean a small number of months as for RR code points. But do not be mistaken: I am not recognizing a right of veto by doing so. If the barrier is Standard required then I am simply going to tell people the number I have picked. I didn't get to vote for anyone involved so they should not exactly be surprised if I don't recognize their right to a veto. Some of you know the political sympathies that got me involved in the Internet in the first place: I believe in democracy. Do not be at all surprised if my lack of tolerance for unaccountable decisions is not limite= d to those of dictators and autocrats. A consensus based approach can be appropriate if the remit of an organization is limited to finding out what we can agree to do together. It is not acceptable if the organization is going to presume to claim veto power over what they do when agreement is not reached. We have a similar situation with SRV prefixes which for various reasons hav= e not been properly tracked for the past ten years. Each time there are proposals to rationalize the prefix registry people pull out absurd technical and logistical issues until the enthusiasm for the proposal is beaten into submission and lies bleeding and battered but not quite dead fo= r the next few years. In the meantime every protocol designer who believes inthe SRV approach jus= t does what I have done in W3C and OASIS standards and writes the stupid code points into the spec. There, done. On Wed, Aug 31, 2011 at 7:47 AM, Andrew Sullivan wr= ote: > On Tue, Aug 30, 2011 at 08:23:51PM -0700, Colm MacC=E1rthaigh wrote: > > On Tue, Aug 30, 2011 at 8:12 PM, Andrew Sullivan > wrote: > > > I actually don't care about the IETF process. What I do care about i= s > > > the potential for interoperability headaches later because of > > > undocumented collisions in EDNS0 option code interpretation. Avoidin= g > > > that sort of headache is the exact reason we have a registry. > > > > How would you feel about proposing more relaxed registry criteria to > > IANA (by way of an RFC), similar to how the ports registry works? > > In my personal, no-hat opinion, the registry rule could be made > first-come, first-served until (say) 50% of the code space was used > up. I see no reason not to do this. > > The current edns0-bis draft actually moves things in the opposite > direction: whereas now the rule is RFC Required, the current draft > makes things Standards Action. In my opinion (again no hat), this is > the wrong direction to be moving. > > > EDNS0 option codes don't appear to be in much demand, so exhaustion > > isn't as much of a concern. > > Right. And we could solve that worry by making the relaxed rule > automatically tighten after a certain number of the codes are gone > anyway, just the way we did for the DNSSEC algorithm numbers. > > A > > -- > Andrew Sullivan > ajs@anvilwalrusden.com > _______________________________________________ > dnsext mailing list > dnsext@ietf.org > https://www.ietf.org/mailman/listinfo/dnsext > --=20 Website: http://hallambaker.com/ --001636c92a3f12204104ac14d6d6 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable It occurs to me that this thread demonstrates that a Standard is NOT requir= ed. Nor has it ever been.

Anyone who wants to can choose= any code point and use it. If they have enough market presence they can ma= ke sure that nobody else wants that same code point.


I do not agree with the need for a priva= te use space. Private use just means that each experiment will burn a minim= um of one code point and if successful will burn a second plue require a tr= ansition. We have been there with X-headers. They didn't really work.


One of the problems with the DNS ar= ea is that there are far too many people who think that they have a veto po= int on the Internet and that is just not true (thank the deity).=A0

I am not trying to pick on the DNS area, just point out= that it is not only governments who regard it as a chokepoint and thus the= subject matter inevitably attracts people who think that it is their missi= on in life to protect the Internet from making the mistakes that they in th= eir wisdom are uniquely capable of recognizing.


I am willing to follow a process if an a= ssignment process gives me a reasonable chance of getting an assignment on = a reasonable schedule. By which I mean a small number of months as for RR c= ode points. But do not be mistaken: I am not recognizing a right of veto by= doing so.

If the barrier is Standard required then I am simply go= ing to tell people the number I have picked. I didn't get to vote for a= nyone involved so they should not exactly be surprised if I don't recog= nize their right to a veto.=A0

Some of you know the political sympathies that got me i= nvolved in the Internet in the first place: I believe in democracy. Do not = be at all surprised if my lack of tolerance for unaccountable decisions is = not limited to those of dictators and autocrats.=A0

A consensus based approach can be appropriate if the re= mit of an organization is limited to finding out what we can agree to do to= gether. It is not acceptable if the organization is going to presume to cla= im veto power over what they do when agreement is not reached.


We have a similar situation with SRV pre= fixes which for various reasons have not been properly tracked for the past= ten years. Each time there are proposals to rationalize the prefix registr= y people pull out absurd technical and logistical issues until the enthusia= sm for the proposal is beaten into submission and lies bleeding and battere= d but not quite dead for the next few years.=A0

In the meantime every protocol designer who believes in= the SRV approach just does what I have done in W3C and OASIS standards and = writes the stupid code points into the spec. There, done.=A0


On Wed, Aug 31, 2011 at 7:47 AM, = Andrew Sullivan <ajs@anvilwalrusden.com> wrote:
On Tue, Aug 30, 2011 at 08:23:51PM -0700, Colm MacC=E1rth= aigh wrote:
> On Tue, Aug 30, 2011 at 8:12 PM, Andrew Sullivan <ajs@anvilwalrusden.com> wrote:
> > I actually don't care about the IETF process. =A0What I do ca= re about is
> > the potential for interoperability headaches later because of
> > undocumented collisions in EDNS0 option code interpretation. =A0A= voiding
> > that sort of headache is the exact reason we have a registry.
>
> How would you feel about proposing more relaxed registry criteria to > IANA (by way of an RFC), similar to how the ports registry works?

In my personal, no-hat opinion, the registry rule could be made
first-come, first-served until (say) 50% of the code space was used
up. =A0I see no reason not to do this.

The current edns0-bis draft actually moves things in the opposite
direction: whereas now the rule is RFC Required, the current draft
makes things Standards Action. =A0In my opinion (again no hat), this is
the wrong direction to be moving.

> EDNS0 option codes don't appear to be in much demand, so exhaustio= n
> isn't as much of a concern.

Right. =A0And we could solve that worry by making the relaxed rule automatically tighten after a certain number of the codes are gone
anyway, just the way we did for the DNSSEC algorithm numbers.

A

--
Andrew Sullivan
ajs@anvilwalrusden.com
___________________________________= ____________
dnsext mailing list
dnsext@ietf.org
= https://www.ietf.org/mailman/listinfo/dnsext



--
= Website: http://hallambaker.com/
--001636c92a3f12204104ac14d6d6-- From hallam@gmail.com Sun Sep 4 05:38:08 2011 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ED9FF21F86B1 for ; Sun, 4 Sep 2011 05:38:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.621 X-Spam-Level: X-Spam-Status: No, score=-2.621 tagged_above=-999 required=5 tests=[AWL=-0.689, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, SARE_HTML_USL_OBFU=1.666] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mjtq8SWcAHm1 for ; Sun, 4 Sep 2011 05:38:08 -0700 (PDT) Received: from mail-gw0-f44.google.com (mail-gw0-f44.google.com [74.125.83.44]) by ietfa.amsl.com (Postfix) with ESMTP id 487BF21F8663 for ; Sun, 4 Sep 2011 05:38:08 -0700 (PDT) Received: by gwb20 with SMTP id 20so2893253gwb.31 for ; Sun, 04 Sep 2011 05:39:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=TOnUEYNRhNefb8fwl0JtKpphVKFzToDEExVFoJWc/jw=; b=QEoF+zDkcv8+ah1G8hh91oIfDYpBCZTP3Tv55F/FxR42tqD6VyJtACnD41CDZyDGTE dCbmpSfLqSTE+4m1RqkqUjlfnBnxKmFDu2qI3DaBeqBqSsdsewJvoTxFLEsAJI/CELF5 458IQuO4TIXAmgeUZ+Zh+44KDbtBLIodFitX0= MIME-Version: 1.0 Received: by 10.100.21.19 with SMTP id 19mr2006108anu.149.1315139989359; Sun, 04 Sep 2011 05:39:49 -0700 (PDT) Received: by 10.100.47.4 with HTTP; Sun, 4 Sep 2011 05:39:49 -0700 (PDT) In-Reply-To: References: <20110830162134.GB84494@shinkuro.com> <20110831031256.GA98758@shinkuro.com> Date: Sun, 4 Sep 2011 08:39:49 -0400 Message-ID: From: Phillip Hallam-Baker To: Jim Reid Content-Type: multipart/alternative; boundary=0016e64697a0e54d2904ac1ce366 Cc: dnsext@ietf.org Subject: Re: [dnsext] a lightweight process for assigning EDNS option codes X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Sep 2011 12:38:09 -0000 --0016e64697a0e54d2904ac1ce366 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable If EDNS0 codes were ever exhausted it is a trivial matter to generate more. Just assign a new extension RR code. I suspect that it won't be a problem though, I can't see how we could run out of EDNS codes before RR codes. 2011/8/31 Jim Reid > On 31 Aug 2011, at 04:23, Colm MacC=E1rthaigh wrote: > > How would you feel about proposing more relaxed registry criteria to >> IANA (by way of an RFC), similar to how the ports registry works? >> > > Sounds like a good idea. > > EDNS0 option codes don't appear to be in much demand, so exhaustion >> isn't as much of a concern. >> > > A process comparable to the one for RRtype code assignment could take car= e > of this. The expert review would provide a sanity check and rate limiter = in > case we started burning through EDNS option codes. What if marketroids we= re > to decide these are more valuable for vanity purposes than new gTLDs? > > It's a pity RFC6195 didn't ring-fence some of the EDNS OPT code (and > Extended RCODE?) number space for private use and/or experiments just lik= e > it did for the RRtype, CLASS and RCODE spaces. > > ______________________________**_________________ > dnsext mailing list > dnsext@ietf.org > https://www.ietf.org/mailman/**listinfo/dnsext > --=20 Website: http://hallambaker.com/ --0016e64697a0e54d2904ac1ce366 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable If EDNS0 codes were ever exhausted it is a trivial matter to generate more.= Just assign a new extension RR code.

I suspect that it = won't be a problem though, I can't see how we could run out of EDNS= codes before RR codes.=A0


2011/8/31 Jim Reid <jim@rfc1035.com>
=
On 31 Aug 2011, at 04:23, Colm MacC=E1rthaigh wrote:

How would you feel about proposing more relaxed registry criteria to
IANA (by way of an RFC), similar to how the ports registry works?

Sounds like a good idea.

EDNS0 option codes don't appear to be in much demand, so exhaustion
isn't as much of a concern.

A process comparable to the one for RRtype code assignment could take care = of this. The expert review would provide a sanity check and rate limiter in= case we started burning through EDNS option codes. What if marketroids wer= e to decide these are more valuable for vanity purposes than new gTLDs?

It's a pity RFC6195 didn't ring-fence some of the EDNS OPT code (an= d Extended RCODE?) number space for private use and/or experiments just lik= e it did for the RRtype, CLASS and RCODE spaces.

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



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

--0016e64697a0e54d2904ac1ce366-- From nweaver@icsi.berkeley.edu Sun Sep 4 06:04:09 2011 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DD96721F8862 for ; Sun, 4 Sep 2011 06:04:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IEkvUOUcl5r0 for ; Sun, 4 Sep 2011 06:04:09 -0700 (PDT) Received: from taffy.ICSI.Berkeley.EDU (taffy.ICSI.Berkeley.EDU [192.150.187.26]) by ietfa.amsl.com (Postfix) with ESMTP id 7F3E221F8783 for ; Sun, 4 Sep 2011 06:04:09 -0700 (PDT) Received: from [10.0.1.3] (c-50-131-88-125.hsd1.ca.comcast.net [50.131.88.125]) (Authenticated sender: nweaver) by taffy.ICSI.Berkeley.EDU (Postfix) with ESMTP id E095E36A37D; Sun, 4 Sep 2011 06:05:50 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1244.3) Content-Type: text/plain; charset=iso-8859-1 From: Nicholas Weaver In-Reply-To: Date: Sun, 4 Sep 2011 06:05:52 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20110830162134.GB84494@shinkuro.com> <20110831031256.GA98758@shinkuro.com> To: Phillip Hallam-Baker X-Mailer: Apple Mail (2.1244.3) Cc: dnsext@ietf.org Subject: Re: [dnsext] a lightweight process for assigning EDNS option codes X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Sep 2011 13:04:10 -0000 On Sep 4, 2011, at 5:39 AM, Phillip Hallam-Baker wrote: > If EDNS0 codes were ever exhausted it is a trivial matter to generate = more. Just assign a new extension RR code. >=20 > I suspect that it won't be a problem though, I can't see how we could = run out of EDNS codes before RR codes.=20 You don't even need to do that. If we reach 50% exhausting of the code = space, just define the reserved EDNS0 options code of FFFF as "the next = 4 bytes are the extended extended option code", and from that point = onward, experimental extensions have to use the extended option code = space. From hallam@gmail.com Sun Sep 4 16:47:50 2011 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3127221F87D3 for ; Sun, 4 Sep 2011 16:47:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.454 X-Spam-Level: X-Spam-Status: No, score=-3.454 tagged_above=-999 required=5 tests=[AWL=0.144, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OT+ac4-6fC1C for ; Sun, 4 Sep 2011 16:47:49 -0700 (PDT) Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by ietfa.amsl.com (Postfix) with ESMTP id 63E7221F87FC for ; Sun, 4 Sep 2011 16:47:49 -0700 (PDT) Received: by gyf3 with SMTP id 3so3459383gyf.31 for ; Sun, 04 Sep 2011 16:49:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=q20PLLwdDShZltVjKluyahpWcYCbmmm8+FpFiqKACUI=; b=YXbz48+k43I7U8SS2ha2eVXfz6CosIomyWA0155jZZGzJnhf992NrQeiLizTd9qBu8 7qXweenejbh/pnwoq/UtPXgVe+GIbQmY+jwpaH2ng7yos/VB+Y77XJCr7RouIj1Sx/HP 5xmnBzW5J+4dwcey9kvRyyEoHaqJdgmclpPEc= MIME-Version: 1.0 Received: by 10.101.26.3 with SMTP id d3mr2211643anj.105.1315180171838; Sun, 04 Sep 2011 16:49:31 -0700 (PDT) Received: by 10.100.47.4 with HTTP; Sun, 4 Sep 2011 16:49:31 -0700 (PDT) In-Reply-To: References: <20110830162134.GB84494@shinkuro.com> <20110831031256.GA98758@shinkuro.com> Date: Sun, 4 Sep 2011 19:49:31 -0400 Message-ID: From: Phillip Hallam-Baker To: Nicholas Weaver Content-Type: multipart/alternative; boundary=001636b2b4f2f545b504ac263eb5 Cc: dnsext@ietf.org Subject: Re: [dnsext] a lightweight process for assigning EDNS option codes X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Sep 2011 23:47:50 -0000 --001636b2b4f2f545b504ac263eb5 Content-Type: text/plain; charset=ISO-8859-1 I think it rather more likely that we end up changing the DNS client-resolver protocol first. One of the things I have found playing about with DPLS is that probably the biggest leverage performance upgrade that can be done is to change the client resolver protocol so that while a request is still one UDP packet, the reply can consist of several. Another thing that I realized is that the cost of transitioning to DNS 1.0 over DPLS (or DTLS) is exactly the same as the cost of transitioning to DNS 2.0 over DPLS. So if people go this route they might as well take the opportunity to tweak the protocol to fix some of the more irritating restrictions (e.g. only one request per request packet). On Sun, Sep 4, 2011 at 9:05 AM, Nicholas Weaver wrote: > > On Sep 4, 2011, at 5:39 AM, Phillip Hallam-Baker wrote: > > > If EDNS0 codes were ever exhausted it is a trivial matter to generate > more. Just assign a new extension RR code. > > > > I suspect that it won't be a problem though, I can't see how we could run > out of EDNS codes before RR codes. > > You don't even need to do that. If we reach 50% exhausting of the code > space, just define the reserved EDNS0 options code of FFFF as "the next 4 > bytes are the extended extended option code", and from that point onward, > experimental extensions have to use the extended option code space. > > -- Website: http://hallambaker.com/ --001636b2b4f2f545b504ac263eb5 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I think it rather more likely that we end up changing the DNS client-resolv= er protocol first.

One of the things I have found playin= g about with DPLS is that probably the biggest leverage performance upgrade= that can be done is to change the client resolver protocol so that while a= request is still one UDP packet, the reply can consist of several.

Another thing that I realized is that the cost of trans= itioning to DNS 1.0 over DPLS (or DTLS) is exactly the same as the cost of = transitioning to DNS 2.0 over DPLS. So if people go this route they might a= s well take the opportunity to tweak the protocol to fix some of the more i= rritating restrictions (e.g. only one request per request packet).



On Sun, S= ep 4, 2011 at 9:05 AM, Nicholas Weaver <nweaver@icsi.berkeley.edu> wro= te:

On Sep 4, 2011, at 5:39 AM, Phillip Hallam-Baker wrote:

> If EDNS0 codes were ever exhausted it is a trivial matter to generate = more. Just assign a new extension RR code.
>
> I suspect that it won't be a problem though, I can't see how w= e could run out of EDNS codes before RR codes.

You don't even need to do that. =A0If we reach 50% exhausting of = the code space, just define the reserved EDNS0 options code of FFFF as &quo= t;the next 4 bytes are the extended extended option code", and from th= at point onward, experimental extensions have to use the extended option co= de space.




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

--001636b2b4f2f545b504ac263eb5-- From wilmer@google.com Mon Sep 5 10:07:51 2011 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1244321F883A for ; Mon, 5 Sep 2011 10:07:51 -0700 (PDT) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6wJlotxsxNlW for ; Mon, 5 Sep 2011 10:07:50 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.67]) by ietfa.amsl.com (Postfix) with ESMTP id 0712921F861A for ; Mon, 5 Sep 2011 10:07:49 -0700 (PDT) Received: from wpaz24.hot.corp.google.com (wpaz24.hot.corp.google.com [172.24.198.88]) by smtp-out.google.com with ESMTP id p85H9T90009360 for ; Mon, 5 Sep 2011 10:09:29 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1315242569; bh=VRUQG29YvitC1/kf8XRtkcaoz74=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type; b=kUDjM8mBIbKBHCi5L8yVO20IIckPYyY+38pSCD/i3sCHA+oa0FcVcVygYUj58ct8E vh40P5xWTL1EqdZDaqtgw== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=dkim-signature:mime-version:in-reply-to:references:date: message-id:subject:from:to:cc:content-type:x-system-of-record; b=AN8V0u8Sk3k37XXlbf7eXbvfvJnHmd1v1UZVgZAqBmLc01NNpQG2AijhmdwWLe2S/ sxlb9CSbrn6vHYUHblQRQ== Received: from iagv1 (iagv1.prod.google.com [10.12.223.1]) by wpaz24.hot.corp.google.com with ESMTP id p85H9G6r027310 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Mon, 5 Sep 2011 10:09:28 -0700 Received: by iagv1 with SMTP id v1so7784099iag.0 for ; Mon, 05 Sep 2011 10:09:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=wolR8+t4gS+EMoIYAhxfOLbQqd0tDiU8yYKsXqIDSqE=; b=IukVfkyEqyBglRf4NFwVzATXOCJMi0ByQUiTbDZeYst1FtHqb4YI4X2qbT+GHQkORh ydAu4cXVFQqvA+tY0Naw== Received: by 10.231.82.14 with SMTP id z14mr7919660ibk.63.1315242567226; Mon, 05 Sep 2011 10:09:27 -0700 (PDT) MIME-Version: 1.0 Received: by 10.231.82.14 with SMTP id z14mr7919618ibk.63.1315242566018; Mon, 05 Sep 2011 10:09:26 -0700 (PDT) Received: by 10.231.16.69 with HTTP; Mon, 5 Sep 2011 10:09:25 -0700 (PDT) In-Reply-To: References: <20110830162134.GB84494@shinkuro.com> Date: Mon, 5 Sep 2011 18:09:25 +0100 Message-ID: From: Wilmer van der Gaast To: Ted Hardie Content-Type: text/plain; charset=ISO-8859-1 X-System-Of-Record: true Cc: dnsext@ietf.org, draft-vandergaast-edns-client-subnet@tools.ietf.org Subject: Re: [dnsext] afasterinternet.com trial and draft-vandergaast-edns-client-subnet-00 X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Sep 2011 17:07:51 -0000 On 31 August 2011 17:03, Ted Hardie wrote: > * 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. > > None of these changes seem to address the balance of discussion of the > previous two versions. > I assume you are referring to the discussion about edns-client-subnet or DNS-based CDNs being a reasonable solution at all? A short discussion of various CDN techniques is, IMHO, outside the scope of an RFC describing an EDNS0 option. Instead, we summarised our concerns about alternative methods suggested in these discussions on http://www.ietf.org/mail-archive/web/dnsext/current/msg08962.html . Regards, -- Wilmer van der Gaast, Traffic SRE/Google Public DNS team. Google Ireland. From wilmer@google.com Mon Sep 5 10:26:44 2011 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F75021F8A4D for ; Mon, 5 Sep 2011 10:26:44 -0700 (PDT) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5DO8eTjj-P0f for ; Mon, 5 Sep 2011 10:26:43 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.67]) by ietfa.amsl.com (Postfix) with ESMTP id 2B64621F8829 for ; Mon, 5 Sep 2011 10:26:42 -0700 (PDT) Received: from wpaz9.hot.corp.google.com (wpaz9.hot.corp.google.com [172.24.198.73]) by smtp-out.google.com with ESMTP id p85HSQru014772 for ; Mon, 5 Sep 2011 10:28:27 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1315243707; bh=TyNptKzxQV7BtcoMnCmIQcWUXKY=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type; b=RS6H+rJ1wPgL1Y+pnR3kQSDdm8d9hIpFBmVOkVqo3t78lluXqN1MDViPfoII3T+fE BymjA+5GOiMWpkphtU1LQ== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=dkim-signature:mime-version:in-reply-to:references:date: message-id:subject:from:to:cc:content-type:x-system-of-record; b=RHA4pqNhiE16tdUR2ouEaNwp9En3SUbfdxpNJR5f+yikTD1MupsYc0r4fzncaAHkB oEnk3PJOxqmWq7M5YP71Q== Received: from ywm3 (ywm3.prod.google.com [10.192.13.3]) by wpaz9.hot.corp.google.com with ESMTP id p85HSPmw024645 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Mon, 5 Sep 2011 10:28:25 -0700 Received: by ywm3 with SMTP id 3so4454072ywm.16 for ; Mon, 05 Sep 2011 10:28:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=V/cVjR7OnhGWCFRJ84TuYPjx7xTf23Qd0yOUqEzSzok=; b=YzxvyM3760ClYpgg/xin99qm9hkCD+D+RbeG8VcL8ZuDCCpo6TtQ2J5s/FkYgkNsqt M7KEsFvBGw+POKoWLF9A== Received: by 10.43.44.200 with SMTP id uh8mr3587153icb.241.1315243705224; Mon, 05 Sep 2011 10:28:25 -0700 (PDT) MIME-Version: 1.0 Received: by 10.43.44.200 with SMTP id uh8mr3587139icb.241.1315243704243; Mon, 05 Sep 2011 10:28:24 -0700 (PDT) Received: by 10.231.16.69 with HTTP; Mon, 5 Sep 2011 10:28:24 -0700 (PDT) In-Reply-To: <4e5f3343.cd06e70a.2596.ffffb1e7SMTPIN_ADDED@mx.google.com> References: <20110830162134.GB84494@shinkuro.com> <4e5f3343.cd06e70a.2596.ffffb1e7SMTPIN_ADDED@mx.google.com> Date: Mon, 5 Sep 2011 18:28:24 +0100 Message-ID: From: Wilmer van der Gaast To: Marc Lampo Content-Type: text/plain; charset=ISO-8859-1 X-System-Of-Record: true Cc: dnsext@ietf.org Subject: Re: [dnsext] afasterinternet.com trial and draft-vandergaast-edns-client-subnet-00 X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Sep 2011 17:26:44 -0000 On 1 September 2011 08:24, Marc Lampo wrote: > [...] > > For an authoritative name server, implementing DNSSEC and this RFC, > it probably implies that it must be able to calculate RRSIG's "on the > fly"; > Which implies that it must have access to the private part of DNSKEY's; > Which implies that signing on a hidden master > and distributing signed data to public slaves is not enough. As someone else already pointed out, this is not strictly necessary. Also, this is not specific to edns-client-subnet as there are nameservers right now that use the query source IP to determine the optimal response. >From how I parse the DNSSEC specs, the OPT record is not signed (wouldn't be possible without secret keys on the server anyway), so edns-client-subnet doesn't change the situation. It may still be reasonable to mention something along these lines in the I-D. I assume the attack scenario you're talking about is sending queries with many different source IP addresses/client-subnet options and sending spoofed responses with no client-subnet option at all? Regards, -- Wilmer van der Gaast, Traffic SRE/Google Public DNS team. Google Ireland. From sm@resistor.net Mon Sep 5 13:02:27 2011 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CD03421F8B4A for ; Mon, 5 Sep 2011 13:02:27 -0700 (PDT) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hjB4xea3X-hQ for ; Mon, 5 Sep 2011 13:02:25 -0700 (PDT) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 85A2021F8B28 for ; Mon, 5 Sep 2011 13:02:25 -0700 (PDT) Received: from SUBMAN.resistor.net (IDENT:sm@localhost [127.0.0.1]) by mx.elandsys.com (8.14.4/8.14.5) with ESMTP id p85K40u9018813 for ; Mon, 5 Sep 2011 13:04:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1315253045; bh=qi8a1FonrNj5oOybphBUgOIFzjGyiw4dTWHs4oEIGoo=; h=Message-Id:Date:To:From:Subject:In-Reply-To:References: Mime-Version:Content-Type:Cc; b=sZ6EwAbhLPslqH5WGZGnNYs2CBZVSSQ5G/zfmu2H/Bbgm0Jh08mnT9fnvHuUOpH+x N0DTW1nSVF9DHnvBKkubc6dLVwPYyW78tQg/6TVj2MS8N+2YQ753SiXAuAZHMQlyOa 1T7GZwnxlCIGXCd96kyMqt61o8bNbEAtWR3mR/6A= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1315253045; bh=qi8a1FonrNj5oOybphBUgOIFzjGyiw4dTWHs4oEIGoo=; h=Message-Id:Date:To:From:Subject:In-Reply-To:References: Mime-Version:Content-Type:Cc; b=azp3PNRLvB6+nOHLvzifUa09tsVfbercs8NfPXI3lUolY32ZWO6izxl8cHFHvXrY0 k7GZFjdWO8HMncPSEci61B+M3KgnmD85XVx2S0/uUkVwNM2PLzVJqrIIcWWW6gPHSD aLUI/BvAOpcbZfk/okbJ0WUlhc13n+ASlz64Qj0M= Message-Id: <6.2.5.6.2.20110905114918.08670a18@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Mon, 05 Sep 2011 13:03:48 -0700 To: dnsext@ietf.org From: SM In-Reply-To: References: <20110830162134.GB84494@shinkuro.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: Re: [dnsext] afasterinternet.com trial and draft-vandergaast-edns-client-subnet-00 X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Sep 2011 20:02:27 -0000 At 10:09 05-09-2011, Wilmer van der Gaast wrote: >A short discussion of various CDN techniques is, IMHO, outside the >scope of an RFC describing an EDNS0 option. Instead, we summarised our If it wasn't for the intended Experimental status, there a lot of topics that cannot be said to be out of scope for this proposal. In the reply to the WG Chairs' comments, it was mentioned that HTTP is the main focus. The following DNS services support edns-client-subnet: - OpenDNS - Google Public DNS I might describe the problem as follows. These DNS services provide an "off-net" recursive resolver service for clients. Clients are generally assigned a DNS server that is topologically close to them, i.e. their ISP's DNS service. The above-mentioned DNS services are are supposed to speed up web browsing. That only works if the content provider can determine the "nearest" HTTP service from where the content can be served. It does not work well when OpenDNS or Google Public DNS are used, hence this proposal to provide some client identifier through an EDNS option. If these DNS services were small fry, I doubt that CDNs would bat an eye about the problem. After all, their existing DNS tricks seemed to be working quite well. If using the DNS services result in slower web access, it is a disadvantage for these two services. The fix proposed is for the these DNS services to send a client identifier to the CDNs. From Section 9.1 of draft-vandergaast-edns-client-subnet-00: "Users who wish their full IP address to be hidden can include an edns-client-subnet option specifying the wildcard address 0.0.0.0/0" It was mentioned previously that: "We believe, however, that a perfect solution would require making changes to how the user agent works. We can't do that, we only get to change the nameservers and recursive resolvers." And: "We don't see this option being enabled by anyone else, or worse, by default." Users who do not wish to provide a client identifier will have to update their software to support this specification. As to being the default, if OpenDNS and Google says that it is better for the Internet and I say it isn't, who would you believe? Regards, -sm From marty@supine.com Tue Sep 6 00:27:21 2011 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 436A121F84A2 for ; Tue, 6 Sep 2011 00:27:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6nuFF0wxhhKk for ; Tue, 6 Sep 2011 00:27:20 -0700 (PDT) Received: from tigger.mamista.net (tigger.mamista.net [IPv6:2001:470:1f05:a0f::1]) by ietfa.amsl.com (Postfix) with ESMTP id 82F9C21F8499 for ; Tue, 6 Sep 2011 00:27:17 -0700 (PDT) Received: by tigger.mamista.net (Postfix, from userid 1012) id 8E1941100B9; Tue, 6 Sep 2011 17:29:02 +1000 (EST) Received: from merboo.mamista.net (merboo.mamista.net [IPv6:2001:470:1f0b:1055::1]) by tigger.mamista.net (Postfix) with ESMTP id CC9561100B9 for ; Tue, 6 Sep 2011 17:29:00 +1000 (EST) Received: by merboo.mamista.net (Postfix, from userid 1000) id 7AB9820D1A; Tue, 6 Sep 2011 09:28:58 +0200 (CEST) Date: Tue, 6 Sep 2011 09:28:58 +0200 From: Martin Barry To: dnsext@ietf.org Message-ID: <20110906072857.GA23307@merboo.mamista.net> References: <20110830162134.GB84494@shinkuro.com> <6.2.5.6.2.20110905114918.08670a18@resistor.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <6.2.5.6.2.20110905114918.08670a18@resistor.net> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [dnsext] afasterinternet.com trial and draft-vandergaast-edns-client-subnet-00 X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Sep 2011 07:27:21 -0000 $quoted_author = "SM" ; > > From Section 9.1 of draft-vandergaast-edns-client-subnet-00: > > "Users who wish their full IP address to be hidden can include an > edns-client-subnet option specifying the wildcard address 0.0.0.0/0" > Users who do not wish to provide a client identifier will have to > update their software to support this specification. Or they could just not use OpenDNS, Google DNS or any other 3rd party recursive DNS provider who enables edns-client-subnet. cheers Marty From mohta@necom830.hpcl.titech.ac.jp Tue Sep 6 00:58:00 2011 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BDB9621F84DD for ; Tue, 6 Sep 2011 00:58:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.023 X-Spam-Level: X-Spam-Status: No, score=-0.023 tagged_above=-999 required=5 tests=[AWL=0.067, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lFzVwQu4iTpe for ; Tue, 6 Sep 2011 00:58:00 -0700 (PDT) Received: from necom830.hpcl.titech.ac.jp (necom830.hpcl.titech.ac.jp [131.112.32.132]) by ietfa.amsl.com (Postfix) with SMTP id C539021F84DF for ; Tue, 6 Sep 2011 00:57:59 -0700 (PDT) Received: (qmail 3832 invoked from network); 6 Sep 2011 08:06: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; 6 Sep 2011 08:06:07 -0000 Message-ID: <4E65D2A7.3010308@necom830.hpcl.titech.ac.jp> Date: Tue, 06 Sep 2011 16:58:31 +0900 From: Masataka Ohta User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:6.0.1) Gecko/20110830 Thunderbird/6.0.1 MIME-Version: 1.0 To: dnsext@ietf.org References: <20110830162134.GB84494@shinkuro.com> <6.2.5.6.2.20110905114918.08670a18@resistor.net> In-Reply-To: <6.2.5.6.2.20110905114918.08670a18@resistor.net> Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit Subject: [dnsext] Address privacy (was Re: afasterinternet.com trial and draft-vandergaast-edns-client-subnet-00) X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Sep 2011 07:58:00 -0000 SM wrote: > The above-mentioned DNS services are are supposed to speed > up web browsing. Do you mean that the motivation is to improve TCP performance by reducing TTL and *NOT* to reduce privacy? > I might describe the problem as follows. These DNS services provide an > "off-net" recursive resolver service for clients. Clients are generally > assigned a DNS server that is topologically close to them, i.e. their > ISP's DNS service. Then, as as an IP address of "a DNS server (resolver is the correct word, here) that is topologically close to them" is known to OpenDNS and Google Public DNS, why do you have to be bothered by client subnet? I'm afraid your actual motivation is *NOT* performance *BUT* precise geo-location of clients. Yes, content providers can still know IP addresses of clietns, from which precise geo-location may be obtained. However, I can see no reason why clients privacy information must unnecessarily known by OpenDNS and Google Public DNS servers. > That only works if the content provider can > determine the "nearest" HTTP service from where the content can be > served. For performance purpose, HTTP server "nearest" to "a DNS resolver that is topologically close to them" should be enough. Masataka Ohta From marc.lampo@eurid.eu Tue Sep 6 01:51:40 2011 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8443021F8514 for ; Tue, 6 Sep 2011 01:51:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.544 X-Spam-Level: X-Spam-Status: No, score=-8.544 tagged_above=-999 required=5 tests=[AWL=0.606, BAYES_00=-2.599, MSGID_MULTIPLE_AT=1.449, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KYBOsjmjQ5If for ; Tue, 6 Sep 2011 01:51:39 -0700 (PDT) Received: from barra.eurid.eu (mx.eurid.eu [212.190.206.103]) by ietfa.amsl.com (Postfix) with ESMTP id 6A84121F8513 for ; Tue, 6 Sep 2011 01:51:38 -0700 (PDT) X-ASG-Debug-ID: 1315299203-0369494a36abd10001-uIE7UK Received: from zimbra.eurid.eu (zcs-master.vt.eurid.eu [10.19.100.121]) by barra.eurid.eu with ESMTP id UZij3pbqA7RJ6nnf; Tue, 06 Sep 2011 10:53:23 +0200 (CEST) X-Barracuda-Envelope-From: marc.lampo@eurid.eu X-ASG-Whitelist: Client Received: from localhost (localhost.localdomain [127.0.0.1]) by zimbra.eurid.eu (Postfix) with ESMTP id 06664E408E; Tue, 6 Sep 2011 10:53:23 +0200 (CEST) X-Virus-Scanned: amavisd-new at techmail.eurid.eu Received: from zimbra.eurid.eu ([127.0.0.1]) by localhost (zimbra.eurid.eu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WhxvcTQ0n4yq; Tue, 6 Sep 2011 10:53:22 +0200 (CEST) Received: from zimbra.eurid.eu (zimbra.eurid.eu [10.19.100.120]) by zimbra.eurid.eu (Postfix) with ESMTP id A8E11E4054; Tue, 6 Sep 2011 10:53:21 +0200 (CEST) From: "Marc Lampo" To: "'Wilmer van der Gaast'" References: <20110830162134.GB84494@shinkuro.com> <4e5f3343.cd06e70a.2596.ffffb1e7SMTPIN_ADDED@mx.google.com> In-Reply-To: Date: Tue, 6 Sep 2011 10:53:21 +0200 (CEST) X-ASG-Orig-Subj: RE: [dnsext] afasterinternet.com trial and draft-vandergaast-edns-client-subnet-00 Message-ID: <002e01cc6c72$6e28c920$4a7a5b60$@lampo@eurid.eu> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 X-Mailer: Zimbra 6.0.10_GA_2692 (ZimbraConnectorForOutlook/5.0.3064.18) Thread-Index: Acxr8UvOEG+VO5uFTGKV4rkdhCX2yQAfWf8w Content-Language: en-za X-Originating-IP: [172.20.1.115] X-Barracuda-Connect: zcs-master.vt.eurid.eu[10.19.100.121] X-Barracuda-Start-Time: 1315299203 X-Barracuda-URL: http://172.20.1.190:8000/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at eurid.eu Cc: dnsext@ietf.org Subject: Re: [dnsext] afasterinternet.com trial and draft-vandergaast-edns-client-subnet-00 X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Sep 2011 08:51:40 -0000 Hello, Point taken about it not being strictly required to effectively calculate RRSIG's on slave name servers. While the caching name service might be aware about this particularity of RRSIG's : - several RRSIG's for same "RRset" but with different number of records in the RRset. Other problems to be solved : - how can caching name service know which RRSIG, applying to RRset with eg one A-record, goes with which A-record ? Do you want to check RRSIG in the caching name service and send only the RRSIG that matches ? - this is not "standard" for the authoritative name services, to provide these multiple RRSIG's. In case of 3 A-records in a RRset, it would mean 3 RRSIG's applying to RRset with one A-record only, + 1 RRSIG applying to complete RRset (all A-records). The EDNS0 OPT record is mandatory, for DNSSEC. Records from client to server cannot be signed anyway; I see no requirement/recommendation of signing the OPT record from server to client. (the OPT record does not "live" as "signable data" in the zone file ! it holds data that is applicable to a particular name server : eg depending on how (what MTU) is valid at that particular name servers location) No, that is not the attack scenario I am referring at. But this mailing list is hardly the place to show potential cache poisoning attacks, is it ? What I really meant to express, is that, for public caching name services, I'd recommend they implement DNSSEC themselves (first - before implementing this/your draft RFC) at least to the extend that they know where to locate the DS records. That way, forwarding name servers are at least allowed to/capable of performing DNSSEC validation themselves, thus eliminating the risk of getting their cache poisoned. Kind regards, Marc Lampo EURid Security Officer -----Original Message----- From: Wilmer van der Gaast [mailto:wilmer@google.com] Sent: 05 September 2011 07:28 PM To: Marc Lampo Cc: dnsext@ietf.org Subject: Re: [dnsext] afasterinternet.com trial and draft-vandergaast-edns-client-subnet-00 On 1 September 2011 08:24, Marc Lampo wrote: > [...] > > For an authoritative name server, implementing DNSSEC and this RFC, > it probably implies that it must be able to calculate RRSIG's "on the > fly"; > Which implies that it must have access to the private part of DNSKEY's; > Which implies that signing on a hidden master > and distributing signed data to public slaves is not enough. As someone else already pointed out, this is not strictly necessary. Also, this is not specific to edns-client-subnet as there are nameservers right now that use the query source IP to determine the optimal response. >From how I parse the DNSSEC specs, the OPT record is not signed (wouldn't be possible without secret keys on the server anyway), so edns-client-subnet doesn't change the situation. It may still be reasonable to mention something along these lines in the I-D. I assume the attack scenario you're talking about is sending queries with many different source IP addresses/client-subnet options and sending spoofed responses with no client-subnet option at all? Regards, -- Wilmer van der Gaast, Traffic SRE/Google Public DNS team. Google Ireland. From fanf2@hermes.cam.ac.uk Tue Sep 6 06:27:25 2011 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8E83D21F8742 for ; Tue, 6 Sep 2011 06:27:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.583 X-Spam-Level: X-Spam-Status: No, score=-6.583 tagged_above=-999 required=5 tests=[AWL=0.016, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y+OYF4tZUCF6 for ; Tue, 6 Sep 2011 06:27:24 -0700 (PDT) Received: from ppsw-51.csi.cam.ac.uk (ppsw-51.csi.cam.ac.uk [131.111.8.151]) by ietfa.amsl.com (Postfix) with ESMTP id DE26D21F8640 for ; Tue, 6 Sep 2011 06:27:23 -0700 (PDT) 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-2.csi.cam.ac.uk ([131.111.8.54]:34599) by ppsw-51.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.158]:25) with esmtpa (EXTERNAL:fanf2) id 1R0vi7-0007Ty-ZI (Exim 4.72) (return-path ); Tue, 06 Sep 2011 14:29:07 +0100 Received: from fanf2 (helo=localhost) by hermes-2.csi.cam.ac.uk (hermes.cam.ac.uk) with local-esmtp id 1R0vi7-0006sp-U1 (Exim 4.67) (return-path ); Tue, 06 Sep 2011 14:29:07 +0100 Date: Tue, 6 Sep 2011 14:29:07 +0100 From: Tony Finch X-X-Sender: fanf2@hermes-2.csi.cam.ac.uk To: Marc Lampo In-Reply-To: <002e01cc6c72$6e28c920$4a7a5b60$@lampo@eurid.eu> Message-ID: References: <20110830162134.GB84494@shinkuro.com> <4e5f3343.cd06e70a.2596.ffffb1e7SMTPIN_ADDED@mx.google.com> <002e01cc6c72$6e28c920$4a7a5b60$@lampo@eurid.eu> 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] afasterinternet.com trial and draft-vandergaast-edns-client-subnet-00 X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Sep 2011 13:27:25 -0000 Marc Lampo wrote: > > - how can caching name service know which RRSIG, applying to RRset with > eg one A-record, goes with which A-record ? An RRSIG covers an entire RRset. Different caches may see different RRsets, and the same cache may see different RRsets at different times, so caches need to ensure each RRSIG is transmitted, cached, and expired alongside its RRset. The EDNS client subnet option allows caches to store multiple RRsets for the same name, type, and class at the same time, distinguishing them according to the client IP address. > - this is not "standard" for the authoritative name services, > to provide these multiple RRSIG's. Correct. Geo IP requires stunt name servers for all authoritative servers. The servers hand out different versions of the same RRset according to some internal logic. Each version of the RRset needs an appropriate RRSIG. There only need to be RRSIGs for the RRsets that are actually served. > The EDNS0 OPT record is mandatory, for DNSSEC. Records from client to > server cannot be signed anyway; I see no requirement/recommendation of > signing the OPT record from server to client. SIG(0) / TSIG. > What I really meant to express, is that, for public caching name services, > I'd recommend they implement DNSSEC themselves > (first - before implementing this/your draft RFC) Yes, but the only people who need to implement this draft are those running open resolvers with a very widely dispersed client population, and content delivery networks who want accurate geo IP for users of large open resolver services. Tony. -- f.anthony.n.finch http://dotat.at/ Portland, Plymouth: Southwest veering west 6 to gale 8, occasionally severe gale 9 at first in Portland, decreasing 5 at times later. Rough, occasionally very rough at first. Rain then showers. Moderate or good. From fweimer@bfk.de Tue Sep 6 06:30:56 2011 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D717D21F886A for ; Tue, 6 Sep 2011 06:30:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.014 X-Spam-Level: X-Spam-Status: No, score=-2.014 tagged_above=-999 required=5 tests=[AWL=0.235, BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nTjxcvzj8erR for ; Tue, 6 Sep 2011 06:30:52 -0700 (PDT) Received: from mx01.bfk.de (mx01.bfk.de [193.227.124.2]) by ietfa.amsl.com (Postfix) with ESMTP id C3BD121F87C9 for ; Tue, 6 Sep 2011 06:30:52 -0700 (PDT) Received: from mx00.int.bfk.de ([10.119.110.2]) by mx01.bfk.de with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) id 1R0vlS-0008NA-1H; Tue, 06 Sep 2011 13:32:34 +0000 Received: by bfk.de with local id 1R0vlR-0002uB-Rx; Tue, 06 Sep 2011 13:32:33 +0000 From: Florian Weimer To: Matt McCutchen References: <20110830162134.GB84494@shinkuro.com> <20110831031256.GA98758@shinkuro.com> <1314763320.2774.5.camel@localhost> Date: Tue, 06 Sep 2011 13:32:33 +0000 In-Reply-To: <1314763320.2774.5.camel@localhost> (Matt McCutchen's message of "Wed, 31 Aug 2011 00:01:58 -0400") Message-ID: <82k49lg5ji.fsf@mid.bfk.de> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Paul Vixie , dnsext@ietf.org Subject: Re: [dnsext] afasterinternet.com trial and draft-vandergaast-edns-client-subnet-00 X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Sep 2011 13:30:57 -0000 * Matt McCutchen: > From the peanut gallery, having a private use range seems like a > no-brainer. Some EDNS0 server-side implementations treat unknown option codes as hard errors. I'm not sure how widespread they are (but I believe at least one of them is still under security support). If widespread, it would make it difficult to define new option codes and make them work. A private use range implies an implicit promise that you can actually use it for experiments, and this may not be the case here. --=20 Florian Weimer BFK edv-consulting GmbH http://www.bfk.de/ Kriegsstra=DFe 100 tel: +49-721-96201-1 D-76133 Karlsruhe fax: +49-721-96201-99 From Ed.Lewis@neustar.biz Tue Sep 6 06:54:55 2011 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D1E3821F866A for ; Tue, 6 Sep 2011 06:54:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.501 X-Spam-Level: X-Spam-Status: No, score=-106.501 tagged_above=-999 required=5 tests=[AWL=0.098, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nt8pHyfMsKdp for ; Tue, 6 Sep 2011 06:54:54 -0700 (PDT) Received: from stora.ogud.com (stora.ogud.com [66.92.146.20]) by ietfa.amsl.com (Postfix) with ESMTP id 9B04B21F8610 for ; Tue, 6 Sep 2011 06:54:54 -0700 (PDT) Received: from Work-Laptop-2.local (nyttbox.md.ogud.com [10.20.30.4]) by stora.ogud.com (8.14.4/8.14.4) with ESMTP id p86Du4IY053572; Tue, 6 Sep 2011 09:56:05 -0400 (EDT) (envelope-from Ed.Lewis@neustar.biz) Received: from [192.168.129.78] by Work-Laptop-2.local (PGP Universal service); Tue, 06 Sep 2011 09:56:05 -0400 X-PGP-Universal: processed; by Work-Laptop-2.local on Tue, 06 Sep 2011 09:56:05 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: <002e01cc6c72$6e28c920$4a7a5b60$@lampo@eurid.eu> References: <20110830162134.GB84494@shinkuro.com> <4e5f3343.cd06e70a.2596.ffffb1e7SMTPIN_ADDED@mx.google.com> <002e01cc6c72$6e28c920$4a7a5b60$@lampo@eurid.eu> Date: Tue, 6 Sep 2011 09:56:02 -0400 To: Marc Lampo From: Edward Lewis Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.71 on 10.20.30.4 Cc: dnsext@ietf.org Subject: Re: [dnsext] afasterinternet.com trial and draft-vandergaast-edns-client-subnet-00 X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Sep 2011 13:54:55 -0000 Marc, Some of your concerns are already addressed by production software, even prior to the client-subnet proposal. Some concerns are already addressed by code that's "on the whiteboard" or better. And some concerns do need to be described in the document. As far as authoritative servers, the code that does the same as client-subnet is out there. For example, BIND has had "views" for a long time to support split DNS. BIND allows packets to be segregated by source IP or by destination IP (for use in servers that are multihomed). BIND uses particular zone files (which may be signed) for each "bucket" where queries are segregated. BIND's approach is not the only way to do this, just the most mature deployment out there, especially when confining the discussion to open source. Neustar (for one, one I have knowledge of) has a proprietary implementation that can do the same. Today our offered service does not support DNSSEC but should in some coming time frame. (I.e., it's whiteboard or better.) Our technical challenge is to sign the different possible answers ahead of time (easy) and then make sure the signature records are correctly associated with the appropriate answer sets (moderate problem). To us (Neustar's authoritative service), the only difference between today's offering (plus DNSSEC) and what client-subnet proposes (plus DNSSEC) is that when we choose based on only on the query's source IP address, we will have to substitute what's in the proposed EDNS0 option field and return appropriate address scoping information. Outside of where we get the parameter for "IP of who's asking" not much changes. As far as how recursive servers handle this, I don't know of any currently distributed servers that support this. (I'm sure there are some, I just am not privy to them.) The matter of assembling the query is rather simple, just put into the proposed option the value (IP subnet) to be used. (Having to treat BCP 153 space is needed as the equivalent in IPv6. And then there's NAT, etc.) The matter of how an iterative, caching server handles all this has to be accomplished. A lot of this though is implementation specific, the draft does need to lay out what defines "interoperable." All in all, though, DNSSEC isn't hard part of this. At 10:53 +0200 9/6/11, Marc Lampo wrote: >Hello, > >Point taken about it not being strictly required to effectively calculate >RRSIG's >on slave name servers. >While the caching name service might be aware about this particularity of >RRSIG's : > - several RRSIG's for same "RRset" but with different number of records >in the RRset. >Other problems to be solved : > - how can caching name service know which RRSIG, applying to RRset with >eg one A-record, > goes with which A-record ? > Do you want to check RRSIG in the caching name service and send only >the RRSIG that matches ? > - this is not "standard" for the authoritative name services, > to provide these multiple RRSIG's. > In case of 3 A-records in a RRset, > it would mean 3 RRSIG's applying to RRset with one A-record only, > + 1 RRSIG applying to complete RRset (all A-records). > > >The EDNS0 OPT record is mandatory, for DNSSEC. >Records from client to server cannot be signed anyway; >I see no requirement/recommendation of signing the OPT record from server >to client. >(the OPT record does not "live" as "signable data" in the zone file ! > it holds data that is applicable to a particular name server : > eg depending on how (what MTU) is valid at that particular name servers >location) > > >No, that is not the attack scenario I am referring at. >But this mailing list is hardly the place to show potential cache >poisoning attacks, is it ? > >What I really meant to express, is that, for public caching name services, >I'd recommend they implement DNSSEC themselves > (first - before implementing this/your draft RFC) >at least to the extend that they know where to locate the DS records. >That way, forwarding name servers are at least allowed to/capable of >performing DNSSEC validation themselves, >thus eliminating the risk of getting their cache poisoned. > > >Kind regards, > >Marc Lampo >EURid >Security Officer > > >-----Original Message----- >From: Wilmer van der Gaast [mailto:wilmer@google.com] >Sent: 05 September 2011 07:28 PM >To: Marc Lampo >Cc: dnsext@ietf.org >Subject: Re: [dnsext] afasterinternet.com trial and >draft-vandergaast-edns-client-subnet-00 > >On 1 September 2011 08:24, Marc Lampo wrote: >> [...] >> >> For an authoritative name server, implementing DNSSEC and this RFC, >> it probably implies that it must be able to calculate RRSIG's "on the >> fly"; >> Which implies that it must have access to the private part of DNSKEY's; >> Which implies that signing on a hidden master >> and distributing signed data to public slaves is not enough. > >As someone else already pointed out, this is not strictly necessary. >Also, this is not specific to edns-client-subnet as there are >nameservers right now that use the query source IP to determine the >optimal response. > >>From how I parse the DNSSEC specs, the OPT record is not signed >(wouldn't be possible without secret keys on the server anyway), so >edns-client-subnet doesn't change the situation. > >It may still be reasonable to mention something along these lines in the >I-D. > >I assume the attack scenario you're talking about is sending queries >with many different source IP addresses/client-subnet options and >sending spoofed responses with no client-subnet option at all? > > >Regards, > >-- >Wilmer van der Gaast, Traffic SRE/Google Public DNS team. >Google Ireland. >_______________________________________________ >dnsext mailing list >dnsext@ietf.org >https://www.ietf.org/mailman/listinfo/dnsext -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis NeuStar You can leave a voice message at +1-571-434-5468 Vote for the word of the day: "Papa"razzi - father that constantly takes photos of the baby Corpureaucracy - The institution of corporate "red tape" From sm@resistor.net Tue Sep 6 09:53:44 2011 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 243DF21F8C42 for ; Tue, 6 Sep 2011 09:53:44 -0700 (PDT) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KaFvOdDqIvsj for ; Tue, 6 Sep 2011 09:53:41 -0700 (PDT) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id E548221F8C41 for ; Tue, 6 Sep 2011 09:53:41 -0700 (PDT) Received: from SUBMAN.resistor.net (IDENT:sm@localhost [127.0.0.1]) by mx.elandsys.com (8.14.4/8.14.5) with ESMTP id p86GtMCb003125 for ; Tue, 6 Sep 2011 09:55:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1315328128; bh=nXxbYBxU4L0GlGRttTZNxCDISTeflfoFzUX2LVllM/4=; h=Message-Id:Date:To:From:Subject:In-Reply-To:References: Mime-Version:Content-Type:Cc; b=4JHJOW8ie0MRl4BcXPNPbLiVBvvwCXZvhGdYaq1hs6Lb//S+Ke73DQCiaOqL+s82z PKvh7IIK11tbW7NvMUr4p2+LL/INr14Yq2FkhZMtJu0zq/l5N7aAVtyhQW3BtyTY2t FOPUSN7iK9Ij5OkaSKxDH2JPTh0zuhyWQRtthB/k= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1315328128; bh=nXxbYBxU4L0GlGRttTZNxCDISTeflfoFzUX2LVllM/4=; h=Message-Id:Date:To:From:Subject:In-Reply-To:References: Mime-Version:Content-Type:Cc; b=nKEtfS4I1vM/5eePjr7q4zDmQK6M2ggfntDuUIxiB0Iti8JFnadWnCpEcS1KPMyvW b0uHMkDDETgsWxprBOVFKpnwbQ5Oz9q2xIgDxE+SWTy5HOj0anCWlq6Hyo5uIZq4e6 wm39haVp1FD3Npg5JSa4yuzx6O7vbdCwn1b9u2nI= Message-Id: <6.2.5.6.2.20110906064509.0871fdf0@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Tue, 06 Sep 2011 07:46:01 -0700 To: dnsext@ietf.org From: SM In-Reply-To: <4E65D2A7.3010308@necom830.hpcl.titech.ac.jp> References: <20110830162134.GB84494@shinkuro.com> <6.2.5.6.2.20110905114918.08670a18@resistor.net> <4E65D2A7.3010308@necom830.hpcl.titech.ac.jp> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: Re: [dnsext] Address privacy (was Re: afasterinternet.com trial and draft-vandergaast-edns-client-subnet-00) X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Sep 2011 16:53:44 -0000 At 00:58 06-09-2011, Masataka Ohta wrote: >Do you mean that the motivation is to improve TCP performance by >reducing TTL and *NOT* to reduce privacy? See http://forums.opendns.com/comments.php?DiscussionID=1096 The privacy threads are at http://www.ietf.org/mail-archive/web/dnsext/current/msg06548.html and http://www.ietf.org/mail-archive/web/dnsext/current/msg06577.html For anyone interested in privacy, there was a position paper submitted by IETF participants ( http://www.w3.org/2010/api-privacy-ws/papers/privacy-ws-32.pdf ). >Then, as as an IP address of "a DNS server (resolver is the >correct word, here) that is topologically close to them" is >known to OpenDNS and Google Public DNS, why do you have to >be bothered by client subnet? The authors of draft-vandergaast-edns-client-subnet-00 might point to Section 9.1. Regards, -sm From ted.ietf@gmail.com Tue Sep 6 10:20:20 2011 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2139221F8BFE for ; Tue, 6 Sep 2011 10:20:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B6xPfYhNLSHl for ; Tue, 6 Sep 2011 10:20:19 -0700 (PDT) Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by ietfa.amsl.com (Postfix) with ESMTP id 6096E21F8BF4 for ; Tue, 6 Sep 2011 10:20:19 -0700 (PDT) Received: by ywe9 with SMTP id 9so4882485ywe.31 for ; Tue, 06 Sep 2011 10:22:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=JMjtrx1SFsJAEidqB9R5DLg3yLoE/ch1B3U8uZ4YOsI=; b=JeAPdeuviYFzrWdaqDc06kEC3LWRjFDLkoCnK+hgnkh5kMESTMkpMPENtCHbcP1AvQ 10jpZRuXNiRpLgeOfGIav8PKc0vXqK8tugiReZtZyq05p6oGYQuVoiA9SxqqRypJ6DNp 52DejGnKVoP+pUsu4QMQorvWj/K3IC24wEzmI= MIME-Version: 1.0 Received: by 10.236.168.68 with SMTP id j44mr25972233yhl.32.1315329725130; Tue, 06 Sep 2011 10:22:05 -0700 (PDT) Received: by 10.236.110.174 with HTTP; Tue, 6 Sep 2011 10:22:04 -0700 (PDT) In-Reply-To: References: <20110830162134.GB84494@shinkuro.com> Date: Tue, 6 Sep 2011 10:22:04 -0700 Message-ID: From: Ted Hardie To: Wilmer van der Gaast Content-Type: text/plain; charset=ISO-8859-1 Cc: dnsext@ietf.org, draft-vandergaast-edns-client-subnet@tools.ietf.org Subject: Re: [dnsext] afasterinternet.com trial and draft-vandergaast-edns-client-subnet-00 X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Sep 2011 17:20:20 -0000 On Mon, Sep 5, 2011 at 10:09 AM, Wilmer van der Gaast wrote: > On 31 August 2011 17:03, Ted Hardie wrote: >> * 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. >> >> None of these changes seem to address the balance of discussion of the >> previous two versions. >> > I assume you are referring to the discussion about edns-client-subnet > or DNS-based CDNs being a reasonable solution at all? Not exactly, no. Some of those discussions suggested that this be opt-in rather than opt-out (so that the EDNS option is set by the client when desired, rather than it setting 0.0.0.0. when it does not desire it). The basic issue here is that this effectively changes the q-tuple to include a subnet as part of the question being asked. A discussion of why an intermediate should be the one to change the question seems warranted, if only to highlight the parameters of the experiment. regards, Ted Hardie From ted.ietf@gmail.com Tue Sep 6 10:23:58 2011 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 60AE821F8B7B for ; Tue, 6 Sep 2011 10:23:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6kln+27o7mHz for ; Tue, 6 Sep 2011 10:23:57 -0700 (PDT) Received: from mail-gx0-f172.google.com (mail-gx0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id ACC0B21F8B62 for ; Tue, 6 Sep 2011 10:23:57 -0700 (PDT) Received: by gxk19 with SMTP id 19so4845217gxk.31 for ; Tue, 06 Sep 2011 10:25:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=mN0HzABd1abz9/Jr1RjTXCH8ZehKco7wUGTf1uPmZLc=; b=bapIIn/M5KZmVq6l9khNseIP58gsMvil37A7Hq71ULLkSa2/l/L9FUpl9H252XOF23 11NjnTGbUAA0HzpcfgfIFNanVGOOMjnlZ8nC4xaSVWMo1sS/qCipFqBgq6Ma1YP0G2AK XOsu8tOT1Q+7sufaSk2zF3TUIYSE+y90/9Xcg= MIME-Version: 1.0 Received: by 10.236.115.70 with SMTP id d46mr25763286yhh.83.1315329944511; Tue, 06 Sep 2011 10:25:44 -0700 (PDT) Received: by 10.236.110.174 with HTTP; Tue, 6 Sep 2011 10:25:44 -0700 (PDT) In-Reply-To: <20110906072857.GA23307@merboo.mamista.net> References: <20110830162134.GB84494@shinkuro.com> <6.2.5.6.2.20110905114918.08670a18@resistor.net> <20110906072857.GA23307@merboo.mamista.net> Date: Tue, 6 Sep 2011 10:25:44 -0700 Message-ID: From: Ted Hardie To: Martin Barry Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: dnsext@ietf.org Subject: Re: [dnsext] afasterinternet.com trial and draft-vandergaast-edns-client-subnet-00 X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Sep 2011 17:23:58 -0000 On Tue, Sep 6, 2011 at 12:28 AM, Martin Barry wrote: > $quoted_author =3D "SM" ; >> >> From Section 9.1 of draft-vandergaast-edns-client-subnet-00: >> >> =A0 "Users who wish their full IP address to be hidden can include an >> =A0 =A0edns-client-subnet option specifying the wildcard address 0.0.0.0= /0" > >> Users who do not wish to provide a client identifier will have to >> update their software to support this specification. > > Or they could just not use OpenDNS, Google DNS or any other 3rd party > recursive DNS provider who enables edns-client-subnet. > > Hi Marty, The current draft says: In any case, the response from the resolver to the client MUST NOT contain the edns-client-subnet option if none was present in the client's original request. If the original client request contained a valid edns-client-subnet option that was used during recursion, the Recursive Resolver MUST include the edns-client-subnet option from the Authoritative Nameserver response in the response to the client. Given that, how is the client to know whether the service they are using en= ables edns-client-subnet? regards, Ted From nweaver@icsi.berkeley.edu Tue Sep 6 10:25:12 2011 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3591321F8BE4 for ; Tue, 6 Sep 2011 10:25:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kG6HDiQbI0Iw for ; Tue, 6 Sep 2011 10:25:11 -0700 (PDT) Received: from taffy.ICSI.Berkeley.EDU (taffy.ICSI.Berkeley.EDU [192.150.187.26]) by ietfa.amsl.com (Postfix) with ESMTP id C443E21F8B7B for ; Tue, 6 Sep 2011 10:25:11 -0700 (PDT) Received: from gala.icir.org (gala.ICIR.org [192.150.187.49]) (Authenticated sender: nweaver) by taffy.ICSI.Berkeley.EDU (Postfix) with ESMTP id EE09136A37E; Tue, 6 Sep 2011 10:26:58 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1244.3) Content-Type: text/plain; charset=iso-8859-1 From: Nicholas Weaver In-Reply-To: <82k49lg5ji.fsf@mid.bfk.de> Date: Tue, 6 Sep 2011 10:26:58 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <312BECDA-4385-4EFB-B94F-02F16D5638EF@icsi.berkeley.edu> References: <20110830162134.GB84494@shinkuro.com> <20110831031256.GA98758@shinkuro.com> <1314763320.2774.5.camel@localhost> <82k49lg5ji.fsf@mid.bfk.de> To: Florian Weimer X-Mailer: Apple Mail (2.1244.3) Cc: dnsext@ietf.org, Paul Vixie Subject: Re: [dnsext] afasterinternet.com trial and draft-vandergaast-edns-client-subnet-00 X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Sep 2011 17:25:12 -0000 On Sep 6, 2011, at 6:32 AM, Florian Weimer wrote: > * Matt McCutchen: >=20 >> =46rom the peanut gallery, having a private use range seems like a >> no-brainer. >=20 > Some EDNS0 server-side implementations treat unknown option codes as > hard errors. I'm not sure how widespread they are (but I believe at > least one of them is still under security support). If widespread, it > would make it difficult to define new option codes and make them work. > A private use range implies an implicit promise that you can actually > use it for experiments, and this may not be the case here. Unless the authority actually CRASHES when it receives an unknown EDNS0 = option code, there is no problem. All the resolver/client using the EDNS0 unknown option code needs to do = is treat it the same way you treat lack of EDNS0 support/lack of = fragment support already: Detect and fallback to not using the unknown = option code. So its really nothing new, just using the same techniques already in = place for all the @#)(*#) which doesn't understand EDNS0 or is behind a = broken (fragment or EDNS0 denying) firewall. And if the authority DOES crash when it receives an unknown EDNS0 option = code, well, report it as a security bug to the vendor. From nweaver@icsi.berkeley.edu Tue Sep 6 10:26:35 2011 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8FC7E21F8B58 for ; Tue, 6 Sep 2011 10:26:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dv+UCAaDOQoP for ; Tue, 6 Sep 2011 10:26:35 -0700 (PDT) Received: from taffy.ICSI.Berkeley.EDU (taffy.ICSI.Berkeley.EDU [192.150.187.26]) by ietfa.amsl.com (Postfix) with ESMTP id D7FE721F8B4D for ; Tue, 6 Sep 2011 10:26:34 -0700 (PDT) Received: from gala.icir.org (gala.ICIR.org [192.150.187.49]) (Authenticated sender: nweaver) by taffy.ICSI.Berkeley.EDU (Postfix) with ESMTP id 20E8736A37E; Tue, 6 Sep 2011 10:28:22 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1244.3) Content-Type: text/plain; charset=iso-8859-1 From: Nicholas Weaver In-Reply-To: Date: Tue, 6 Sep 2011 10:28:21 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <39736B7C-63B4-4C3F-B87F-92D05C7B88AA@icsi.berkeley.edu> References: <20110830162134.GB84494@shinkuro.com> <6.2.5.6.2.20110905114918.08670a18@resistor.net> <20110906072857.GA23307@merboo.mamista.net> To: Ted Hardie X-Mailer: Apple Mail (2.1244.3) Cc: dnsext@ietf.org Subject: Re: [dnsext] afasterinternet.com trial and draft-vandergaast-edns-client-subnet-00 X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Sep 2011 17:26:35 -0000 On Sep 6, 2011, at 10:25 AM, Ted Hardie wrote: > Hi Marty, >=20 > The current draft says: >=20 > In any case, the response from the resolver to the client MUST NOT > contain the edns-client-subnet option if none was present in the > client's original request. If the original client request contained > a valid edns-client-subnet option that was used during recursion, = the > Recursive Resolver MUST include the edns-client-subnet option from > the Authoritative Nameserver response in the response to the client. >=20 > Given that, how is the client to know whether the service they are = using enables > edns-client-subnet? a) Does it matter? b) Do a query with EDNS0 client subnet and see what happens. From ted.ietf@gmail.com Tue Sep 6 10:38:49 2011 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 30F9921F8C7F for ; Tue, 6 Sep 2011 10:38:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mWNtXbmUk8pE for ; Tue, 6 Sep 2011 10:38:48 -0700 (PDT) Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by ietfa.amsl.com (Postfix) with ESMTP id 62CE421F8C7A for ; Tue, 6 Sep 2011 10:38:48 -0700 (PDT) Received: by gyf3 with SMTP id 3so4688112gyf.31 for ; Tue, 06 Sep 2011 10:40:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=7s9tHyI7WvESSswUR4liV5tbFFAJKnHKUodKohnDdK8=; b=A6tfM7gPrUbRogBrEKDgjjY3z4iDnvpGUDJYlkGizbEkPyibMw0CbVwy+D4HHYjEpA Xp/47s2O+weaRIe0Y4vMmtYAi1sX1+q9Dd1BAhA6XPieerfpwxBpGahxNen11rooen/l bi69kvs2oGf04h0EMkfz1Elw9AndjE/ThR484= MIME-Version: 1.0 Received: by 10.236.179.103 with SMTP id g67mr8751156yhm.49.1315330834424; Tue, 06 Sep 2011 10:40:34 -0700 (PDT) Received: by 10.236.110.174 with HTTP; Tue, 6 Sep 2011 10:40:34 -0700 (PDT) In-Reply-To: <39736B7C-63B4-4C3F-B87F-92D05C7B88AA@icsi.berkeley.edu> References: <20110830162134.GB84494@shinkuro.com> <6.2.5.6.2.20110905114918.08670a18@resistor.net> <20110906072857.GA23307@merboo.mamista.net> <39736B7C-63B4-4C3F-B87F-92D05C7B88AA@icsi.berkeley.edu> Date: Tue, 6 Sep 2011 10:40:34 -0700 Message-ID: From: Ted Hardie To: Nicholas Weaver Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: dnsext@ietf.org Subject: Re: [dnsext] afasterinternet.com trial and draft-vandergaast-edns-client-subnet-00 X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Sep 2011 17:38:49 -0000 On Tue, Sep 6, 2011 at 10:28 AM, Nicholas Weaver wrote: > > On Sep 6, 2011, at 10:25 AM, Ted Hardie wrote: (adding Marty's comment back in ) On Tue, Sep 6, 2011 at 12:28 AM, Martin Barry wrote: > $quoted_author =3D "SM" ; >> >> From Section 9.1 of draft-vandergaast-edns-client-subnet-00: >> >> "Users who wish their full IP address to be hidden can include an >> edns-client-subnet option specifying the wildcard address 0.0.0.0/0" > >> Users who do not wish to provide a client identifier will have to >> update their software to support this specification. > > Or they could just not use OpenDNS, Google DNS or any other 3rd party > recursive DNS provider who enables edns-client-subnet. > >> Hi Marty, >> >> The current draft says: >> >> =A0 In any case, the response from the resolver to the client MUST NOT >> =A0 contain the edns-client-subnet option if none was present in the >> =A0 client's original request. =A0If the original client request contain= ed >> =A0 a valid edns-client-subnet option that was used during recursion, th= e >> =A0 Recursive Resolver MUST include the edns-client-subnet option from >> =A0 the Authoritative Nameserver response in the response to the client. >> >> Given that, how is the client to know whether the service they are using= enables >> edns-client-subnet? > > a) =A0Does it matter? > > b) =A0Do a query with EDNS0 client subnet and see what happens. > The upshot of this is that SM is right: clients who do not wish to provide a client identifier will have to update their software to achieve this goal, since they cannot identify whether a service is using it without that update. regards, Ted Hardie > From nweaver@ICSI.Berkeley.EDU Tue Sep 6 11:00:28 2011 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B2D7B21F8CC0 for ; Tue, 6 Sep 2011 11:00:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PFZZ8er-rljI for ; Tue, 6 Sep 2011 11:00:28 -0700 (PDT) Received: from taffy.ICSI.Berkeley.EDU (taffy.ICSI.Berkeley.EDU [192.150.187.26]) by ietfa.amsl.com (Postfix) with ESMTP id 2487D21F8B6B for ; Tue, 6 Sep 2011 11:00:28 -0700 (PDT) Received: from gala.icir.org (gala.ICIR.org [192.150.187.49]) (Authenticated sender: nweaver) by taffy.ICSI.Berkeley.EDU (Postfix) with ESMTP id 5D15C36A37E; Tue, 6 Sep 2011 11:02:15 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1244.3) Content-Type: text/plain; charset=iso-8859-1 From: Nicholas Weaver In-Reply-To: Date: Tue, 6 Sep 2011 11:02:15 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <62A2F704-6DDF-458B-B994-5A0200DE3F03@ICSI.Berkeley.EDU> References: <20110830162134.GB84494@shinkuro.com> <6.2.5.6.2.20110905114918.08670a18@resistor.net> <20110906072857.GA23307@merboo.mamista.net> <39736B7C-63B4-4C3F-B87F-92D05C7B88AA@icsi.berkeley.edu> To: Ted Hardie X-Mailer: Apple Mail (2.1244.3) Cc: dnsext@ietf.org Subject: Re: [dnsext] afasterinternet.com trial and draft-vandergaast-edns-client-subnet-00 X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Sep 2011 18:00:28 -0000 On Sep 6, 2011, at 10:40 AM, Ted Hardie wrote: >> a) Does it matter? >>=20 >> b) Do a query with EDNS0 client subnet and see what happens. >>=20 >=20 > The upshot of this is that SM is right: clients who do not wish to > provide a client > identifier will have to update their software to achieve this goal, > since they cannot > identify whether a service is using it without that update. >=20 > regards, But at the same time, what information is being leaked to whom? =20 Which is the only reason why a client would want to disable this at all, = and the only reason to argue for "opt-in" rather than "opt-out" on the = client viewpoint. (Yes, this zombie keeps rising.)=20 NO information is being leaked TO the recursive resolver, it already = gets all this information. The only information leakage is SUBNET (NOT IP address), TO the = authority for the domain. =20 Which would ONLY be an information leakage at all if either: a) The authority is NOT responsible for operating the final server the = client eventually contacts=20 or b) The client does NOT use the DNS record to contact a server belonging = to the authority or c) The client uses a broken tunnel, contacting the final server from a = different IP from that used by DNS. And this is ONLY necessary for out-of-path resolvers (eg, Google Public = DNS, OpenDNS), where in almost all cases the user has already explicitly = opted in! =20 No other resolver really benefits from supporting this anyway, as most = of the big nation-spanning ISPs have already gone with a distributed DNS = infrastructure, so the IP address of the query to the authority is = already giving the authority of the domain information roughly = equivalent to what EDNS-client-subnet provides. From ted.ietf@gmail.com Tue Sep 6 11:27:21 2011 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E21C021F8D05 for ; Tue, 6 Sep 2011 11:27:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 51k8JAHWpJlH for ; Tue, 6 Sep 2011 11:27:21 -0700 (PDT) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by ietfa.amsl.com (Postfix) with ESMTP id 418DF21F8CFF for ; Tue, 6 Sep 2011 11:27:21 -0700 (PDT) Received: by yxj17 with SMTP id 17so3677163yxj.31 for ; Tue, 06 Sep 2011 11:29:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=zAWqxqJl/VAw+FGyEmSznFOii/WGkDmmtttNO1C26xs=; b=ZOIqlQw7NJE4JahpvbmQXrAnzz+bXWHO2ipx1aHJVAUNLujp3EbwW6Jga6tEE/+056 kvaJsZTQaPChUnqgWLcBa8jAP9ULzQT97HT7SzNXdvTb4dSWP+TSA3S7VW1yN7J4zSv2 bdc703woRdJtiOe/uRETHz00IfwjyGrFm5oRs= MIME-Version: 1.0 Received: by 10.236.165.71 with SMTP id d47mr26022069yhl.15.1315333748260; Tue, 06 Sep 2011 11:29:08 -0700 (PDT) Received: by 10.236.110.174 with HTTP; Tue, 6 Sep 2011 11:29:08 -0700 (PDT) In-Reply-To: <62A2F704-6DDF-458B-B994-5A0200DE3F03@ICSI.Berkeley.EDU> References: <20110830162134.GB84494@shinkuro.com> <6.2.5.6.2.20110905114918.08670a18@resistor.net> <20110906072857.GA23307@merboo.mamista.net> <39736B7C-63B4-4C3F-B87F-92D05C7B88AA@icsi.berkeley.edu> <62A2F704-6DDF-458B-B994-5A0200DE3F03@ICSI.Berkeley.EDU> Date: Tue, 6 Sep 2011 11:29:08 -0700 Message-ID: From: Ted Hardie To: Nicholas Weaver Content-Type: text/plain; charset=ISO-8859-1 Cc: dnsext@ietf.org Subject: Re: [dnsext] afasterinternet.com trial and draft-vandergaast-edns-client-subnet-00 X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Sep 2011 18:27:22 -0000 On Tue, Sep 6, 2011 at 11:02 AM, Nicholas Weaver wrote: > > The only information leakage is SUBNET (NOT IP address), TO the authority for the domain. > This EDNS0 option provides data about the address range in which the stub resolver's IP occurs to the authoritative DNS server (whether it should really be called a subnet is a nit). I think that intention is clear in the draft, and if I said anything that indicated I didn't see that as the intention or didn't think it was clear, please take this as a correction. regards, Ted Hardie From marty@supine.com Tue Sep 6 11:51:33 2011 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1385221F8BEF for ; Tue, 6 Sep 2011 11:51:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cuWrddxrlRIF for ; Tue, 6 Sep 2011 11:51:32 -0700 (PDT) Received: from tigger.mamista.net (tigger.mamista.net [IPv6:2001:470:1f05:a0f::1]) by ietfa.amsl.com (Postfix) with ESMTP id 2186421F8BE9 for ; Tue, 6 Sep 2011 11:51:32 -0700 (PDT) Received: by tigger.mamista.net (Postfix, from userid 1012) id 727201101CE; Wed, 7 Sep 2011 04:53:18 +1000 (EST) Received: from merboo.mamista.net (merboo.mamista.net [IPv6:2001:470:1f0b:1055::1]) by tigger.mamista.net (Postfix) with ESMTP id CC04E1100B2 for ; Wed, 7 Sep 2011 04:53:15 +1000 (EST) Received: by merboo.mamista.net (Postfix, from userid 1000) id 4219920D37; Tue, 6 Sep 2011 20:53:14 +0200 (CEST) Date: Tue, 6 Sep 2011 20:53:14 +0200 From: Martin Barry To: dnsext@ietf.org Message-ID: <20110906185314.GB26523@merboo.mamista.net> References: <20110830162134.GB84494@shinkuro.com> <6.2.5.6.2.20110905114918.08670a18@resistor.net> <20110906072857.GA23307@merboo.mamista.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [dnsext] afasterinternet.com trial and draft-vandergaast-edns-client-subnet-00 X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Sep 2011 18:51:33 -0000 $quoted_author = "Ted Hardie" ; > > The current draft says: > > In any case, the response from the resolver to the client MUST NOT > contain the edns-client-subnet option if none was present in the > client's original request. If the original client request contained > a valid edns-client-subnet option that was used during recursion, the > Recursive Resolver MUST include the edns-client-subnet option from > the Authoritative Nameserver response in the response to the client. > > Given that, how is the client to know whether the service they are using enables > edns-client-subnet? You could, as Nicholas suggested, test a query with edns-client-subnet set. However I would expect that the information these providers offer to potential users contains advice that use of the service implies opting-in to the forwarding of the range containing the user's IP to other services to improve geo-IP responses. I'm sure users will read it and understand it much like they do all the other fine print. However, I'm sure anyone who cares about privacy to this extent is probably already too risk averse to use said services anyway. cheers Marty From bmanning@karoshi.com Tue Sep 6 13:54:50 2011 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CB88121F8EB9 for ; Tue, 6 Sep 2011 13:54:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.208 X-Spam-Level: X-Spam-Status: No, score=-6.208 tagged_above=-999 required=5 tests=[AWL=0.391, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qvQRNsbBTy1u for ; Tue, 6 Sep 2011 13:54:49 -0700 (PDT) Received: from vacation.karoshi.com (vacation.karoshi.com [198.32.6.68]) by ietfa.amsl.com (Postfix) with ESMTP id 4C33221F8EB8 for ; Tue, 6 Sep 2011 13:54:49 -0700 (PDT) Received: from karoshi.com (localhost.localdomain [127.0.0.1]) by vacation.karoshi.com (8.12.8/8.12.8) with ESMTP id p86KtWhn004629; Tue, 6 Sep 2011 20:55:33 GMT Received: (from bmanning@localhost) by karoshi.com (8.12.8/8.12.8/Submit) id p86KtVlT004628; Tue, 6 Sep 2011 20:55:31 GMT Date: Tue, 6 Sep 2011 20:55:31 +0000 From: bmanning@vacation.karoshi.com To: Nicholas Weaver Message-ID: <20110906205531.GB4576@vacation.karoshi.com.> References: <20110830162134.GB84494@shinkuro.com> <6.2.5.6.2.20110905114918.08670a18@resistor.net> <20110906072857.GA23307@merboo.mamista.net> <39736B7C-63B4-4C3F-B87F-92D05C7B88AA@icsi.berkeley.edu> <62A2F704-6DDF-458B-B994-5A0200DE3F03@ICSI.Berkeley.EDU> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <62A2F704-6DDF-458B-B994-5A0200DE3F03@ICSI.Berkeley.EDU> User-Agent: Mutt/1.4.1i Cc: dnsext@ietf.org Subject: Re: [dnsext] afasterinternet.com trial and draft-vandergaast-edns-client-subnet-00 X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Sep 2011 20:54:50 -0000 On Tue, Sep 06, 2011 at 11:02:15AM -0700, Nicholas Weaver wrote: > > The only information leakage is SUBNET (NOT IP address), TO the authority for the domain. > > Which would ONLY be an information leakage at all if either: > > a) The authority is NOT responsible for operating the final server the client eventually contacts > b) The client does NOT use the DNS record to contact a server belonging to the authority > c) The client uses a broken tunnel, contacting the final server from a different IP from that used by DNS. c) - at one time was very common, most computers had multiple NICs, each with its own IP. in the last decade, it became common for a single NIC with one usable IP, HOWEVER these days, the NIC in my laptop has NINE IPs associated with it (thanks IPv6)... So the channel my machine uses to talk to the DNS likely has little to no relationship with the channel used to talk with other nodes. This is particularly true in walled gardens with DNS lattice... The DNS server has no idea/concept of the topology betwen my node and the target node - This proposal is trying to allow DNS service to fabricate a synthetic view of a presumed map of Internet topology and then project that fabrication on its clients. IMHO, that pretty much exceeds the remit of the DNS. :) /bill > > > > And this is ONLY necessary for out-of-path resolvers (eg, Google Public DNS, OpenDNS), where in almost all cases the user has already explicitly opted in! > > No other resolver really benefits from supporting this anyway, as most of the big nation-spanning ISPs have already gone with a distributed DNS infrastructure, so the IP address of the query to the authority is already giving the authority of the domain information roughly equivalent to what EDNS-client-subnet provides. > > _______________________________________________ > dnsext mailing list > dnsext@ietf.org > https://www.ietf.org/mailman/listinfo/dnsext From hallam@gmail.com Tue Sep 6 15:25:03 2011 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D39AA21F8F2B for ; Tue, 6 Sep 2011 15:25:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.456 X-Spam-Level: X-Spam-Status: No, score=-3.456 tagged_above=-999 required=5 tests=[AWL=0.142, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vq19KH7qdnmM for ; Tue, 6 Sep 2011 15:25:03 -0700 (PDT) Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by ietfa.amsl.com (Postfix) with ESMTP id 04F8721F8F25 for ; Tue, 6 Sep 2011 15:25:02 -0700 (PDT) Received: by ywe9 with SMTP id 9so5131407ywe.31 for ; Tue, 06 Sep 2011 15:26:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=liffi0wcQBlkfwW/JMHO8zA8Cy4/rG/qfHpYvfUnDLs=; b=fdrsO/P3xNvbuj7ne4KvPXmnOLmQZBBzsk+y2II9DexPFjt3dQCbKyYJGymgKZ7rvK Tu3w1jw4rhciaiK3JI0p6AvPD8hN6vcaMWDLbelYVHIxMA2Z6p8B187DjkDNv2bkTwkn AS2CvceSlYCgGQX9/czY/7bv2Sh2VWfDObcR4= MIME-Version: 1.0 Received: by 10.101.131.4 with SMTP id i4mr4062052ann.61.1315348009694; Tue, 06 Sep 2011 15:26:49 -0700 (PDT) Received: by 10.100.8.7 with HTTP; Tue, 6 Sep 2011 15:26:49 -0700 (PDT) In-Reply-To: <82k49lg5ji.fsf@mid.bfk.de> References: <20110830162134.GB84494@shinkuro.com> <20110831031256.GA98758@shinkuro.com> <1314763320.2774.5.camel@localhost> <82k49lg5ji.fsf@mid.bfk.de> Date: Tue, 6 Sep 2011 18:26:49 -0400 Message-ID: From: Phillip Hallam-Baker To: Florian Weimer Content-Type: multipart/alternative; boundary=001636c92a3fdfb72a04ac4d5201 Cc: dnsext@ietf.org, Paul Vixie Subject: Re: [dnsext] afasterinternet.com trial and draft-vandergaast-edns-client-subnet-00 X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Sep 2011 22:25:04 -0000 --001636c92a3fdfb72a04ac4d5201 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Then let them break. If people are cretinous to make that type of mistake then they are going to see stuff break all over. Google can fix this in a week. All they need to do is to advertise a random EDNS0 code and the problem will go away pronto. Seriously, this was intended to be the extension mechanism for DNS . People should have known. On Tue, Sep 6, 2011 at 9:32 AM, Florian Weimer wrote: > * Matt McCutchen: > > > From the peanut gallery, having a private use range seems like a > > no-brainer. > > Some EDNS0 server-side implementations treat unknown option codes as > hard errors. I'm not sure how widespread they are (but I believe at > least one of them is still under security support). If widespread, it > would make it difficult to define new option codes and make them work. > A private use range implies an implicit promise that you can actually > use it for experiments, and this may not be the case here. > > -- > 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 > _______________________________________________ > dnsext mailing list > dnsext@ietf.org > https://www.ietf.org/mailman/listinfo/dnsext > --=20 Website: http://hallambaker.com/ --001636c92a3fdfb72a04ac4d5201 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Then let them break.

If people are cretinous to make tha= t type of mistake then they are going to see stuff break all over.


Google can fix this in a week. All they nee= d to do is to advertise a random EDNS0 code and the problem will go away pr= onto.

Seriously, this was intended to be the extension mechan= ism for DNS . People should have known.


On Tue, Sep 6, 2011 at 9:32 AM, Florian Weimer = <fweimer@bfk.de> wrote:<= br>
* Matt McCutchen:

> From the peanut gallery, having a private use range seems like a
> no-brainer.

Some EDNS0 server-side implementations treat unknown option codes as<= br> hard errors. =A0I'm not sure how widespread they are (but I believe at<= br> least one of them is still under security support). =A0If widespread, it would make it difficult to define new option codes and make them work.
A private use range implies an implicit promise that you can actually
use it for experiments, and this may not be the case here.

--
Florian Weimer =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0<fweimer@bfk.de>
BFK edv-consulting GmbH =A0 =A0 =A0 http://www.bfk.de/
Kriegsstra=DFe 100 =A0 =A0 =A0 =A0 =A0 =A0 =A0tel: +49-721-96201-1
D-76133 Karlsruhe =A0 =A0 =A0 =A0 =A0 =A0 fax: +49-721-96201-99
__________________________________= _____________
dnsext mailing list
dnsext@ietf.org
= https://www.ietf.org/mailman/listinfo/dnsext



--
= Website: http://hallambaker.com/
--001636c92a3fdfb72a04ac4d5201-- From mohta@necom830.hpcl.titech.ac.jp Tue Sep 6 16:01:08 2011 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CB9EE21F8DC1 for ; Tue, 6 Sep 2011 16:01:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.025 X-Spam-Level: X-Spam-Status: No, score=-0.025 tagged_above=-999 required=5 tests=[AWL=0.065, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ymWDgsLrcgVS for ; Tue, 6 Sep 2011 16:01:08 -0700 (PDT) Received: from necom830.hpcl.titech.ac.jp (necom830.hpcl.titech.ac.jp [131.112.32.132]) by ietfa.amsl.com (Postfix) with SMTP id CCC9021F8DA0 for ; Tue, 6 Sep 2011 16:01:07 -0700 (PDT) Received: (qmail 8913 invoked from network); 6 Sep 2011 23:09: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; 6 Sep 2011 23:09:46 -0000 Message-ID: <4E66A65C.6080604@necom830.hpcl.titech.ac.jp> Date: Wed, 07 Sep 2011 08:01:48 +0900 From: Masataka Ohta User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:6.0.1) Gecko/20110830 Thunderbird/6.0.1 MIME-Version: 1.0 To: SM References: <20110830162134.GB84494@shinkuro.com> <6.2.5.6.2.20110905114918.08670a18@resistor.net> <4E65D2A7.3010308@necom830.hpcl.titech.ac.jp> <6.2.5.6.2.20110906064509.0871fdf0@resistor.net> In-Reply-To: <6.2.5.6.2.20110906064509.0871fdf0@resistor.net> Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit Cc: dnsext@ietf.org Subject: Re: [dnsext] Address privacy (was Re: afasterinternet.com trial and draft-vandergaast-edns-client-subnet-00) X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Sep 2011 23:01:08 -0000 SM wrote: >> Do you mean that the motivation is to improve TCP performance by >> reducing TTL and *NOT* to reduce privacy? > See http://forums.opendns.com/comments.php?DiscussionID=1096 The privacy > threads are at > http://www.ietf.org/mail-archive/web/dnsext/current/msg06548.html and > http://www.ietf.org/mail-archive/web/dnsext/current/msg06577.html I looked at your referral but can't see any point, which impresses me that you are trying not to enhance performance but to reduce users' privacy. Then, there is no point for IETF to admit such an extension. Or, if you want to argue something, make your point by your own words. > For anyone interested in privacy, there was a position paper submitted > by IETF participants ( > http://www.w3.org/2010/api-privacy-ws/papers/privacy-ws-32.pdf ). Isn't it enough that the paper title says "improving privacy on the Internet", where as the client subnet option actively degrade the privacy? >> Then, as as an IP address of "a DNS server (resolver is the >> correct word, here) that is topologically close to them" is >> known to OpenDNS and Google Public DNS, why do you have to >> be bothered by client subnet? > > The authors of draft-vandergaast-edns-client-subnet-00 might point to > Section 9.1. My question is "why do you have to be bothered by client subnet?" even though there is no need for performance enhancement. The section of the draft says nothing about it. Masataka Ohta From wilmer@google.com Wed Sep 7 03:37:51 2011 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DCE8D21F8B15 for ; Wed, 7 Sep 2011 03:37:51 -0700 (PDT) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Plq6wE0bwMjA for ; Wed, 7 Sep 2011 03:37:51 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by ietfa.amsl.com (Postfix) with ESMTP id E5B9421F8B11 for ; Wed, 7 Sep 2011 03:37:50 -0700 (PDT) Received: from wpaz13.hot.corp.google.com (wpaz13.hot.corp.google.com [172.24.198.77]) by smtp-out.google.com with ESMTP id p87AddTs011281 for ; Wed, 7 Sep 2011 03:39:39 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1315391979; bh=wedknSPqsMheaYGu1Sn/RCqSmbs=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type:Content-Transfer-Encoding; b=p8UDztJvDY532/cA8vBAlyZq6fhcYhvggtcrNEtsZWTjJoH+ceyCMjF6GRKhbuR9E 1xncPuyBuqyfeMkh1wAVQ== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=dkim-signature:mime-version:in-reply-to:references:date: message-id:subject:from:to:cc:content-type: content-transfer-encoding:x-system-of-record; b=hIa3oTu83sGX4yKwMbOGvw/KFR5iaRftTUgge4zbJ+C5ryytdDWF6AezkzFNW5pOb HTC1Ydcw2+ivguePZn1Xg== Received: from gye5 (gye5.prod.google.com [10.243.50.5]) by wpaz13.hot.corp.google.com with ESMTP id p87AdcTT011135 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Wed, 7 Sep 2011 03:39:38 -0700 Received: by gye5 with SMTP id 5so294648gye.32 for ; Wed, 07 Sep 2011 03:39:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=7DkiLnerWhqjF5bhQkXojCj2NhDBjjvvkp364s8n9WQ=; b=Z6Pm3k6ty3U11yuc7ODoslSpDdmN4PInjk3C3kBi6trauM1DpOR4w2NrqiJ2a6T+r2 jb7+1S9tAVz26TgqrWJw== Received: by 10.42.18.132 with SMTP id x4mr1368315ica.107.1315391977556; Wed, 07 Sep 2011 03:39:37 -0700 (PDT) MIME-Version: 1.0 Received: by 10.42.18.132 with SMTP id x4mr1368310ica.107.1315391977371; Wed, 07 Sep 2011 03:39:37 -0700 (PDT) Received: by 10.231.16.69 with HTTP; Wed, 7 Sep 2011 03:39:37 -0700 (PDT) In-Reply-To: References: <20110830162134.GB84494@shinkuro.com> <6.2.5.6.2.20110905114918.08670a18@resistor.net> <20110906072857.GA23307@merboo.mamista.net> Date: Wed, 7 Sep 2011 11:39:37 +0100 Message-ID: From: Wilmer van der Gaast To: Ted Hardie Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-System-Of-Record: true Cc: dnsext@ietf.org Subject: Re: [dnsext] afasterinternet.com trial and draft-vandergaast-edns-client-subnet-00 X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Sep 2011 10:37:52 -0000 On 6 September 2011 18:25, Ted Hardie wrote: > The current draft says: > > =A0 In any case, the response from the resolver to the client MUST NOT > =A0 contain the edns-client-subnet option if none was present in the > =A0 client's original request. =A0If the original client request containe= d > =A0 a valid edns-client-subnet option that was used during recursion, the > =A0 Recursive Resolver MUST include the edns-client-subnet option from > =A0 the Authoritative Nameserver response in the response to the client. > > Given that, how is the client to know whether the service they are using = enables > edns-client-subnet? > Correct. If there's demand for it, it shouldn't be hard to run a server somewhere that (similar to names like self.myresolver.info and dso.honeyd.org) will return you a response telling if there was an edns-client-subnet option and/or what was in it. Cheers, --=20 Wilmer van der Gaast, Traffic SRE/Google Public DNS team. Google Ireland. From sm@resistor.net Wed Sep 7 10:00:27 2011 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8FEE021F8D21 for ; Wed, 7 Sep 2011 10:00:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.573 X-Spam-Level: X-Spam-Status: No, score=-102.573 tagged_above=-999 required=5 tests=[AWL=0.026, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wY-aRNrFzRJy for ; Wed, 7 Sep 2011 10:00:23 -0700 (PDT) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 715FF21F8CF8 for ; Wed, 7 Sep 2011 10:00:23 -0700 (PDT) Received: from SUBMAN.resistor.net (IDENT:sm@localhost [127.0.0.1]) by mx.elandsys.com (8.14.4/8.14.5) with ESMTP id p87H24dN027522 for ; Wed, 7 Sep 2011 10:02:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1315414933; bh=L2qVS1fshhYVIF4PFyWo5JrNacIb7Q7mIfsI+/fCOXg=; h=Message-Id:Date:To:From:Subject:In-Reply-To:References: Mime-Version:Content-Type:Cc; b=UorQsLS0BRwOggrbuTbaPd8S7nqRs0hzS78vywGGSyx3sensr1j3qhF70OP+eUElc Uuv7/d3YTSptcZaiMZqOfqpahAze7hk4dghEC+7uKLgImHy47rYlOFu/TWKPwCg2tX BRWShrFU9GVMIVZ1ZjF/kKpQGszLNAas0vHwckTU= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1315414933; bh=L2qVS1fshhYVIF4PFyWo5JrNacIb7Q7mIfsI+/fCOXg=; h=Message-Id:Date:To:From:Subject:In-Reply-To:References: Mime-Version:Content-Type:Cc; b=UiFLM4pQt6mOpOhHF2OiO0Rbwn3UpO57iXtEct2//MpCb+llyABWwAkc5A8tNsvcB xtuFDr34+8R25zEzoK6ANlfDUhIqTEGMky7qp7EZJEnNVJMKN9qY6W/FHohoS2BY+E ICp/ppfNUXdHpMW2j3WsWcBWF4u8TlQe6wFy5erE= Message-Id: <6.2.5.6.2.20110907092212.07f4c378@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Wed, 07 Sep 2011 09:47:57 -0700 To: dnsext@ietf.org From: SM In-Reply-To: <4E66A65C.6080604@necom830.hpcl.titech.ac.jp> References: <20110830162134.GB84494@shinkuro.com> <6.2.5.6.2.20110905114918.08670a18@resistor.net> <4E65D2A7.3010308@necom830.hpcl.titech.ac.jp> <6.2.5.6.2.20110906064509.0871fdf0@resistor.net> <4E66A65C.6080604@necom830.hpcl.titech.ac.jp> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: Re: [dnsext] Address privacy (was Re: afasterinternet.com trial and draft-vandergaast-edns-client-subnet-00) X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Sep 2011 17:00:27 -0000 At 16:01 06-09-2011, Masataka Ohta wrote: >I looked at your referral but can't see any point, which >impresses me that you are trying not to enhance performance >but to reduce users' privacy. There seems to be a misunderstanding. I did not author the proposal. The referrals are informative. It is left to the reader to form an opinion about performance enhancement and loss of user privacy. Regards, -sm From casey@deccio.net Wed Sep 7 16:08:09 2011 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B30521F8DE5 for ; Wed, 7 Sep 2011 16:08:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.976 X-Spam-Level: X-Spam-Status: No, score=-2.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o+z3lS3kO+nK for ; Wed, 7 Sep 2011 16:08:08 -0700 (PDT) Received: from mail-qy0-f179.google.com (mail-qy0-f179.google.com [209.85.216.179]) by ietfa.amsl.com (Postfix) with ESMTP id 8361621F8DE2 for ; Wed, 7 Sep 2011 16:08:08 -0700 (PDT) Received: by qyk35 with SMTP id 35so116545qyk.10 for ; Wed, 07 Sep 2011 16:09:58 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.62.81 with SMTP id w17mr3339797qch.168.1315436998675; Wed, 07 Sep 2011 16:09:58 -0700 (PDT) Received: by 10.229.34.138 with HTTP; Wed, 7 Sep 2011 16:09:58 -0700 (PDT) Date: Wed, 7 Sep 2011 16:09:58 -0700 Message-ID: From: Casey Deccio To: DNSSEC deployment Content-Type: multipart/alternative; boundary=0016e651fd5007cc6204ac620bf7 Cc: dnsext@ietf.org Subject: [dnsext] mandatory algorithms (was: Some more sinners... virginia.gov & onguardonline.gov) X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Sep 2011 23:08:09 -0000 --0016e651fd5007cc6204ac620bf7 Content-Type: text/plain; charset=ISO-8859-1 On Wed, Sep 7, 2011 at 11:37 AM, Casey Deccio wrote: > I can see that dnssec-bis-updates-14 omits that and only requires that the > DNSKEY RRset be signed only using algs from the DNSKEY RRset itself: > > http://tools.ietf.org/html/draft-ietf-dnsext-dnssec-bis-updates-14 > > (Sec 5.11) > > [including dnsext... feel free to move entirely, if appropriate] Ahem. Upon more careful examination I see that when you combine the requirements that 1) all algorithms from the DS RRset must appear in the DNSKEY RRset and that 2) all algorithms in the DNSKEY RRset must be used to sign the DNSKEY RRset, you get that requirement that the DNSKEY RRset must be signed using all algorithms appearing in the DS RRset. That being said, there still seems to be something missing from dnssec-bis-updates-14, section 5.11 . The requirement that the DNSKEY RRset be signed with all algorithms in the DS RRset is insufficient. For example, consider the following: Parent zone contains: DS with alg 5 and key tag 123 DS with alg 7 and key tag 456 Corresponding child zone contains: DNSKEY with alg 5 and key tag 789 DNSKEY with alg 7 and key tag 456 RRSIG(DNSKEY) with alg 5 and key tag 789 RRSIG(DNSKEY) with alg 7 and key tag 456 This meets all the said requirements. It also meets the requirements in RFC 4035, section 2.2, for which dnssec-bis-updates 5.11 was written. And it doesn't violate RFC 4035, section 2.4, which appropriately uses "SHOULD" to describe how DS RRs should correspond to DNSKEYs. But, it's insufficient because a validator that understands algorithm 5 and not algorithm 7 will be unable to complete a chain of trust. Although the DNSKEY RRset has been signed with alg 5, it has not been signed with a key with alg 5 that corresponds to the DS RR. Here's a more basic example (stripping out the second algorithm) that clearly doesn't work: Parent zone contains: DS with alg 5 and key tag 123 Corresponding child zone contains: DNSKEY with alg 5 and key tag 789 RRSIG(DNSKEY) with alg 5 and key tag 789 If I'm not missing another reference somewhere that fills this void, I would suggest clarifying the wording, so that it's not simply algorithms that are required, but also includes DS awareness. Casey --0016e651fd5007cc6204ac620bf7 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Wed, Sep 7, 2011 at 11:37 AM, Casey Deccio <casey@deccio.net> wrote:
I can see that dnssec-bis-updates-14 omits that and only requires that the DNSKEY RRset be signed only using algs from the DNSKEY RR= set itself:

[including dnsext= ... feel free to move entirely, if appropriate]

Ahem.=A0 Upon more c= areful examination I see that when you combine the requirements that 1) all= algorithms from the DS RRset must appear in the DNSKEY RRset and that 2) a= ll algorithms in the DNSKEY RRset must be used to sign the DNSKEY RRset, yo= u get that requirement that the DNSKEY RRset must be signed using all algor= ithms appearing in the DS RRset.

That being said, there still seems to be something missing from dnssec-= bis-updates-14, section 5.11 .=A0 The requirement that the DNSKEY RRset be = signed with all algorithms in the DS RRset is insufficient.=A0 For example,= consider the following:

Parent zone contains:
DS with alg 5 and key tag 123
DS with alg 7= and key tag 456

Corresponding child zone contains:
DNSKEY with a= lg 5 and key tag 789
DNSKEY with alg 7 and key tag 456
RRSIG(DNSKEY) = with alg 5 and key tag 789
RRSIG(DNSKEY) with alg 7 and key tag 456

This meets all the said req= uirements.=A0 It also meets the requirements in RFC 4035, section 2.2, for = which dnssec-bis-updates 5.11 was written.=A0 And it doesn't violate RF= C 4035, section 2.4, which appropriately uses "SHOULD" to describ= e how DS RRs should correspond to DNSKEYs.=A0 But, it's insufficient be= cause a validator that understands algorithm 5 and not algorithm 7 will be = unable to complete a chain of trust.=A0 Although the DNSKEY RRset has been = signed with alg 5, it has not been signed with a key with alg 5 that corres= ponds to the DS RR.=A0 Here's a more basic example (stripping out the s= econd algorithm) that clearly doesn't work:

Parent zone contains:
DS with alg 5 and key tag 123

Corresponding child zone contains:
DNSKEY with alg 5 and key tag 789
RRSIG(DNSKEY) with alg 5 and key tag 789

If I'm not missing anot= her reference somewhere that fills this void, I would suggest clarifying th= e wording, so that it's not simply algorithms that are required, but al= so includes DS awareness.

Casey
--0016e651fd5007cc6204ac620bf7-- From matthijs@nlnetlabs.nl Thu Sep 8 00:47:41 2011 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AE9A521F8B3B for ; Thu, 8 Sep 2011 00:47:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.444 X-Spam-Level: X-Spam-Status: No, score=-102.444 tagged_above=-999 required=5 tests=[AWL=0.155, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BoeuX9OUOLW9 for ; Thu, 8 Sep 2011 00:47:40 -0700 (PDT) Received: from open.nlnetlabs.nl (open.nlnetlabs.nl [IPv6:2001:7b8:206:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A2EE21F8B20 for ; Thu, 8 Sep 2011 00:47:40 -0700 (PDT) Received: from [192.168.178.21] (a83-160-139-153.adsl.xs4all.nl [83.160.139.153]) (authenticated bits=0) by open.nlnetlabs.nl (8.14.4/8.14.4) with ESMTP id p887nRCI024533 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Thu, 8 Sep 2011 09:49:28 +0200 (CEST) (envelope-from matthijs@nlnetlabs.nl) Message-ID: <4E687387.9000800@nlnetlabs.nl> Date: Thu, 08 Sep 2011 09:49:27 +0200 From: Matthijs Mekking User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.21) Gecko/20110831 Thunderbird/3.1.13 MIME-Version: 1.0 To: dnssec-deployment@dnssec-deployment.org References: <20110907163036.GE11094@nysernet.org> <15F70F1D-F71F-490F-B937-6069557FF9C0@surfnet.nl> <20110907164607.GG11094@nysernet.org> <4E67A701.2060701@rancid.berkeley.edu> <955DB35F-30E0-49FB-9AF3-9CE7E5EBC771@icann.org> <20110907193734.GT35347@crankycanuck.ca> In-Reply-To: <20110907193734.GT35347@crankycanuck.ca> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (open.nlnetlabs.nl [213.154.224.1]); Thu, 08 Sep 2011 09:49:28 +0200 (CEST) Cc: dnsext@ietf.org Subject: Re: [dnsext] [Dnssec-deployment] Some more sinners... virginia.gov & onguardonline.gov X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Sep 2011 07:47:41 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, On 09/07/2011 09:37 PM, Andrew Sullivan wrote: > On Wed, Sep 07, 2011 at 11:49:01AM -0700, Joe Abley wrote: >> >> I don't think that's incorrect. It's valid for DS RRs to exist in >> the parent referring to keys that are not yet published in the >> child zone, for example, as a means to facilitate an emergency KSK >> roll. So long as one DS RR provides a chain of trust to an RRSIG, >> you're good. >> > > The problem here is not that they're different keys, but that > they're different algorithms. Unbound is, IMO, being far too strict > about this, rejecting as bogus something that is not strictly > speaking broken, just a bad idea. The maintainers' argument used to > be that something so bad about some algorithm could come to light > that this rigid rule would protect validators against algorithm > downgrade attacks. This seemed to me to be like setting up a shotgun > rigged to a string on your front door knob in case someone bad > manages to pick your deadbolt: the day you forget about the string > will be pretty bad for you. I thought Unbound had relaxed this rule > to make it optional behaviour, but I could be wrong. > > A > Unbound indeed has relaxed its rules in 1.4.8: algorithm compromise protection using the algorithms signalled in the DS record. Also, trust anchors, DLV, and RFC5011 receive this, and thus, if you have multiple algorithms in your trust- anchor-file then it will now behave different than before. Also, 5011 rollover for algorithms needs to be double-signature until the old algorithm is revoked. Before that, it also required a signature for each RRset using at least one key of each algorithm that is present in the DNSKEY RRset. It followed the rules in section 2.2., RFC 4035. It was unclear that this rule is for zone signing only, not for validating. Therefor, Unbound has removed this check. It still checks the algorithms signaled in the DS record. It only makes sense to me, because why would you otherwise add the DS record of a different algorithm in the parent zone? Even in the case of algorithm rollover you need to first add the new DNSKEYs and sign and wait TTL. This whole mandatory algorithms stuff is a moving target. Several attempts were made to get this clear. From the current specification it is unclear what validators may and cannot do. We should try to get consensus about the clarifications, written down in dnssec-bis-updates. Sorry for cross-posting. Best regards, Matthijs -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJOaHOHAAoJEA8yVCPsQCW50IoH/R73vyJ6qmaNsOovsMi1vlXo z9rwnRKQHtfH9oysN6tX468noz0okrHnKWsuqxyKLKMQzBUvstLOcY8iCast3aKC eReZjfhaAG8J7rJLYAixA7PbUblXDEFZe1Y/Z/qd2aVapqg+uwFgQF1tGRBqTjcp bkWkdPnauVy4+qlhAiy8zZD9+UcaoVLs8NdPEGiKHzrw5uS5m8or9v3TKf0455io 3wNt3YSsSxO4l/41x+m3r0kNEJQkzUXahsYR2TCgMQYlXEP3csR/Z10bcdrcNmQ6 IFR6Yh9cfmdokAqN0DojppbeBkC+we/J7r69tWgTIx0gwFr3pDX73uM98NBTB94= =mIC1 -----END PGP SIGNATURE----- From ajs@anvilwalrusden.com Thu Sep 8 06:46:51 2011 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D3DB21F8B8A for ; Thu, 8 Sep 2011 06:46:51 -0700 (PDT) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7uH2EQGRUn6D for ; Thu, 8 Sep 2011 06:46:50 -0700 (PDT) Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by ietfa.amsl.com (Postfix) with ESMTP id 96FF321F8B88 for ; Thu, 8 Sep 2011 06:46:50 -0700 (PDT) Received: from shinkuro.com (69-196-144-227.dsl.teksavvy.com [69.196.144.227]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yitter.info (Postfix) with ESMTPSA id F2E231ECB41D for ; Thu, 8 Sep 2011 13:48:40 +0000 (UTC) Date: Thu, 8 Sep 2011 09:48:42 -0400 From: Andrew Sullivan To: dnsext@ietf.org Message-ID: <20110908134842.GC38973@shinkuro.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) Subject: [dnsext] Note WGLC going on in MIF X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Sep 2011 13:46:51 -0000 Hi all, I just thought it'd be useful to draw to everyone's attention the last call going on over in MIF: http://tools.ietf.org/id/draft-ietf-mif-dns-server-selection-03.txt It would not be a bad idea if people had a look at that. A -- Andrew Sullivan ajs@anvilwalrusden.com From apb@cequrux.com Fri Sep 9 01:10:16 2011 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6ECDA21F8BBF for ; Fri, 9 Sep 2011 01:10:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3lUZ5oYd96mD for ; Fri, 9 Sep 2011 01:09:46 -0700 (PDT) Received: from citadel.cequrux.com (citadel.cequrux.com [192.96.22.18]) by ietfa.amsl.com (Postfix) with ESMTP id A6F6721F8B1E for ; Fri, 9 Sep 2011 01:09:33 -0700 (PDT) Received: (from nobody@localhost) by citadel.cequrux.com (8.12.11/8.12.11) id p898BPJV002133 for ; Fri, 9 Sep 2011 10:11:25 +0200 (SAST) (envelope-from apb@cequrux.com) Received: by citadel.cequrux.com via recvmail id 2131; Fri, 09 Sep 2011 10:11:24 +0200 (SAST) Date: Fri, 9 Sep 2011 10:11:19 +0200 From: Alan Barrett To: dnsext@ietf.org Message-ID: <20110909081119.GC1722@apb-laptoy.apb.alt.za> References: <20110819050440.21024.qmail@joyce.lan> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Disposition: inline In-Reply-To: Subject: Re: [dnsext] Draft of an RRTYPE extension language X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Sep 2011 08:10:17 -0000 On Fri, 19 Aug 2011, Tony Finch wrote: >> http://www.ietf.org/id/draft-levine-dnsextlang-00.txt > >For auto-provisioning user interfaces I think you need a description for >each field, e.g. [...] I'd suggest both a field name (compulsory) and a description (optional). For example: SOA:6 Start of a zone of authority MNAME:N[C] Name of the original or primary name server RNAME:N[M,C] Email address of person responsible for this zone SERIAL:I4 Version number of the original copy of the zone REFRESH:I4 Number of seconds before the zone should be refreshed RETRY:I4 Number of seconds before a failed refresh should be retried EXPIRE:I4 Number of seconds before the zone is no longer authoritative MINIMUM:I4 Minimum TTL (in seconds) for any RR from this zone --apb (Alan Barrett) From johnl@iecc.com Fri Sep 9 09:42:52 2011 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AD05221F86E0 for ; Fri, 9 Sep 2011 09:42:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -111.149 X-Spam-Level: X-Spam-Status: No, score=-111.149 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, HABEAS_ACCREDITED_SOI=-4.3, RCVD_IN_BSP_TRUSTED=-4.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mWJgqnmkw8bF for ; Fri, 9 Sep 2011 09:42:52 -0700 (PDT) Received: from leila.iecc.com (leila6.iecc.com [IPv6:2001:470:1f07:1126:0:4c:6569:6c61]) by ietfa.amsl.com (Postfix) with ESMTP id EBA3321F86DE for ; Fri, 9 Sep 2011 09:42:51 -0700 (PDT) Received: (qmail 27468 invoked from network); 9 Sep 2011 16:44:43 -0000 Received: from gal.iecc.com (64.57.183.53) by mail2.iecc.com with SMTP; 9 Sep 2011 16:44:43 -0000 Received: (qmail 11929 invoked from network); 9 Sep 2011 16:44:43 -0000 Received: from leila.iecc.com (64.57.183.34) by mail1.iecc.com with QMQP; 9 Sep 2011 16:44:43 -0000 Date: 9 Sep 2011 16:44:21 -0000 Message-ID: <20110909164421.5418.qmail@joyce.lan> From: "John Levine" To: dnsext@ietf.org In-Reply-To: <20110909081119.GC1722@apb-laptoy.apb.alt.za> Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 7bit Subject: Re: [dnsext] Draft of an RRTYPE extension language X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Sep 2011 16:42:52 -0000 >>> http://www.ietf.org/id/draft-levine-dnsextlang-00.txt >> >>For auto-provisioning user interfaces I think you need a description for >>each field, e.g. [...] > >I'd suggest both a field name (compulsory) and a description (optional). >For example: Not a bad thought, although the current master file definitions often don't give specific names to fields. > SOA:6 Start of a zone of authority > MNAME:N[C] Name of the original or primary name server > RNAME:N[M,C] Email address of person responsible for this zone > SERIAL:I4 Version number of the original copy of the zone > REFRESH:I4 Number of seconds before the zone should be refreshed > RETRY:I4 Number of seconds before a failed refresh should be retried > EXPIRE:I4 Number of seconds before the zone is no longer authoritative > MINIMUM:I4 Minimum TTL (in seconds) for any RR from this zone This also offers a variety of new ways that might screw up, like what happens if two fields have the same name, or what if I'm from China and want to use UTF-8 field names. R's, John From jiangsheng@huawei.com Mon Sep 19 23:15:42 2011 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7890411E8073 for ; Mon, 19 Sep 2011 23:15:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.316 X-Spam-Level: X-Spam-Status: No, score=-6.316 tagged_above=-999 required=5 tests=[AWL=0.283, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ktftYx4nV7wD for ; Mon, 19 Sep 2011 23:15:41 -0700 (PDT) Received: from szxga01-in.huawei.com (szxga01-in.huawei.com [119.145.14.64]) by ietfa.amsl.com (Postfix) with ESMTP id 3065911E8080 for ; Mon, 19 Sep 2011 23:15:41 -0700 (PDT) Received: from huawei.com (szxga05-in [172.24.2.49]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LRT006K15EAZ8@szxga05-in.huawei.com> for dnsext@ietf.org; Tue, 20 Sep 2011 14:15:46 +0800 (CST) Received: from szxrg01-dlp.huawei.com ([172.24.2.119]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LRT00GMG5EAN3@szxga05-in.huawei.com> for dnsext@ietf.org; Tue, 20 Sep 2011 14:15:46 +0800 (CST) Received: from szxeml201-edg.china.huawei.com ([172.24.2.119]) by szxrg01-dlp.huawei.com (MOS 4.1.9-GA) with ESMTP id AEB22758; Tue, 20 Sep 2011 14:15:45 +0800 Received: from SZXEML412-HUB.china.huawei.com (10.82.67.91) by szxeml201-edg.china.huawei.com (172.24.2.39) with Microsoft SMTP Server (TLS) id 14.1.270.1; Tue, 20 Sep 2011 14:15:41 +0800 Received: from SZXEML506-MBS.china.huawei.com ([169.254.3.124]) by szxeml412-hub.china.huawei.com ([10.82.67.91]) with mapi id 14.01.0270.001; Tue, 20 Sep 2011 14:15:43 +0800 Date: Tue, 20 Sep 2011 06:15:42 +0000 From: Sheng Jiang X-Originating-IP: [10.110.98.67] To: "dnsext@ietf.org" Message-id: <5D36713D8A4E7348A7E10DF7437A4B9201261445@SZXEML506-MBS.china.huawei.com> MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-language: zh-CN Content-transfer-encoding: 7BIT Accept-Language: en-GB, zh-CN, en-US Thread-topic: New Version Notification for draft-jiang-dnsext-a6-to-historic-00.txt Thread-index: AQHMd1NSUU2ycfNEFEOhVGBl42BL3ZVVyAuw X-MS-Has-Attach: X-MS-TNEF-Correlator: X-CFilter-Loop: Reflected Subject: [dnsext] FW: New Version Notification for draft-jiang-dnsext-a6-to-historic-00.txt X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Sep 2011 06:15:42 -0000 Following the discussion on mail list, here is the text that proposes to move A6 to Historic status. This document provides a summary of issues and discusses the current usage status of A6 DNS records and moves the A6 specifications to Historic status, providing clarity to implementers and operators. Comments are welcome. Sheng, David and Brian > -----Original Message----- > From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] > Sent: Tuesday, September 20, 2011 1:06 PM > To: Sheng Jiang > Cc: drc@cloudflare.com; brian.e.carpenter@gmail.com; Sheng Jiang > Subject: New Version Notification for draft-jiang-dnsext-a6-to- > historic-00.txt > > A new version of I-D, draft-jiang-dnsext-a6-to-historic-00.txt has been > successfully submitted by Sheng Jiang and posted to the IETF repository. > > Filename: draft-jiang-dnsext-a6-to-historic > Revision: 00 > Title: Moving A6 to Historic Status > Creation date: 2011-09-20 > WG ID: Individual Submission > Number of pages: 8 > > Abstract: > This document provides a summary of issues and discusses the current > usage status of A6 DNS records and moves the A6 specifications to > Historic status, providing clarity to implementers and operators. > > > > > The IETF Secretariat From jabley@hopcount.ca Tue Sep 20 05:42:11 2011 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9707E21F87D9 for ; Tue, 20 Sep 2011 05:42:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sBl9y50I-rcA for ; Tue, 20 Sep 2011 05:42:11 -0700 (PDT) Received: from monster.hopcount.ca (monster.hopcount.ca [IPv6:2001:4900:1:392:213:20ff:fe1b:3bfe]) by ietfa.amsl.com (Postfix) with ESMTP id 3314C21F86A5 for ; Tue, 20 Sep 2011 05:42:11 -0700 (PDT) Received: from [2001:4900:1042:100:adc1:3942:4f7b:1c28] by monster.hopcount.ca with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.76 (FreeBSD)) (envelope-from ) id 1R5zgc-0004jR-00; Tue, 20 Sep 2011 12:44:31 +0000 Mime-Version: 1.0 (Apple Message framework v1244.3) Content-Type: text/plain; charset=us-ascii From: Joe Abley In-Reply-To: <5D36713D8A4E7348A7E10DF7437A4B9201261445@SZXEML506-MBS.china.huawei.com> Date: Tue, 20 Sep 2011 08:44:18 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <5D36713D8A4E7348A7E10DF7437A4B9201261445@SZXEML506-MBS.china.huawei.com> To: Sheng Jiang X-Mailer: Apple Mail (2.1244.3) X-SA-Exim-Connect-IP: 2001:4900:1042:100:adc1:3942:4f7b:1c28 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] New Version Notification for draft-jiang-dnsext-a6-to-historic-00.txt X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Sep 2011 12:42:11 -0000 On 2011-09-20, at 02:15, Sheng Jiang wrote: > Following the discussion on mail list, here is the text that proposes = to move A6 to Historic status. >=20 > This document provides a summary of issues and discusses the current = usage status of A6 DNS records and moves the A6 specifications to = Historic status, providing clarity to implementers and operators. >=20 > Comments are welcome. I find this document extremely pleasing, and am enthusiastic about its = publication. Joe From marka@isc.org Tue Sep 20 08:35:58 2011 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A2DCB11E808A for ; Tue, 20 Sep 2011 08:35:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r7jN07wH91Uh for ; Tue, 20 Sep 2011 08:35:58 -0700 (PDT) Received: from mx.ams1.isc.org (mx.ams1.isc.org [IPv6:2001:500:60::65]) by ietfa.amsl.com (Postfix) with ESMTP id 0D08911E8087 for ; Tue, 20 Sep 2011 08:35:57 -0700 (PDT) Received: from bikeshed.isc.org (bikeshed.isc.org [IPv6:2001:4f8:3:d::19]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "bikeshed.isc.org", Issuer "ISC CA" (verified OK)) by mx.ams1.isc.org (Postfix) with ESMTPS id 74A5D5F988D; Tue, 20 Sep 2011 15:38:06 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (unknown [IPv6:2620:101:8003:300:6233:4bff:fe01:7585]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by bikeshed.isc.org (Postfix) with ESMTPSA id B228C216C80; Tue, 20 Sep 2011 15:38:04 +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 02B131421DB9; Wed, 21 Sep 2011 01:38:04 +1000 (EST) To: Sheng Jiang From: Mark Andrews References: <5D36713D8A4E7348A7E10DF7437A4B9201261445@SZXEML506-MBS.china.huawei.com> In-reply-to: Your message of "Tue, 20 Sep 2011 06:15:42 GMT." <5D36713D8A4E7348A7E10DF7437A4B9201261445@SZXEML506-MBS.china.huawei.com> Date: Wed, 21 Sep 2011 01:38:03 +1000 Message-Id: <20110920153804.02B131421DB9@drugs.dv.isc.org> Cc: "dnsext@ietf.org" Subject: Re: [dnsext] FW: New Version Notification for draft-jiang-dnsext-a6-to-historic-00.txt X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Sep 2011 15:35:58 -0000 There is no discussion about A6 and DNSSEC. Type 38 is permanently tainted w.r.t. DNSSEC. Mark In message <5D36713D8A4E7348A7E10DF7437A4B9201261445@SZXEML506-MBS.china.huawei.com>, Sheng Jiang writes: > Following the discussion on mail list, here is the text that proposes to move A6 to Historic st > atus. > > This document provides a summary of issues and discusses the current usage status of A6 DNS rec > ords and moves the A6 specifications to Historic status, providing clarity to implementers and > operators. > > Comments are welcome. > > Sheng, David and Brian > > > -----Original Message----- > > From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] > > Sent: Tuesday, September 20, 2011 1:06 PM > > To: Sheng Jiang > > Cc: drc@cloudflare.com; brian.e.carpenter@gmail.com; Sheng Jiang > > Subject: New Version Notification for draft-jiang-dnsext-a6-to- > > historic-00.txt > > > > A new version of I-D, draft-jiang-dnsext-a6-to-historic-00.txt has been > > successfully submitted by Sheng Jiang and posted to the IETF repository. > > > > Filename: draft-jiang-dnsext-a6-to-historic > > Revision: 00 > > Title: Moving A6 to Historic Status > > Creation date: 2011-09-20 > > WG ID: Individual Submission > > Number of pages: 8 > > > > Abstract: > > This document provides a summary of issues and discusses the current > > usage status of A6 DNS records and moves the A6 specifications to > > Historic status, providing clarity to implementers and operators. > > > > > > > > > > The IETF Secretariat > _______________________________________________ > 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 drc@virtualized.org Tue Sep 20 08:47:46 2011 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EE3CF21F8CB8 for ; Tue, 20 Sep 2011 08:47:46 -0700 (PDT) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id slfJXJ7FjkJ5 for ; Tue, 20 Sep 2011 08:47:46 -0700 (PDT) Received: from trantor.virtualized.org (trantor.virtualized.org [199.48.134.42]) by ietfa.amsl.com (Postfix) with ESMTP id 2318F21F8CAB for ; Tue, 20 Sep 2011 08:47:46 -0700 (PDT) Received: from [192.168.1.101] (unknown [173.245.57.22]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: drc) by trantor.virtualized.org (Postfix) with ESMTPSA id 53B991704E; Tue, 20 Sep 2011 15:50:11 +0000 (UTC) Mime-Version: 1.0 (Apple Message framework v1244.3) Content-Type: text/plain; charset=us-ascii From: David Conrad In-Reply-To: <20110920153804.02B131421DB9@drugs.dv.isc.org> Date: Tue, 20 Sep 2011 08:50:11 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <95D8C0B8-B329-4115-9412-73E882B618B3@virtualized.org> References: <5D36713D8A4E7348A7E10DF7437A4B9201261445@SZXEML506-MBS.china.huawei.com> <20110920153804.02B131421DB9@drugs.dv.isc.org> To: Mark Andrews X-Mailer: Apple Mail (2.1244.3) Cc: "dnsext@ietf.org" Subject: Re: [dnsext] New Version Notification for draft-jiang-dnsext-a6-to-historic-00.txt X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Sep 2011 15:47:47 -0000 Mark, On Sep 20, 2011, at 8:38 AM, Mark Andrews wrote: > There is no discussion about A6 and DNSSEC. Type 38 is permanently = tainted w.r.t. DNSSEC. Sorry, could you expand on this a bit? I'm not sure I understand. Regards, -drc From marka@isc.org Tue Sep 20 09:19:05 2011 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8AB0F21F8B8A for ; Tue, 20 Sep 2011 09:19:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.487 X-Spam-Level: X-Spam-Status: No, score=-2.487 tagged_above=-999 required=5 tests=[AWL=0.113, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s6EkFtxaZy+R for ; Tue, 20 Sep 2011 09:19:05 -0700 (PDT) Received: from mx.ams1.isc.org (mx.ams1.isc.org [IPv6:2001:500:60::65]) by ietfa.amsl.com (Postfix) with ESMTP id 0D16D21F8B81 for ; Tue, 20 Sep 2011 09:19:05 -0700 (PDT) Received: from bikeshed.isc.org (bikeshed.isc.org [IPv6:2001:4f8:3:d::19]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "bikeshed.isc.org", Issuer "ISC CA" (verified OK)) by mx.ams1.isc.org (Postfix) with ESMTPS id 90B535F98BF; Tue, 20 Sep 2011 16:21:09 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (unknown [IPv6:2620:101:8003:300:6233:4bff:fe01:7585]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by bikeshed.isc.org (Postfix) with ESMTPSA id F10DF216C85; Tue, 20 Sep 2011 16:21:07 +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 79B3614224A5; Wed, 21 Sep 2011 02:11:00 +1000 (EST) To: David Conrad From: Mark Andrews References: <5D36713D8A4E7348A7E10DF7437A4B9201261445@SZXEML506-MBS.china.huawei.com> <20110920153804.02B131421DB9@drugs.dv.isc.org> <95D8C0B8-B329-4115-9412-73E882B618B3@virtualized.org> In-reply-to: Your message of "Tue, 20 Sep 2011 08:50:11 MST." <95D8C0B8-B329-4115-9412-73E882B618B3@virtualized.org> Date: Wed, 21 Sep 2011 02:11:00 +1000 Message-Id: <20110920161100.79B3614224A5@drugs.dv.isc.org> Cc: "dnsext@ietf.org" Subject: Re: [dnsext] New Version Notification for draft-jiang-dnsext-a6-to-historic-00.txt X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Sep 2011 16:19:05 -0000 In message <95D8C0B8-B329-4115-9412-73E882B618B3@virtualized.org>, David Conrad writes: > Mark, > > On Sep 20, 2011, at 8:38 AM, Mark Andrews wrote: > > There is no discussion about A6 and DNSSEC. Type 38 is permanently = > tainted w.r.t. DNSSEC. > > Sorry, could you expand on this a bit? I'm not sure I understand. A6 has a compressed domainname. To reuse 38 you need to upgrade every validator in the world. > Regards, > -drc > -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From fanf2@hermes.cam.ac.uk Wed Sep 21 03:21:41 2011 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 368FA21F8C40 for ; Wed, 21 Sep 2011 03:21:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.584 X-Spam-Level: X-Spam-Status: No, score=-6.584 tagged_above=-999 required=5 tests=[AWL=0.015, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r6b0W8PFrUmo for ; Wed, 21 Sep 2011 03:21:40 -0700 (PDT) Received: from ppsw-41.csi.cam.ac.uk (ppsw-41.csi.cam.ac.uk [131.111.8.141]) by ietfa.amsl.com (Postfix) with ESMTP id D61C021F8C31 for ; Wed, 21 Sep 2011 03:21:39 -0700 (PDT) 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-2.csi.cam.ac.uk ([131.111.8.54]:46989) by ppsw-41.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.156]:25) with esmtpa (EXTERNAL:fanf2) id 1R6JyF-00071p-SB (Exim 4.72) (return-path ); Wed, 21 Sep 2011 11:24:03 +0100 Received: from fanf2 (helo=localhost) by hermes-2.csi.cam.ac.uk (hermes.cam.ac.uk) with local-esmtp id 1R6JyF-0001BE-NK (Exim 4.67) (return-path ); Wed, 21 Sep 2011 11:24:03 +0100 Date: Wed, 21 Sep 2011 11:24:03 +0100 From: Tony Finch X-X-Sender: fanf2@hermes-2.csi.cam.ac.uk To: Mark Andrews In-Reply-To: <20110920161100.79B3614224A5@drugs.dv.isc.org> Message-ID: References: <5D36713D8A4E7348A7E10DF7437A4B9201261445@SZXEML506-MBS.china.huawei.com> <20110920153804.02B131421DB9@drugs.dv.isc.org> <95D8C0B8-B329-4115-9412-73E882B618B3@virtualized.org> <20110920161100.79B3614224A5@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] New Version Notification for draft-jiang-dnsext-a6-to-historic-00.txt X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Sep 2011 10:21:41 -0000 Mark Andrews wrote: > > A6 has a compressed domainname. To reuse 38 you need to upgrade > every validator in the world. The plan is not to remove the assignment of type 38 to A6, but to mark it obsolete like types 3 (MD) and 4 (MF) etc. Tony. -- f.anthony.n.finch http://dotat.at/ Thames, Dover: Southwest veering west 5 to 7. Moderate, occasionally rough. Rain then showers. Good, occasionally poor. From marka@isc.org Wed Sep 21 10:59:22 2011 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E0BF91F0CBB for ; Wed, 21 Sep 2011 10:59:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1sTV6rgnmv0k for ; Wed, 21 Sep 2011 10:59:22 -0700 (PDT) Received: from mx.pao1.isc.org (mx.pao1.isc.org [IPv6:2001:4f8:0:2::2b]) by ietfa.amsl.com (Postfix) with ESMTP id 636631F0C54 for ; Wed, 21 Sep 2011 10:59:22 -0700 (PDT) Received: from bikeshed.isc.org (bikeshed.isc.org [IPv6:2001:4f8:3:d::19]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "bikeshed.isc.org", Issuer "ISC CA" (verified OK)) by mx.pao1.isc.org (Postfix) with ESMTPS id 7745CC9425; Wed, 21 Sep 2011 18:01:35 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (unknown [IPv6:2001:4f8:3:65:6233:4bff:fe01:7585]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by bikeshed.isc.org (Postfix) with ESMTPSA id 51DCB216C22; Wed, 21 Sep 2011 18:01: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 D3100142AD37; Thu, 22 Sep 2011 04:01:34 +1000 (EST) To: bmanning@vacation.karoshi.com From: Mark Andrews References: <5D36713D8A4E7348A7E10DF7437A4B9201261445@SZXEML506-MBS.china.huawei.com> <20110920153804.02B131421DB9@drugs.dv.isc.org> <95D8C0B8-B329-4115-9412-73E882B618B3@virtualized.org> <20110920161100.79B3614224A5@drugs.dv.isc.org> <20110921134848.GB8102@vacation.karoshi.com.> In-reply-to: Your message of "Wed, 21 Sep 2011 13:48:48 GMT." <20110921134848.GB8102@vacation.karoshi.com.> Date: Thu, 22 Sep 2011 04:01:34 +1000 Message-Id: <20110921180134.D3100142AD37@drugs.dv.isc.org> Cc: "dnsext@ietf.org" Subject: Re: [dnsext] New Version Notification for draft-jiang-dnsext-a6-to-historic-00.txt X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Sep 2011 17:59:23 -0000 In message <20110921134848.GB8102@vacation.karoshi.com.>, bmanning@vacation.karoshi.com writes: > On Wed, Sep 21, 2011 at 02:11:00AM +1000, Mark Andrews wrote: > > > > In message <95D8C0B8-B329-4115-9412-73E882B618B3@virtualized.org>, David Conrad > > writes: > > > Mark, > > > > > > On Sep 20, 2011, at 8:38 AM, Mark Andrews wrote: > > > > There is no discussion about A6 and DNSSEC. Type 38 is permanently = > > > tainted w.r.t. DNSSEC. > > > > > > Sorry, could you expand on this a bit? I'm not sure I understand. > > > > A6 has a compressed domainname. To reuse 38 you need to upgrade > > every validator in the world. > > > > > Regards, > > > -drc > > > > > -- > > Mark Andrews, ISC > > 1 Seymour St., Dundas Valley, NSW 2117, Australia > > PHONE: +61 2 9871 4742 INTERNET: marka@isc.org > > Does this document call out for the reuse of Type 38? > > I find that idea to be unacceptable at this point in time. There is > no call whatsoever to start recycling code points for RR Types. > > //bill If there is a A6 record in a signed zone and it is returned (* or TYPE38 query or as additional) validation of the result will fail as the validator will no longer understand TYPE38 as this document is calling for the removal of support of TYPE38 from new products. At the very least if we are going to make thing break we should identify all the know failure modes. In reality there is very little cost to supporting A6 in validators and nameservers as a record type and doing is all that is required to prevent breakages if will are willing to put up with breaking delegations to zones that are only server by servers with A6 records. Saying that A6 records SHOULD NOT be used to identify IPv6 hosts and A6 records SHOULD NOT cause additional section processing and that getaddrinfo(), or similar, SHOULD NOT lookup A6 records really should be enough for this document. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From Ed.Lewis@neustar.biz Wed Sep 21 11:38:35 2011 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A884A1F0C45 for ; Wed, 21 Sep 2011 11:38:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.466 X-Spam-Level: X-Spam-Status: No, score=-105.466 tagged_above=-999 required=5 tests=[AWL=-0.726, BAYES_20=-0.74, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VbRF4bGjvWPg for ; Wed, 21 Sep 2011 11:38:35 -0700 (PDT) Received: from stora.ogud.com (stora.ogud.com [66.92.146.20]) by ietfa.amsl.com (Postfix) with ESMTP id CF58A1F0C38 for ; Wed, 21 Sep 2011 11:38:34 -0700 (PDT) Received: from [10.31.204.233] (nyttbox.md.ogud.com [10.20.30.4]) by stora.ogud.com (8.14.4/8.14.4) with ESMTP id p8LIf2E6071791; Wed, 21 Sep 2011 14:41:03 -0400 (EDT) (envelope-from Ed.Lewis@neustar.biz) Mime-Version: 1.0 Message-Id: In-Reply-To: <20110921180134.D3100142AD37@drugs.dv.isc.org> References: <5D36713D8A4E7348A7E10DF7437A4B9201261445@SZXEML506-MBS.china.huawei.com> <20110920153804.02B131421DB9@drugs.dv.isc.org> <95D8C0B8-B329-4115-9412-73E882B618B3@virtualized.org> <20110920161100.79B3614224A5@drugs.dv.isc.org> <20110921134848.GB8102@vacation.karoshi.com.> <20110921180134.D3100142AD37@drugs.dv.isc.org> Date: Wed, 21 Sep 2011 14:40:06 -0400 To: "dnsext@ietf.org" From: Edward Lewis Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.71 on 10.20.30.4 Cc: ed.lewis@neustar.biz Subject: Re: [dnsext] New Version Notification for draft-jiang-dnsext-a6-to-historic-00.txt X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Sep 2011 18:38:35 -0000 At 4:01 +1000 9/22/11, Mark Andrews wrote: >In reality there is very little cost to supporting A6 in validators >and nameservers as a record type and doing is all that is required >to prevent breakages if will are willing to put up with breaking >delegations to zones that are only server by servers with A6 records. Except that the A6 record itself is potentially a DOS tool, one of the reasons why it was moved off the standards track. "Breaking" the A6 record is a good thing. A6 has already been busted from standards track to experimental for a couple of reasons. It's not like retiring an integral, well-used and studied element of the protocol. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis NeuStar You can leave a voice message at +1-571-434-5468 Vote for the word of the day: "Papa"razzi - father that constantly takes photos of the baby Corpureaucracy - The institution of corporate "red tape" From marka@isc.org Wed Sep 21 11:40:27 2011 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9661F1F0C4E for ; Wed, 21 Sep 2011 11:40:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bPKSPtljto-c for ; Wed, 21 Sep 2011 11:40:27 -0700 (PDT) Received: from mx.ams1.isc.org (mx.ams1.isc.org [IPv6:2001:500:60::65]) by ietfa.amsl.com (Postfix) with ESMTP id D4DBB1F0C38 for ; Wed, 21 Sep 2011 11:40:26 -0700 (PDT) Received: from bikeshed.isc.org (bikeshed.isc.org [IPv6:2001:4f8:3:d::19]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "bikeshed.isc.org", Issuer "ISC CA" (verified OK)) by mx.ams1.isc.org (Postfix) with ESMTPS id 6CF875F98EC; Wed, 21 Sep 2011 18:42:42 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (unknown [IPv6:2001:4f8:3:65:6233:4bff:fe01:7585]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by bikeshed.isc.org (Postfix) with ESMTPSA id B8846216C22; Wed, 21 Sep 2011 18:42:40 +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 B2B84142BD4F; Thu, 22 Sep 2011 04:42:40 +1000 (EST) To: Edward Lewis From: Mark Andrews References: <5D36713D8A4E7348A7E10DF7437A4B9201261445@SZXEML506-MBS.china.huawei.com> <20110920153804.02B131421DB9@drugs.dv.isc.org> <95D8C0B8-B329-4115-9412-73E882B618B3@virtualized.org> <20110920161100.79B3614224A5@drugs.dv.isc.org> <20110921134848.GB8102@vacation.karoshi.com.> <20110921180134.D3100142AD37@drugs.dv.isc.org> In-reply-to: Your message of "Wed, 21 Sep 2011 14:40:06 -0400." Date: Thu, 22 Sep 2011 04:42:40 +1000 Message-Id: <20110921184240.B2B84142BD4F@drugs.dv.isc.org> Cc: "dnsext@ietf.org" Subject: Re: [dnsext] New Version Notification for draft-jiang-dnsext-a6-to-historic-00.txt X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Sep 2011 18:40:27 -0000 In message , Edward Lewis writes: > At 4:01 +1000 9/22/11, Mark Andrews wrote: > > >In reality there is very little cost to supporting A6 in validators > >and nameservers as a record type and doing is all that is required > >to prevent breakages if will are willing to put up with breaking > >delegations to zones that are only server by servers with A6 records. > > Except that the A6 record itself is potentially a DOS tool, one of > the reasons why it was moved off the standards track. "Breaking" the > A6 record is a good thing. Only if you do the additional processing. > A6 has already been busted from standards track to experimental for a > couple of reasons. It's not like retiring an integral, well-used and > studied element of the protocol. > > -- > -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- > Edward Lewis > NeuStar You can leave a voice message at +1-571-434-5468 > > Vote for the word of the day: > "Papa"razzi - father that constantly takes photos of the baby > Corpureaucracy - The institution of corporate "red tape" > _______________________________________________ > 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 mail@sabahattin-gucukoglu.com Thu Sep 22 11:36:03 2011 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 649A21F0C63 for ; Thu, 22 Sep 2011 11:36:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.323 X-Spam-Level: X-Spam-Status: No, score=-1.323 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, HOST_MISMATCH_COM=0.311, RDNS_DYNAMIC=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HSFxRwj+CQGb for ; Thu, 22 Sep 2011 11:36:03 -0700 (PDT) Received: from Mintaka.sabahattin-gucukoglu.com (sgucukoglu-2-pt.tunnel.tserv8.dal1.ipv6.he.net [IPv6:2001:470:1f0e:7ef::2]) by ietfa.amsl.com (Postfix) with ESMTP id E1ECC1F0C5D for ; Thu, 22 Sep 2011 11:36:02 -0700 (PDT) Received: from Mintaka.sabahattin-gucukoglu.com ([::ffff:127.0.0.1]:39719) by Mintaka.sabahattin-gucukoglu.com with [XMail 1.27 ESMTP Server] id for from ; Thu, 22 Sep 2011 19:38:34 +0100 Received: from [192.168.1.65] (host213-123-192-30.in-addr.btopenworld.com [213.123.192.30]) (using SMTP over TLS) by Mintaka.sabahattin-gucukoglu.com (tmda-ofmipd) with ESMTP; Thu, 22 Sep 2011 19:38:33 +0100 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Thu, 22 Sep 2011 19:38:31 +0100 Message-Id: <283F0BCD-019C-4316-BDD5-390972207383@sabahattin-gucukoglu.com> To: dnsext@ietf.org Mime-Version: 1.0 (Apple Message framework v1244.3) X-Mailer: Apple Mail (2.1244.3) X-Delivery-Agent: TMDA/1.1.12-kg3 (Haumea) From: Sabahattin Gucukoglu X-Primary-Address: mail@sabahattin-gucukoglu.com Subject: [dnsext] client Subnet Option X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Sabahattin Gucukoglu List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Sep 2011 18:36:03 -0000 It's not the first time I've come across this, but I just got OpenDNS's = hard sell on the matter in my Inbox today. I'm not one of their = customers any more, so I couldn't help find the promise a touch amusing = - I run my own server, so I'm already at the promised land. I just want to ask one question and then I'll go away to reading the = archives and letting you guys go on going on. Was the subject of a client selection of closest server option ever = brought up? It seems to me that, in parity with the DNS in general, the = only congenial solution is one which does not return partial results and = thus ruin DNS consistency for existing resource types. I would be less = objectionable about an option which, for instance, told me about the = geographic locations of each of the available servers so I, or my OS = client software, could choose. I also want to remind web content = providers that this is easy to do with HTTP redirects as DNS, and I = completely understand the merit of getting rid of the existing CDN = poison techniques currently in use. Cheers, Sabahattin From rwfranks@gmail.com Tue Sep 27 07:37:41 2011 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2201F21F8BB6 for ; Tue, 27 Sep 2011 07:37:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.977 X-Spam-Level: X-Spam-Status: No, score=-102.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HSqmghFPNF73 for ; Tue, 27 Sep 2011 07:37:40 -0700 (PDT) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 64A0121F8CAA for ; Tue, 27 Sep 2011 07:37:40 -0700 (PDT) Received: by vcbfo11 with SMTP id fo11so5310831vcb.31 for ; Tue, 27 Sep 2011 07:40:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type :content-transfer-encoding; bh=XJ/7801T90qIbTiVVBVoH4tq8eQ2d9lb80ycgAxbWT8=; b=tXlrMzebpR5SWQR5lxGrrauNkkCDiE57O3Q7M0vZ2LT2HkC4q5T0pqW7/Qg0Je9WOX ZxYgIXd/yeoNGpNSQA9qgraWxI7euWy/ri1+f6+lHiuSOwgEJjALCHfbPmGEBu3DIaf+ FZhKgd0k+YjBJgVNwTwMHVN0kUIXyLkKfeSmY= Received: by 10.52.24.112 with SMTP id t16mr4992073vdf.398.1317134424094; Tue, 27 Sep 2011 07:40:24 -0700 (PDT) MIME-Version: 1.0 Sender: rwfranks@gmail.com Received: by 10.52.158.197 with HTTP; Tue, 27 Sep 2011 07:40:04 -0700 (PDT) In-Reply-To: <5D36713D8A4E7348A7E10DF7437A4B9201261445@SZXEML506-MBS.china.huawei.com> References: <5D36713D8A4E7348A7E10DF7437A4B9201261445@SZXEML506-MBS.china.huawei.com> From: Dick Franks Date: Tue, 27 Sep 2011 15:40:04 +0100 X-Google-Sender-Auth: 3D3vKod_WNTkthZzepXlgdpUxuQ Message-ID: To: "dnsext@ietf.org" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Subject: Re: [dnsext] FW: New Version Notification for draft-jiang-dnsext-a6-to-historic-00.txt X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Sep 2011 14:37:41 -0000 The central premise of this I-D is that production deployment of A6 lies somewhere between negligible and non-existent. If this assertion holds, any arguments about negative consequences are really arguments applicable to RFC3597 unknown record types in general which would be better advanced elsewhere. Further A6-specific arguments need to be supported by evidence that the central premise is erroneous. Challenge: Can anyone cite an A6 record, in production use, in the wild, having a domain name in its RDATA? I will summarise any responses received in next 7 days and post to this list. --Dick On 20 September 2011 07:15, Sheng Jiang wrote: > Following the discussion on mail list, here is the text that proposes to = move A6 to Historic status. > > This document provides a summary of issues and discusses the current usag= e status of A6 DNS records and moves the A6 specifications to Historic stat= us, providing clarity to implementers and operators. > > Comments are welcome. > > Sheng, David and Brian > >> -----Original Message----- >> From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] >> Sent: Tuesday, September 20, 2011 1:06 PM >> To: Sheng Jiang >> Cc: drc@cloudflare.com; brian.e.carpenter@gmail.com; Sheng Jiang >> Subject: New Version Notification for draft-jiang-dnsext-a6-to- >> historic-00.txt >> >> A new version of I-D, draft-jiang-dnsext-a6-to-historic-00.txt has been >> successfully submitted by Sheng Jiang and posted to the IETF repository. >> >> Filename: =C2=A0 =C2=A0 =C2=A0draft-jiang-dnsext-a6-to-historic >> Revision: =C2=A0 =C2=A0 =C2=A000 >> Title: =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Moving A6= to Historic Status >> Creation date: =C2=A0 =C2=A0 =C2=A0 =C2=A0 2011-09-20 >> WG ID: =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Individua= l Submission >> Number of pages: 8 >> >> Abstract: >> =C2=A0 =C2=A0This document provides a summary of issues and discusses th= e current >> =C2=A0 =C2=A0usage status of A6 DNS records and moves the A6 specificati= ons to >> =C2=A0 =C2=A0Historic status, providing clarity to implementers and oper= ators. >> >> >> >> >> The IETF Secretariat > _______________________________________________ > dnsext mailing list > dnsext@ietf.org > https://www.ietf.org/mailman/listinfo/dnsext > From jim@rfc1035.com Tue Sep 27 11:27:56 2011 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CD9F621F8ECB for ; Tue, 27 Sep 2011 11:27:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.509 X-Spam-Level: X-Spam-Status: No, score=-2.509 tagged_above=-999 required=5 tests=[AWL=0.090, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g1l4hSmQ-iHc for ; Tue, 27 Sep 2011 11:27:56 -0700 (PDT) Received: from hutch.rfc1035.com (hutch.rfc1035.com [195.54.233.70]) by ietfa.amsl.com (Postfix) with ESMTP id 2EC0C21F8EB8 for ; Tue, 27 Sep 2011 11:27:56 -0700 (PDT) Received: from gromit.rfc1035.com (gromit.rfc1035.com [195.54.233.69]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: jim) by hutch.rfc1035.com (Postfix) with ESMTPSA id 4D4F815420A1; Tue, 27 Sep 2011 19:30:29 +0100 (BST) Message-Id: <2634E06D-576A-429F-A079-48DE5645A4A0@rfc1035.com> From: Jim Reid To: Dick Franks 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: Tue, 27 Sep 2011 19:30:28 +0100 References: <5D36713D8A4E7348A7E10DF7437A4B9201261445@SZXEML506-MBS.china.huawei.com> X-Mailer: Apple Mail (2.936) Cc: "dnsext@ietf.org" Subject: Re: [dnsext] FW: New Version Notification for draft-jiang-dnsext-a6-to-historic-00.txt X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Sep 2011 18:27:56 -0000 On 27 Sep 2011, at 15:40, Dick Franks wrote: > The central premise of this I-D is that production deployment of A6 > lies somewhere between negligible and non-existent. > > If this assertion holds, any arguments about negative consequences are > really arguments applicable to RFC3597 unknown record types in > general which would be better advanced elsewhere. Not really. A6 is special because of its potential for involvement in DNS metadata. Misguided or obsolete resolvers may well attempt to use this currently experimental RRtype to construct an IPv6 address for the RDATA in an NS record. They wouldn't (need to try to) do that for other "unknown" record types. The problem is not the implementations that no longer support A6: it's the ones that still do and need to be fixed. IMO moving A6 to Historic is a necessary and overdue step on that path. > Challenge: Can anyone cite an A6 record, in production use, in the > wild, having a domain name in its RDATA? Evidence of absence is not absence of evidence. From ajs@anvilwalrusden.com Tue Sep 27 12:23:28 2011 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 52B0521F8F94 for ; Tue, 27 Sep 2011 12:23:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.57 X-Spam-Level: X-Spam-Status: No, score=-2.57 tagged_above=-999 required=5 tests=[AWL=0.029, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GYYGalTTfpKq for ; Tue, 27 Sep 2011 12:23:27 -0700 (PDT) Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by ietfa.amsl.com (Postfix) with ESMTP id C257321F8F68 for ; Tue, 27 Sep 2011 12:23:27 -0700 (PDT) Received: from shinkuro.com (69-196-144-227.dsl.teksavvy.com [69.196.144.227]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yitter.info (Postfix) with ESMTPSA id 9ED451ECB41F for ; Tue, 27 Sep 2011 19:26:08 +0000 (UTC) Date: Tue, 27 Sep 2011 15:26:11 -0400 From: Andrew Sullivan To: dnsext@ietf.org Message-ID: <20110927192611.GQ16696@shinkuro.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) Subject: [dnsext] draft-ietf-geopriv-res-gw-lis-discovery X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Sep 2011 19:23:28 -0000 Dear colleagues, I received a request from one of the geopriv chairs that draft-ietf-geopriv-res-gw-lis-discovery get some additional DNS eyes on it, so I said I'd pass along the request. The draft includes a procedure that involves tree-climbing in the reverse tree under some conditions, so it might be something that some from this community want to look at. Best regards, Andrew -- Andrew Sullivan ajs@anvilwalrusden.com From suruti94@gmail.com Wed Sep 28 11:22:10 2011 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 77B7311E80D5 for ; Wed, 28 Sep 2011 11:22:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F-rnW38j8uYK for ; Wed, 28 Sep 2011 11:22:10 -0700 (PDT) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by ietfa.amsl.com (Postfix) with ESMTP id BA12311E80AC for ; Wed, 28 Sep 2011 11:22:09 -0700 (PDT) Received: by yxt33 with SMTP id 33so8227953yxt.31 for ; Wed, 28 Sep 2011 11:24:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:cc:content-type; bh=NZe8lI9aqX2PgEB2mDcGbKs8BB1gyKAZ4mZj8ze2fPE=; b=Q7UkJKQrV2MotyQuuHdnb1CmCAZGQP23Pa8vb61TxX9ZpfBcZYS82xJLzxKuwHhc/w N2+tKnGneiU2NviEqDlbfrljcha6G+blFZULQUFo1ulyHJAooryTPibP8I6UwvlQP2R4 yPxO43kmdc5oZOMNMVYVgZAFJDuTYsQ8fROmw= MIME-Version: 1.0 Received: by 10.68.0.167 with SMTP id 7mr32899755pbf.106.1317234298183; Wed, 28 Sep 2011 11:24:58 -0700 (PDT) Received: by 10.68.46.200 with HTTP; Wed, 28 Sep 2011 11:24:58 -0700 (PDT) Date: Wed, 28 Sep 2011 11:24:58 -0700 Message-ID: From: Mohan Parthasarathy To: dnsext@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Cc: Paul Vixie Subject: [dnsext] draft-mohan-dns-query-xml-00.txt X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Sep 2011 18:22:10 -0000 Hi, DNSSEC validation is stub resolver is dependent on DNSSEC-aware CPEs, recursive servers etc. Here is a draft that we submitted yesterday to address this problem. http://www.ietf.org/id/draft-mohan-dns-query-xml-00.txt Please send your comments/feedback to the list. thanks -mohan From paul@xelerance.com Wed Sep 28 12:31:28 2011 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C45411E811A for ; Wed, 28 Sep 2011 12:31:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.504 X-Spam-Level: X-Spam-Status: No, score=-6.504 tagged_above=-999 required=5 tests=[AWL=0.095, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EjZDCGucor4z for ; Wed, 28 Sep 2011 12:31:27 -0700 (PDT) Received: from newtla.xelerance.com (newtla.xelerance.com [193.110.157.143]) by ietfa.amsl.com (Postfix) with ESMTP id 7D33311E811D for ; Wed, 28 Sep 2011 12:31:27 -0700 (PDT) Received: from newtla.xelerance.com (newtla.xelerance.com [127.0.0.1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by newtla.xelerance.com (Postfix) with ESMTP id DDAFF572F9; Wed, 28 Sep 2011 15:32:45 -0400 (EDT) Date: Wed, 28 Sep 2011 15:32:45 -0400 (EDT) From: Paul Wouters To: Mohan Parthasarathy In-Reply-To: Message-ID: References: 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 Vixie , dnsext@ietf.org Subject: Re: [dnsext] draft-mohan-dns-query-xml-00.txt X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Sep 2011 19:31:28 -0000 On Wed, 28 Sep 2011, Mohan Parthasarathy wrote: > DNSSEC validation is stub resolver is dependent on DNSSEC-aware CPEs, > recursive servers etc. Here is a draft that we submitted yesterday to > address this problem. > > http://www.ietf.org/id/draft-mohan-dns-query-xml-00.txt > > Please send your comments/feedback to the list. Have you done any research on running DNS over port 80/443? That seems to work quite often (after hotspot auth that breaks all dns) I'm wondering about the difference in working with running dns over http on port 80/443 and running plain dns over port 80/443 Also, if this is considered a good idea (of which I am not yet convinced), why not add a mode similar to the "dnssec chains" proposal to speed things up for the resolver, as we're already on TCP so response size shouldn't matter as much as latency does. You can test running dns over port 80/443 using ounbound and forwarding it to open.nlnetlabs.nl Paul From ted.ietf@gmail.com Wed Sep 28 14:03:50 2011 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D9A71F0D19 for ; Wed, 28 Sep 2011 14:03:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.506 X-Spam-Level: X-Spam-Status: No, score=-3.506 tagged_above=-999 required=5 tests=[AWL=0.093, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 30Imz5PCnvWQ for ; Wed, 28 Sep 2011 14:03:49 -0700 (PDT) Received: from mail-yi0-f44.google.com (mail-yi0-f44.google.com [209.85.218.44]) by ietfa.amsl.com (Postfix) with ESMTP id 815951F0CD2 for ; Wed, 28 Sep 2011 14:03:49 -0700 (PDT) Received: by yic13 with SMTP id 13so8062263yic.31 for ; Wed, 28 Sep 2011 14:06:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=i2yASxxcrszn7Jh2KUt7VPqMZsgcCOk7yxpXAz6Svzg=; b=GveLsSsCENqSJUFtzqUiyf2mH4YbmE+lcKeh4QPKHxNH3mJEREhM0K5CSTx9RiV1Ps Ub8wBkJxXmNYgZjKtBWB6QPJjMi8SyFQXPWLhh8wa3ZOQxW0Lya09Ub2WzR9kDoB4wyC U2Do4sS4p8A4PkYxjDNTOGL1jUqzYXeVJxQjI= MIME-Version: 1.0 Received: by 10.236.187.36 with SMTP id x24mr58713115yhm.74.1317243998509; Wed, 28 Sep 2011 14:06:38 -0700 (PDT) Received: by 10.236.105.169 with HTTP; Wed, 28 Sep 2011 14:06:38 -0700 (PDT) In-Reply-To: References: Date: Wed, 28 Sep 2011 14:06:38 -0700 Message-ID: From: Ted Hardie To: Mohan Parthasarathy Content-Type: multipart/alternative; boundary=20cf303dd9d09d1ac004ae06c4b4 Cc: Paul Vixie , dnsext@ietf.org Subject: Re: [dnsext] draft-mohan-dns-query-xml-00.txt X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Sep 2011 21:03:50 -0000 --20cf303dd9d09d1ac004ae06c4b4 Content-Type: text/plain; charset=ISO-8859-1 Howdy, I have a few questions on this proposal. Why not re-use the syntax of RFC4501 for the query? That is: https://relayingwebserver.example.com/query.cgi?dns:[//authority/]domain[?CLASS=class;TYPE=type] ? Declaring a namespace for the xml is generally good practice. It's also not clear why you need an XML-based representation, rather than using a mime-type like that set out in RFC 4027 (which uses detached domain name information as set out in RFC 2540). Even if those need updating, it's not clear to me what you're gaining with the use of XML here. It seems like you're wanting this to be used when CD bit is set to 1; any reason why you'd want to support this for CD bit set to 0? In general, I think a little bit more wording on when this tunneling would be used would be really useful to flesh out when this is needed. NIT: You cite RFC 2396, but the current reference is RFC 3986 regards, Ted Hardie On Wed, Sep 28, 2011 at 11:24 AM, Mohan Parthasarathy wrote: > Hi, > > DNSSEC validation is stub resolver is dependent on DNSSEC-aware CPEs, > recursive servers etc. Here is a draft that we submitted yesterday to > address this problem. > > http://www.ietf.org/id/draft-mohan-dns-query-xml-00.txt > > Please send your comments/feedback to the list. > > thanks > -mohan > _______________________________________________ > dnsext mailing list > dnsext@ietf.org > https://www.ietf.org/mailman/listinfo/dnsext > --20cf303dd9d09d1ac004ae06c4b4 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Howdy,

I have a few questions on this proposal.

Why not re-us= e the syntax of RFC4501 for the query?=A0 That is: https://relayingwebserver.example.com/q= uery.cgi?dns:[//autho= rity/]domain[?CLASS=3Dclass;TYPE=3Dtype] ?

Declaring a namespace for the xml is generally good practice.=A0 It'= ;s also not clear why you need an XML-based representation, rather than usi= ng a mime-type like that set out in RFC 4027 (which uses detached domain na= me information as set out in RFC 2540).=A0 Even if those need updating, it&= #39;s not clear to me what you're gaining with the use of XML here.

It seems like you're wanting this to be used when CD bit is set to = 1; any reason why you'd want to support this for CD bit set to 0?=A0 In general, I think a little bit more wording on when this tunneling woul= d be used would be really useful to flesh out when this is needed.

NIT: You cite RFC 2396, but the current reference is RFC 3986

re= gards,

Ted Hardie


On Wed, Sep = 28, 2011 at 11:24 AM, Mohan Parthasarathy <suruti94@gmail.com> wrote:
Hi,

DNSSEC validation is stub resolver is dependent on DNSSEC-aware CPEs,
recursive servers etc. Here is a draft that we submitted yesterday to
address this problem.

http://www.ietf.org/id/draft-mohan-dns-query-xml-00.txt

Please send your comments/feedback to the list.

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

--20cf303dd9d09d1ac004ae06c4b4-- From suruti94@gmail.com Wed Sep 28 14:04:23 2011 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2FB7F1F0D27 for ; Wed, 28 Sep 2011 14:04:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0paDyu0cesTl for ; Wed, 28 Sep 2011 14:04:22 -0700 (PDT) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by ietfa.amsl.com (Postfix) with ESMTP id 0DAA31F0D26 for ; Wed, 28 Sep 2011 14:04:15 -0700 (PDT) Received: by yxt33 with SMTP id 33so9925yxt.31 for ; Wed, 28 Sep 2011 14:07:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=W80QARPspCyI1ATCZKMozX7Bcggx0oXL6UD53WREfig=; b=bOq15/U2jLSIW80DDMvbsQjFAW4KsZStwrssNX7YQ/Gw8YJWB3fbTxTU6HL1ZtU2Zb jVUJ8uQZf+aPQzkDYzgo077IMXtiPIhGdgiSFW/dZsWXDwWrkWdRNHCFCYVJGGvxrn89 MMk+6uIJTr+MgBpkF/wbKRURSW1qtgllvDFrY= MIME-Version: 1.0 Received: by 10.68.30.199 with SMTP id u7mr47223745pbh.55.1317244024886; Wed, 28 Sep 2011 14:07:04 -0700 (PDT) Received: by 10.68.46.200 with HTTP; Wed, 28 Sep 2011 14:07:04 -0700 (PDT) In-Reply-To: References: Date: Wed, 28 Sep 2011 14:07:04 -0700 Message-ID: From: Mohan Parthasarathy To: Paul Wouters Content-Type: text/plain; charset=ISO-8859-1 Cc: Paul Vixie , dnsext@ietf.org Subject: Re: [dnsext] draft-mohan-dns-query-xml-00.txt X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Sep 2011 21:04:23 -0000 On Wed, Sep 28, 2011 at 12:32 PM, Paul Wouters wrote: > On Wed, 28 Sep 2011, Mohan Parthasarathy wrote: > >> DNSSEC validation is stub resolver is dependent on DNSSEC-aware CPEs, >> recursive servers etc. Here is a draft that we submitted yesterday to >> address this problem. >> >> http://www.ietf.org/id/draft-mohan-dns-query-xml-00.txt >> >> Please send your comments/feedback to the list. > > Have you done any research on running DNS over port 80/443? That seems > to work quite often (after hotspot auth that breaks all dns) > > I'm wondering about the difference in working with running dns over http > on port 80/443 and running plain dns over port 80/443 > If I want to be able to run both my web service and DNS service from the same address, then I can't just run DNS alone over 80/443. > Also, if this is considered a good idea (of which I am not yet convinced), > why not add a mode similar to the "dnssec chains" proposal to speed things > up > for the resolver, as we're already on TCP so response size shouldn't matter > as much as latency does. > I am not sure I understand. It is not about speed. It is about the stub validator being able to get the DNSSEC records when sitting behind CPEs and recursive servers (and other middle boxes) that are not DNSSEC aware. -mohan > You can test running dns over port 80/443 using ounbound and forwarding it > to open.nlnetlabs.nl > > Paul > From nweaver@icsi.berkeley.edu Wed Sep 28 14:13:25 2011 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6023B21F8DD2 for ; Wed, 28 Sep 2011 14:13:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.149 X-Spam-Level: X-Spam-Status: No, score=-2.149 tagged_above=-999 required=5 tests=[AWL=0.450, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 16FxKyAkq+pZ for ; Wed, 28 Sep 2011 14:13:24 -0700 (PDT) Received: from rock.ICSI.Berkeley.EDU (rock.ICSI.Berkeley.EDU [192.150.186.19]) by ietfa.amsl.com (Postfix) with ESMTP id 4442A21F8DCF for ; Wed, 28 Sep 2011 14:13:22 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by rock.ICSI.Berkeley.EDU (Postfix) with ESMTP id 0C0FE2C4004; Wed, 28 Sep 2011 14:16:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at ICSI.Berkeley.EDU Received: from rock.ICSI.Berkeley.EDU ([127.0.0.1]) by localhost (maihub.ICSI.Berkeley.EDU [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 5HWrscwO1h6m; Wed, 28 Sep 2011 14:16:10 -0700 (PDT) Received: from [10.0.1.2] (c-76-103-166-40.hsd1.ca.comcast.net [76.103.166.40]) (Authenticated sender: nweaver) by rock.ICSI.Berkeley.EDU (Postfix) with ESMTP id 9F5F12C4002; Wed, 28 Sep 2011 14:16:10 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1244.3) Content-Type: text/plain; charset=us-ascii From: Nicholas Weaver In-Reply-To: Date: Wed, 28 Sep 2011 14:16:09 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <71422E92-1832-4703-98F4-62FB839A5235@icsi.berkeley.edu> References: To: Mohan Parthasarathy X-Mailer: Apple Mail (2.1244.3) Cc: Paul Vixie , dnsext@ietf.org Subject: Re: [dnsext] draft-mohan-dns-query-xml-00.txt X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Sep 2011 21:13:25 -0000 On Sep 28, 2011, at 2:07 PM, Mohan Parthasarathy wrote: > If I want to be able to run both my web service and DNS service from > the same address, then I can't just run DNS alone over 80/443. Have you looked at just running normal DNS recursively from the end = host, including failover to TCP when things are obviously breaking? We don't have ALL the information yet (our test is not comprehensive = enough), but most systems CAN do direct fetches on UDP or TCP if they = must: non-functioning recursive resolvers should not be a problem for = DNSSEC validation. In fact, for the purposes of A records, etc, just the recursive request = from the end host is enough to be "close enough" to the security effect = you would get from full DNSSEC validation. (DANE or the like, where = DNSSEC is used to validate key material not host->IP mappings, requires = end-host validation) From suruti94@gmail.com Wed Sep 28 14:46:55 2011 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 70D9E21F8C1A for ; Wed, 28 Sep 2011 14:46:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NQWgqDL-M31S for ; Wed, 28 Sep 2011 14:46:55 -0700 (PDT) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by ietfa.amsl.com (Postfix) with ESMTP id DC9A321F8C0F for ; Wed, 28 Sep 2011 14:46:54 -0700 (PDT) Received: by yxt33 with SMTP id 33so46938yxt.31 for ; Wed, 28 Sep 2011 14:49:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=pBxnyPYE+IfKfCXQjoGlncd/x+U8aNoy2GcPdQmvpO4=; b=hvOBvzij4rVyqPVzbSfFhVPWxEbPshtUmzJCMbckmBPg9Pl19HpzGjViV/i71mfTLt kbfAeEbrICUPpm0QW3wxT+hLZ5MuLBXfPTpWPa+bd9w8Ka4+pCxdBc2ncGlDz7Ayhx6Y k5fKx3RI364aHcdhDndi5iA3MXmTWD8iu8adY= MIME-Version: 1.0 Received: by 10.68.9.104 with SMTP id y8mr46580011pba.21.1317246583642; Wed, 28 Sep 2011 14:49:43 -0700 (PDT) Received: by 10.68.46.200 with HTTP; Wed, 28 Sep 2011 14:49:43 -0700 (PDT) In-Reply-To: References: Date: Wed, 28 Sep 2011 14:49:43 -0700 Message-ID: From: Mohan Parthasarathy To: Ted Hardie Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Paul Vixie , dnsext@ietf.org Subject: Re: [dnsext] draft-mohan-dns-query-xml-00.txt X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Sep 2011 21:46:55 -0000 On Wed, Sep 28, 2011 at 2:06 PM, Ted Hardie wrote: > Howdy, > > I have a few questions on this proposal. > > Why not re-use the syntax of RFC4501 for the query?=A0 That is: > https://relayingwebserver.example.com/query.cgi?dns:[//authority/]domain[= ?CLASS=3Dclass;TYPE=3Dtype] > ? > We should definitely study that for the next revision. We need to be able to specify more than what is given in RFC 4501. Is that extensible ? > Declaring a namespace for the xml is generally good practice.=A0 It's als= o not > clear why you need an XML-based representation, rather than using a > mime-type like that set out in RFC 4027 (which uses detached domain name > information as set out in RFC 2540).=A0 Even if those need updating, it's= not > clear to me what you're gaining with the use of XML here. > We chose XML because it is readily available and also better inter-operabil= ity. > It seems like you're wanting this to be used when CD bit is set to 1; any > reason why you'd want to support this for CD bit set to 0? > In general, I think a little bit more wording on when this tunneling woul= d > be used would be really useful to flesh out when this is needed. > Yes, the main use case is DNSSEC. Does it make sense to restrict to just th= at ? > NIT: You cite RFC 2396, but the current reference is RFC 3986 > Will fix that. thanks mohan > regards, > > Ted Hardie > > > On Wed, Sep 28, 2011 at 11:24 AM, Mohan Parthasarathy > wrote: >> >> Hi, >> >> DNSSEC validation is stub resolver is dependent on DNSSEC-aware CPEs, >> recursive servers etc. Here is a draft that we submitted yesterday to >> address this problem. >> >> http://www.ietf.org/id/draft-mohan-dns-query-xml-00.txt >> >> Please send your comments/feedback to the list. >> >> thanks >> -mohan >> _______________________________________________ >> dnsext mailing list >> dnsext@ietf.org >> https://www.ietf.org/mailman/listinfo/dnsext > > From wilmer@google.com Wed Sep 28 15:08:10 2011 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9951F1F0C81 for ; Wed, 28 Sep 2011 15:08:10 -0700 (PDT) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KnujTNt5tJiV for ; Wed, 28 Sep 2011 15:08:09 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.67]) by ietfa.amsl.com (Postfix) with ESMTP id 3579B1F0C4E for ; Wed, 28 Sep 2011 15:08:02 -0700 (PDT) Received: from hpaq11.eem.corp.google.com (hpaq11.eem.corp.google.com [172.25.149.11]) by smtp-out.google.com with ESMTP id p8SMAjYn008681 for ; Wed, 28 Sep 2011 15:10:45 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1317247845; bh=fIQP0YxdwNYT0uGDbflZOHBS/4Q=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type; b=tEw4WdQOkX89cz9N+E9G4QWGhyNuI0cQSDIJca/f7HVj6bYb5u0PWM7Jc9xf0DKwz qtUvtEt4+S0rfhXjW4JvA== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=dkim-signature:mime-version:in-reply-to:references:date: message-id:subject:from:to:cc:content-type:x-system-of-record; b=qaAvOaGtP76HoTRW5UXM+AprYT2bKbAhSQj8Wu8CWdEOGn0EfkkImcataL9G25cuU 2D3ptfL9dPa8isW7EZcsA== Received: from iagv1 (iagv1.prod.google.com [10.12.223.1]) by hpaq11.eem.corp.google.com with ESMTP id p8SM5TPM009967 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Wed, 28 Sep 2011 15:10:43 -0700 Received: by iagv1 with SMTP id v1so9935282iag.30 for ; Wed, 28 Sep 2011 15:10:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=LNnD6cjtNdnHtgUZP0ZD/EHx7c4uUuncmn8roGjLJjo=; b=g+qqSNb50ecdTz8AWEnAkuNpVoPMQAwnit4Zu3/+4ydSjIZnDV+WUPgv/LC6Moko4c XktQCcI9LD2B2yq0p05Q== Received: by 10.231.28.131 with SMTP id m3mr13646875ibc.24.1317247842847; Wed, 28 Sep 2011 15:10:42 -0700 (PDT) MIME-Version: 1.0 Received: by 10.231.28.131 with SMTP id m3mr13646861ibc.24.1317247842502; Wed, 28 Sep 2011 15:10:42 -0700 (PDT) Received: by 10.231.35.77 with HTTP; Wed, 28 Sep 2011 15:10:42 -0700 (PDT) In-Reply-To: References: Date: Wed, 28 Sep 2011 15:10:42 -0700 Message-ID: From: Wilmer van der Gaast To: Mohan Parthasarathy Content-Type: text/plain; charset=ISO-8859-1 X-System-Of-Record: true Cc: Paul Vixie , dnsext@ietf.org Subject: Re: [dnsext] draft-mohan-dns-query-xml-00.txt X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Sep 2011 22:08:10 -0000 On 28 September 2011 11:24, Mohan Parthasarathy wrote: > > Please send your comments/feedback to the list. > Two things off the top of my head after quickly reading this: A) Is it necessary to hardcode the /dns_service path? IMHO it would be nice to allow the use of base URLs instead, in case for some reason /dns_service can't be used on a host. Also, this lets the user choose if s/he wants to talk to a DNS service with/without DNSSEC validation for example (or opt out from things like ISP DNS "monetisation" in a nicer way). B) Nit, but why not convert the booleans in responses from value into if it's 1 and being absent if it's 0? Cheers, -- Wilmer van der Gaast, Traffic SRE/Google Public DNS team. Google Ireland. From paul.hoffman@vpnc.org Wed Sep 28 16:23:15 2011 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1B16311E80A0 for ; Wed, 28 Sep 2011 16:23:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.559 X-Spam-Level: X-Spam-Status: No, score=-102.559 tagged_above=-999 required=5 tests=[AWL=0.040, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w4O4d8JEmHdm for ; Wed, 28 Sep 2011 16:23:14 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 70FD211E8088 for ; Wed, 28 Sep 2011 16:23:14 -0700 (PDT) Received: from [10.20.30.100] (50-0-66-4.dsl.dynamic.fusionbroadband.com [50.0.66.4]) (authenticated bits=0) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id p8SNQ3Zk038010 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Wed, 28 Sep 2011 16:26:03 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1244.3) From: Paul Hoffman In-Reply-To: Date: Wed, 28 Sep 2011 16:26:02 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <9D2E8A4D-484C-4F9C-B1B7-4DAE95D3B3DA@vpnc.org> References: To: DNSEXT Working Group X-Mailer: Apple Mail (2.1244.3) Subject: Re: [dnsext] draft-mohan-dns-query-xml-00.txt X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Sep 2011 23:23:15 -0000 (I sent Mohan and Paul comments offline yesterday. The following are the = most significant.) XML carries a lot of baggage with it. Instead of an XML format, JSON = would be a lot easier. "response" is a dictionary; ID, aa, rcode, = anscount are integers, answers is a list of integers. In the RR format, = name, type, class, and rdlength are integers and ttl is an integer. = rdata is a string of Base64 of the data with no escaping.=20 Also, "anscount" and "rdlength" should not be there either for XML or = JSON: they introduce a silly state. =20 --Paul Hoffman From suruti94@gmail.com Wed Sep 28 16:45:37 2011 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A85511E815A for ; Wed, 28 Sep 2011 16:45:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8Gn8kvWh4Enx for ; Wed, 28 Sep 2011 16:45:36 -0700 (PDT) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by ietfa.amsl.com (Postfix) with ESMTP id BC05C11E8159 for ; Wed, 28 Sep 2011 16:45:36 -0700 (PDT) Received: by yxt33 with SMTP id 33so138497yxt.31 for ; Wed, 28 Sep 2011 16:48:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=dSWpgm9150fnXSU63w6NGtAA3nO79SQvcyx91SR8RUs=; b=HlySqWOomt/xxGILRe4Ql5U/IQGuBjVFS3mbDevBK+M/SryhGrhH8kviKGOl8x4xDs 7feqxQLFBxnKJUushxEHNDMtNko4fBf267F2Zb82RoVWPtf7pYgY/Gcu/PgET0uQIORr MGOlPJmBgnJe61txSB238FkHczZFMG4kK9/tA= MIME-Version: 1.0 Received: by 10.68.58.138 with SMTP id r10mr7148850pbq.72.1317253705744; Wed, 28 Sep 2011 16:48:25 -0700 (PDT) Received: by 10.68.46.200 with HTTP; Wed, 28 Sep 2011 16:48:25 -0700 (PDT) In-Reply-To: <71422E92-1832-4703-98F4-62FB839A5235@icsi.berkeley.edu> References: <71422E92-1832-4703-98F4-62FB839A5235@icsi.berkeley.edu> Date: Wed, 28 Sep 2011 16:48:25 -0700 Message-ID: From: Mohan Parthasarathy To: Nicholas Weaver Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Paul Vixie , dnsext@ietf.org Subject: Re: [dnsext] draft-mohan-dns-query-xml-00.txt X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Sep 2011 23:45:37 -0000 On Wed, Sep 28, 2011 at 2:16 PM, Nicholas Weaver wrote: > > On Sep 28, 2011, at 2:07 PM, Mohan Parthasarathy wrote: >> If I want to be able to run both my web service and DNS service from >> the same address, then I can't just run DNS alone over 80/443. > > Have you looked at just running normal DNS recursively from the end host,= including failover to TCP when things are obviously breaking? > > We don't have ALL the information yet (our test is not comprehensive enou= gh), but most systems CAN do direct fetches on UDP or TCP if they must: non= -functioning recursive resolvers should not be a problem for DNSSEC validat= ion. > I am not sure I understand the question. If you are dependent on a recursive server to fetch the DNSSEC records, then that server needs to be DNSSEC aware. If you are operating in iterative mode fetching it yourself, then it does not work in environments where firewalls normally prohibit talking to external name servers. Which one are you talking about ? We had a lengthy discussion about the various options in the dnssec-deployment group recently. > In fact, for the purposes of A records, etc, just the recursive request f= rom the end host is enough to be "close enough" to the security effect you = would get from full DNSSEC validation. =A0(DANE or the like, where DNSSEC i= s used to validate key material not host->IP mappings, requires end-host va= lidation) > > Why do you assume that the draft is not applicable for DANE use case ? -mohan From suruti94@gmail.com Wed Sep 28 16:54:50 2011 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BDF2D11E8157 for ; Wed, 28 Sep 2011 16:54:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FxMfx4BTg0yp for ; Wed, 28 Sep 2011 16:54:49 -0700 (PDT) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id 6313211E80DA for ; Wed, 28 Sep 2011 16:54:49 -0700 (PDT) Received: by iaby26 with SMTP id y26so58792iab.31 for ; Wed, 28 Sep 2011 16:57:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=eWmob5Wd7xkB4tvcUxRxeBnJ+K22BqGvwj7QOg+Ncq0=; b=UoMRhF/oQhGjNTIw99beEsybLCGGOBu4bre5ReNixgeFuqO9CktzJcvCN6i/OpvT6+ mFMcdwdRQ14Je7jiHgpT1AgzHtt3vbFZfgNmADO1uPyr5pcx5y675j5a3R7II1MPmqTo 7dtStZyBCA0t5P/yvnCgujEOviqBHVUFLebz8= MIME-Version: 1.0 Received: by 10.68.209.37 with SMTP id mj5mr47100755pbc.123.1317254258744; Wed, 28 Sep 2011 16:57:38 -0700 (PDT) Received: by 10.68.46.200 with HTTP; Wed, 28 Sep 2011 16:57:38 -0700 (PDT) In-Reply-To: References: Date: Wed, 28 Sep 2011 16:57:38 -0700 Message-ID: From: Mohan Parthasarathy To: Wilmer van der Gaast Content-Type: text/plain; charset=ISO-8859-1 Cc: Paul Vixie , dnsext@ietf.org Subject: Re: [dnsext] draft-mohan-dns-query-xml-00.txt X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Sep 2011 23:54:50 -0000 On Wed, Sep 28, 2011 at 3:10 PM, Wilmer van der Gaast wrote: > On 28 September 2011 11:24, Mohan Parthasarathy wrote: >> >> Please send your comments/feedback to the list. >> > Two things off the top of my head after quickly reading this: > > A) Is it necessary to hardcode the /dns_service path? IMHO it would be > nice to allow the use of base URLs instead, in case for some reason > /dns_service can't be used on a host. Also, this lets the user choose > if s/he wants to talk to a DNS service with/without DNSSEC validation > for example (or opt out from things like ISP DNS "monetisation" in a > nicer way). > If we can avoid hardcoding that would be nice. I am not sure I understand your proposal. Could you clarify ? The initial thought is that it would be nice to access it in a standard way but I do see the issues you noted above. > B) Nit, but why not convert the booleans in responses from > value into if it's 1 and being absent if it's 0? > Is this a standard approach ? Or it saves bytes ? thanks, mohan > > > Cheers, > > -- > Wilmer van der Gaast, Traffic SRE/Google Public DNS team. > Google Ireland. > From wilmer@google.com Wed Sep 28 17:28:41 2011 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C9BD11E8155 for ; Wed, 28 Sep 2011 17:28:41 -0700 (PDT) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jZ0Jy7dugkdU for ; Wed, 28 Sep 2011 17:28:40 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by ietfa.amsl.com (Postfix) with ESMTP id C3F1D11E8144 for ; Wed, 28 Sep 2011 17:28:40 -0700 (PDT) Received: from wpaz21.hot.corp.google.com (wpaz21.hot.corp.google.com [172.24.198.85]) by smtp-out.google.com with ESMTP id p8T0VUXT015705 for ; Wed, 28 Sep 2011 17:31:30 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1317256290; bh=TZoIzCO5xkiirvaxYpdxwddjieI=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type; b=QytmxgNzgcMMluanrlWRlALcyrsBZ7h4uV3PsUAuFQ9CHc6aIrxkJXxGqKE8jTlVD TMhzIg9LtJd1cqxdStbPg== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=dkim-signature:mime-version:in-reply-to:references:date: message-id:subject:from:to:cc:content-type:x-system-of-record; b=RUSnd0RqVnr+dRskc5t18+SD+255g3dQCbc+L5dE1BZ7cIlvTjI71B2y8a0JLjL7T VuOzW6eO7kzOadTYingow== Received: from iabz21 (iabz21.prod.google.com [10.12.102.21]) by wpaz21.hot.corp.google.com with ESMTP id p8T0Thsk018753 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Wed, 28 Sep 2011 17:31:29 -0700 Received: by iabz21 with SMTP id z21so95469iab.37 for ; Wed, 28 Sep 2011 17:31:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=07PTyMoGDoybrYXptI1T1tBVDlJbeZ9qolaCBMYV+9A=; b=NylPxOEjTYURWEK0MI03YDgUj3E00Spp3IrYL9EoA8fQRpuHzXjxxxIBfAEJLvLXHr dcHGDCDacSUMBYYluVqQ== Received: by 10.231.6.79 with SMTP id 15mr13628259iby.52.1317256288900; Wed, 28 Sep 2011 17:31:28 -0700 (PDT) MIME-Version: 1.0 Received: by 10.231.6.79 with SMTP id 15mr13628250iby.52.1317256288762; Wed, 28 Sep 2011 17:31:28 -0700 (PDT) Received: by 10.231.35.77 with HTTP; Wed, 28 Sep 2011 17:31:28 -0700 (PDT) In-Reply-To: References: Date: Wed, 28 Sep 2011 17:31:28 -0700 Message-ID: From: Wilmer van der Gaast To: Mohan Parthasarathy Content-Type: text/plain; charset=ISO-8859-1 X-System-Of-Record: true Cc: Paul Vixie , dnsext@ietf.org Subject: Re: [dnsext] draft-mohan-dns-query-xml-00.txt X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Sep 2011 00:28:41 -0000 On 28 September 2011 16:57, Mohan Parthasarathy wrote: > > If we can avoid hardcoding that would be nice. I am not sure I > understand your proposal. Could you clarify ? The initial thought is > that it would be nice to access it in a standard way but I do see the > issues you noted above. > Basically what I'm suggesting is that instead of an IP address, the user fills in a base URL. In your example on page 10 the base URL would be "https://server_address/dns_service/". The client implementation just glues query?name=.... to that base URL to get the exact URL to query. This lets me put the dns service under a different path, like for example just /dns ... or I could have a /dns and a /dns-secure for people who already want strict DNSSEC validation even though it may make some names unresolvable. >> B) Nit, but why not convert the booleans in responses from >> value into if it's 1 and being absent if it's 0? > Is this a standard approach ? Or it saves bytes ? > It saves bytes, IMHO it looks clearer and also it's (again IMHO) easier to parse; you just check if the element is present or not, instead of finding it and evaluating it (what to do if the text value is not 0 or 1?). Cheers, -- Wilmer van der Gaast, Traffic SRE/Google Public DNS team. Google Ireland. From nweaver@ICSI.Berkeley.EDU Wed Sep 28 17:37:22 2011 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 679195E8004 for ; Wed, 28 Sep 2011 17:37:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T2G5JPOx9cva for ; Wed, 28 Sep 2011 17:37:21 -0700 (PDT) Received: from rock.ICSI.Berkeley.EDU (rock.ICSI.Berkeley.EDU [192.150.186.19]) by ietfa.amsl.com (Postfix) with ESMTP id 48B035E8003 for ; Wed, 28 Sep 2011 17:37:21 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by rock.ICSI.Berkeley.EDU (Postfix) with ESMTP id 1E5912C4003; Wed, 28 Sep 2011 17:40:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at ICSI.Berkeley.EDU Received: from rock.ICSI.Berkeley.EDU ([127.0.0.1]) by localhost (maihub.ICSI.Berkeley.EDU [127.0.0.1]) (amavisd-new, port 10024) with LMTP id nFKIhAB2Sxw7; Wed, 28 Sep 2011 17:40:10 -0700 (PDT) Received: from [10.0.1.2] (c-76-103-166-40.hsd1.ca.comcast.net [76.103.166.40]) (Authenticated sender: nweaver) by rock.ICSI.Berkeley.EDU (Postfix) with ESMTP id 871472C4002; Wed, 28 Sep 2011 17:40:10 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1244.3) Content-Type: text/plain; charset=iso-8859-1 From: Nicholas Weaver In-Reply-To: Date: Wed, 28 Sep 2011 17:40:11 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <9127D76F-53FC-4F69-B0E7-5328CFFF6871@ICSI.Berkeley.EDU> References: <71422E92-1832-4703-98F4-62FB839A5235@icsi.berkeley.edu> To: Mohan Parthasarathy X-Mailer: Apple Mail (2.1244.3) Cc: Paul Vixie , dnsext@ietf.org Subject: Re: [dnsext] draft-mohan-dns-query-xml-00.txt X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Sep 2011 00:37:22 -0000 On Sep 28, 2011, at 4:48 PM, Mohan Parthasarathy wrote: > On Wed, Sep 28, 2011 at 2:16 PM, Nicholas Weaver > wrote: >>=20 >> On Sep 28, 2011, at 2:07 PM, Mohan Parthasarathy wrote: >>> If I want to be able to run both my web service and DNS service from >>> the same address, then I can't just run DNS alone over 80/443. >>=20 >> Have you looked at just running normal DNS recursively from the end = host, including failover to TCP when things are obviously breaking? >>=20 >> We don't have ALL the information yet (our test is not comprehensive = enough), but most systems CAN do direct fetches on UDP or TCP if they = must: non-functioning recursive resolvers should not be a problem for = DNSSEC validation. >>=20 >=20 > I am not sure I understand the question. If you are dependent on a > recursive server to fetch the DNSSEC records, then that server needs > to be DNSSEC aware. If you are operating in iterative mode fetching it > yourself, then it does not work in environments where firewalls > normally prohibit talking to external name servers. Which one are you > talking about ? We had a lengthy discussion about the various options > in the dnssec-deployment group recently. Don't be dependent on the recursive server. Just fetch it thyself = iteratively, starting with the root, and be done with it. =20 There are cases where this fails, but the cases are far rarer than you = think, especially when using TCP as well as UDP, and FAR FAR less common = than the broken proxies clients are configured to use as recursive = resolvers. >> In fact, for the purposes of A records, etc, just the recursive = request from the end host is enough to be "close enough" to the security = effect you would get from full DNSSEC validation. (DANE or the like, = where DNSSEC is used to validate key material not host->IP mappings, = requires end-host validation) >>=20 >>=20 >=20 > Why do you assume that the draft is not applicable for DANE use case ? Actually, its that the draft is ONLY applicable for the DANE use case or = other cases where DNSSEC is used to distribute cryptographic material... Given you are doing a direct fetch, starting with the root and bypassing = the recursive resolver. In this case, validating DNSSEC for A-records = and the like does not matter at all, because almost all adversaries who = are in a position to modify the DNS reply you receive can also instead = modify the protocol which USES the A record. And the final protocol either resists a MITM (in which case, DNSSEC = validation of A records doesn't matter because modifying the DNS reply = doesn't help the adversary) or is vulnerable to a MITM (in which case, = DNSSEC validation of A records doesn't matter because the adversary = could just MITM the final application protocol). In fact, this is my proposed policy for client validation FAILURE using = existing, non-DNSSEC aware APIs: IF DNSSEC validation fails, bypass the = recursive resolver, do a direct iterative fetch, and accept whatever you = get without question, since most DNSSEC validation failures will be = errors, not attacks. I also agree with the observation from Paul Hoffman that XML is way too = heavyweight and that JSON is the way to go for serializing arbitrary = blobs of data over HTTP. From Aki.Tuomi@tdc.fi Thu Sep 29 00:15:49 2011 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2424D21F8DB1 for ; Thu, 29 Sep 2011 00:15:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U0pt47PRNyxG for ; Thu, 29 Sep 2011 00:15:48 -0700 (PDT) Received: from mx10.tdc.fi (mx10.tdc.fi [80.64.7.197]) by ietfa.amsl.com (Postfix) with ESMTP id 2265E21F8DAB for ; Thu, 29 Sep 2011 00:15:46 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.68,459,1312146000"; d="scan'208";a="81074125" Received: from fi-hel2ex03.nordiclan.net ([194.100.5.181]) by mail-gw1.tdc.fi with ESMTP; 29 Sep 2011 10:18:35 +0300 Received: from FI-HEL2EX02.nordiclan.net ([194.100.5.180]) by fi-hel2ex03.nordiclan.net ([169.254.2.93]) with mapi id 14.01.0339.001; Thu, 29 Sep 2011 10:18:35 +0300 From: Aki Tuomi To: Nicholas Weaver , Mohan Parthasarathy Thread-Topic: [dnsext] draft-mohan-dns-query-xml-00.txt Thread-Index: AQHMfgwGM/xRHxVWqUCYwA6Ec0xRypVi/GiAgAAaWgCAAAKKgIAAKouAgAAOdoCAAKE6AA== Date: Thu, 29 Sep 2011 07:18:34 +0000 Message-ID: <4343712A0D390E46ABDE28EA69F91EF21C862A08@fi-hel2ex02.nordiclan.net> References: <71422E92-1832-4703-98F4-62FB839A5235@icsi.berkeley.edu> <9127D76F-53FC-4F69-B0E7-5328CFFF6871@ICSI.Berkeley.EDU> In-Reply-To: <9127D76F-53FC-4F69-B0E7-5328CFFF6871@ICSI.Berkeley.EDU> Accept-Language: en-US, fi-FI Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.16.52.207] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Cc: Paul Vixie , "dnsext@ietf.org" Subject: Re: [dnsext] draft-mohan-dns-query-xml-00.txt X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Sep 2011 07:15:49 -0000 PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBkbnNleHQtYm91bmNlc0BpZXRm Lm9yZyBbbWFpbHRvOmRuc2V4dC1ib3VuY2VzQGlldGYub3JnXSBPbg0KPiBCZWhhbGYgT2YgTmlj aG9sYXMgV2VhdmVyDQo+IFNlbnQ6IFRodXJzZGF5LCBTZXB0ZW1iZXIgMjksIDIwMTEgMzo0MCBB TQ0KPiBUbzogTW9oYW4gUGFydGhhc2FyYXRoeQ0KPiBDYzogUGF1bCBWaXhpZTsgZG5zZXh0QGll dGYub3JnDQo+IFN1YmplY3Q6IFJlOiBbZG5zZXh0XSBkcmFmdC1tb2hhbi1kbnMtcXVlcnkteG1s LTAwLnR4dA0KPiANCj4gDQo+IE9uIFNlcCAyOCwgMjAxMSwgYXQgNDo0OCBQTSwgTW9oYW4gUGFy dGhhc2FyYXRoeSB3cm90ZToNCj4gDQo+ID4gT24gV2VkLCBTZXAgMjgsIDIwMTEgYXQgMjoxNiBQ TSwgTmljaG9sYXMgV2VhdmVyDQo+ID4gPG53ZWF2ZXJAaWNzaS5iZXJrZWxleS5lZHU+IHdyb3Rl Og0KPiA+Pg0KPiA+PiBPbiBTZXAgMjgsIDIwMTEsIGF0IDI6MDcgUE0sIE1vaGFuIFBhcnRoYXNh cmF0aHkgd3JvdGU6DQo+ID4+PiBJZiBJIHdhbnQgdG8gYmUgYWJsZSB0byBydW4gYm90aCBteSB3 ZWIgc2VydmljZSBhbmQgRE5TIHNlcnZpY2UNCj4gZnJvbQ0KPiA+Pj4gdGhlIHNhbWUgYWRkcmVz cywgdGhlbiBJIGNhbid0IGp1c3QgcnVuIEROUyBhbG9uZSBvdmVyIDgwLzQ0My4NCj4gPj4NCj4g Pj4gSGF2ZSB5b3UgbG9va2VkIGF0IGp1c3QgcnVubmluZyBub3JtYWwgRE5TIHJlY3Vyc2l2ZWx5 IGZyb20gdGhlIGVuZA0KPiBob3N0LCBpbmNsdWRpbmcgZmFpbG92ZXIgdG8gVENQIHdoZW4gdGhp bmdzIGFyZSBvYnZpb3VzbHkgYnJlYWtpbmc/DQo+ID4+DQo+ID4+IFdlIGRvbid0IGhhdmUgQUxM IHRoZSBpbmZvcm1hdGlvbiB5ZXQgKG91ciB0ZXN0IGlzIG5vdCBjb21wcmVoZW5zaXZlDQo+IGVu b3VnaCksIGJ1dCBtb3N0IHN5c3RlbXMgQ0FOIGRvIGRpcmVjdCBmZXRjaGVzIG9uIFVEUCBvciBU Q1AgaWYgdGhleQ0KPiBtdXN0OiBub24tZnVuY3Rpb25pbmcgcmVjdXJzaXZlIHJlc29sdmVycyBz aG91bGQgbm90IGJlIGEgcHJvYmxlbSBmb3INCj4gRE5TU0VDIHZhbGlkYXRpb24uDQo+ID4+DQo+ ID4NCj4gPiBJIGFtIG5vdCBzdXJlIEkgdW5kZXJzdGFuZCB0aGUgcXVlc3Rpb24uIElmIHlvdSBh cmUgZGVwZW5kZW50IG9uIGENCj4gPiByZWN1cnNpdmUgc2VydmVyIHRvIGZldGNoIHRoZSBETlNT RUMgcmVjb3JkcywgdGhlbiB0aGF0IHNlcnZlciBuZWVkcw0KPiA+IHRvIGJlIEROU1NFQyBhd2Fy ZS4gSWYgeW91IGFyZSBvcGVyYXRpbmcgaW4gaXRlcmF0aXZlIG1vZGUgZmV0Y2hpbmcNCj4gaXQN Cj4gPiB5b3Vyc2VsZiwgdGhlbiBpdCBkb2VzIG5vdCB3b3JrIGluIGVudmlyb25tZW50cyB3aGVy ZSBmaXJld2FsbHMNCj4gPiBub3JtYWxseSBwcm9oaWJpdCB0YWxraW5nIHRvIGV4dGVybmFsIG5h bWUgc2VydmVycy4gV2hpY2ggb25lIGFyZSB5b3UNCj4gPiB0YWxraW5nIGFib3V0ID8gV2UgaGFk IGEgbGVuZ3RoeSBkaXNjdXNzaW9uIGFib3V0IHRoZSB2YXJpb3VzIG9wdGlvbnMNCj4gPiBpbiB0 aGUgZG5zc2VjLWRlcGxveW1lbnQgZ3JvdXAgcmVjZW50bHkuDQo+IA0KPiBEb24ndCBiZSBkZXBl bmRlbnQgb24gdGhlIHJlY3Vyc2l2ZSBzZXJ2ZXIuICBKdXN0IGZldGNoIGl0IHRoeXNlbGYNCj4g aXRlcmF0aXZlbHksIHN0YXJ0aW5nIHdpdGggdGhlIHJvb3QsIGFuZCBiZSBkb25lIHdpdGggaXQu DQo+IA0KDQpNYW55IGNvcnBvcmF0ZSBmaXJld2FsbHMgZG8gbm90IHBlcm1pdCB5b3UgdG8gZ28g ZmV0Y2ggc3R1ZmYgeW91cnNlbGYsIGJ1dCBpbnNpc3QgeW91IHVzZSB0aGUgbG9jYWwgcmVzb2x2 ZXJzLiBPZiBjb3Vyc2UsIGNvcnBvcmF0ZSBlbnZpcm9ubWVudHMgcHJvYmFibHkgZG8gbm90IGFw cGx5IGhlcmUgaW4gYW55IGNhc2UuIEJ1dCBJIHRob3VnaHQgSSdkIGp1c3QgbWVudGlvbiB0aGlz LiANCg0KQWtpIFR1b21pDQo= From fanf2@hermes.cam.ac.uk Thu Sep 29 04:01:29 2011 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E810821F8D8A for ; Thu, 29 Sep 2011 04:01:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.584 X-Spam-Level: X-Spam-Status: No, score=-6.584 tagged_above=-999 required=5 tests=[AWL=0.015, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OPEmIwNAC4rP for ; Thu, 29 Sep 2011 04:01:26 -0700 (PDT) Received: from ppsw-52.csi.cam.ac.uk (ppsw-52.csi.cam.ac.uk [131.111.8.152]) by ietfa.amsl.com (Postfix) with ESMTP id DB7F521F8D70 for ; Thu, 29 Sep 2011 04:01:25 -0700 (PDT) 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-2.csi.cam.ac.uk ([131.111.8.54]:45455) by ppsw-52.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.159]:25) with esmtpa (EXTERNAL:fanf2) id 1R9EPV-0008TJ-Fp (Exim 4.72) (return-path ); Thu, 29 Sep 2011 12:04:13 +0100 Received: from fanf2 (helo=localhost) by hermes-2.csi.cam.ac.uk (hermes.cam.ac.uk) with local-esmtp id 1R9EPV-0008QY-Sq (Exim 4.67) (return-path ); Thu, 29 Sep 2011 12:04:13 +0100 Date: Thu, 29 Sep 2011 12:04:13 +0100 From: Tony Finch X-X-Sender: fanf2@hermes-2.csi.cam.ac.uk To: Ted Hardie In-Reply-To: Message-ID: References: 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 Vixie , dnsext@ietf.org Subject: Re: [dnsext] draft-mohan-dns-query-xml-00.txt X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Sep 2011 11:01:30 -0000 Ted Hardie wrote: > > Why not re-use the syntax of RFC4501 for the query? [...] It's also not > clear why you need an XML-based representation, rather than using a > mime-type like that set out in RFC 4027 (which uses detached domain name > information as set out in RFC 2540). Even if those need updating, it's > not clear to me what you're gaining with the use of XML here. I agree with these suggestions and questions. I don't understand the interoperability argument. The software that will be producing and consuming this data is DNS software that already has parsers for binary DNS data, and doesn't have serializers or parsers for XML. Binary data is also much more friendly for mobile endpoints. Interoperability with non-DNS software should be handled by a separate gateway that doesn't put a disgustingly wasteful pessimization in the fast path. Is this draft going to specify how to get the complete DNSSEC validation chain, or is that going to be specified elsewhere? Google Chrome already implements a format for embedding validation chains in X.509 certificates which is binary but sadly does not use standard DNS message format. Tony. -- f.anthony.n.finch http://dotat.at/ Viking: Southerly 4 or 5, occasionally 6 in northeast. Moderate. Mainly fair. Good, occasionally poor. From mohta@necom830.hpcl.titech.ac.jp Thu Sep 29 04:04:28 2011 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B4F2221F8B76 for ; Thu, 29 Sep 2011 04:04:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.04 X-Spam-Level: X-Spam-Status: No, score=-0.04 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WxbKotu4cDOg for ; Thu, 29 Sep 2011 04:04:28 -0700 (PDT) Received: from necom830.hpcl.titech.ac.jp (necom830.hpcl.titech.ac.jp [131.112.32.132]) by ietfa.amsl.com (Postfix) with SMTP id 1556221F8B37 for ; Thu, 29 Sep 2011 04:04:27 -0700 (PDT) Received: (qmail 87262 invoked from network); 29 Sep 2011 11:21:02 -0000 Received: from necom830.hpcl.titech.ac.jp (HELO ?127.0.0.1?) (131.112.32.132) by necom830.hpcl.titech.ac.jp with SMTP; 29 Sep 2011 11:21:02 -0000 Message-ID: <4E84515C.9040300@necom830.hpcl.titech.ac.jp> Date: Thu, 29 Sep 2011 20:07:08 +0900 From: Masataka Ohta User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:6.0.2) Gecko/20110902 Thunderbird/6.0.2 MIME-Version: 1.0 To: dnsext@ietf.org Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit Subject: [dnsext] Using DNS SRV RRs with URLs X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Sep 2011 11:04:28 -0000 I just post draft-ohta-urlsrv-00.txt. Comments are welcome. Masataka Ohta From olaf@NLnetLabs.nl Thu Sep 29 04:44:34 2011 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ABC8B21F8C7B for ; Thu, 29 Sep 2011 04:44:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.733 X-Spam-Level: X-Spam-Status: No, score=-102.733 tagged_above=-999 required=5 tests=[AWL=-0.133, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9VJ+0XzoOcl4 for ; Thu, 29 Sep 2011 04:44:29 -0700 (PDT) Received: from open.nlnetlabs.nl (open.nlnetlabs.nl [IPv6:2001:7b8:206:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 55BE521F899D for ; Thu, 29 Sep 2011 04:44:29 -0700 (PDT) Received: from [IPv6:2001:7b8:206:1:225:bcff:fedd:61d2] ([IPv6:2001:7b8:206:1:225:bcff:fedd:61d2]) (authenticated bits=0) by open.nlnetlabs.nl (8.14.4/8.14.4) with ESMTP id p8TBlDAH098403 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 29 Sep 2011 13:47:14 +0200 (CEST) (envelope-from olaf@NLnetLabs.nl) Mime-Version: 1.0 (Apple Message framework v1244.3) Content-Type: multipart/signed; boundary="Apple-Mail=_1C29081E-99DF-4153-99EB-ECFEFE25824F"; protocol="application/pkcs7-signature"; micalg=sha1 From: Olaf Kolkman In-Reply-To: Date: Thu, 29 Sep 2011 13:47:04 +0200 Message-Id: <50038315-3BF8-4E5F-A03F-942C55EC1FF2@NLnetLabs.nl> References: To: Paul Wouters X-Mailer: Apple Mail (2.1244.3) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (open.nlnetlabs.nl [IPv6:2001:7b8:206:1::1]); Thu, 29 Sep 2011 13:47:14 +0200 (CEST) Cc: Paul Vixie , dnsext@ietf.org Subject: Re: [dnsext] draft-mohan-dns-query-xml-00.txt X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Sep 2011 11:44:34 -0000 --Apple-Mail=_1C29081E-99DF-4153-99EB-ECFEFE25824F Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Sep 28, 2011, at 9:32 PM, Paul Wouters wrote: > You can test running dns over port 80/443 using ounbound and = forwarding it > to open.nlnetlabs.nl Correction: We do not run that resolver on open.nlnetlabs.nl but on = restrigd.nlnetlabs.nl. (All part of early deployment tests of a project that brings DNSSEC to = 127.0.0.1 http://www.nlnetlabs.nl/projects/dnssec-trigger/ )=20 I can see some value in using a method to make sure you multiplex on = port 443 some folk may also want to run other services on the same = machine.=20 --Olaf ________________________________________________________=20 Olaf M. Kolkman NLnet Labs http://www.nlnetlabs.nl/ =20 --Apple-Mail=_1C29081E-99DF-4153-99EB-ECFEFE25824F Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIFMTCCBS0w ggMVoAMCAQICAwn66TANBgkqhkiG9w0BAQUFADB5MRAwDgYDVQQKEwdSb290IENBMR4wHAYDVQQL ExVodHRwOi8vd3d3LmNhY2VydC5vcmcxIjAgBgNVBAMTGUNBIENlcnQgU2lnbmluZyBBdXRob3Jp dHkxITAfBgkqhkiG9w0BCQEWEnN1cHBvcnRAY2FjZXJ0Lm9yZzAeFw0xMTAzMjMxNTIzNTlaFw0x MzAzMjIxNTIzNTlaMDkxFTATBgNVBAMTDE9sYWYgS29sa21hbjEgMB4GCSqGSIb3DQEJARYRb2xh ZkBubG5ldGxhYnMubmwwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCtxtZNngmuLgcf rto+Uax1WhonECqb5W8US2Z+ZPw/ASKsjKEF8Wa3Nnispys6Gj9Sl7C1X0/2pH//qauLpBqA+lHW L9mgdGW1T9KU1Fb8Odqw0PBnIIhbLNQzecZL+BchEetcrubplQWzDOpROCJ00IwXksusBiKqhew4 u7X2QoraW+z32Knj5ogajIhdkAeBHUy1pwXsk/mDnV8cIEdz1MhaZWDSn7kJUQtRMVCpFBjVoiXh ToXMJfiMvn0CKaeFxFm72dcdzvFsw906Ndafd2MOfdP7QSsTVP6sG9am790AOgkzxT5CM77IDPbD zxZlQ8jTdhcp/WtUrFWIU4QBAgMBAAGjgf0wgfowDAYDVR0TAQH/BAIwADBWBglghkgBhvhCAQ0E SRZHVG8gZ2V0IHlvdXIgb3duIGNlcnRpZmljYXRlIGZvciBGUkVFIGhlYWQgb3ZlciB0byBodHRw Oi8vd3d3LkNBY2VydC5vcmcwQAYDVR0lBDkwNwYIKwYBBQUHAwQGCCsGAQUFBwMCBgorBgEEAYI3 CgMEBgorBgEEAYI3CgMDBglghkgBhvhCBAEwMgYIKwYBBQUHAQEEJjAkMCIGCCsGAQUFBzABhhZo dHRwOi8vb2NzcC5jYWNlcnQub3JnMBwGA1UdEQQVMBOBEW9sYWZAbmxuZXRsYWJzLm5sMA0GCSqG SIb3DQEBBQUAA4ICAQDKn+TpSrPQr3M8c8F2GGx3BgUnJUN7BBdUI7edGLqLrCBDYLIQSeC/uvLJ gXt80tfIEGXENNbjb2lrAyrzdounfwTD5GsXqESDXJfCMYiZxVCDmZ71ncXWw9tCW8EmibhmPAeS fL2yYoGlTOdl48mlZfb0oEB7KeFrjjkP18XbgKsZRhUAmGSBFufJbCxO/LN+F9jCIDOPWM4A6+v3 gjHWc23uW6ZHOqJouviAXkzRJhLSOBSHyOMtgcuGoqoNStzKw3X/FvKXyLF7+Ij5Fss7Gfh0Yiwb rdP9AcZJL8ZWPw6StTJwSJHuly4co//NIozcFcGQ+qY8iUnDU6Y2YjQZ5iFQ3k7HELCknEJF48Ww r18NO5l+Wv6Za5UjJJxI2J8l7f1vE7Pa0/Q0o2m5/TeWhbS3Y1U+jfdXmHIwfcxggzqwerNQ9Pm5 uiwRxwElUPfNVDa30rI+UJ4h/tUJsyPCsbQrcVFt3tqL1tyxcPfkebzGuh6oUTG0VVBLM7wNqG+i nMO1XdqIC1AzNxzq9iOse5YrIK8H++rUdF34vWicvxMMtgzIYGhJwgdRshWs6JL2sRjDCkiUto4b FWixno9yfESzsQ9LmQ/9A8fQyXsIvSdfZ5Ywh/n8j71Za9E/U43dGrMBstldNoBhvKRHv574PAlU JwTq0EP4A0X7e7EqgjGCAzMwggMvAgEBMIGAMHkxEDAOBgNVBAoTB1Jvb3QgQ0ExHjAcBgNVBAsT FWh0dHA6Ly93d3cuY2FjZXJ0Lm9yZzEiMCAGA1UEAxMZQ0EgQ2VydCBTaWduaW5nIEF1dGhvcml0 eTEhMB8GCSqGSIb3DQEJARYSc3VwcG9ydEBjYWNlcnQub3JnAgMJ+ukwCQYFKw4DAhoFAKCCAYcw GAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTEwOTI5MTE0NzA0WjAj BgkqhkiG9w0BCQQxFgQUArwX/mxrq3m/jjUMB18Y0lQ/NyIwgZEGCSsGAQQBgjcQBDGBgzCBgDB5 MRAwDgYDVQQKEwdSb290IENBMR4wHAYDVQQLExVodHRwOi8vd3d3LmNhY2VydC5vcmcxIjAgBgNV BAMTGUNBIENlcnQgU2lnbmluZyBBdXRob3JpdHkxITAfBgkqhkiG9w0BCQEWEnN1cHBvcnRAY2Fj ZXJ0Lm9yZwIDCfrpMIGTBgsqhkiG9w0BCRACCzGBg6CBgDB5MRAwDgYDVQQKEwdSb290IENBMR4w HAYDVQQLExVodHRwOi8vd3d3LmNhY2VydC5vcmcxIjAgBgNVBAMTGUNBIENlcnQgU2lnbmluZyBB dXRob3JpdHkxITAfBgkqhkiG9w0BCQEWEnN1cHBvcnRAY2FjZXJ0Lm9yZwIDCfrpMA0GCSqGSIb3 DQEBAQUABIIBAHY9+sDZXXm0AO7jmsHRsmnGbqw0pySBQlhU8Kk5ysljOwBYH6moJr5s+oxwhrTP LFZMyN6V02+zM2VHxWeGYgipKhGthkBn+wKlr3tus6Qlpen/jliJm3iDXe1gQOAUgfECeD5iLcK5 TV1SWal2Ew/kweSeNzKOXrb7FbnlZXc+YGj9kk1MddlS9lFCyr3nR8+wnAjFPHDEt2SBK+pbsf1F GaxoqQFlB2LpcshUl5r6IKsl1PylekMa+RA483Ghlip7bO9b2gQQw/C77O+TibkqaiYKiaxzl8gI 8iJgzr50AObCOHL7wnaRDxgwf4BAlmTfT6rel+icgWHrEA1GrPoAAAAAAAA= --Apple-Mail=_1C29081E-99DF-4153-99EB-ECFEFE25824F-- From ted.ietf@gmail.com Thu Sep 29 09:28:40 2011 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A4C5E21F8E42 for ; Thu, 29 Sep 2011 09:28:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.208 X-Spam-Level: X-Spam-Status: No, score=-3.208 tagged_above=-999 required=5 tests=[AWL=-0.210, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_35=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OZb9DsCxTBGq for ; Thu, 29 Sep 2011 09:28:39 -0700 (PDT) Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by ietfa.amsl.com (Postfix) with ESMTP id 37AF121F8CBB for ; Thu, 29 Sep 2011 09:28:39 -0700 (PDT) Received: by ywa6 with SMTP id 6so879567ywa.31 for ; Thu, 29 Sep 2011 09:31:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=GuA0nLPLExOD/1UvwGaX9K5OGCGbyzuqDquZZ4iwEJc=; b=hUIenQHVIKfINWod6LnbCwQs7UAoT3KPlVN8zrc0W6XZbSr9ReOmIaLfFoSEnMeFM9 Pu9cXhnBIy1HeYXMtT7p/wcm/ZPREnU7Bz8WRa2nEo74Fsj9zGOk6HgFbRlDJB2dpTQJ MvLIYwsJmpKVsKhIpithXH/MTgGN0TZnHyqR8= MIME-Version: 1.0 Received: by 10.236.191.71 with SMTP id f47mr64997839yhn.125.1317313890553; Thu, 29 Sep 2011 09:31:30 -0700 (PDT) Received: by 10.236.105.169 with HTTP; Thu, 29 Sep 2011 09:31:30 -0700 (PDT) In-Reply-To: References: Date: Thu, 29 Sep 2011 09:31:30 -0700 Message-ID: From: Ted Hardie To: Mohan Parthasarathy Content-Type: multipart/alternative; boundary=20cf303f649681105104ae170a27 Cc: Paul Vixie , dnsext@ietf.org Subject: Re: [dnsext] draft-mohan-dns-query-xml-00.txt X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Sep 2011 16:28:40 -0000 --20cf303f649681105104ae170a27 Content-Type: text/plain; charset=ISO-8859-1 On Wed, Sep 28, 2011 at 2:49 PM, Mohan Parthasarathy wrote: > On Wed, Sep 28, 2011 at 2:06 PM, Ted Hardie wrote: > > Howdy, > > > > I have a few questions on this proposal. > > > > Why not re-use the syntax of RFC4501 for the query? That is: > > > https://relayingwebserver.example.com/query.cgi?dns:[//authority/]domain[?CLASS=class;TYPE=type] > > ? > > > We should definitely study that for the next revision. We need to be > able to specify more than what is given in RFC 4501. Is that > extensible ? > > What kind of extension do you need, the validation bit? It likely is extensible if there is need, provided the existing strings remain valid. At worst, you'd need to mint a new URI. If you go down that road, though, I would suggest simply minting a URI for dns.https, where the authority is the webserver you are querying and the path is the domain[?CLASS=class;Type=Type;CD=1]. That makes https a "transport" for DNS, rather than seeing this as a relayed service. To me, it also suggests you continue to use the DNS binary representations, since the results will get fed to a local DNS subsystem. With either XML or JSON, you're going through a double translation (once on the relaying server and once in the local subsystem pushing it to the DNS), and that seems more likely to introduce error than to get you much benefit. > > Declaring a namespace for the xml is generally good practice. It's also > not > > clear why you need an XML-based representation, rather than using a > > mime-type like that set out in RFC 4027 (which uses detached domain name > > information as set out in RFC 2540). Even if those need updating, it's > not > > clear to me what you're gaining with the use of XML here. > > > > We chose XML because it is readily available and also better > inter-operability. > > As others have noted, XML parsers are common--but the interpretation of the XML in any particular namespace has to develop interoperability on its own. > > It seems like you're wanting this to be used when CD bit is set to 1; any > > reason why you'd want to support this for CD bit set to 0? > > In general, I think a little bit more wording on when this tunneling > would > > be used would be really useful to flesh out when this is needed. > > > Yes, the main use case is DNSSEC. Does it make sense to restrict to just > that ? > > The advantage is really that you can tailor the return data parsers to throw out anything that doesn't include the required DNSSEC bits. As it is, you're going to move from one set of issues (poor caching resolvers) to another: HTTP interception proxies. Those are often not known to the end host and their behavior is, at best, "interesting". Mandating the use of HTTPS will help some, but there is going to be an increased risk of HTTP cache poisoning having an impact on the DNS if you use this--without DNSSEC, that attack vector seems to me personally pretty bad. regards, Ted > > NIT: You cite RFC 2396, but the current reference is RFC 3986 > > > Will fix that. > > thanks > mohan > > > regards, > > > > Ted Hardie > > > > > > On Wed, Sep 28, 2011 at 11:24 AM, Mohan Parthasarathy < > suruti94@gmail.com> > > wrote: > >> > >> Hi, > >> > >> DNSSEC validation is stub resolver is dependent on DNSSEC-aware CPEs, > >> recursive servers etc. Here is a draft that we submitted yesterday to > >> address this problem. > >> > >> http://www.ietf.org/id/draft-mohan-dns-query-xml-00.txt > >> > >> Please send your comments/feedback to the list. > >> > >> thanks > >> -mohan > >> _______________________________________________ > >> dnsext mailing list > >> dnsext@ietf.org > >> https://www.ietf.org/mailman/listinfo/dnsext > > > > > --20cf303f649681105104ae170a27 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Wed, Sep 28, 2011 at 2:49 PM, Mohan Parthasarathy <= suruti94@gmail.com> wro= te:
On Wed, Sep 28, 2011 at 2:06 PM, Ted Hardie <ted.ietf@gmail.com> wrote:
> Howdy,
>
> I have a few questions on this proposal.
>
> Why not re-use the syntax of RFC4501 for the query?=A0 That is:
> https://relayi= ngwebserver.example.com/query.cgi?dns:[//authority/]domain[?CLASS=3Dclass;T= YPE=3Dtype]
> ?
>
We should definitely study that for the next revision. We need to be<= br> able to specify more than what is given in RFC 4501. Is that
extensible ?


What kind of extension do= you need, the validation bit?=A0

It likely is extensible if there = is need, provided the existing strings remain valid.=A0 At worst, you'd= need to mint a new URI.=A0 If you go down that road, though, I would sugge= st simply minting a URI for dns.https, where the authority is the webserver= you are querying and the path is the domain[?CLASS=3Dclass;Type=3DType;CD= =3D1].=A0 That makes https a "transport" for DNS, rather than see= ing this as a relayed service.=A0 To me, it also suggests you continue to u= se the DNS binary representations, since the results will get fed to a loca= l DNS subsystem.=A0 With either XML or JSON, you're going through a dou= ble translation (once on the relaying server and once in the local subsyste= m pushing it to the DNS), and that seems more likely to introduce error tha= n to get you much benefit.


=A0
=
> Declaring a namespace for the xml is generally good practice.=A0 It= 9;s also not
> clear why you need an XML-based representation, rather than using a > mime-type like that set out in RFC 4027 (which uses detached domain na= me
> information as set out in RFC 2540).=A0 Even if those need updating, i= t's not
> clear to me what you're gaining with the use of XML here.
>

We chose XML because it is readily available and also better inter-op= erability.


As others have noted, XML= parsers are common--but the interpretation of the XML in any particular na= mespace has to develop interoperability on its own.
=A0
> It seems like you're wanting this to be used when CD bit is set to= 1; any
> reason why you'd want to support this for CD bit set to 0?
> In general, I think a little bit more wording on when this tunneling w= ould
> be used would be really useful to flesh out when this is needed.
>
Yes, the main use case is DNSSEC. Does it make sense to restrict to j= ust that ?


The advantage is really t= hat you can tailor the return data parsers to throw out anything that doesn= 't include the required DNSSEC bits.=A0 As it is, you're going to m= ove from one set of issues (poor caching resolvers) to another:=A0 HTTP int= erception proxies.=A0 Those are often not known to the end host and their b= ehavior is, at best, "interesting".=A0 Mandating the use of HTTPS= will help some, but there is going to be an increased risk of HTTP cache p= oisoning having an impact on the DNS if you use this--without DNSSEC, that = attack vector seems to me personally pretty bad.

regards,

Ted
=A0
> NIT: You cite RFC 2396, but the current reference is RFC 3986
>
Will fix that.

thanks
mohan

> regards,
>
> Ted Hardie
>
>
> On Wed, Sep 28, 2011 at 11:24 AM, Mohan Parthasarathy <suruti94@gmail.com>
> wrote:
>>
>> Hi,
>>
>> DNSSEC validation is stub resolver is dependent on DNSSEC-aware CP= Es,
>> recursive servers etc. Here is a draft that we submitted yesterday= to
>> address this problem.
>>
>> http://www.ietf.org/id/draft-mohan-dns-query-xml-00.txt=
>>
>> Please send your comments/feedback to the list.
>>
>> thanks
>> -mohan
>> _______________________________________________
>> dnsext mailing list
>> dnsext@ietf.org
>> https://www.ietf.org/mailman/listinfo/dnsext
>
>

--20cf303f649681105104ae170a27-- From suruti94@gmail.com Thu Sep 29 12:54:16 2011 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A06F21F8C73 for ; Thu, 29 Sep 2011 12:54:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Qi05fXHwejHh for ; Thu, 29 Sep 2011 12:54:15 -0700 (PDT) Received: from mail-pz0-f50.google.com (mail-pz0-f50.google.com [209.85.210.50]) by ietfa.amsl.com (Postfix) with ESMTP id 5C46121F8C6F for ; Thu, 29 Sep 2011 12:54:15 -0700 (PDT) Received: by pzk37 with SMTP id 37so2462490pzk.9 for ; Thu, 29 Sep 2011 12:57:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=DXZF220On3CLejJIfMPqTPI4cuDEGvjNI85UwUHK6IE=; b=ntzuQIjPXmHWSjFQX8UozZoi9xnv3Z6lv1acU2tOBxNxj3LGH+Nv7HUd/CwR+UvR1R jB4SsA3jkEXwO7899BSlri6GQTWecByonFN54J5eYFStTIasVtwCl/c+mKZG0pxkzLz8 y9DFKaEkc+SG+xfCediSFKWLAsPdoml7JeLD0= MIME-Version: 1.0 Received: by 10.68.0.167 with SMTP id 7mr40168151pbf.106.1317326226058; Thu, 29 Sep 2011 12:57:06 -0700 (PDT) Received: by 10.68.46.200 with HTTP; Thu, 29 Sep 2011 12:57:05 -0700 (PDT) In-Reply-To: References: Date: Thu, 29 Sep 2011 12:57:05 -0700 Message-ID: From: Mohan Parthasarathy To: Tony Finch Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Paul Vixie , dnsext@ietf.org Subject: Re: [dnsext] draft-mohan-dns-query-xml-00.txt X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Sep 2011 19:54:16 -0000 On Thu, Sep 29, 2011 at 4:04 AM, Tony Finch wrote: > Ted Hardie wrote: >> >> Why not re-use the syntax of RFC4501 for the query? [...] It's also not >> clear why you need an XML-based representation, rather than using a >> mime-type like that set out in RFC 4027 (which uses detached domain name >> information as set out in RFC 2540). =A0Even if those need updating, it'= s >> not clear to me what you're gaining with the use of XML here. > > I agree with these suggestions and questions. > > I don't understand the interoperability argument. The software that will > be producing and consuming this data is DNS software that already has > parsers for binary DNS data, and doesn't have serializers or parsers for > XML. Binary data is also much more friendly for mobile endpoints. > Interoperability with non-DNS software should be handled by a separate > gateway that doesn't put a disgustingly wasteful pessimization in the fas= t > path. > We started with XML and then came JSON and we have the third format for consideration :-) We should just use the right one at the end. DNS soft= ware is going to use a different API to retrieve the HTTP response which hopeful= ly will work fine when it sees a new MIME type. How about if I am using wiresh= ark ? Would XML/JSON make a difference until someone writes a plugin ? How about the server side plugin that wants to encode the response ? Would one be eas= ier over the other. Perhaps, there are other factors. > Is this draft going to specify how to get the complete DNSSEC validation > chain, or is that going to be specified elsewhere? Google Chrome already > implements a format for embedding validation chains in X.509 certificates > which is binary but sadly does not use standard DNS message format. > Very good point. As written, it just encodes a single response. But it should be easy to extend this ask for a "chain" and the server plugin can build a chain (to a known trust anchor that has to be communicated ? ) and return it. We reduce a lot of latency. Is that what you meant ? -mohan > Tony. > -- > f.anthony.n.finch =A0 =A0http://dotat.at/ > Viking: Southerly 4 or 5, occasionally 6 in northeast. Moderate. Mainly f= air. > Good, occasionally poor. > From ietf-namedroppers@m.gmane.org Thu Sep 29 14:02:21 2011 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 39B3F21F8C55 for ; Thu, 29 Sep 2011 14:02:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id skXQLIW4vDds for ; Thu, 29 Sep 2011 14:02:20 -0700 (PDT) Received: from lo.gmane.org (lo.gmane.org [80.91.229.12]) by ietfa.amsl.com (Postfix) with ESMTP id 5AE9021F8C4F for ; Thu, 29 Sep 2011 14:02:20 -0700 (PDT) Received: from list by lo.gmane.org with local (Exim 4.69) (envelope-from ) id 1R9Nn2-0004Xb-9I for dnsext@ietf.org; Thu, 29 Sep 2011 23:05:08 +0200 Received: from chase.mycre.ws ([70.89.251.89]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 29 Sep 2011 23:05:08 +0200 Received: from edmonds by chase.mycre.ws with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 29 Sep 2011 23:05:08 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: dnsext@ietf.org From: Robert Edmonds Date: Thu, 29 Sep 2011 20:55:26 +0000 (UTC) Lines: 49 Message-ID: References: X-Complaints-To: usenet@dough.gmane.org X-Gmane-NNTP-Posting-Host: chase.mycre.ws User-Agent: slrn/pre1.0.0-18 (Linux) Subject: Re: [dnsext] draft-mohan-dns-query-xml-00.txt X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Sep 2011 21:02:21 -0000 On 2011-09-29, Tony Finch wrote: > Ted Hardie wrote: >> >> Why not re-use the syntax of RFC4501 for the query? [...] It's also not >> clear why you need an XML-based representation, rather than using a >> mime-type like that set out in RFC 4027 (which uses detached domain name >> information as set out in RFC 2540). Even if those need updating, it's >> not clear to me what you're gaining with the use of XML here. > > I agree with these suggestions and questions. > > I don't understand the interoperability argument. The software that will > be producing and consuming this data is DNS software that already has > parsers for binary DNS data, and doesn't have serializers or parsers for > XML. Binary data is also much more friendly for mobile endpoints. > Interoperability with non-DNS software should be handled by a separate > gateway that doesn't put a disgustingly wasteful pessimization in the fast > path. hi, i believe this is the first time i've ever posted to an IETF mailing list, but as someone who writes DNS software and, less frequently, HTTP software, i'd like to voice support for this point of view. i don't believe that re-formatting DNS query messages is necessary for transporting DNS over HTTP(S), and in fact any re-formatting is effectively a "fork" of the DNS protocol. i'd much rather see the thinnest possible mapping of DNS onto HTTP. for instance, an average DNS query packet length is around 49 octets. simply hex-encoding the entire query message would not result in an abnormally long URL, e.g.: https://server/dns/00000010000100000000000100000200010000291000000080000000 here i've set the ID field to 0. i suspect that in the majority of uses the ID field could always be set to a fixed value, and this would aid HTTP caching. (speaking of which, you would also want to send a "Cache-Control: max-age" header in the HTTP response with the max-age set to the minimum of all RRset TTL values in the DNS response.) the actual HTTP response payload would simply be a binary wire-format DNS response message, possibly with a leading two byte length field like plain TCP DNS. -- Robert Edmonds edmonds@isc.org From dwessels@verisign.com Thu Sep 29 14:14:58 2011 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 67E0D21F8EB5 for ; Thu, 29 Sep 2011 14:14:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Cd4zdTnMTPke for ; Thu, 29 Sep 2011 14:14:58 -0700 (PDT) Received: from exprod6og109.obsmtp.com (exprod6og109.obsmtp.com [64.18.1.23]) by ietfa.amsl.com (Postfix) with ESMTP id 9296221F8EB2 for ; Thu, 29 Sep 2011 14:14:57 -0700 (PDT) Received: from peregrine.verisign.com ([216.168.239.74]) (using TLSv1) by exprod6ob109.postini.com ([64.18.5.12]) with SMTP ID DSNKToTgd6jGspdtyFXcgY7zj1ibDQIcQzSR@postini.com; Thu, 29 Sep 2011 14:17:50 PDT Received: from dul1wnexcn03.vcorp.ad.vrsn.com (dul1wnexcn03.vcorp.ad.vrsn.com [10.170.12.113]) by peregrine.verisign.com (8.13.6/8.13.4) with ESMTP id p8TLHgd8007245 for ; Thu, 29 Sep 2011 17:17:42 -0400 Received: from mail.labs.vrsn.com ([10.173.152.121]) by dul1wnexcn03.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 29 Sep 2011 17:17:42 -0400 Received: from [10.100.1.9] (unknown [10.100.1.9]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mail.labs.vrsn.com (Postfix) with ESMTP id DA6EC1BC8CA for ; Thu, 29 Sep 2011 17:17:40 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1084) From: "Wessels, Duane" In-Reply-To: Date: Thu, 29 Sep 2011 14:17:31 -0700 Content-Transfer-Encoding: 7bit Message-Id: References: To: dnsext@ietf.org X-Mailer: Apple Mail (2.1084) X-OriginalArrivalTime: 29 Sep 2011 21:17:42.0225 (UTC) FILETIME=[39663410:01CC7EED] Subject: Re: [dnsext] draft-mohan-dns-query-xml-00.txt X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Sep 2011 21:14:58 -0000 On Sep 29, 2011, at 1:55 PM, Robert Edmonds wrote: > (speaking of which, you would also want to send a > "Cache-Control: max-age" header in the HTTP response with the max-age > set to the minimum of all RRset TTL values in the DNS response.) I'd prefer to not attempt mixing HTTP caching and DNS caching in the first version of this new beast. I'd rather see 'no-cache' from the server until it has been deployed for a few years and we can make informed statements about how the two will interact. For example, probably every HTTP caching proxy written gives admins the ability to ignore or change cache-control directives. HTTP caching is much more complex than DNS caching. Duane W. From jakob@kirei.se Thu Sep 29 14:18:48 2011 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5CC3B21F8EC5 for ; Thu, 29 Sep 2011 14:18:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.647 X-Spam-Level: X-Spam-Status: No, score=-0.647 tagged_above=-999 required=5 tests=[AWL=0.051, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_EQ_SE=0.35, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gCVbXOyJ7V1Q for ; Thu, 29 Sep 2011 14:18:47 -0700 (PDT) Received: from spg.kirei.se (spg.kirei.se [IPv6:2001:67c:394:15::9]) by ietfa.amsl.com (Postfix) with ESMTP id BD85621F8EB1 for ; Thu, 29 Sep 2011 14:18:46 -0700 (PDT) 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=VeXw0/9lXBrBw0CvlK6qWwC0RmwDkSYv0YNgG6HPwr8=; b=nKQWyudRIWdffPUWH48p3vi9cuFV4o1MuB9bOvOY/Qpxc/rPvLfVJ/xRGixi7LE3EyKGcBnMoMKX3 oJJoKjXpKjKj9iYlbhoOgb2Xw45AqDZTF8g1nLnaN3tNmc6S6EaA3uCZTbAEkkQWDMsMuBY0xKiirK cEN/+qNbw1Tz/h5c= Received: from mail.kirei.se (unknown [91.206.174.10]) by spg-relay.kirei.se (Halon Mail Gateway) with ESMTPS; Thu, 29 Sep 2011 23:21:35 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1244.3) Content-Type: text/plain; charset=us-ascii From: Jakob Schlyter In-Reply-To: Date: Thu, 29 Sep 2011 23:21:34 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <0394FB3B-6C2B-4D47-B1FA-AA54B7EB1053@kirei.se> References: To: Mohan Parthasarathy X-Mailer: Apple Mail (2.1244.3) Cc: Paul Vixie , dnsext@ietf.org Subject: Re: [dnsext] draft-mohan-dns-query-xml-00.txt X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Sep 2011 21:18:48 -0000 On 28 sep 2011, at 20:24, Mohan Parthasarathy wrote: > DNSSEC validation is stub resolver is dependent on DNSSEC-aware CPEs, > recursive servers etc. Here is a draft that we submitted yesterday to > address this problem. First, let me say I think this an interesting proposal and I'm looking = following this work. I would prefer a RESTful API where the response data format is dependent = on the HTTP accept headers. Using such an API, one could receive various = formats, e.g., XML, JSON or plain old DNS wire format. A DNS client in = Javascript would probably like JSON, a libresolv-like DNS library would = like wire format and someone else (although I fail to see who) might = prefer XML. Regarding the XML format (if one is used), I agree with Ted Hardie on = the namespace issue, and like to add a request for some XML schema = definition (xsd, relax ng, relax ng compact, ...). Also, I second the request for a DNSSEC chain mode. jakob From paf@cisco.com Fri Sep 30 00:12:25 2011 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DA0DA21F8B6B for ; Fri, 30 Sep 2011 00:12:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.288 X-Spam-Level: X-Spam-Status: No, score=-2.288 tagged_above=-999 required=5 tests=[AWL=0.011, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w130o9PBczcc for ; Fri, 30 Sep 2011 00:12:24 -0700 (PDT) Received: from mtv-iport-4.cisco.com (mtv-iport-4.cisco.com [173.36.130.15]) by ietfa.amsl.com (Postfix) with ESMTP id E107621F8B66 for ; Fri, 30 Sep 2011 00:12:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=paf@cisco.com; l=661; q=dns/txt; s=iport; t=1317366917; x=1318576517; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=1iJVvApUBNvCRTwp9aiVbdh6a8e9rJSSsqXu07qTkMM=; b=fMOldQ0LngZCr2Al4jA4tm5Gucd8VnGMpHFiyo78ws8NUEEjgvbV0AQ/ sJOgK4ooVGueqUSXP/MweTiKFKSjOouD7utUQUgG6CU60YrpCCodoSnZf dZzDcbDbstHeaNnV294dgZiZAyOUO7ry6VtVSc0ub1UJ/o+hvVVF3QJQY U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EACdrhU6rRDoG/2dsb2JhbABBqB53gVMBAQEBAgESASc/BQsLRlcGNYdYmXYBniqGPWEEh2+La5E+ X-IronPort-AV: E=Sophos;i="4.68,465,1312156800"; d="scan'208";a="5165815" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by mtv-iport-4.cisco.com with ESMTP; 30 Sep 2011 07:15:17 +0000 Received: from sjc-vpn5-1614.cisco.com (sjc-vpn5-1614.cisco.com [10.21.94.78]) by mtv-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id p8U7EApx015193; Fri, 30 Sep 2011 07:15:15 GMT Mime-Version: 1.0 (Apple Message framework v1244.3) Content-Type: text/plain; charset=us-ascii From: =?iso-8859-1?Q?Patrik_F=E4ltstr=F6m?= In-Reply-To: <0394FB3B-6C2B-4D47-B1FA-AA54B7EB1053@kirei.se> Date: Fri, 30 Sep 2011 09:36:11 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: References: <0394FB3B-6C2B-4D47-B1FA-AA54B7EB1053@kirei.se> To: Jakob Schlyter X-Mailer: Apple Mail (2.1244.3) Cc: Paul Vixie , dnsext@ietf.org Subject: Re: [dnsext] draft-mohan-dns-query-xml-00.txt X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Sep 2011 07:12:25 -0000 On 30 sep 2011, at 00:21, Jakob Schlyter wrote: > I would prefer a RESTful API where the response data format is = dependent on the HTTP accept headers. Using such an API, one could = receive various formats, e.g., XML, JSON or plain old DNS wire format. A = DNS client in Javascript would probably like JSON, a libresolv-like DNS = library would like wire format and someone else (although I fail to see = who) might prefer XML. +10000000 My claim/feelings/religious view is that JSON is so much better than XML = when coming to the kind of usage we talk about. So if _one_ format is to be used, please choose JSON and not XML. Patrik From Ed.Lewis@neustar.biz Fri Sep 30 07:10:49 2011 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8E1E621F8B4C for ; Fri, 30 Sep 2011 07:10:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.433 X-Spam-Level: X-Spam-Status: No, score=-105.433 tagged_above=-999 required=5 tests=[AWL=-0.693, BAYES_20=-0.74, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oNzO59bVP6OW for ; Fri, 30 Sep 2011 07:10:49 -0700 (PDT) Received: from stora.ogud.com (stora.ogud.com [66.92.146.20]) by ietfa.amsl.com (Postfix) with ESMTP id C28E321F8B4B for ; Fri, 30 Sep 2011 07:10:48 -0700 (PDT) Received: from gdun-e4300.cis.neustar.com (nyttbox.md.ogud.com [10.20.30.4]) by stora.ogud.com (8.14.4/8.14.4) with ESMTP id p8UEDext005412; Fri, 30 Sep 2011 10:13:41 -0400 (EDT) (envelope-from Ed.Lewis@neustar.biz) Received: from [192.168.128.252] by gdun-e4300.cis.neustar.com (PGP Universal service); Fri, 30 Sep 2011 10:13:41 -0400 X-PGP-Universal: processed; by gdun-e4300.cis.neustar.com on Fri, 30 Sep 2011 10:13:41 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: References: <4e4a5da0.410dcc0a.0f19.6b20SMTPIN_ADDED@mx.google.com> <86AD8857-3E07-4A01-8AB0-02E832270C21@gmail.com> <20110816224930.GC14894@vacation.karoshi.com.> <6D7DCFB3-FD79-456C-ADE6-18966EBBF52E@virtualized.org> <20110818033644.GF19852@vacation.karoshi.com.> <0B4CF9B3-F42F-4E26-8087-B85C9E6B68F4@virtualized.org> <20110818112522.GB22163@vacation.karoshi.com.> Date: Fri, 30 Sep 2011 10:13:37 -0400 To: From: Edward Lewis Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.71 on 10.20.30.4 Cc: ed.lewis@neustar.biz Subject: Re: [dnsext] A6 to Historic X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Sep 2011 14:10:49 -0000 >I'm trying to understand if there is a valid reason to keep A6 as >experimental or whether it should the experiment be declared over by moving >A6 to historic. I doing some research I came across this link, which is interesting reading. The late Itojun raises a lot of good questions. http://tools.ietf.org/html/draft-ietf-dnsext-aaaa-a6-01 Too bad that such documents were never published in a stable format. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis NeuStar You can leave a voice message at +1-571-434-5468 Vote for the word of the day: "Papa"razzi - father that constantly takes photos of the baby Corpureaucracy - The institution of corporate "red tape" From denghui02@hotmail.com Fri Sep 30 08:26:25 2011 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6881321F8C49; Fri, 30 Sep 2011 08:26:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.148 X-Spam-Level: X-Spam-Status: No, score=-100.148 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_CHARSET_FARAWAY=2.45, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ozse7vX1UZyG; Fri, 30 Sep 2011 08:26:24 -0700 (PDT) Received: from col0-omc2-s3.col0.hotmail.com (col0-omc2-s3.col0.hotmail.com [65.55.34.77]) by ietfa.amsl.com (Postfix) with ESMTP id 7F10721F8BDB; Fri, 30 Sep 2011 08:26:24 -0700 (PDT) Received: from COL118-W55 ([65.55.34.73]) by col0-omc2-s3.col0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 30 Sep 2011 08:29:18 -0700 Message-ID: Content-Type: multipart/alternative; boundary="_bcee45fa-b601-421d-9227-642c3b85b5f8_" X-Originating-IP: [117.136.0.1] From: Hui Deng To: , , , Date: Fri, 30 Sep 2011 23:29:18 +0800 Importance: Normal MIME-Version: 1.0 X-OriginalArrivalTime: 30 Sep 2011 15:29:18.0255 (UTC) FILETIME=[B81343F0:01CC7F85] X-Mailman-Approved-At: Fri, 30 Sep 2011 08:42:31 -0700 Cc: pk@isoc.de, Lemon Ted , john_brzozowski@cable.comcast.com, ogud@ogud.com Subject: [dnsext] 2nd Last Call for MIF DNS server selection document X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Sep 2011 15:26:25 -0000 --_bcee45fa-b601-421d-9227-642c3b85b5f8_ Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: 8bit Dear all Based on 1st round WG LC, the authors have received significant advice about revision and submited a new version accordingly: http://www.ietf.org/internet-drafts/draft-ietf-mif-dns-server-selection-05.txt And we plan to issue a second round WG LC, and cc to DHCWG, DNSEXT, DNSOP related working groups, please DNSEXT/DNSOP chairs help to forward to the MLs since I may not subscribe to them. This is a 2 weeks with little extension LC, it will finish on October 17, Please send substantive review and editorial comments to mif@ietf.org Thanks a lot for youre view Best regards, Margaret and Hui Below are Teemu's writeup about the revision: I uploaded -05 update so that next comments would take into account changes I already did based on discussions with Murray (as was copied to this list). The biggest clarifications related to how DNS queries are sent to different servers and when all servers are waited for answers (if reply is not validated) and when not. I.e. this text: -- A node SHALL send requests to DNS servers in the order defined by the priority list until an acceptable reply is received, all replies are received, or a time out occurs. In the case of a requested name matching to a specific domain or network rule accepted from any interface, a DNSSEC-aware resolver MUST NOT proceed with a reply that cannot be validated using DNSSEC until all DNS servers on the priority list have been contacted or timed out. This protects against possible redirection attacks. In the case of the requested name not matching to any specific domain or network, first received response from any DNS server MAY be considered acceptable. A DNSSEC- aware node MAY always contact all DNS server in an attempt to receive a response that can be validated, but contacting all DNS servers is not mandated for the default case as in some deployments that would consume excess resources. -- Teemu > -----Original Message----- > From: mif-bounces@ietf.org [mailto:mif-bounces@ietf.org] On Behalf Of > ext internet-drafts@ietf.org > Sent: 20. syyskuuta 2011 22:10 > To: i-d-announce@ietf.org > Cc: mif@ietf.org > Subject: [mif] I-D Action: draft-ietf-mif-dns-server-selection-05.txt - 显示引用文字 - > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the Multiple Interfaces Working Group of the > IETF. > > Title : Improved DNS Server Selection for Multi-Interfaced > Nodes > Author(s) : Teemu Savolainen > Jun-ya Kato > Ted Lemon > Filename : draft-ietf-mif-dns-server-selection-05.txt > Pages : 26 > Date : 2011-09-20 > > A multi-interfaced node is connected to multiple networks, some of > which may be utilizing private DNS namespaces. A node commonly > receives DNS server configuration information from all connected > networks. Some of the DNS servers may have information about > namespaces other servers do not have. When a multi-interfaced node > needs to utilize DNS, the node has to choose which of the servers to > contact to. This document describes DHCPv4 and DHCPv6 option that > can be used to configure nodes with information required to perform > informed DNS server selection decisions. > > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-mif-dns-server-selection-05.txt --_bcee45fa-b601-421d-9227-642c3b85b5f8_ Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: 8bit
Dear all
 
Based on 1st round WG LC, the authors have received significant advice about revision and submited a new version accordingly:
http://www.ietf.org/internet-drafts/draft-ietf-mif-dns-server-selection-05.txt
 
And we plan to issue a second round WG LC, and cc to DHCWG, DNSEXT, DNSOP related working groups, please DNSEXT/DNSOP chairs help to forward to the MLs since I may not subscribe to them.
 
This is a 2 weeks with little extension LC, it will finish on October 17,
Please send substantive review and editorial comments to mif@ietf.org
 
Thanks a lot for youre view
Best regards,
 
Margaret and Hui
 
 
 
Below are Teemu's writeup about the revision:
 
I uploaded -05 update so that next comments would take into account changes
I already did based on discussions with Murray (as was copied to this list).
The biggest clarifications related to how DNS queries are sent to different
servers and when all servers are waited for answers (if reply is not
validated) and when not. I.e. this text:
--
  A node SHALL send requests to DNS servers in the order defined by the
  priority list until an acceptable reply is received, all replies are
  received, or a time out occurs.  In the case of a requested name
  matching to a specific domain or network rule accepted from any
  interface, a DNSSEC-aware resolver MUST NOT proceed with a reply that
  cannot be validated using DNSSEC until all DNS servers on the
  priority list have been contacted or timed out.  This protects
  against possible redirection attacks.  In the case of the requested
  name not matching to any specific domain or network, first received
  response from any DNS server MAY be considered acceptable.  A DNSSEC-
  aware node MAY always contact all DNS server in an attempt to receive
  a response that can be validated, but contacting all DNS servers is
  not mandated for the default case as in some deployments that would
  consume excess resources.
--
       Teemu
> -----Original Message-----
> From: mif-bounces@ietf.org [mailto:mif-bounces@ietf.org] On Behalf Of
> ext internet-drafts@ietf.org
> Sent: 20. syyskuuta 2011 22:10
> To: i-d-announce@ietf.org
> Cc: mif@ietf.org
> Subject: [mif] I-D Action: draft-ietf-mif-dns-server-selection-05.txt
- 显示引用文字 -
>
> A New Internet-Draft is available from the on-line Internet-Drafts
directories.
> This draft is a work item of the Multiple Interfaces Working Group of the
> IETF.
>
>       Title           : Improved DNS Server Selection for Multi-Interfaced
> Nodes
>       Author(s)       : Teemu Savolainen
>                           Jun-ya Kato
>                           Ted Lemon
>       Filename        : draft-ietf-mif-dns-server-selection-0 5.txt
>       Pages           : 26
>       Date            : 2011-09-20
>
>    A multi-interfaced node is connected to multiple networks, some of
>    which may be utilizing private DNS namespaces.  A node commonly
>    receives DNS server configuration information from all connected
>    networks.  Some of the DNS servers may have information about
>    namespaces other servers do not have.  When a multi-interfaced node
>    needs to utilize DNS, the node has to choose which of the servers to
>    contact to.  This document describes DHCPv4 and DHCPv6 option that
>    can be used to configure nodes with inform ation required to perform
>    informed DNS server selection decisions.
>
>
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-ietf-mif-dns-server-selection-05.txt

--_bcee45fa-b601-421d-9227-642c3b85b5f8_--