From vixie@isc.org Fri Sep 30 21:55: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 C007B21F85F7 for ; Fri, 30 Sep 2011 21:55:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.45 X-Spam-Level: X-Spam-Status: No, score=-2.45 tagged_above=-999 required=5 tests=[AWL=0.150, 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 B-Jjbg8efTlw for ; Fri, 30 Sep 2011 21:55:40 -0700 (PDT) Received: from ss.vix.com (ss.vix.com [IPv6:2001:559:8000:cb::2]) by ietfa.amsl.com (Postfix) with ESMTP id 4E40921F85F2 for ; Fri, 30 Sep 2011 21:55:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at redbarn.org Received: from ww.vix.com (ww.vix.com [IPv6:2001:559:8000:cb:215:17ff:fed4:730a]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by ss.vix.com (Postfix) with ESMTPS id 49A2FEE515 for ; Sat, 1 Oct 2011 04:58:27 +0000 (UTC) (envelope-from vixie@isc.org) From: Paul Vixie Organization: Internet Systems Consortium To: dnsext@ietf.org Date: Sat, 1 Oct 2011 04:58:26 +0000 User-Agent: KMail/1.13.5 (FreeBSD/8.1-RELEASE; KDE/4.4.5; amd64; ; ) References: <0394FB3B-6C2B-4D47-B1FA-AA54B7EB1053@kirei.se> In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Message-Id: <201110010458.26859.vixie@isc.org> X-Mailman-Approved-At: Sat, 01 Oct 2011 07:42:45 -0700 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: Sat, 01 Oct 2011 04:55:40 -0000 Checking back in on this discussion after several days of watching it run. On Friday, September 30, 2011 06:36:11 am Patrik F=E4ltstr=F6m wrote: > 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. >=20 > My claim/feelings/religious view is that JSON is so much better than XML > when coming to the kind of usage we talk about. >=20 > So if _one_ format is to be used, please choose JSON and not XML. I like the binary format first proposed here by Edmonds. I'm not as sure=20 about Jakob's "use the accept headers to determine the format" idea since t= he=20 only reason I wanted a printable format was so I could debug with "telnet".= =20 All clients, even those written in javascript, already know how to handle=20 "plain old DNS wire format". I truly do only expect this transport to be u= sed=20 when the normal UDP/53 and TCP/53 paths are middlebox-corrupted. Assuming that Mohan agrees with me on "just use wire format" in the respons= e,=20 my observation is, we should not be using GET at all, nor should we be=20 encoding the query into the URI. We should use POST and our request body=20 should be in DNS wire format. This would defeat web caches but I think tha= t's=20 fine since I worry about web caches that don't understand DNS TTL and I wor= ry=20 even more about web caches that are intercepting rather than explicit. POS= T=20 is presumed by web caches to be unique data to which a unique response will= be=20 needed. A side benefit of this is, the UPDATE opcode gets easy. =46eel free to respond 1x1, I would summarize. Paul From colm@allcosts.net Sat Oct 1 07:53: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 62C8421F97B3 for ; Sat, 1 Oct 2011 07:53:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.677 X-Spam-Level: X-Spam-Status: No, score=-2.677 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, 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 fHWB-nYXYleA for ; Sat, 1 Oct 2011 07:53:49 -0700 (PDT) Received: from mail-qw0-f44.google.com (mail-qw0-f44.google.com [209.85.216.44]) by ietfa.amsl.com (Postfix) with ESMTP id C94BE21F97B2 for ; Sat, 1 Oct 2011 07:53:49 -0700 (PDT) Received: by qadb12 with SMTP id b12so1149513qad.31 for ; Sat, 01 Oct 2011 07:56:46 -0700 (PDT) MIME-Version: 1.0 Received: by 10.224.185.205 with SMTP id cp13mr6259459qab.221.1317481006298; Sat, 01 Oct 2011 07:56:46 -0700 (PDT) Received: by 10.224.89.2 with HTTP; Sat, 1 Oct 2011 07:56:45 -0700 (PDT) In-Reply-To: References: Date: Sat, 1 Oct 2011 10:56:45 -0400 Message-ID: From: =?ISO-8859-1?Q?Colm_MacC=E1rthaigh?= To: Robert Edmonds Content-Type: text/plain; charset=ISO-8859-1 Cc: 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: Sat, 01 Oct 2011 14:53:50 -0000 On Thu, Sep 29, 2011 at 4:55 PM, Robert Edmonds wrote: > 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. "Content-Length:" or a chunked encoding should take care of this. -- Colm From nweaver@icsi.berkeley.edu Sat Oct 1 07:58: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 52F3721F95CF for ; Sat, 1 Oct 2011 07:58:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.499 X-Spam-Level: X-Spam-Status: No, score=-2.499 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ogX-2CBI1AWh for ; Sat, 1 Oct 2011 07:58:34 -0700 (PDT) Received: from rock.ICSI.Berkeley.EDU (rock.ICSI.Berkeley.EDU [192.150.186.19]) by ietfa.amsl.com (Postfix) with ESMTP id CB92621F95CD for ; Sat, 1 Oct 2011 07:58:34 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by rock.ICSI.Berkeley.EDU (Postfix) with ESMTP id E0A412C4016; Sat, 1 Oct 2011 08:01:31 -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 wz4hEIYjbbyx; Sat, 1 Oct 2011 08:01:31 -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 707172C4002; Sat, 1 Oct 2011 08:01:31 -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: <201110010458.26859.vixie@isc.org> Date: Sat, 1 Oct 2011 08:01:33 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <0394FB3B-6C2B-4D47-B1FA-AA54B7EB1053@kirei.se> <201110010458.26859.vixie@isc.org> To: Paul Vixie X-Mailer: Apple Mail (2.1244.3) Cc: 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: Sat, 01 Oct 2011 14:58:35 -0000 On Sep 30, 2011, at 9:58 PM, Paul Vixie wrote: > I like the binary format first proposed here by Edmonds. I'm not as = sure=20 > about Jakob's "use the accept headers to determine the format" idea = since the=20 > only reason I wanted a printable format was so I could debug with = "telnet". =20 > All clients, even those written in javascript, already know how to = handle=20 > "plain old DNS wire format". I truly do only expect this transport to = be used=20 > when the normal UDP/53 and TCP/53 paths are middlebox-corrupted. >=20 > Assuming that Mohan agrees with me on "just use wire format" in the = response,=20 > my observation is, we should not be using GET at all, nor should we be=20= > encoding the query into the URI. We should use POST and our request = body=20 > should be in DNS wire format. This would defeat web caches but I = think that's=20 > fine since I worry about web caches that don't understand DNS TTL and = I worry=20 > even more about web caches that are intercepting rather than explicit. = POST=20 > is presumed by web caches to be unique data to which a unique response = will be=20 > needed. >=20 > A side benefit of this is, the UPDATE opcode gets easy. >=20 > Feel free to respond 1x1, I would summarize. Use GET, but if you want it to get through the most busted of web = caches, do the following: In the fetch, include cache-busters in the URL: rather than things that = translate to get http://dns_server/name/rtype use things like get = http;//dns_server/name/rtype/NONCE Web caches don't work. In our experience, nearly 50% of those in = Netalyzr tests cache things they shouldn't, so if the worry is = cache-staleness, include a cache-buster. But you don't need to use POST = to get through the bustedness if the URLs can have nonces in them. And I'd have the return value be JSON rather than raw DNS on the wire. = Why? Because since the point is validating DNSSEC, the HTTP-server should not = just return the record asked for, but the whole signature chain that it = has. Since this is more information than a normal DNS reply, it might = benefit from a new encoding. And if you are going to do a new encording, JSON is the way to go: it = is FAR far easier to parse than any specialized format. The other alternative is to say its "OK to put the whole signature chain = in the additional field", in which case this would be DNS wire format, = but that might be a good policy for ALL resolvers to support: why = shouldn't a DNSSEC aware resolver provide the whole signature chain that = it has in a reply? From colm@allcosts.net Sat Oct 1 08:00: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 997E521F961F for ; Sat, 1 Oct 2011 08:00:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.677 X-Spam-Level: X-Spam-Status: No, score=-2.677 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, 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 5faNO1MBOIQX for ; Sat, 1 Oct 2011 08:00:37 -0700 (PDT) Received: from mail-qw0-f44.google.com (mail-qw0-f44.google.com [209.85.216.44]) by ietfa.amsl.com (Postfix) with ESMTP id 1356D21F95FD for ; Sat, 1 Oct 2011 08:00:37 -0700 (PDT) Received: by qadb12 with SMTP id b12so1151692qad.31 for ; Sat, 01 Oct 2011 08:03:33 -0700 (PDT) MIME-Version: 1.0 Received: by 10.224.217.73 with SMTP id hl9mr10275072qab.121.1317481413797; Sat, 01 Oct 2011 08:03:33 -0700 (PDT) Received: by 10.224.89.2 with HTTP; Sat, 1 Oct 2011 08:03:33 -0700 (PDT) In-Reply-To: <201110010458.26859.vixie@isc.org> References: <0394FB3B-6C2B-4D47-B1FA-AA54B7EB1053@kirei.se> <201110010458.26859.vixie@isc.org> Date: Sat, 1 Oct 2011 11:03:33 -0400 Message-ID: From: =?ISO-8859-1?Q?Colm_MacC=E1rthaigh?= To: dnsext@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable 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: Sat, 01 Oct 2011 15:00:37 -0000 On Sat, Oct 1, 2011 at 12:58 AM, Paul Vixie wrote: > I like the binary format first proposed here by Edmonds. =A0I'm not as su= re > about Jakob's "use the accept headers to determine the format" idea since= the > only reason I wanted a printable format was so I could debug with "telnet= ". > All clients, even those written in javascript, already know how to handle > "plain old DNS wire format". =A0I truly do only expect this transport to = be used > when the normal UDP/53 and TCP/53 paths are middlebox-corrupted. Printable formats for DNS payloads are also lossy and sacrifice monotonicity. If a binary response is turned into, say, json and then back again - the original points of label compression may be not be the same. Since not all implementations compress equivalently, it's a minor loss of information - probably only relevant to fingerprinting, but still a loss. --=20 Colm From paul.hoffman@vpnc.org Sat Oct 1 08:22:38 2011 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0A00A21F9206 for ; Sat, 1 Oct 2011 08:22:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.57 X-Spam-Level: X-Spam-Status: No, score=-102.57 tagged_above=-999 required=5 tests=[AWL=0.029, 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 gwH--IKwUHSK for ; Sat, 1 Oct 2011 08:22:37 -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 797AE21F9200 for ; Sat, 1 Oct 2011 08:22:37 -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 p91FPXGD054842 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sat, 1 Oct 2011 08:25:33 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 (Apple Message framework v1244.3) Content-Type: text/plain; charset=us-ascii From: Paul Hoffman In-Reply-To: Date: Sat, 1 Oct 2011 08:25:33 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <5C4E07BC-E6CC-45A6-8018-10C2A799A55E@vpnc.org> References: <0394FB3B-6C2B-4D47-B1FA-AA54B7EB1053@kirei.se> <201110010458.26859.vixie@isc.org> To: Nicholas Weaver X-Mailer: Apple Mail (2.1244.3) Cc: DNSEXT Working Group 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: Sat, 01 Oct 2011 15:22:38 -0000 On Oct 1, 2011, at 8:01 AM, Nicholas Weaver wrote: > Web caches don't work. =20 +1. > In our experience, nearly 50% of those in Netalyzr tests cache things = they shouldn't, so if the worry is cache-staleness, include a = cache-buster. -.5. You are assuming that a bad HTTP cache will be bad in a predictable = fashion. I'm not against using nonces to bust caches, but I don't think = we should rely on it. > But you don't need to use POST to get through the bustedness if the = URLs can have nonces in them. True, but is there really any disadvantage to using POST in the design? My sense is that we will get less HTTP caching with POST than we would = with GET-with-nonce, but I have no data to back that up. --Paul Hoffman From paul@xelerance.com Sat Oct 1 10:30:45 2011 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4099121F8FB0 for ; Sat, 1 Oct 2011 10:30:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.444 X-Spam-Level: X-Spam-Status: No, score=-4.444 tagged_above=-999 required=5 tests=[AWL=-1.845, 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 RzFPFcMnduv5 for ; Sat, 1 Oct 2011 10:30:44 -0700 (PDT) Received: from mx.xelerance.com (mx.xelerance.com [193.110.157.188]) by ietfa.amsl.com (Postfix) with ESMTP id 252BB21F8FA8 for ; Sat, 1 Oct 2011 10:30:44 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mx.xelerance.com (Postfix) with ESMTP id 4184463; Sat, 1 Oct 2011 13:33:37 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=xelerance.com; h= content-type:content-type:mime-version:user-agent:references :message-id:in-reply-to:subject:subject:from:from:date:date :received:received:received:received; s=smtp; t=1317490416; x= 1318095216; bh=IEaNPLH06p/4VZUpGZyVOHO5z8Nem4MjiH0YxkQExsQ=; b=Z YTdeRbuy0jP+/qB0iUfiOtGZNN8BGDGaBkr7UNoc4L/OGcxhE7iVRTf+2nrXqer1 ONK9jlSftPwj7MvqPYgh6sUKUrSUDfhbmGE+Q+eZZMTtPGv2Nhou5dh5hU6xFJic X4MZe0jNFewtj1xzvsPYIY6PcwLhSBLqAiiToXvbwE= Received: from mx.xelerance.com ([127.0.0.1]) by localhost (mx.xelerance.com [127.0.0.1]) (amavisd-new, port 10026) with LMTP id 8Q9bKPA0Gq4g; Sat, 1 Oct 2011 13:33:36 -0400 (EDT) Received: from mail.xelerance.com (mail.xelerance.com [193.110.157.189]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.xelerance.com (Postfix) with ESMTPS id D5DEB2C; Sat, 1 Oct 2011 13:33:35 -0400 (EDT) Received: by mail.xelerance.com (Postfix, from userid 1001) id B5F9D19DE; Sat, 1 Oct 2011 13:33:29 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.xelerance.com (Postfix) with ESMTP id AFFBF19D9; Sat, 1 Oct 2011 13:33:29 -0400 (EDT) Date: Sat, 1 Oct 2011 13:33:29 -0400 (EDT) From: Paul Wouters To: Paul Vixie In-Reply-To: <201110010458.26859.vixie@isc.org> Message-ID: References: <0394FB3B-6C2B-4D47-B1FA-AA54B7EB1053@kirei.se> <201110010458.26859.vixie@isc.org> User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: 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: Sat, 01 Oct 2011 17:30:45 -0000 On Sat, 1 Oct 2011, Paul Vixie wrote: > "plain old DNS wire format". I truly do only expect this transport to be used > when the normal UDP/53 and TCP/53 paths are middlebox-corrupted. I am not sure people agree on the user cases for this. If you truly think you are addressing the middlebox problem, most likely you could just run the DNS over port 54 or 80/443. This proposal does not at all address the problem where DNS is mangled due to hotspot and captive portal scenarios. Once you work around that scenario, for example like with the dnssec-trigger experiment that's still far from workable to non-engineers, you usually get a clean connection with the exception of port 53 mangling, which just moving to another port seems to almost always fix it (with 80/443 having a slightly better chance then a random port. Doing DNS-over-HTTP is still going to get broken results in captive portals. What dnssec-trigger is trying to do now is: - selectable (but should be automatic) hot spot mode where you allow insecure dns only to go past captivity - attempt to use DHCP assigned DNS servers as cache, validate locally - if broken, try and query auth servers directly - if broken, try an open resolver on port 80/443 - if broken give user option for "insecure or cached only" Aside from this, we have the new dnssec chains via alternative source, both as a speedup and as a workaround using a leap of faith in TLS. this is useful, though not a replacement for the above. It would also be nice if any dnssec-chain extension would use some kind of standard so we can feed it into a validating caching server. Doing dns-over-http for broken middlewhere alone is going to be a partial solution that is not going to be very useful on its own. Paul From vixie@isc.org Sat Oct 1 10:33: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 3210D21F907A for ; Sat, 1 Oct 2011 10:33:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.5 X-Spam-Level: X-Spam-Status: No, score=-2.5 tagged_above=-999 required=5 tests=[AWL=0.100, 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 W8DYhfq-FnWt for ; Sat, 1 Oct 2011 10:33:39 -0700 (PDT) Received: from ss.vix.com (ss.vix.com [IPv6:2001:559:8000:cb::2]) by ietfa.amsl.com (Postfix) with ESMTP id A40AC21F9079 for ; Sat, 1 Oct 2011 10:33:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at redbarn.org Received: from ww.vix.com (ww.vix.com [IPv6:2001:559:8000:cb:215:17ff:fed4:730a]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by ss.vix.com (Postfix) with ESMTPS id 517ECEE51C for ; Sat, 1 Oct 2011 17:36:28 +0000 (UTC) (envelope-from vixie@isc.org) From: Paul Vixie Organization: Internet Systems Consortium To: dnsext@ietf.org Date: Sat, 1 Oct 2011 17:36:27 +0000 User-Agent: KMail/1.13.5 (FreeBSD/8.1-RELEASE; KDE/4.4.5; amd64; ; ) References: <201110010458.26859.vixie@isc.org> In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201110011736.27664.vixie@isc.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: Sat, 01 Oct 2011 17:33:40 -0000 On Saturday, October 01, 2011 03:01:33 pm Nicholas Weaver wrote: > > A side benefit of this is, the UPDATE opcode gets easy. > > Use GET, but if you want it to get through the most busted of web caches, > do the following: why "use GET"? if POST allows us to send a dns message as post-body, which could either be a query or an update, then why would we prefer GET? > And I'd have the return value be JSON rather than raw DNS on the wire. > Why? > > Because since the point is validating DNSSEC, the HTTP-server should not > just return the record asked for, but the whole signature chain that it > has. Since this is more information than a normal DNS reply, it might > benefit from a new encoding. i've got a draft in production that adds an EDNS option "send chain" where the option payload is any ancestor of the QNAME and indicates the requestor's deepest validated trusted domain name. this will solicit a longer trust chain (all the RRSIG, DNSKEY, DS RRs) between this ancestor and the QNAME. it is something i'd like for UDP/53 whenever ip fragmentation is working, and something i'd like for TCP/53 whenever that's not firewalled out. it could also be used in DNS-over-HTTP, assuming that we allow transmission of full DNS messages in both directions (therefore, using POST). in other words i don't see this as HTTP-specific which is why it's not in this draft. From vixie@isc.org Sat Oct 1 10:40: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 1BBDA21F90E3 for ; Sat, 1 Oct 2011 10:40:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.525 X-Spam-Level: X-Spam-Status: No, score=-2.525 tagged_above=-999 required=5 tests=[AWL=0.075, 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 x181zC9-PogC for ; Sat, 1 Oct 2011 10:40:12 -0700 (PDT) Received: from ss.vix.com (ss.vix.com [IPv6:2001:559:8000:cb::2]) by ietfa.amsl.com (Postfix) with ESMTP id A9EAE21F90E2 for ; Sat, 1 Oct 2011 10:40:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at redbarn.org Received: from ww.vix.com (ww.vix.com [IPv6:2001:559:8000:cb:215:17ff:fed4:730a]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by ss.vix.com (Postfix) with ESMTPS id 06916EE51C for ; Sat, 1 Oct 2011 17:43:04 +0000 (UTC) (envelope-from vixie@isc.org) From: Paul Vixie Organization: Internet Systems Consortium To: dnsext@ietf.org Date: Sat, 1 Oct 2011 17:43:03 +0000 User-Agent: KMail/1.13.5 (FreeBSD/8.1-RELEASE; KDE/4.4.5; amd64; ; ) References: <201110010458.26859.vixie@isc.org> In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201110011743.03563.vixie@isc.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: Sat, 01 Oct 2011 17:40:13 -0000 On Saturday, October 01, 2011 05:33:29 pm Paul Wouters wrote: > If you truly think you are addressing the middlebox problem, most likely > you could just run the DNS over port 54 or 80/443. no, because all-that-is-not-allowed-is-denied for most firewalls. random udp ports especially low numbered ones just don't work in a lot of places. it's not that UDP/53 is special by being middleboxed, it's that UDP/53 is special by being allowed to work at all (where "work" and "middlebox" are at odds.) > ... (with 80/443 having a slightly better chance then a random port. indeed, 80 and 443 are often cleaner. especially 443 with private keys (no CA). especially if the request is a POST. > Doing DNS-over-HTTP is still going to get broken results in captive > portals. alas, you are right, there is no universal way to get our packets through, since just about everybody between the dns requestor and the dns responder wants a piece of the action these days, or thinks they know better, or both. however, TCP/80 and TCP/443 are "the RS232 of the new millenium" and i expect good results on average from making these available as a fallback to the long corrupted UDP/53 and TCP/53. > Doing dns-over-http for broken middlewhere alone is going to be a partial > solution that is not going to be very useful on its own. right, agreed, but the things it will work better alongside are also useful in their own right, like "send me the trust chain from the QNAME back to the deepest trust anchor i've currently validated". therefore that proposal is going to come separately. paul From nweaver@ICSI.Berkeley.EDU Sat Oct 1 11:22: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 024EF21F91D2 for ; Sat, 1 Oct 2011 11:22:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.209 X-Spam-Level: X-Spam-Status: No, score=-2.209 tagged_above=-999 required=5 tests=[AWL=-0.210, BAYES_00=-2.599, J_CHICKENPOX_14=0.6] 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 3igWOeRbLo86 for ; Sat, 1 Oct 2011 11:22:28 -0700 (PDT) Received: from rock.ICSI.Berkeley.EDU (rock.ICSI.Berkeley.EDU [192.150.186.19]) by ietfa.amsl.com (Postfix) with ESMTP id 21FC521F91CA for ; Sat, 1 Oct 2011 11:22:28 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by rock.ICSI.Berkeley.EDU (Postfix) with ESMTP id A8A382C4015; Sat, 1 Oct 2011 11:25:25 -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 5Ww8qHS+gck6; Sat, 1 Oct 2011 11:25:24 -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 4313F2C4002; Sat, 1 Oct 2011 11:25:24 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1244.3) Content-Type: text/plain; charset=us-ascii From: Nicholas Weaver In-Reply-To: <5C4E07BC-E6CC-45A6-8018-10C2A799A55E@vpnc.org> Date: Sat, 1 Oct 2011 11:25:22 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <66077D12-F568-426A-8E5C-CC077CC24622@ICSI.Berkeley.EDU> References: <0394FB3B-6C2B-4D47-B1FA-AA54B7EB1053@kirei.se> <201110010458.26859.vixie@isc.org> <5C4E07BC-E6CC-45A6-8018-10C2A799A55E@vpnc.org> To: Paul Hoffman X-Mailer: Apple Mail (2.1244.3) Cc: DNSEXT Working Group 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: Sat, 01 Oct 2011 18:22:29 -0000 On Oct 1, 2011, at 8:25 AM, Paul Hoffman wrote: > On Oct 1, 2011, at 8:01 AM, Nicholas Weaver wrote: >=20 >> Web caches don't work. =20 >=20 > +1. >=20 >> In our experience, nearly 50% of those in Netalyzr tests cache things = they shouldn't, so if the worry is cache-staleness, include a = cache-buster. >=20 > -.5. You are assuming that a bad HTTP cache will be bad in a = predictable fashion. I'm not against using nonces to bust caches, but I = don't think we should rely on it. No, what I'm assuming is SOME minimal-level of nonborkenness. IF a cache takes url=20 http://www.example.com/url_a and instead returns http://www.example.com/url_b Its going to be so b0rken for everything that HTTP will be nonusable. Thus making the URLs like http://www.dnsresolver.com/name/rtype/NONCEA.json will be noncached, because if it instead returns the results of a = previous fetch http://www.dnsresolver.com/name/rtype/NONCEB.json the cache will be not subtly broken, but so broken-as-to-uselessness. THats the other reason for json: If the middlebox is content aware, = JSON is one thing that will be let through because block = application/json these days you might as well block the web altogether. So encoded as JSON, transfered as mimetype application/json, is most = likely to get through. From alex@alex.org.uk Sat Oct 1 14:00:06 2011 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D987C21F8F80 for ; Sat, 1 Oct 2011 14:00:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.562 X-Spam-Level: X-Spam-Status: No, score=-2.562 tagged_above=-999 required=5 tests=[AWL=0.038, 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 yalBWXv7TroR for ; Sat, 1 Oct 2011 14:00:05 -0700 (PDT) Received: from mail.avalus.com (mail.avalus.com [IPv6:2001:41c8:10:1dd::10]) by ietfa.amsl.com (Postfix) with ESMTP id 6292E21F8F7F for ; Sat, 1 Oct 2011 14:00:04 -0700 (PDT) Received: from [192.168.100.16] (87-194-71-186.bethere.co.uk [87.194.71.186]) by mail.avalus.com (Postfix) with ESMTPSA id 785FCC56103; Sat, 1 Oct 2011 22:02:59 +0100 (BST) Date: Sat, 01 Oct 2011 22:02:58 +0100 From: Alex Bligh To: Nicholas Weaver , Paul Hoffman Message-ID: <33BA32D8CFF5BCB5D2895142@nimrod.local> In-Reply-To: <66077D12-F568-426A-8E5C-CC077CC24622@ICSI.Berkeley.EDU> References: <0394FB3B-6C2B-4D47-B1FA-AA54B7EB1053@kirei.se> <201110010458.26859.vixie@isc.org> <5C4E07BC-E6CC-45A6-8018-10C2A799A55E@vpnc.org> <66077D12-F568-426A-8E5C-CC077CC24622@ICSI.Berkeley.EDU> X-Mailer: Mulberry/4.0.8 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Cc: DNSEXT Working Group Subject: Re: [dnsext] draft-mohan-dns-query-xml-00.txt X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Alex Bligh List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 Oct 2011 21:00:06 -0000 --On 1 October 2011 11:25:22 -0700 Nicholas Weaver wrote: >> -.5. You are assuming that a bad HTTP cache will be bad in a predictable >> fashion. I'm not against using nonces to bust caches, but I don't think >> we should rely on it. > > No, what I'm assuming is SOME minimal-level of nonborkenness. > > IF a cache takes url > > http://www.example.com/url_a > > and instead returns > > http://www.example.com/url_b This is true, but the GET/POST question is half orthogonal (so that would be 45 degrees?) to the nonce question. IE you could use a POST plus a nonce if you wanted. IIRC POST /should/ do enough alone to avoid the need for a nonce though, as I can't see how any web cache would cache POSTs. -- Alex Bligh From nweaver@ICSI.Berkeley.EDU Sat Oct 1 14:05: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 232D121F901D for ; Sat, 1 Oct 2011 14:05:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.49 X-Spam-Level: X-Spam-Status: No, score=-2.49 tagged_above=-999 required=5 tests=[AWL=0.109, 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 pkG3jvtCUaOs for ; Sat, 1 Oct 2011 14:05:26 -0700 (PDT) Received: from rock.ICSI.Berkeley.EDU (rock.ICSI.Berkeley.EDU [192.150.186.19]) by ietfa.amsl.com (Postfix) with ESMTP id 4357F21F901C for ; Sat, 1 Oct 2011 14:05:26 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by rock.ICSI.Berkeley.EDU (Postfix) with ESMTP id C99C82C400A; Sat, 1 Oct 2011 14:08:21 -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 dzGg0TXJWNNJ; Sat, 1 Oct 2011 14:08:21 -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 65FE22C4002; Sat, 1 Oct 2011 14:08:21 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1244.3) Content-Type: text/plain; charset=us-ascii From: Nicholas Weaver In-Reply-To: <33BA32D8CFF5BCB5D2895142@nimrod.local> Date: Sat, 1 Oct 2011 14:08:20 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <4C6F86F7-9FFD-4C71-B1A0-4CCD56E48D12@ICSI.Berkeley.EDU> References: <0394FB3B-6C2B-4D47-B1FA-AA54B7EB1053@kirei.se> <201110010458.26859.vixie@isc.org> <5C4E07BC-E6CC-45A6-8018-10C2A799A55E@vpnc.org> <66077D12-F568-426A-8E5C-CC077CC24622@ICSI.Berkeley.EDU> <33BA32D8CFF5BCB5D2895142@nimrod.local> To: Alex Bligh X-Mailer: Apple Mail (2.1244.3) Cc: Paul Hoffman , DNSEXT Working Group 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: Sat, 01 Oct 2011 21:05:27 -0000 On Oct 1, 2011, at 2:02 PM, Alex Bligh wrote: >> No, what I'm assuming is SOME minimal-level of nonborkenness. >>=20 >> IF a cache takes url >>=20 >> http://www.example.com/url_a >>=20 >> and instead returns >>=20 >> http://www.example.com/url_b >=20 > This is true, but the GET/POST question is half orthogonal (so that = would be 45 degrees?) to the nonce question. IE you could use a POST = plus a nonce if you wanted. IIRC POST /should/ do enough alone to avoid = the need for a nonce though, as I can't see how any web cache would = cache POSTs. Yeah, but if we're assuming maximum borkennes, I could see truly borken = proxies failing to properly return data in the reply of a POST. Thus if the goal of using POST instead of GET is cache-busting, GET with = NONCE should work unless the case is "Broken to the point of uselessness = HTTP proxy". Oh, one BIG warning that might sabotage this that I just realized: I've = seen proxies, eg the Bluecoat proxy, which will intercept all traffic = until the BROWSER is logged into the proxy and has a cookie set, so = there isn't HTTP access unless through a browser that's already gone = through the login process. :( Since thats likely to the the same sort of network where you can't = bypass the DNS borkenness by TCP or UDP port 53, this could be a = problem. From drc@virtualized.org Sat Oct 1 14: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 13DEE21F8E75 for ; Sat, 1 Oct 2011 14:23:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.799 X-Spam-Level: X-Spam-Status: No, score=-2.799 tagged_above=-999 required=5 tests=[AWL=-0.200, 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 gYE0fKK5q8WO for ; Sat, 1 Oct 2011 14:23:57 -0700 (PDT) Received: from trantor.virtualized.org (trantor.virtualized.org [199.48.134.42]) by ietfa.amsl.com (Postfix) with ESMTP id 929B021F8E71 for ; Sat, 1 Oct 2011 14:23:57 -0700 (PDT) Received: from [10.0.1.9] (cpe-66-91-109-17.hawaii.res.rr.com [66.91.109.17]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: drc) by trantor.virtualized.org (Postfix) with ESMTPSA id 118F01704E; Sat, 1 Oct 2011 21:26:53 +0000 (UTC) Mime-Version: 1.0 (Apple Message framework v1244.3) Content-Type: text/plain; charset=us-ascii From: David Conrad In-Reply-To: <4C6F86F7-9FFD-4C71-B1A0-4CCD56E48D12@ICSI.Berkeley.EDU> Date: Sat, 1 Oct 2011 11:26:51 -1000 Content-Transfer-Encoding: quoted-printable Message-Id: <6F36FE11-36C6-4F56-B6C7-50B9C3705C13@virtualized.org> References: <0394FB3B-6C2B-4D47-B1FA-AA54B7EB1053@kirei.se> <201110010458.26859.vixie@isc.org> <5C4E07BC-E6CC-45A6-8018-10C2A799A55E@vpnc.org> <66077D12-F568-426A-8E5C-CC077CC24622@ICSI.Berkeley.EDU> <33BA32D8CFF5BCB5D2895142@nimrod.local> <4C6F86F7-9FFD-4C71-B1A0-4CCD56E48D12@ICSI.Berkeley.EDU> To: Nicholas Weaver X-Mailer: Apple Mail (2.1244.3) Cc: DNSEXT Working Group 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: Sat, 01 Oct 2011 21:23:58 -0000 On Oct 1, 2011, at 11:08 AM, Nicholas Weaver wrote: > Since thats likely to the the same sort of network where you can't = bypass the DNS borkenness by TCP or UDP port 53, this could be a = problem. This succinctly captures my ill-ease about this proposal. Pretending (in effect) HTTP{,S} is IPv7 will work until the network = administrators/middlebox vendors decide they want to block/intercept = that traffic. Then what? How many levels of turtles are we willing to = go down? Regards, -drc From mohta@necom830.hpcl.titech.ac.jp Sat Oct 1 16:30:28 2011 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A06E021F8C1A for ; Sat, 1 Oct 2011 16:30:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.7 X-Spam-Level: X-Spam-Status: No, score=0.7 tagged_above=-999 required=5 tests=[AWL=-0.699, BAYES_05=-1.11, 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 uhJTSF00lly4 for ; Sat, 1 Oct 2011 16:30: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 BDBD521F8C19 for ; Sat, 1 Oct 2011 16:30:27 -0700 (PDT) Received: (qmail 16528 invoked from network); 1 Oct 2011 23:47:38 -0000 Received: from necom830.hpcl.titech.ac.jp (HELO ?127.0.0.1?) (131.112.32.132) by necom830.hpcl.titech.ac.jp with SMTP; 1 Oct 2011 23:47:38 -0000 Message-ID: <4E87A351.3070206@necom830.hpcl.titech.ac.jp> Date: Sun, 02 Oct 2011 08:33:37 +0900 From: Masataka Ohta User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: dnsext@ietf.org References: <0394FB3B-6C2B-4D47-B1FA-AA54B7EB1053@kirei.se> <201110010458.26859.vixie@isc.org> <5C4E07BC-E6CC-45A6-8018-10C2A799A55E@vpnc.org> <66077D12-F568-426A-8E5C-CC077CC24622@ICSI.Berkeley.EDU> <33BA32D8CFF5BCB5D2895142@nimrod.local> <4C6F86F7-9FFD-4C71-B1A0-4CCD56E48D12@ICSI.Berkeley.EDU> <6F36FE11-36C6-4F56-B6C7-50B9C3705C13@virtualized.org> In-Reply-To: <6F36FE11-36C6-4F56-B6C7-50B9C3705C13@virtualized.org> Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit 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: Sat, 01 Oct 2011 23:30:28 -0000 I'm not sure about the environment to use this proposal. Perhaps, DHCP is not expected to work and the raw addresses of http servers are written in /etc/resolv.conf. But, how can a client get secure time? Masataka Ohta From mohta@necom830.hpcl.titech.ac.jp Sat Oct 1 16:57:43 2011 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D503821F8B71 for ; Sat, 1 Oct 2011 16:57:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.033 X-Spam-Level: X-Spam-Status: No, score=-0.033 tagged_above=-999 required=5 tests=[AWL=0.057, 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 lz6t5yNv2JQv for ; Sat, 1 Oct 2011 16:57:43 -0700 (PDT) Received: from necom830.hpcl.titech.ac.jp (necom830.hpcl.titech.ac.jp [131.112.32.132]) by ietfa.amsl.com (Postfix) with SMTP id 21BEF21F8B70 for ; Sat, 1 Oct 2011 16:57:43 -0700 (PDT) Received: (qmail 16701 invoked from network); 2 Oct 2011 00:15:08 -0000 Received: from necom830.hpcl.titech.ac.jp (HELO ?127.0.0.1?) (131.112.32.132) by necom830.hpcl.titech.ac.jp with SMTP; 2 Oct 2011 00:15:08 -0000 Message-ID: <4E87A9C8.8090401@necom830.hpcl.titech.ac.jp> Date: Sun, 02 Oct 2011 09:01:12 +0900 From: Masataka Ohta User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: dnsext@ietf.org References: <0394FB3B-6C2B-4D47-B1FA-AA54B7EB1053@kirei.se> <201110010458.26859.vixie@isc.org> In-Reply-To: <201110010458.26859.vixie@isc.org> Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit 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: Sat, 01 Oct 2011 23:57:43 -0000 Paul Vixie wrote: > I truly do only expect this transport to be used > when the normal UDP/53 and TCP/53 paths are middlebox-corrupted. And only for SDNS. Maybe, google is considering to always use this transport with hardwired addresses of 8.8.8.8 and 8.8.4.4 even for plain DNS to get privacy information of clients from HTTP headers. Masataka Ohta From nweaver@icsi.berkeley.edu Sat Oct 1 17:06: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 8DDE221F8E22 for ; Sat, 1 Oct 2011 17:06:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.499 X-Spam-Level: X-Spam-Status: No, score=-2.499 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Eorneguo5iHm for ; Sat, 1 Oct 2011 17:06:40 -0700 (PDT) Received: from rock.ICSI.Berkeley.EDU (rock.ICSI.Berkeley.EDU [192.150.186.19]) by ietfa.amsl.com (Postfix) with ESMTP id F142021F8C18 for ; Sat, 1 Oct 2011 17:06:39 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by rock.ICSI.Berkeley.EDU (Postfix) with ESMTP id D66982C4015; Sat, 1 Oct 2011 17:09:37 -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 pg6knNqDJlHx; Sat, 1 Oct 2011 17:09:37 -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 80F8A2C4002; Sat, 1 Oct 2011 17:09:37 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1244.3) Content-Type: text/plain; charset=us-ascii From: Nicholas Weaver In-Reply-To: <4E87A9C8.8090401@necom830.hpcl.titech.ac.jp> Date: Sat, 1 Oct 2011 17:09:37 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <6C66E591-5278-415B-A7A8-21AB824F2599@icsi.berkeley.edu> References: <0394FB3B-6C2B-4D47-B1FA-AA54B7EB1053@kirei.se> <201110010458.26859.vixie@isc.org> <4E87A9C8.8090401@necom830.hpcl.titech.ac.jp> To: Masataka Ohta X-Mailer: Apple Mail (2.1244.3) Cc: 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: Sun, 02 Oct 2011 00:06:40 -0000 On Oct 1, 2011, at 5:01 PM, Masataka Ohta wrote: > And only for SDNS. >=20 > Maybe, google is considering to always use this transport with > hardwired addresses of 8.8.8.8 and 8.8.4.4 even for plain DNS > to get privacy information of clients from HTTP headers. For google, the information they get from Public DNS is a poor source of = data by Google's standards. a) Google's privacy policy is clear on what data they keep and discard = from Public DNS. http://code.google.com/speed/public-dns/privacy.html Full IP logs are kept for 24-48 hours, after that, IP addresses are = replaced with a network & city level GeoIP localization, which means it = is very poor for user tracking. Which is excellent for tracking = aggregate information but fails completely for user tracking. b) Google +1 and Analytics capture much much much more information = about what users are reading on the web. The rumors (threats?) about +1 = being used by the pagerank algorithm are particularly disturbing. Rather, it appears Google Public DNS is about having a public DNS = service where an NXDOMAIN remains an NXDOMAIN, since half of those = NXDOMAINs from the browser result in a Google search anyway (the other = half go to Bing), so there is little point in monetizing NXDOMAINs for = Google. From brian.peter.dickson@gmail.com Sat Oct 1 18:01: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 9743F21F8E42 for ; Sat, 1 Oct 2011 18:01:12 -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 tL5Je0aoCZqy for ; Sat, 1 Oct 2011 18:01:12 -0700 (PDT) Received: from mail-bw0-f44.google.com (mail-bw0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id C230F21F8E41 for ; Sat, 1 Oct 2011 18:01:11 -0700 (PDT) Received: by bkaq10 with SMTP id q10so3892028bka.31 for ; Sat, 01 Oct 2011 18:04:09 -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=YBYSCAdcEatO1/Mnw63Dv2Wn+XUsbmMK3S85QOI3Z5M=; b=i0Jj/Zz91xomUxXThvCMk836sxE+f8vHj6NlNv2bLcoCXTJRO3rlSdMyqIDSCpElDm qbqgrtuqVz0bPRcq8fIuT9gULsmhOxxJ/Ud2JdqUyw9RLPEfojoDLp9uLqqSkYV6AV4A jZl9FeTErYd7rorPx1VTEUAQQ8tLtNznQ1pJM= MIME-Version: 1.0 Received: by 10.223.55.218 with SMTP id v26mr8896701fag.82.1317517449226; Sat, 01 Oct 2011 18:04:09 -0700 (PDT) Received: by 10.223.144.135 with HTTP; Sat, 1 Oct 2011 18:04:09 -0700 (PDT) In-Reply-To: <6F36FE11-36C6-4F56-B6C7-50B9C3705C13@virtualized.org> References: <0394FB3B-6C2B-4D47-B1FA-AA54B7EB1053@kirei.se> <201110010458.26859.vixie@isc.org> <5C4E07BC-E6CC-45A6-8018-10C2A799A55E@vpnc.org> <66077D12-F568-426A-8E5C-CC077CC24622@ICSI.Berkeley.EDU> <33BA32D8CFF5BCB5D2895142@nimrod.local> <4C6F86F7-9FFD-4C71-B1A0-4CCD56E48D12@ICSI.Berkeley.EDU> <6F36FE11-36C6-4F56-B6C7-50B9C3705C13@virtualized.org> Date: Sat, 1 Oct 2011 21:04:09 -0400 Message-ID: From: Brian Dickson To: David Conrad Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: DNSEXT Working Group 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: Sun, 02 Oct 2011 01:01:12 -0000 On Sat, Oct 1, 2011 at 5:26 PM, David Conrad wrote: > On Oct 1, 2011, at 11:08 AM, Nicholas Weaver wrote: >> Since thats likely to the the same sort of network where you can't bypas= s the DNS borkenness by TCP or UDP port 53, this could be a problem. > > This succinctly captures my ill-ease about this proposal. > > Pretending (in effect) HTTP{,S} is IPv7 will work until the network admin= istrators/middlebox vendors decide they want to block/intercept that traffi= c. Then what? =A0How many levels of turtles are we willing to go down? Including this, depending on how you count, one, or two if you treat http and https in this proposal as two turtles instead of one. Here's why: Intercept precludes https (since the "s" means end-to-end TLS). And blocking https requires some way of determining what to block, on a destination basis alone, for the same reason. The http component is opaque in an https connection, protected by the TLS connection. So, in the case of the middlebox vendors or network administrators not reacting to the use of DNS over HTTP(S), problem solved. Otherwise, it then becomes baby+bathwater for those trying to block this, based only on IP addresses. Name-based HTTP servers that support this (on 80 or 443) on shared infrastructure (web hosting etc.), plus popularity of use (large numbers of sites and/or well known large sites), including phone-home use with client-authentication by HTTPS servers, means there will be significant benefit to this, and significant pressure to not try to break it (at least in the HTTPS case). Where practical to do so, eg for business enterprise employees away from the office, having server running on both 80 and 443 is ideal. If 80 works, there is low cost for doing this. If 80 does not (ie blocked or mangled), 443 should. Blocking 443 on a given IP is particularly ill-advised for hot-spot operators and hotels. As for encoding, I definitely support wire-format over XML. Brian From mohta@necom830.hpcl.titech.ac.jp Sat Oct 1 22:41:01 2011 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1A48121F8E39 for ; Sat, 1 Oct 2011 22:41:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.034 X-Spam-Level: X-Spam-Status: No, score=-0.034 tagged_above=-999 required=5 tests=[AWL=0.056, 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 514oZgE+3imi for ; Sat, 1 Oct 2011 22:41: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 1FA9521F8E33 for ; Sat, 1 Oct 2011 22:40:59 -0700 (PDT) Received: (qmail 19643 invoked from network); 2 Oct 2011 05:58:10 -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; 2 Oct 2011 05:58:10 -0000 Message-ID: <4E87FA22.5010700@necom830.hpcl.titech.ac.jp> Date: Sun, 02 Oct 2011 14:44:02 +0900 From: Masataka Ohta User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: Nicholas Weaver References: <0394FB3B-6C2B-4D47-B1FA-AA54B7EB1053@kirei.se> <201110010458.26859.vixie@isc.org> <4E87A9C8.8090401@necom830.hpcl.titech.ac.jp> <6C66E591-5278-415B-A7A8-21AB824F2599@icsi.berkeley.edu> In-Reply-To: <6C66E591-5278-415B-A7A8-21AB824F2599@icsi.berkeley.edu> Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit Cc: 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: Sun, 02 Oct 2011 05:41:01 -0000 Nicholas Weaver wrote: > a) Google's privacy policy is clear on what data they > keep and discard from Public DNS. That's not the point. See client subnet thread. Masataka Ohta From nweaver@ICSI.Berkeley.EDU Sun Oct 2 04:39: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 BD42121F8E62 for ; Sun, 2 Oct 2011 04:39:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.507 X-Spam-Level: X-Spam-Status: No, score=-2.507 tagged_above=-999 required=5 tests=[AWL=0.092, 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 8JrLsCRu-yAi for ; Sun, 2 Oct 2011 04:39:40 -0700 (PDT) Received: from rock.ICSI.Berkeley.EDU (rock.ICSI.Berkeley.EDU [192.150.186.19]) by ietfa.amsl.com (Postfix) with ESMTP id E9BFB21F8D8C for ; Sun, 2 Oct 2011 04:39:40 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by rock.ICSI.Berkeley.EDU (Postfix) with ESMTP id 3FB1B2C4018; Sun, 2 Oct 2011 04:42:38 -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 ye5EfD8Eg82a; Sun, 2 Oct 2011 04:42:38 -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 E488D2C4002; Sun, 2 Oct 2011 04:42:37 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1244.3) Content-Type: text/plain; charset=iso-2022-jp From: Nicholas Weaver In-Reply-To: <4E87FA22.5010700@necom830.hpcl.titech.ac.jp> Date: Sun, 2 Oct 2011 04:42:39 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <54496460-643C-4ECC-BFAA-BAE3B545FFB4@ICSI.Berkeley.EDU> References: <0394FB3B-6C2B-4D47-B1FA-AA54B7EB1053@kirei.se> <201110010458.26859.vixie@isc.org> <4E87A9C8.8090401@necom830.hpcl.titech.ac.jp> <6C66E591-5278-415B-A7A8-21AB824F2599@icsi.berkeley.edu> <4E87FA22.5010700@necom830.hpcl.titech.ac.jp> To: Masataka Ohta X-Mailer: Apple Mail (2.1244.3) Cc: 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: Sun, 02 Oct 2011 11:39:41 -0000 On Oct 1, 2011, at 10:44 PM, Masataka Ohta wrote: > Nicholas Weaver wrote: >=20 >> a) Google's privacy policy is clear on what data they >> keep and discard from Public DNS. >=20 > That's not the point. See client subnet thread. Oh, THAT particular weird meme, which makes no sense either since: a) Client subnet doesn't send IP, only subnet b) It sends this information to the DNS authority representing the = domain the user is going to contact anyway. From nweaver@ICSI.Berkeley.EDU Sun Oct 2 04:45:17 2011 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C3AF921F8E80 for ; Sun, 2 Oct 2011 04:45:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.513 X-Spam-Level: X-Spam-Status: No, score=-2.513 tagged_above=-999 required=5 tests=[AWL=0.086, 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 4Lby4XLcGsj3 for ; Sun, 2 Oct 2011 04:45:17 -0700 (PDT) Received: from rock.ICSI.Berkeley.EDU (rock.ICSI.Berkeley.EDU [192.150.186.19]) by ietfa.amsl.com (Postfix) with ESMTP id 5503B21F8E77 for ; Sun, 2 Oct 2011 04:45:17 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by rock.ICSI.Berkeley.EDU (Postfix) with ESMTP id E6FAF2C4017; Sun, 2 Oct 2011 04:48:16 -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 B8CT-eqBQwdl; Sun, 2 Oct 2011 04:48:16 -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 7FBB72C4002; Sun, 2 Oct 2011 04:48:16 -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, 2 Oct 2011 04:48:18 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <0394FB3B-6C2B-4D47-B1FA-AA54B7EB1053@kirei.se> <201110010458.26859.vixie@isc.org> <5C4E07BC-E6CC-45A6-8018-10C2A799A55E@vpnc.org> <66077D12-F568-426A-8E5C-CC077CC24622@ICSI.Berkeley.EDU> <33BA32D8CFF5BCB5D2895142@nimrod.local> <4C6F86F7-9FFD-4C71-B1A0-4CCD56E48D12@ICSI.Berkeley.EDU> <6F36FE11-36C6-4F56-B6C7-50B9C3705C13@virtualized.org> To: Brian Dickson X-Mailer: Apple Mail (2.1244.3) Cc: DNSEXT Working Group 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: Sun, 02 Oct 2011 11:45:17 -0000 On Oct 1, 2011, at 6:04 PM, Brian Dickson wrote: > So, in the case of the middlebox vendors or network administrators not > reacting to the use of DNS over HTTP(S), problem solved. Otherwise, it > then becomes baby+bathwater for those trying to block this, based only > on IP addresses. Name-based HTTP servers that support this (on 80 or > 443) on shared infrastructure (web hosting etc.), plus popularity of > use (large numbers of sites and/or well known large sites), including > phone-home use with client-authentication by HTTPS servers, means > there will be significant benefit to this, and significant pressure to > not try to break it (at least in the HTTPS case). There is actually two cases that this seems to want to address: a) The amazingly borken middlebox at a consumer/hotspot. In this case, = DNS over TCP is likely to work (they don't get it), and DNS over TCP on = a high port is really likely to work. =20 The network is probably not trying to restrict DNS AFTER login anyway. b) A corporate network with a vicious firewall. In this case, well, = its less clear that THIS proposal would work if the network = administrator doesn't want it to work. These networks sometimes do = proxy HTTPS as well as HTTP, by having an additional certificate = installed in the client. EG, I've seen Netalyzr runs from corporate networks that block = EVERYTHING out (and I mean EVERYTHING), routing ALL traffic through = HTTP/HTTPS proxies and blocking everything else. So for a: (which is mostly ignorant network), having a few global = recursive resolvers with high ports is probably sufficient. For b: (which is the deliberate corporate network), I don't think this = proposal is guarenteed to work. From mohta@necom830.hpcl.titech.ac.jp Sun Oct 2 05:50:06 2011 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 10BB621F8B49 for ; Sun, 2 Oct 2011 05:50:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.035 X-Spam-Level: X-Spam-Status: No, score=-0.035 tagged_above=-999 required=5 tests=[AWL=0.055, 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 IJ9zmGpK90PQ for ; Sun, 2 Oct 2011 05:50:05 -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 4505321F8B43 for ; Sun, 2 Oct 2011 05:50:04 -0700 (PDT) Received: (qmail 22250 invoked from network); 2 Oct 2011 13:07:19 -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; 2 Oct 2011 13:07:19 -0000 Message-ID: <4E885EBC.7010902@necom830.hpcl.titech.ac.jp> Date: Sun, 02 Oct 2011 21:53:16 +0900 From: Masataka Ohta User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: Nicholas Weaver References: <0394FB3B-6C2B-4D47-B1FA-AA54B7EB1053@kirei.se> <201110010458.26859.vixie@isc.org> <4E87A9C8.8090401@necom830.hpcl.titech.ac.jp> <6C66E591-5278-415B-A7A8-21AB824F2599@icsi.berkeley.edu> <4E87FA22.5010700@necom830.hpcl.titech.ac.jp> <54496460-643C-4ECC-BFAA-BAE3B545FFB4@ICSI.Berkeley.EDU> In-Reply-To: <54496460-643C-4ECC-BFAA-BAE3B545FFB4@ICSI.Berkeley.EDU> Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit Cc: 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: Sun, 02 Oct 2011 12:50:06 -0000 Nicholas Weaver wrote: > Oh, THAT particular weird meme, which makes no sense either since: > > a) Client subnet doesn't send IP, only subnet > > b) It sends this information to the DNS authority representing the domain the user is going to contact anyway. You completely miss the point. I acknowledge you don't understand the problem of implied business model. Masataka Ohta From fanf2@hermes.cam.ac.uk Mon Oct 3 07:23: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 4CA2521F8A91 for ; Mon, 3 Oct 2011 07:23:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.585 X-Spam-Level: X-Spam-Status: No, score=-6.585 tagged_above=-999 required=5 tests=[AWL=0.014, 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 GZ-beGrMFgDX for ; Mon, 3 Oct 2011 07:23:36 -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 1A5F821F8586 for ; Mon, 3 Oct 2011 07:23:35 -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]:49201) by ppsw-41.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.156]:25) with esmtpa (EXTERNAL:fanf2) id 1RAjTY-0001er-S8 (Exim 4.72) (return-path ); Mon, 03 Oct 2011 15:26:36 +0100 Received: from fanf2 (helo=localhost) by hermes-2.csi.cam.ac.uk (hermes.cam.ac.uk) with local-esmtp id 1RAjTY-0002wS-Ms (Exim 4.67) (return-path ); Mon, 03 Oct 2011 15:26:36 +0100 Date: Mon, 3 Oct 2011 15:26:36 +0100 From: Tony Finch X-X-Sender: fanf2@hermes-2.csi.cam.ac.uk To: Paul Vixie In-Reply-To: <201110011736.27664.vixie@isc.org> Message-ID: References: <201110010458.26859.vixie@isc.org> <201110011736.27664.vixie@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] 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: Mon, 03 Oct 2011 14:23:40 -0000 Paul Vixie wrote: > > i've got a draft in production that adds an EDNS option "send chain" where the > option payload is any ancestor of the QNAME and indicates the requestor's > deepest validated trusted domain name. this will solicit a longer trust chain > (all the RRSIG, DNSKEY, DS RRs) between this ancestor and the QNAME. What about support for lookaside trust anchors? > [...] i don't see this as HTTP-specific which is why it's not in this draft. Sensible. Tony. -- f.anthony.n.finch http://dotat.at/ Viking, North Utsire: Southerly veering southwesterly 6 to gale 8, occasionally severe gale 9 at first in northwest Viking. Moderate or rough becoming very rough or high. Rain then squally showers. Moderate or good, occasionally poor. From vixie@isc.org Mon Oct 3 08:46: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 EA60E21F8BB7 for ; Mon, 3 Oct 2011 08:46:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.54 X-Spam-Level: X-Spam-Status: No, score=-2.54 tagged_above=-999 required=5 tests=[AWL=0.060, 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 GZj8eLEOAogx for ; Mon, 3 Oct 2011 08:46:15 -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 A3E3021F8BAD for ; Mon, 3 Oct 2011 08:46:15 -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 419CDC9423 for ; Mon, 3 Oct 2011 15:49:05 +0000 (UTC) (envelope-from vixie@isc.org) Received: from unknown (75-54-222-121.lightspeed.rdcyca.sbcglobal.net [75.54.222.121]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (Client did not present a certificate) by bikeshed.isc.org (Postfix) with ESMTPSA id 22573216C3B for ; Mon, 3 Oct 2011 15:49:05 +0000 (UTC) (envelope-from vixie@isc.org) Date: Mon, 3 Oct 2011 15:49:02 +0000 From: Paul Vixie To: dnsext@ietf.org Message-ID: <20111003154902.000049f1@unknown> In-Reply-To: References: <201110010458.26859.vixie@isc.org> <201110011736.27664.vixie@isc.org> Organization: ISC X-Mailer: Claws Mail 3.7.8cvs47 (GTK+ 2.16.6; i586-pc-mingw32msvc) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit 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: Mon, 03 Oct 2011 15:46:36 -0000 On Mon, 3 Oct 2011 15:26:36 +0100 Tony Finch wrote: > Paul Vixie wrote: > > i've got a draft in production that adds an EDNS option "send > > chain" where the option payload is any ancestor of the QNAME and > > indicates the requestor's deepest validated trusted domain name. > > this will solicit a longer trust chain (all the RRSIG, DNSKEY, DS > > RRs) between this ancestor and the QNAME. > > What about support for lookaside trust anchors? i don't think we should enshrine lookaside in dnssec validation, so i was not planning to incorporate that in a "send chain" edns option proposal. complete support for lookaside would include support for ISP-layer data replacement (perhaps under government mandate), as well as enterprise (private keys), and the quasi-public deployment aid represented by DLV. none of these things have a place in my long term vision for ubiquitous DNSSEC, though i have championed DLV as an early deployment aid. -- Paul Vixie From dwessels@verisign.com Mon Oct 3 08:51: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 C22B121F8BC4 for ; Mon, 3 Oct 2011 08:51:35 -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 WgXEzAR9zTUG for ; Mon, 3 Oct 2011 08:51:35 -0700 (PDT) Received: from exprod6og106.obsmtp.com (exprod6og106.obsmtp.com [64.18.1.191]) by ietfa.amsl.com (Postfix) with ESMTP id 077B221F8BC3 for ; Mon, 3 Oct 2011 08:51:34 -0700 (PDT) Received: from peregrine.verisign.com ([216.168.239.74]) (using TLSv1) by exprod6ob106.postini.com ([64.18.5.12]) with SMTP; Mon, 03 Oct 2011 08:54:38 PDT Received: from dul1wnexcn01.vcorp.ad.vrsn.com (dul1wnexcn01.vcorp.ad.vrsn.com [10.170.12.138]) by peregrine.verisign.com (8.13.6/8.13.4) with ESMTP id p93FsSQR023164; Mon, 3 Oct 2011 11:54:28 -0400 Received: from mail.labs.vrsn.com ([10.173.152.121]) by dul1wnexcn01.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 3 Oct 2011 11:54:27 -0400 Received: from [10.100.1.22] (unknown [10.100.1.22]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mail.labs.vrsn.com (Postfix) with ESMTP id B7CA91BC8CA; Mon, 3 Oct 2011 11:54:27 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: "Wessels, Duane" In-Reply-To: <201110010458.26859.vixie@isc.org> Date: Mon, 3 Oct 2011 08:54:24 -0700 Content-Transfer-Encoding: 7bit Message-Id: <8F26AB69-C5BD-47BD-B3F4-6D840E419A23@verisign.com> References: <0394FB3B-6C2B-4D47-B1FA-AA54B7EB1053@kirei.se> <201110010458.26859.vixie@isc.org> To: Paul Vixie X-Mailer: Apple Mail (2.1084) X-OriginalArrivalTime: 03 Oct 2011 15:54:27.0974 (UTC) FILETIME=[BB2D5A60:01CC81E4] Cc: 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: Mon, 03 Oct 2011 15:51:35 -0000 On Sep 30, 2011, at 9:58 PM, Paul Vixie wrote: > I like the binary format first proposed here by Edmonds. I also like that format. > my observation is, we should not be using GET at all, nor should we be > encoding the query into the URI. We should use POST and our request body I have a slight preference for GET over POST. I find GET simpler to implement (maybe code size isn't a concern) and probably more likely to get through. OTOH I also like that POST has the content-length header. DW From vixie@isc.org Mon Oct 3 10:10: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 373E221F8C74 for ; Mon, 3 Oct 2011 10:10:20 -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 p8i4ZfzjhTi1 for ; Mon, 3 Oct 2011 10:10:19 -0700 (PDT) Received: from nsa.vix.com (nsa.vix.com [IPv6:2001:4f8:3:30::3]) by ietfa.amsl.com (Postfix) with ESMTP id A9D7221F8C7F for ; Mon, 3 Oct 2011 10:10:19 -0700 (PDT) Received: from nsa.vix.com (localhost [127.0.0.1]) by nsa.vix.com (Postfix) with ESMTP id 81514A1063 for ; Mon, 3 Oct 2011 17:13:20 +0000 (UTC) (envelope-from vixie@isc.org) Received: from six.localnet (six.vix.com [IPv6:2001:4f8:3:30::2]) by nsa.vix.com (Postfix) with ESMTP id 5A804A1051 for ; Mon, 3 Oct 2011 17:13:20 +0000 (UTC) (envelope-from vixie@isc.org) From: Paul Vixie Organization: ISC To: dnsext@ietf.org Date: Mon, 3 Oct 2011 17:13:19 +0000 User-Agent: KMail/1.13.5 (FreeBSD/8.1-RELEASE; KDE/4.4.5; amd64; ; ) References: <201110010458.26859.vixie@isc.org> <8F26AB69-C5BD-47BD-B3F4-6D840E419A23@verisign.com> In-Reply-To: <8F26AB69-C5BD-47BD-B3F4-6D840E419A23@verisign.com> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201110031713.20103.vixie@isc.org> X-Virus-Scanned: ClamAV using ClamSMTP 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: Mon, 03 Oct 2011 17:10:20 -0000 On Monday, October 03, 2011 15:54:24 Wessels, Duane wrote: > On Sep 30, 2011, at 9:58 PM, Paul Vixie wrote: > > my observation is, we should not be using GET at all, nor should we be > > encoding the query into the URI. We should use POST and our request body > > I have a slight preference for GET over POST. I find GET simpler to > implement (maybe code size isn't a concern) and probably more likely > to get through. OTOH I also like that POST has the content-length > header. what's your view of the need to someday express UPDATE, and to include future extensions to QUERY (like more stuff in the additional section)? if those seem like worthwhile goals, then we really need to put the request into the body rather than into the URI or into the http headers. that calls for POST. From paul.hoffman@vpnc.org Mon Oct 3 10:18:25 2011 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3BE4D21F8C22 for ; Mon, 3 Oct 2011 10:18:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.571 X-Spam-Level: X-Spam-Status: No, score=-102.571 tagged_above=-999 required=5 tests=[AWL=0.028, 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 4JtwKGJwhnGB for ; Mon, 3 Oct 2011 10:18:24 -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 0C5A721F8B56 for ; Mon, 3 Oct 2011 10:18:16 -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 p93HLIPs004215 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Mon, 3 Oct 2011 10:21:19 -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: <201110031713.20103.vixie@isc.org> Date: Mon, 3 Oct 2011 10:21:19 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <54E677EE-0720-4220-9FB8-17EDE978E904@vpnc.org> References: <201110010458.26859.vixie@isc.org> <8F26AB69-C5BD-47BD-B3F4-6D840E419A23@verisign.com> <201110031713.20103.vixie@isc.org> 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: Mon, 03 Oct 2011 17:18:25 -0000 On Oct 3, 2011, at 10:13 AM, Paul Vixie wrote: > On Monday, October 03, 2011 15:54:24 Wessels, Duane wrote: >> On Sep 30, 2011, at 9:58 PM, Paul Vixie wrote: >>> my observation is, we should not be using GET at all, nor should we = be >>> encoding the query into the URI. We should use POST and our request = body >>=20 >> I have a slight preference for GET over POST. I find GET simpler to >> implement (maybe code size isn't a concern) and probably more likely >> to get through. OTOH I also like that POST has the content-length >> header. >=20 > what's your view of the need to someday express UPDATE, and to include = future=20 > extensions to QUERY (like more stuff in the additional section)? if = those=20 > seem like worthwhile goals, then we really need to put the request = into the=20 > body rather than into the URI or into the http headers. that calls = for POST. +1. The slight increase in programming difficulty of using POST vs. GET = buys you a huge amount of flexibility in queries. It's not just about = cache-prevention. --Paul Hoffman From ted.ietf@gmail.com Mon Oct 3 10:29: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 DA6B621F8B4A for ; Mon, 3 Oct 2011 10:29:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.503 X-Spam-Level: X-Spam-Status: No, score=-3.503 tagged_above=-999 required=5 tests=[AWL=0.095, 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 uF7WyM4CDt2b for ; Mon, 3 Oct 2011 10:29:56 -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 840CC21F8C60 for ; Mon, 3 Oct 2011 10:29:44 -0700 (PDT) Received: by ywm3 with SMTP id 3so1336508ywm.31 for ; Mon, 03 Oct 2011 10:32:47 -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=LWz+4jRLcVajWoZO/EVa0b4N7/756t5+R3mOYzGKPlI=; b=FPlQFcSMgzHFrO+COdVppkCs61Ti464WZvAv8b2d8RzLrRpxkBjFMh5Qnxe/rjo5G4 3QXbRlUvMiCPKdgakiCnoL9ZnWKWm/VLQMtqzUW0KDjYAdwOcQxWtpn8zinPWTjik1N2 RyLKQ46MFNvhPUH8B1h8phH/fbP9Hr3Omnp3A= MIME-Version: 1.0 Received: by 10.236.191.71 with SMTP id f47mr1021120yhn.125.1317663167208; Mon, 03 Oct 2011 10:32:47 -0700 (PDT) Received: by 10.236.105.169 with HTTP; Mon, 3 Oct 2011 10:32:47 -0700 (PDT) In-Reply-To: <54E677EE-0720-4220-9FB8-17EDE978E904@vpnc.org> References: <201110010458.26859.vixie@isc.org> <8F26AB69-C5BD-47BD-B3F4-6D840E419A23@verisign.com> <201110031713.20103.vixie@isc.org> <54E677EE-0720-4220-9FB8-17EDE978E904@vpnc.org> Date: Mon, 3 Oct 2011 10:32:47 -0700 Message-ID: From: Ted Hardie To: Paul Hoffman Content-Type: multipart/alternative; boundary=20cf303f649603dd2f04ae685d93 Cc: DNSEXT Working Group 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: Mon, 03 Oct 2011 17:29:57 -0000 --20cf303f649603dd2f04ae685d93 Content-Type: text/plain; charset=ISO-8859-1 On Mon, Oct 3, 2011 at 10:21 AM, Paul Hoffman wrote: > > +1. The slight increase in programming difficulty of using POST vs. GET > buys you a huge amount of flexibility in queries. It's not just about > cache-prevention. > > All silver linings have their clouds... The only unfortunate thing about POST, in my view, is that the flexibility can trend you away from interoperability as people add and change things at different speeds at different hosts. If you want standard behavior the descending list goes: New Method, GET, POST, at least in my view. Since new methods are notoriously hard to get deployed, POST seems like the best choice if you want something that can handle any DNS operation. If it is meant to be only retrieval, then I would personally say that keeping it within GET is the best choice. I'm also increasingly of the opinion that this should have the validation bits sets by default. Allowing a web site to update the local DNS cache for a client system by including a reference and a DNS result for the reference causes my paranoia to ratchet up a few notches. The only other defense against it I see is using Web results only in same-origin web contexts, and that's going to be very hard to make work. Ted --20cf303f649603dd2f04ae685d93 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Mon, Oct 3, 2011 at 10:21 AM, Paul Hoffman <paul.hoffman@vpnc.org> wrot= e:

+1. The slight increase in programming difficulty of using POST vs. G= ET buys you a huge amount of flexibility in queries. It's not just abou= t cache-prevention.


All silver linings have their clouds...=A0 The on= ly unfortunate thing about POST, in my view, is that the flexibility can tr= end you away from interoperability as people add and change things at=A0 di= fferent=A0 speeds at different hosts.=A0 If you want standard behavior the = descending list goes: New Method, GET, POST, at least in my view.

Since new methods are notoriously hard to get deployed, POST seems like= the best choice if you want something that can handle any DNS operation.= =A0 If it is meant to be only retrieval, then I would personally say that k= eeping it within GET is the best choice.

I'm also increasingly of the opinion that this should have the vali= dation bits sets by default.=A0 Allowing a web site to update the local DNS= cache for a client system by including a reference and a DNS result for th= e reference causes my paranoia to ratchet up a few notches.=A0 The only oth= er defense against it I see is using Web results only in same-origin web co= ntexts, and that's going to be very hard to make work.

Ted
--20cf303f649603dd2f04ae685d93-- From dwessels@verisign.com Mon Oct 3 10:32:02 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 0392921F8B26 for ; Mon, 3 Oct 2011 10:32:02 -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 BdPnA2DvYWv3 for ; Mon, 3 Oct 2011 10:32:01 -0700 (PDT) Received: from exprod6og101.obsmtp.com (exprod6og101.obsmtp.com [64.18.1.181]) by ietfa.amsl.com (Postfix) with ESMTP id 3BDB621F8B05 for ; Mon, 3 Oct 2011 10:32:00 -0700 (PDT) Received: from peregrine.verisign.com ([216.168.239.74]) (using TLSv1) by exprod6ob101.postini.com ([64.18.5.12]) with SMTP; Mon, 03 Oct 2011 10:35:04 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 p93HYt15026919; Mon, 3 Oct 2011 13:34:55 -0400 Received: from mail.labs.vrsn.com ([10.173.152.121]) by dul1wnexcn03.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 3 Oct 2011 13:34:55 -0400 Received: from [10.100.1.22] (unknown [10.100.1.22]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mail.labs.vrsn.com (Postfix) with ESMTP id 41E061BC8CA; Mon, 3 Oct 2011 13:34:54 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: "Wessels, Duane" In-Reply-To: <201110031713.20103.vixie@isc.org> Date: Mon, 3 Oct 2011 10:34:48 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <58EB32F9-08D2-4579-BC56-1423C00FC371@verisign.com> References: <201110010458.26859.vixie@isc.org> <8F26AB69-C5BD-47BD-B3F4-6D840E419A23@verisign.com> <201110031713.20103.vixie@isc.org> To: Paul Vixie X-Mailer: Apple Mail (2.1084) X-OriginalArrivalTime: 03 Oct 2011 17:34:55.0613 (UTC) FILETIME=[C3EE12D0:01CC81F2] Cc: 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: Mon, 03 Oct 2011 17:32:02 -0000 On Oct 3, 2011, at 10:13 AM, Paul Vixie wrote: >=20 > what's your view of the need to someday express UPDATE, and to include = future=20 > extensions to QUERY (like more stuff in the additional section)? if = those=20 > seem like worthwhile goals, then we really need to put the request = into the=20 > body rather than into the URI or into the http headers. that calls = for POST. Robert's idea was to take a (binary) UDP message, express it in hex, and = it becomes the URL-pathname. I don't see why you can't also do that with = UPDATE. (I'd add a message TCP-like length prefix, as you suggested, so the = receiver knows it got the whole thing). Maybe your point is that URL length becomes a problem? We've all seen very long URLs I'm sure. =20 Anyway, my preference for GET over POST is not that strong. DW= From vixie@isc.org Mon Oct 3 11:13: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 B525421F8C8B for ; Mon, 3 Oct 2011 11:13:33 -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 28ss8rRfXSUI for ; Mon, 3 Oct 2011 11:13:33 -0700 (PDT) Received: from nsa.vix.com (nsa.vix.com [IPv6:2001:4f8:3:30::3]) by ietfa.amsl.com (Postfix) with ESMTP id E1BC721F8CE8 for ; Mon, 3 Oct 2011 11:13:32 -0700 (PDT) Received: from nsa.vix.com (localhost [127.0.0.1]) by nsa.vix.com (Postfix) with ESMTP id 59BE2A1037 for ; Mon, 3 Oct 2011 18:16:33 +0000 (UTC) (envelope-from vixie@isc.org) Received: from six.localnet (six.vix.com [IPv6:2001:4f8:3:30::2]) by nsa.vix.com (Postfix) with ESMTP id 3CA62A101E for ; Mon, 3 Oct 2011 18:16:33 +0000 (UTC) (envelope-from vixie@isc.org) From: Paul Vixie Organization: ISC To: dnsext@ietf.org Date: Mon, 3 Oct 2011 18:16:32 +0000 User-Agent: KMail/1.13.5 (FreeBSD/8.1-RELEASE; KDE/4.4.5; amd64; ; ) References: <201110031713.20103.vixie@isc.org> <58EB32F9-08D2-4579-BC56-1423C00FC371@verisign.com> In-Reply-To: <58EB32F9-08D2-4579-BC56-1423C00FC371@verisign.com> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201110031816.32959.vixie@isc.org> X-Virus-Scanned: ClamAV using ClamSMTP 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: Mon, 03 Oct 2011 18:13:33 -0000 On Monday, October 03, 2011 17:34:48 Wessels, Duane wrote: > Robert's idea was to take a (binary) UDP message, express it in hex, and it > becomes the URL-pathname. I don't see why you can't also do that with > UPDATE. theoretically we could, yes. > (I'd add a message TCP-like length prefix, as you suggested, so the > receiver knows it got the whole thing). > > Maybe your point is that URL length becomes a problem? We've all seen > very long URLs I'm sure. i'm not sure i've seen 64KB URL's. i have seen 64KB UPDATE's. but it's not the size that concerns me, rather the content-aware routers out there who may or may not respect our http cacheability headers. we have no need of another layer of caching at the transport layer, especially if it means we have to translate our DNS TTL's into http expiration times. and i don't know how to reliably avoid that caching on this data path if we use GET. > Anyway, my preference for GET over POST is not that strong. does anyone here have anecdotal evidence of POST being intercepted by a content aware router, or otherwise painfully middleboxed the way GET so often is? at the moment i've got three weak reasons for preferring POST, but if any of the three is silly, they would not add up to a strong preference as they do (for me) at the moment. paul From alex@alex.org.uk Mon Oct 3 11:28:54 2011 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8E52B21F8CAB for ; Mon, 3 Oct 2011 11:28:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.569 X-Spam-Level: X-Spam-Status: No, score=-2.569 tagged_above=-999 required=5 tests=[AWL=0.030, 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 RUVhQnks7gmj for ; Mon, 3 Oct 2011 11:28:54 -0700 (PDT) Received: from mail.avalus.com (mail.avalus.com [IPv6:2001:41c8:10:1dd::10]) by ietfa.amsl.com (Postfix) with ESMTP id 07EAA21F8C89 for ; Mon, 3 Oct 2011 11:28:53 -0700 (PDT) Received: from [192.168.100.16] (87-194-71-186.bethere.co.uk [87.194.71.186]) by mail.avalus.com (Postfix) with ESMTPSA id E5A44C56104; Mon, 3 Oct 2011 19:31:53 +0100 (BST) Date: Mon, 03 Oct 2011 19:31:52 +0100 From: Alex Bligh To: Paul Vixie , dnsext@ietf.org Message-ID: In-Reply-To: <201110031816.32959.vixie@isc.org> References: <201110031713.20103.vixie@isc.org> <58EB32F9-08D2-4579-BC56-1423C00FC371@verisign.com> <201110031816.32959.vixie@isc.org> X-Mailer: Mulberry/4.0.8 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Subject: Re: [dnsext] draft-mohan-dns-query-xml-00.txt X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Alex Bligh List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Oct 2011 18:28:54 -0000 --On 3 October 2011 18:16:32 +0000 Paul Vixie wrote: > i'm not sure i've seen 64KB URL's. i have seen 64KB UPDATE's. but it's > not the size that concerns me, rather the content-aware routers out > there who may or may not respect our http cacheability headers. I would also bet money that application layer interceptors of http traffic are more likely to fail on 64KB GET URLs than 64KB POST. I presume we could base64 encode POST data if we couldn't send it binary, whereas IIRC we couldn't do much more than hex encode GET URLs. So +1 for POST here, with body content as close to UDP message format as possible, save that we should surely be able to junk a pile of UDP restrictions (e.g. we can surely mandate EDNS, assume 'packet' size can 2^32 bytes, etc.). I presume we also don't need UDP headers etc. -- Alex Bligh From vixie@isc.org Mon Oct 3 11:38:39 2011 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B05F021F8D4D for ; Mon, 3 Oct 2011 11:38:39 -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 ByJjrauAE4rs for ; Mon, 3 Oct 2011 11:38:39 -0700 (PDT) Received: from nsa.vix.com (nsa.vix.com [IPv6:2001:4f8:3:30::3]) by ietfa.amsl.com (Postfix) with ESMTP id 3EC9121F8D2B for ; Mon, 3 Oct 2011 11:38:39 -0700 (PDT) Received: from nsa.vix.com (localhost [127.0.0.1]) by nsa.vix.com (Postfix) with ESMTP id 168B6A1058 for ; Mon, 3 Oct 2011 18:41:42 +0000 (UTC) (envelope-from vixie@isc.org) Received: from six.localnet (six.vix.com [IPv6:2001:4f8:3:30::2]) by nsa.vix.com (Postfix) with ESMTP id E4076A1021 for ; Mon, 3 Oct 2011 18:41:41 +0000 (UTC) (envelope-from vixie@isc.org) From: Paul Vixie Organization: ISC To: dnsext@ietf.org Date: Mon, 3 Oct 2011 18:41:41 +0000 User-Agent: KMail/1.13.5 (FreeBSD/8.1-RELEASE; KDE/4.4.5; amd64; ; ) References: <201110031816.32959.vixie@isc.org> In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201110031841.41629.vixie@isc.org> X-Virus-Scanned: ClamAV using ClamSMTP 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: Mon, 03 Oct 2011 18:38:39 -0000 On Monday, October 03, 2011 18:31:52 Alex Bligh wrote: > I presume we could base64 encode POST data if we couldn't send it > binary, whereas IIRC we couldn't do much more than hex encode GET URLs. the ability to base64-encode POST data is part of the HTTP spec, so yes. the response could also come back encoded that way. this is supposed to be "just web traffic." > So +1 for POST here, with body content as close to UDP message format > as possible, save that we should surely be able to junk a pile of UDP > restrictions (e.g. we can surely mandate EDNS, assume 'packet' size > can 2^32 bytes, etc.). I presume we also don't need UDP headers etc. i don't think we should overly constrain the message (like mandating EDNS) since this adds test cases to compliance suites and precludes future DNS protocol extensions that could be better than EDNS. we would only include the DNS message, which UDP thinks of as a "payload"; not the transport or network headers. also note, this isn't necessarily a tunneling protocol -- if it's used by a stub then there is no underlying UDP packet to pull anything from. and where it is used as a tunneling protocol, the underlying DNS message could have arrived via TCP/53 or even HTTP. paul From suruti94@gmail.com Mon Oct 3 12:19: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 2F71E21F8DF6 for ; Mon, 3 Oct 2011 12:19:44 -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 DCf4QPZU87C4 for ; Mon, 3 Oct 2011 12:19:43 -0700 (PDT) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 7621821F8DF2 for ; Mon, 3 Oct 2011 12:19:43 -0700 (PDT) Received: by vws5 with SMTP id 5so4768874vws.31 for ; Mon, 03 Oct 2011 12:22:46 -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=KA+zT1JCYg9azbNo9wfA2JYfHVuvj32UI4veAuvhigg=; b=g+eonugDV1fzlrsUjhAFQ5vsJA3yatH7HLM6WVayoilFUhhGZOtJ7FxDxZhk+cR1Bi wXsRFC7ndwrQAPWsnJuSyNWiVUOuig9RldOupCEvhjyCVL2gti9AQ554gq2L/xb5JdOl 4nBKJdRGA3oxMvHAo8uDrrBVULF20kT+1+bck= MIME-Version: 1.0 Received: by 10.68.19.2 with SMTP id a2mr3417718pbe.72.1317669765081; Mon, 03 Oct 2011 12:22:45 -0700 (PDT) Received: by 10.68.46.200 with HTTP; Mon, 3 Oct 2011 12:22:44 -0700 (PDT) In-Reply-To: References: <201110010458.26859.vixie@isc.org> <8F26AB69-C5BD-47BD-B3F4-6D840E419A23@verisign.com> <201110031713.20103.vixie@isc.org> <54E677EE-0720-4220-9FB8-17EDE978E904@vpnc.org> Date: Mon, 3 Oct 2011 12:22:44 -0700 Message-ID: From: Mohan Parthasarathy To: Ted Hardie Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Paul Hoffman , DNSEXT Working Group 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: Mon, 03 Oct 2011 19:19:44 -0000 On Mon, Oct 3, 2011 at 10:32 AM, Ted Hardie wrote: > On Mon, Oct 3, 2011 at 10:21 AM, Paul Hoffman wro= te: >> >> +1. The slight increase in programming difficulty of using POST vs. GET >> buys you a huge amount of flexibility in queries. It's not just about >> cache-prevention. >> > > All silver linings have their clouds...=A0 The only unfortunate thing abo= ut > POST, in my view, is that the flexibility can trend you away from > interoperability as people add and change things at=A0 different=A0 speed= s at > different hosts.=A0 If you want standard behavior the descending list goe= s: > New Method, GET, POST, at least in my view. > > Since new methods are notoriously hard to get deployed, POST seems like t= he > best choice if you want something that can handle any DNS operation.=A0 I= f it > is meant to be only retrieval, then I would personally say that keeping i= t > within GET is the best choice. > > I'm also increasingly of the opinion that this should have the validation > bits sets by default.=A0 Allowing a web site to update the local DNS cach= e for > a client system by including a reference and a DNS result for the referen= ce > causes my paranoia to ratchet up a few notches.=A0 The only other defense > against it I see is using Web results only in same-origin web contexts, a= nd > that's going to be very hard to make work. > I am not sure I understand this concern fully. I guess you mean that you want to use this only with CD =3D1 which also implies that you want to use only with DNSSEC . Though this is the primary use case that this draft is trying to address, should we restrict it ? Previously, your concern was cache poisoning of the HTTP proxies having an impact on DNS. If we require HTTPS and POST, is this still a concern ? -mohan > Ted > > _______________________________________________ > dnsext mailing list > dnsext@ietf.org > https://www.ietf.org/mailman/listinfo/dnsext > > From ted.ietf@gmail.com Mon Oct 3 13:22: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 0FB0521F8DB5 for ; Mon, 3 Oct 2011 13:22:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.505 X-Spam-Level: X-Spam-Status: No, score=-3.505 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 E1i13q+mbHxi for ; Mon, 3 Oct 2011 13:22:25 -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 A9B1921F8D4F for ; Mon, 3 Oct 2011 13:22:25 -0700 (PDT) Received: by yxt33 with SMTP id 33so4855318yxt.31 for ; Mon, 03 Oct 2011 13:25:28 -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=vzeH9dDVX3ZTnvXnJ8gUySuLzefQyCZqQaCesv1svxI=; b=uckVYBcjFWwxa04LzQBkscLk4WD5yNoARfg0hBb9iW8rkJmUTZCVfKcZ0Hlg4qLXo9 DagLJYC3CaZTeZlrIG7Fwy5kpemsSEr3ZUiUg8XilMrrBmBO86DyTPs1YQtgI8yhFYi0 G5dCVNGwqzjNUiUu12I2J6e7F5L7ajHQOCdFM= MIME-Version: 1.0 Received: by 10.236.127.144 with SMTP id d16mr2342327yhi.40.1317673528477; Mon, 03 Oct 2011 13:25:28 -0700 (PDT) Received: by 10.236.105.169 with HTTP; Mon, 3 Oct 2011 13:25:27 -0700 (PDT) In-Reply-To: References: <201110010458.26859.vixie@isc.org> <8F26AB69-C5BD-47BD-B3F4-6D840E419A23@verisign.com> <201110031713.20103.vixie@isc.org> <54E677EE-0720-4220-9FB8-17EDE978E904@vpnc.org> Date: Mon, 3 Oct 2011 13:25:27 -0700 Message-ID: From: Ted Hardie To: Mohan Parthasarathy Content-Type: multipart/alternative; boundary=20cf3010e3c598468004ae6ac644 Cc: Paul Hoffman , DNSEXT Working Group 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: Mon, 03 Oct 2011 20:22:27 -0000 --20cf3010e3c598468004ae6ac644 Content-Type: text/plain; charset=ISO-8859-1 On Mon, Oct 3, 2011 at 12:22 PM, Mohan Parthasarathy wrote: > On Mon, Oct 3, 2011 at 10:32 AM, Ted Hardie wrote: > > On Mon, Oct 3, 2011 at 10:21 AM, Paul Hoffman > wrote: > > > > I'm also increasingly of the opinion that this should have the validation > > bits sets by default. Allowing a web site to update the local DNS cache > for > > a client system by including a reference and a DNS result for the > reference > > causes my paranoia to ratchet up a few notches. The only other defense > > against it I see is using Web results only in same-origin web contexts, > and > > that's going to be very hard to make work. > > > > I am not sure I understand this concern fully. I guess you mean that > you want to use this only with CD =1 which also implies that you want > to use only with DNSSEC . Though this is the primary use case that > this draft is trying to address, should we restrict it ? Previously, > your concern was cache poisoning of the HTTP proxies having an impact > on DNS. If we require HTTPS and POST, is this still a concern ? > > Well, I don't think you can functionally say that it can only be used with DNSSEC at the protocol level; there's always the risk that you want to use it for some zone that hasn't been signed. But I think we're going to have to strongly suggest that it should be used when DNSSEC validation can be done and, if it has not been, how to handle the results with respect to the local cache. If I am a helpful web site with the ability to do this DNS return, I could theoretically get slightly higher speed for web page loads by providing the DNS data for the component loads along with the initial return. If those can be trusted because of DNSSEC validation, using the data and storing it in the local cache for use by other applications (subject to TTL expiry etc.) should be fine. But if I cannot validate it, then I have to have some other trust model for the data. One potential model is to use (but likely not store) data with the same origin as the web server from which I got it. So if I land at financial.example.com, I use the data it gives me for nasdaq.financial.example.com and sp500.financial.example.com, but not for ftse.example.co.uk or, even worse, for social.network.com of deposit.bank.com. It's still a cache poisoning problem, but it is the local cache that might be poisoned in this worry. In the case where you are getting this from a 3rd party DNS provider which supports HTTPS transport, the trust is presumably between you and that provider. That may be the initial use case. But I'm guessing that once this is available, other uses, included blended content/DNS returns will occur. regards, Ted -mohan > > > Ted > > > > _______________________________________________ > > dnsext mailing list > > dnsext@ietf.org > > https://www.ietf.org/mailman/listinfo/dnsext > > > > > --20cf3010e3c598468004ae6ac644 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Mon, Oct 3, 2011 at 12:22 PM, Mohan Parthasarathy <= suruti94@gmail.com> wro= te:
On Mon, Oct 3, 2011 at 10:32 AM, Ted Hard= ie <ted.ietf@gmail.com> wro= te:
> On Mon, Oct 3, 2011 at 10:21 AM, Paul Hoffman <paul.hoffman@vpnc.org> wrote:
>
> I'm also increasingly of the opinion that this should have the val= idation
> bits sets by default.=A0 Allowing a web site to update the local DNS c= ache for
> a client system by including a reference and a DNS result for the refe= rence
> causes my paranoia to ratchet up a few notches.=A0 The only other defe= nse
> against it I see is using Web results only in same-origin web contexts= , and
> that's going to be very hard to make work.
>

I am not sure I understand this concern fully. I guess you mean= that
you want to use this only with CD =3D1 which also implies that you want
to use only with DNSSEC . Though this is the primary use case that
this draft is trying to address, should we restrict it ? Previously,
your concern was cache poisoning of the HTTP proxies having an impact
on DNS. If we require HTTPS and POST, is this still a concern ?


Well, I don't think you can functionally say = that it can only be used with DNSSEC at the protocol level; there's alw= ays the risk that you want to use it for some zone that hasn't been sig= ned.=A0 But I think we're going to have to strongly suggest that it sho= uld be used when DNSSEC validation can be done and, if it has not been, how= to handle the results with respect to the local cache.

If I am a helpful web site with the ability to do this DNS return, I co= uld theoretically get slightly higher speed for web page loads by providing= the DNS data for the component loads along with the initial return.=A0 If = those can be trusted because of DNSSEC validation, using the data and stori= ng it in the local cache for use by other applications (subject to TTL expi= ry etc.) should be fine.=A0 But if I cannot validate it, then I have to hav= e some other trust model for the data.=A0 One potential model is to use (bu= t likely not store) data with the same origin as the web server from which = I got it.=A0 So if I land at finan= cial.example.com, I use the data it gives me for nasdaq.financial.example.com and sp500.financial.example.com, but not= for ftse.example.co.uk or, even = worse, for social.network.com of = deposit.bank.com.

It's still a cache poisoning problem, but it is the local cache tha= t might be poisoned in this worry.

In the case where you are getting= this from a 3rd party DNS provider which supports HTTPS transport, the tru= st is presumably between you and that provider.=A0 That may be the initial = use case.=A0 But I'm guessing that once this is available, other uses, = included blended content/DNS returns will occur.

regards,

Ted



-mohan

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

--20cf3010e3c598468004ae6ac644-- From mohta@necom830.hpcl.titech.ac.jp Mon Oct 3 14:55:45 2011 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C106821F8E8C for ; Mon, 3 Oct 2011 14:55:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.036 X-Spam-Level: X-Spam-Status: No, score=-0.036 tagged_above=-999 required=5 tests=[AWL=0.054, 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 3YDWtUYoTqSW for ; Mon, 3 Oct 2011 14:55:45 -0700 (PDT) Received: from necom830.hpcl.titech.ac.jp (necom830.hpcl.titech.ac.jp [131.112.32.132]) by ietfa.amsl.com (Postfix) with SMTP id C672B21F8E89 for ; Mon, 3 Oct 2011 14:55:44 -0700 (PDT) Received: (qmail 35670 invoked from network); 3 Oct 2011 22:13:25 -0000 Received: from necom830.hpcl.titech.ac.jp (HELO ?127.0.0.1?) (131.112.32.132) by necom830.hpcl.titech.ac.jp with SMTP; 3 Oct 2011 22:13:25 -0000 Message-ID: <4E8A3043.1060203@necom830.hpcl.titech.ac.jp> Date: Tue, 04 Oct 2011 06:59:31 +0900 From: Masataka Ohta User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: dnsext@ietf.org References: <201110010458.26859.vixie@isc.org> <8F26AB69-C5BD-47BD-B3F4-6D840E419A23@verisign.com> <201110031713.20103.vixie@isc.org> <54E677EE-0720-4220-9FB8-17EDE978E904@vpnc.org> In-Reply-To: Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit 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: Mon, 03 Oct 2011 21:55:45 -0000 Mohan Parthasarathy wrote: > Though this is the primary use case that > this draft is trying to address, The primary use case is not clear. How can a client know an address of an HTTP server? How can a client know secure time? Both are important information of a use case. Masataka Ohta From marka@isc.org Mon Oct 3 17:13:36 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 0C6B721F8F26 for ; Mon, 3 Oct 2011 17:13:36 -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 2WirneynejAE for ; Mon, 3 Oct 2011 17:13:35 -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 784C321F8F24 for ; Mon, 3 Oct 2011 17:13:31 -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 B7952C9496; Tue, 4 Oct 2011 00:16:16 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (unknown [IPv6:2001:470:1f00:820:6233:4bff:fe01:7585]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by bikeshed.isc.org (Postfix) with ESMTPSA id 692AC216C36; Tue, 4 Oct 2011 00:16:13 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (Postfix) with ESMTP id 7ED7C149063F; Tue, 4 Oct 2011 11:15:47 +1100 (EST) To: Mohan Parthasarathy From: Mark Andrews References: <201110010458.26859.vixie@isc.org> <8F26AB69-C5BD-47BD-B3F4-6D840E419A23@verisign.com> <201110031713.20103.vixie@isc.org> <54E677EE-0720-4220-9FB8-17EDE978E904@vpnc.org> In-reply-to: Your message of "Mon, 03 Oct 2011 12:22:44 PDT." Date: Tue, 04 Oct 2011 11:15:47 +1100 Message-Id: <20111004001547.7ED7C149063F@drugs.dv.isc.org> Cc: Paul Hoffman , DNSEXT Working Group 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: Tue, 04 Oct 2011 00:13:36 -0000 In message , Mohan Parthasarathy writes: > On Mon, Oct 3, 2011 at 10:32 AM, Ted Hardie wrote: > > On Mon, Oct 3, 2011 at 10:21 AM, Paul Hoffman wro= > te: > >> > >> +1. The slight increase in programming difficulty of using POST vs. GET > >> buys you a huge amount of flexibility in queries. It's not just about > >> cache-prevention. > >> > > > > All silver linings have their clouds...=A0 The only unfortunate thing abo= > ut > > POST, in my view, is that the flexibility can trend you away from > > interoperability as people add and change things at=A0 different=A0 speed= > s at > > different hosts.=A0 If you want standard behavior the descending list goe= > s: > > New Method, GET, POST, at least in my view. > > > > Since new methods are notoriously hard to get deployed, POST seems like t= > he > > best choice if you want something that can handle any DNS operation.=A0 I= > f it > > is meant to be only retrieval, then I would personally say that keeping it > > within GET is the best choice. > > > > I'm also increasingly of the opinion that this should have the validation > > bits sets by default.=A0 Allowing a web site to update the local DNS cach= > e for > > a client system by including a reference and a DNS result for the referen= > ce > > causes my paranoia to ratchet up a few notches.=A0 The only other defense > > against it I see is using Web results only in same-origin web contexts, a= > nd > > that's going to be very hard to make work. > > > > I am not sure I understand this concern fully. I guess you mean that > you want to use this only with CD =3D1 which also implies that you want > to use only with DNSSEC . Though this is the primary use case that > this draft is trying to address, should we restrict it ? Previously, > your concern was cache poisoning of the HTTP proxies having an impact > on DNS. If we require HTTPS and POST, is this still a concern ? DO=1 implies DNSSEC. Stubs/forwarders SHOULD NOT set CD=1. The upstream validator needs to filter out the spoofed responses on behalf of the stub/forwarder. Also it is just a "DNS message". UDP/TCP/HTTP/HTTPS is just the transport for the DNS message. > -mohan > > > Ted > > > > _______________________________________________ > > dnsext mailing list > > dnsext@ietf.org > > https://www.ietf.org/mailman/listinfo/dnsext > > > > > _______________________________________________ > dnsext mailing list > dnsext@ietf.org > https://www.ietf.org/mailman/listinfo/dnsext -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From suruti94@gmail.com Mon Oct 3 19:32:54 2011 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4CAC821F8CC4 for ; Mon, 3 Oct 2011 19:32:54 -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 JDopq7a7DoBW for ; Mon, 3 Oct 2011 19:32:53 -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 8953B21F8CB5 for ; Mon, 3 Oct 2011 19:32:53 -0700 (PDT) Received: by ggnk3 with SMTP id k3so757717ggn.31 for ; Mon, 03 Oct 2011 19:35:57 -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=aTeXVENQ4oewLta6irCykCo4g4DFtqiiv2Ycavqw+Ow=; b=vJ0yjufPmkJiJ0PkNLb9UJHZ+YpM11rqxOaHngfwy6ppra8KEgYTHoE9M3eaw+GP6r mr8VEe1DsvuzjjKOkPtu24Qb/pGBxqAVaaxBVa5EojA7Vn9MqxayW09eRIrqKEkjlTvA u+dU0jSgnAO2StJBmULTOAb8lMJXCUDqn9GSM= MIME-Version: 1.0 Received: by 10.68.9.104 with SMTP id y8mr5951732pba.21.1317695756666; Mon, 03 Oct 2011 19:35:56 -0700 (PDT) Received: by 10.68.46.200 with HTTP; Mon, 3 Oct 2011 19:35:56 -0700 (PDT) In-Reply-To: <20111004001547.7ED7C149063F@drugs.dv.isc.org> References: <201110010458.26859.vixie@isc.org> <8F26AB69-C5BD-47BD-B3F4-6D840E419A23@verisign.com> <201110031713.20103.vixie@isc.org> <54E677EE-0720-4220-9FB8-17EDE978E904@vpnc.org> <20111004001547.7ED7C149063F@drugs.dv.isc.org> Date: Mon, 3 Oct 2011 19:35:56 -0700 Message-ID: From: Mohan Parthasarathy To: Mark Andrews Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Paul Hoffman , DNSEXT Working Group 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: Tue, 04 Oct 2011 02:32:54 -0000 On Mon, Oct 3, 2011 at 5:15 PM, Mark Andrews wrote: > > In message , Mohan Parthasarathy writes: >> On Mon, Oct 3, 2011 at 10:32 AM, Ted Hardie wrote: >> > On Mon, Oct 3, 2011 at 10:21 AM, Paul Hoffman = wro=3D >> te: >> >> >> >> +1. The slight increase in programming difficulty of using POST vs. G= ET >> >> buys you a huge amount of flexibility in queries. It's not just about >> >> cache-prevention. >> >> >> > >> > All silver linings have their clouds...=3DA0 The only unfortunate thin= g abo=3D >> ut >> > POST, in my view, is that the flexibility can trend you away from >> > interoperability as people add and change things at=3DA0 different=3DA= 0 speed=3D >> s at >> > different hosts.=3DA0 If you want standard behavior the descending lis= t goe=3D >> s: >> > New Method, GET, POST, at least in my view. >> > >> > Since new methods are notoriously hard to get deployed, POST seems lik= e t=3D >> he >> > best choice if you want something that can handle any DNS operation.= =3DA0 I=3D >> f it >> > is meant to be only retrieval, then I would personally say that keepin= g it >> > within GET is the best choice. >> > >> > I'm also increasingly of the opinion that this should have the validat= ion >> > bits sets by default.=3DA0 Allowing a web site to update the local DNS= cach=3D >> e for >> > a client system by including a reference and a DNS result for the refe= ren=3D >> ce >> > causes my paranoia to ratchet up a few notches.=3DA0 The only other de= fense >> > against it I see is using Web results only in same-origin web contexts= , a=3D >> nd >> > that's going to be very hard to make work. >> > >> >> I am not sure I understand this concern fully. I guess you mean that >> you want to use this only with CD =3D3D1 which also implies that you wan= t >> to use only with DNSSEC . Though this is the primary use case that >> this draft is trying to address, should we restrict it ? Previously, >> your concern was cache poisoning of the HTTP proxies having an impact >> on DNS. If we require HTTPS and POST, is this still a concern ? > > DO=3D1 implies DNSSEC. =A0Stubs/forwarders SHOULD NOT set CD=3D1. =A0The > upstream validator needs to filter out the spoofed responses > on behalf of the stub/forwarder. > > Also it is just a "DNS message". =A0UDP/TCP/HTTP/HTTPS is just the > transport for the DNS message. > If a validating stub resolver can set CD =3D 1 for UDP/TCP why not for HTTP or HTTPS ? -mohan >> -mohan >> >> > Ted >> > >> > _______________________________________________ >> > dnsext mailing list >> > dnsext@ietf.org >> > https://www.ietf.org/mailman/listinfo/dnsext >> > >> > >> _______________________________________________ >> dnsext mailing list >> dnsext@ietf.org >> https://www.ietf.org/mailman/listinfo/dnsext > -- > Mark Andrews, ISC > 1 Seymour St., Dundas Valley, NSW 2117, Australia > PHONE: +61 2 9871 4742 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 INTERNET: marka@is= c.org > From marka@isc.org Mon Oct 3 19:52: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 2C96121F8CDC for ; Mon, 3 Oct 2011 19:52:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.001 X-Spam-Level: ** X-Spam-Status: No, score=2.001 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MANGLED_LIST=2.3, MANGLED_WANT=2.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 5+fGhs29jQ6c for ; Mon, 3 Oct 2011 19:52:22 -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 2A21921F8C70 for ; Mon, 3 Oct 2011 19:52: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.ams1.isc.org (Postfix) with ESMTPS id BCC325F98E9; Tue, 4 Oct 2011 02:55:10 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (unknown [IPv6:2001:470:1f00:820:6233:4bff:fe01:7585]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by bikeshed.isc.org (Postfix) with ESMTPSA id 75865216C56; Tue, 4 Oct 2011 02:55: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 504DD14924EC; Tue, 4 Oct 2011 13:55:02 +1100 (EST) To: Mohan Parthasarathy From: Mark Andrews References: <201110010458.26859.vixie@isc.org> <8F26AB69-C5BD-47BD-B3F4-6D840E419A23@verisign.com> <201110031713.20103.vixie@isc.org> <54E677EE-0720-4220-9FB8-17EDE978E904@vpnc.org> <20111004001547.7ED7C149063F@drugs.dv.isc.org> In-reply-to: Your message of "Mon, 03 Oct 2011 19:35:56 PDT." Date: Tue, 04 Oct 2011 13:55:02 +1100 Message-Id: <20111004025502.504DD14924EC@drugs.dv.isc.org> Cc: Paul Hoffman , DNSEXT Working Group 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: Tue, 04 Oct 2011 02:52:23 -0000 In message , Mohan Parthasarathy writes: > On Mon, Oct 3, 2011 at 5:15 PM, Mark Andrews wrote: > > > > In message l.com>, Mohan Parthasarathy writes: > >> On Mon, Oct 3, 2011 at 10:32 AM, Ted Hardie wrote: > >> > On Mon, Oct 3, 2011 at 10:21 AM, Paul Hoffman = > wro=3D > >> te: > >> >> > >> >> +1. The slight increase in programming difficulty of using POST vs. G= > ET > >> >> buys you a huge amount of flexibility in queries. It's not just about > >> >> cache-prevention. > >> >> > >> > > >> > All silver linings have their clouds...=3DA0 The only unfortunate thin= > g abo=3D > >> ut > >> > POST, in my view, is that the flexibility can trend you away from > >> > interoperability as people add and change things at=3DA0 different=3DA= > 0 speed=3D > >> s at > >> > different hosts.=3DA0 If you want standard behavior the descending lis= > t goe=3D > >> s: > >> > New Method, GET, POST, at least in my view. > >> > > >> > Since new methods are notoriously hard to get deployed, POST seems lik= > e t=3D > >> he > >> > best choice if you want something that can handle any DNS operation.= > =3DA0 I=3D > >> f it > >> > is meant to be only retrieval, then I would personally say that keepin= > g it > >> > within GET is the best choice. > >> > > >> > I'm also increasingly of the opinion that this should have the validat= > ion > >> > bits sets by default.=3DA0 Allowing a web site to update the local DNS= > cach=3D > >> e for > >> > a client system by including a reference and a DNS result for the refe= > ren=3D > >> ce > >> > causes my paranoia to ratchet up a few notches.=3DA0 The only other de= > fense > >> > against it I see is using Web results only in same-origin web contexts= > , a=3D > >> nd > >> > that's going to be very hard to make work. > >> > > >> > >> I am not sure I understand this concern fully. I guess you mean that > >> you want to use this only with CD =3D3D1 which also implies that you wan= > t > >> to use only with DNSSEC . Though this is the primary use case that > >> this draft is trying to address, should we restrict it ? Previously, > >> your concern was cache poisoning of the HTTP proxies having an impact > >> on DNS. If we require HTTPS and POST, is this still a concern ? > > > > DO=3D1 implies DNSSEC. =A0Stubs/forwarders SHOULD NOT set CD=3D1. =A0The > > upstream validator needs to filter out the spoofed responses > > on behalf of the stub/forwarder. > > > > Also it is just a "DNS message". =A0UDP/TCP/HTTP/HTTPS is just the > > transport for the DNS message. > > > > If a validating stub resolver can set CD =3D 1 for UDP/TCP why not for > HTTP or HTTPS ? A validating stub resolver really doesn't want to set CD=1, by default. If it gets SERVFAIL back to a CD=0 query then resending with CD=1, may help if the SERVFAIL was a validation failure caused by a bad clock on the recursive server / out of date trust anchors. A stub resolver *needs* the upstream server to weed out the bogus responses due to spoofing or, more likely, operational stuff ups and only pass through those that pass validation. Remember a stub resolver does not have access to multiple authoritative sources, only the recursive server does. If you are willing to bet that every response you get back is good then always set CD=1 otherwise CD=1 should only be set if the CD=0 lookup fails. > -mohan > > >> -mohan > >> > >> > Ted > >> > > >> > _______________________________________________ > >> > dnsext mailing list > >> > dnsext@ietf.org > >> > https://www.ietf.org/mailman/listinfo/dnsext > >> > > >> > > >> _______________________________________________ > >> dnsext mailing list > >> dnsext@ietf.org > >> https://www.ietf.org/mailman/listinfo/dnsext > > -- > > Mark Andrews, ISC > > 1 Seymour St., Dundas Valley, NSW 2117, Australia > > PHONE: +61 2 9871 4742 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 INTERNET: marka@is= > c.org > > -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From suruti94@gmail.com Mon Oct 3 20:14:57 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 2224921F8EE0 for ; Mon, 3 Oct 2011 20:14:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.397 X-Spam-Level: ** X-Spam-Status: No, score=2.397 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MANGLED_LIST=2.3, MANGLED_WANT=2.3, MIME_QP_LONG_LINE=1.396, 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 CL8ytoH4aToS for ; Mon, 3 Oct 2011 20:14:56 -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 43FFD21F8EDF for ; Mon, 3 Oct 2011 20:14:56 -0700 (PDT) Received: by gyd12 with SMTP id 12so67922gyd.31 for ; Mon, 03 Oct 2011 20:17:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=references:in-reply-to:mime-version:content-transfer-encoding :content-type:message-id:cc:x-mailer:from:subject:date:to; bh=qRB4W0qv2h9DsV/M2oyDWoUwwAIh4DUg/O5w3hplTwM=; b=j59X+SlF3qpAqSV/Dq6CDSk924jPOsx+xHSgtNLl7WiomsG97+NlRI81bIbHjdDHou s0gDTBD6LJo39h625W1uzBS5u1fa6mSA+WAlfbVymLxffu82a4ltEVL+Z9ap4RbgU5Of h3M9AvGFgELTEVbH9HzFh2mKlPHvqpizDHLlY= Received: by 10.236.143.99 with SMTP id k63mr3672123yhj.64.1317698278959; Mon, 03 Oct 2011 20:17:58 -0700 (PDT) Received: from [10.89.135.116] ([166.205.138.53]) by mx.google.com with ESMTPS id w70sm18148120yhk.6.2011.10.03.20.17.56 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 03 Oct 2011 20:17:58 -0700 (PDT) References: <201110010458.26859.vixie@isc.org> <8F26AB69-C5BD-47BD-B3F4-6D840E419A23@verisign.com> <201110031713.20103.vixie@isc.org> <54E677EE-0720-4220-9FB8-17EDE978E904@vpnc.org> <20111004001547.7ED7C149063F@drugs.dv.isc.org> <20111004025502.504DD14924EC@drugs.dv.isc.org> In-Reply-To: <20111004025502.504DD14924EC@drugs.dv.isc.org> Mime-Version: 1.0 (iPhone Mail 8L1) Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Message-Id: X-Mailer: iPhone Mail (8L1) From: Mohan Date: Mon, 3 Oct 2011 20:17:48 -0700 To: Mark Andrews Cc: Paul Hoffman , DNSEXT Working Group 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: Tue, 04 Oct 2011 03:14:57 -0000 On Oct 3, 2011, at 7:55 PM, Mark Andrews wrote: >=20 > In message > , Mohan Parthasarathy writes: >> On Mon, Oct 3, 2011 at 5:15 PM, Mark Andrews wrote: >>>=20 >>> In message > l.com>, Mohan Parthasarathy writes: >>>> On Mon, Oct 3, 2011 at 10:32 AM, Ted Hardie wrote:= >>>>> On Mon, Oct 3, 2011 at 10:21 AM, Paul Hoffman =3D= >> wro=3D3D >>>> te: >>>>>>=20 >>>>>> +1. The slight increase in programming difficulty of using POST vs. G= =3D >> ET >>>>>> buys you a huge amount of flexibility in queries. It's not just about= >>>>>> cache-prevention. >>>>>>=20 >>>>>=20 >>>>> All silver linings have their clouds...=3D3DA0 The only unfortunate th= in=3D >> g abo=3D3D >>>> ut >>>>> POST, in my view, is that the flexibility can trend you away from >>>>> interoperability as people add and change things at=3D3DA0 different=3D= 3DA=3D >> 0 speed=3D3D >>>> s at >>>>> different hosts.=3D3DA0 If you want standard behavior the descending l= is=3D >> t goe=3D3D >>>> s: >>>>> New Method, GET, POST, at least in my view. >>>>>=20 >>>>> Since new methods are notoriously hard to get deployed, POST seems lik= =3D >> e t=3D3D >>>> he >>>>> best choice if you want something that can handle any DNS operation.=3D= >> =3D3DA0 I=3D3D >>>> f it >>>>> is meant to be only retrieval, then I would personally say that keepin= =3D >> g it >>>>> within GET is the best choice. >>>>>=20 >>>>> I'm also increasingly of the opinion that this should have the validat= =3D >> ion >>>>> bits sets by default.=3D3DA0 Allowing a web site to update the local D= NS=3D >> cach=3D3D >>>> e for >>>>> a client system by including a reference and a DNS result for the refe= =3D >> ren=3D3D >>>> ce >>>>> causes my paranoia to ratchet up a few notches.=3D3DA0 The only other d= e=3D >> fense >>>>> against it I see is using Web results only in same-origin web contexts= =3D >> , a=3D3D >>>> nd >>>>> that's going to be very hard to make work. >>>>>=20 >>>>=20 >>>> I am not sure I understand this concern fully. I guess you mean that >>>> you want to use this only with CD =3D3D3D1 which also implies that you w= an=3D >> t >>>> to use only with DNSSEC . Though this is the primary use case that >>>> this draft is trying to address, should we restrict it ? Previously, >>>> your concern was cache poisoning of the HTTP proxies having an impact >>>> on DNS. If we require HTTPS and POST, is this still a concern ? >>>=20 >>> DO=3D3D1 implies DNSSEC. =3DA0Stubs/forwarders SHOULD NOT set CD=3D3D1. =3D= A0The >>> upstream validator needs to filter out the spoofed responses >>> on behalf of the stub/forwarder. >>>=20 >>> Also it is just a "DNS message". =3DA0UDP/TCP/HTTP/HTTPS is just the >>> transport for the DNS message. >>>=20 >>=20 >> If a validating stub resolver can set CD =3D3D 1 for UDP/TCP why not for >> HTTP or HTTPS ? >=20 > A validating stub resolver really doesn't want to set CD=3D1, by > default. If it gets SERVFAIL back to a CD=3D0 query then resending > with CD=3D1, may help if the SERVFAIL was a validation failure caused > by a bad clock on the recursive server / out of date trust anchors. > A stub resolver *needs* the upstream server to weed out the bogus > responses due to spoofing or, more likely, operational stuff ups > and only pass through those that pass validation. Remember a stub Why does a validating stub resolver care ? If there was spoofing or other pr= oblems, it can find out itself. It is much easier to set CD=3D1 always.=20 -mohan > resolver does not have access to multiple authoritative sources, > only the recursive server does. If you are willing to bet that > every response you get back is good then always set CD=3D1 otherwise > CD=3D1 should only be set if the CD=3D0 lookup fails. >=20 >> -mohan >>=20 >>>> -mohan >>>>=20 >>>>> Ted >>>>>=20 >>>>> _______________________________________________ >>>>> dnsext mailing list >>>>> dnsext@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/dnsext >>>>>=20 >>>>>=20 >>>> _______________________________________________ >>>> 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 =3DA0 =3DA0 =3DA0 =3DA0 =3DA0 =3DA0 =3DA0 =3DA0 I= NTERNET: marka@is=3D >> c.org >>>=20 > --=20 > Mark Andrews, ISC > 1 Seymour St., Dundas Valley, NSW 2117, Australia > PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From marka@isc.org Mon Oct 3 21:00:18 2011 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D1F5521F8EA0 for ; Mon, 3 Oct 2011 21:00:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.149 X-Spam-Level: X-Spam-Status: No, score=-1.149 tagged_above=-999 required=5 tests=[AWL=0.850, BAYES_00=-2.599, J_CHICKENPOX_13=0.6] 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 NhKrsyaW-m-T for ; Mon, 3 Oct 2011 21:00:18 -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 C3F2921F8E82 for ; Mon, 3 Oct 2011 21:00:17 -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 6D5F8C94A6; Tue, 4 Oct 2011 04:03:02 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (unknown [IPv6:2001:470:1f00:820:6233:4bff:fe01:7585]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by bikeshed.isc.org (Postfix) with ESMTPSA id EFA67216C56; Tue, 4 Oct 2011 04:03:01 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (Postfix) with ESMTP id 324041492901; Tue, 4 Oct 2011 15:02:59 +1100 (EST) To: Mohan From: Mark Andrews References: <201110010458.26859.vixie@isc.org> <8F26AB69-C5BD-47BD-B3F4-6D840E419A23@verisign.com> <201110031713.20103.vixie@isc.org> <54E677EE-0720-4220-9FB8-17EDE978E904@vpnc.org> <20111004001547.7ED7C149063F@drugs.dv.isc.org> <20111004025502.504DD14924EC@drugs.dv.isc.org> In-reply-to: Your message of "Mon, 03 Oct 2011 20:17:48 PDT." Date: Tue, 04 Oct 2011 15:02:59 +1100 Message-Id: <20111004040259.324041492901@drugs.dv.isc.org> Cc: Paul Hoffman , DNSEXT Working Group 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: Tue, 04 Oct 2011 04:00:18 -0000 In message , Mohan writes: > > > On Oct 3, 2011, at 7:55 PM, Mark Andrews wrote: > > > > > In message il.com> > > , Mohan Parthasarathy writes: > >> On Mon, Oct 3, 2011 at 5:15 PM, Mark Andrews wrote: > >>> > >>> In message i= > >> l.com>, Mohan Parthasarathy writes: > >>>> On Mon, Oct 3, 2011 at 10:32 AM, Ted Hardie wrote:= > > >>>>> On Mon, Oct 3, 2011 at 10:21 AM, Paul Hoffman = > 3D= > > >> wro= > >>>> te: > >>>>>> > >>>>>> +1. The slight increase in programming difficulty of using POST vs. G= > = > >> ET > >>>>>> buys you a huge amount of flexibility in queries. It's not just about= > > >>>>>> cache-prevention. > >>>>>> > >>>>> > >>>>> All silver linings have their clouds... The only unfortunate th= > in= > >> g abo= > >>>> ut > >>>>> POST, in my view, is that the flexibility can trend you away from > >>>>> interoperability as people add and change things at different= > = > 3DA= > >> 0 speed= > >>>> s at > >>>>> different hosts. If you want standard behavior the descending l= > is= > >> t goe= > >>>> s: > >>>>> New Method, GET, POST, at least in my view. > >>>>> > >>>>> Since new methods are notoriously hard to get deployed, POST seems lik= > = > >> e t= > >>>> he > >>>>> best choice if you want something that can handle any DNS operation.= > = > > >> I= > >>>> f it > >>>>> is meant to be only retrieval, then I would personally say that keepin= > = > >> g it > >>>>> within GET is the best choice. > >>>>> > >>>>> I'm also increasingly of the opinion that this should have the validat= > = > >> ion > >>>>> bits sets by default. Allowing a web site to update the local D= > NS= > >> cach= > >>>> e for > >>>>> a client system by including a reference and a DNS result for the refe= > = > >> ren= > >>>> ce > >>>>> causes my paranoia to ratchet up a few notches. The only other d > = > e= > >> fense > >>>>> against it I see is using Web results only in same-origin web contexts= > = > >> , a= > >>>> nd > >>>>> that's going to be very hard to make work. > >>>>> > >>>> > >>>> I am not sure I understand this concern fully. I guess you mean that > >>>> you want to use this only with CD =1 which also implies that you w > = > an= > >> t > >>>> to use only with DNSSEC . Though this is the primary use case that > >>>> this draft is trying to address, should we restrict it ? Previously, > >>>> your concern was cache poisoning of the HTTP proxies having an impact > >>>> on DNS. If we require HTTPS and POST, is this still a concern ? > >>> > >>> DO=1 implies DNSSEC. Stubs/forwarders SHOULD NOT set CD=1. = > 3D= > A0The > >>> upstream validator needs to filter out the spoofed responses > >>> on behalf of the stub/forwarder. > >>> > >>> Also it is just a "DNS message". UDP/TCP/HTTP/HTTPS is just the > >>> transport for the DNS message. > >>> > >> > >> If a validating stub resolver can set CD = 1 for UDP/TCP why not for > >> HTTP or HTTPS ? > > > > A validating stub resolver really doesn't want to set CD=1, by > > default. If it gets SERVFAIL back to a CD=0 query then resending > > with CD=1, may help if the SERVFAIL was a validation failure caused > > by a bad clock on the recursive server / out of date trust anchors. > > A stub resolver *needs* the upstream server to weed out the bogus > > responses due to spoofing or, more likely, operational stuff ups > > and only pass through those that pass validation. Remember a stub > > Why does a validating stub resolver care? Say example.com is served by a DNSSEC aware authoritative server (D) and a DNSSEC unaware authoritative server (P). The stub resolver asks for www.example.com/DO=1/CD=1. The validating recurive server get a answer from P (without DNSSEC records) and passes it on. Validation fails. The stub resolver asks for www.example.com/DO=1/CD=1 again and it gets the same answer (from thout DNSSEC records) the CD=1 cache and again fails. Rince, lather, repeat. Now if the stub asks for www.example.com/DO=1/CD=0 the validating resolver will reject any answers from P and only pass on answers from D (with DNSSEC record) which should then validate. Now if the recursive server doesn't validate or it validates as insecure you are left with first senario hoping that you are getting answers from the DNSSEC aware authoritative server. What would help would be a EDNS option to send to the recursive server the closest trust anchor(s) and current time so that it can validate responses in a consistant manner to the stub resolver. Mark > If there was spoofing or other problems, it can find out itself. > It is much easier to set CD=1 always. > > -mohan -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From suruti94@gmail.com Mon Oct 3 21:40: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 A3FC421F8F2B for ; Mon, 3 Oct 2011 21:40:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.299 X-Spam-Level: X-Spam-Status: No, score=-3.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_13=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 G8rzFqzoICCf for ; Mon, 3 Oct 2011 21:40:50 -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 6F79E21F8F29 for ; Mon, 3 Oct 2011 21:40:50 -0700 (PDT) Received: by yxt33 with SMTP id 33so127107yxt.31 for ; Mon, 03 Oct 2011 21:43:54 -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=0oReWdodsbRMrBdQuHFEkhXuwOqMpyzrJ0+ae45s31M=; b=kWdkL6xj30LiVAqvbROtq7sQHbMoaGqyHeUAtLhWCbZorzAF4W6OlDuGVWNg7jHhvO 99117FLeLhcTXVSyXOsDUdoaEPlaoEvQQXG56WsHWNOdft0rqjlmipHy00Fi8SrOhU4c 43+2j8q7w+xkcUoCKJS6aEk4jQPrFYVrvh90I= MIME-Version: 1.0 Received: by 10.68.32.130 with SMTP id j2mr6652261pbi.4.1317703433844; Mon, 03 Oct 2011 21:43:53 -0700 (PDT) Received: by 10.68.46.200 with HTTP; Mon, 3 Oct 2011 21:43:53 -0700 (PDT) In-Reply-To: <20111004040259.324041492901@drugs.dv.isc.org> References: <201110010458.26859.vixie@isc.org> <8F26AB69-C5BD-47BD-B3F4-6D840E419A23@verisign.com> <201110031713.20103.vixie@isc.org> <54E677EE-0720-4220-9FB8-17EDE978E904@vpnc.org> <20111004001547.7ED7C149063F@drugs.dv.isc.org> <20111004025502.504DD14924EC@drugs.dv.isc.org> <20111004040259.324041492901@drugs.dv.isc.org> Date: Mon, 3 Oct 2011 21:43:53 -0700 Message-ID: From: Mohan Parthasarathy To: Mark Andrews Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Paul Hoffman , DNSEXT Working Group 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: Tue, 04 Oct 2011 04:40:51 -0000 On Mon, Oct 3, 2011 at 9:02 PM, Mark Andrews wrote: > > In message , Mohan writes= : >> >> >> On Oct 3, 2011, at 7:55 PM, Mark Andrews wrote: >> >> > >> > In message > il.com> >> > , Mohan Parthasarathy writes: >> >> On Mon, Oct 3, 2011 at 5:15 PM, Mark Andrews wrote: >> >>> >> >>> In message > i=3D >> >> l.com>, Mohan Parthasarathy writes: >> >>>> On Mon, Oct 3, 2011 at 10:32 AM, Ted Hardie wr= ote:=3D >> >> >>>>> On Mon, Oct 3, 2011 at 10:21 AM, Paul Hoffman =3D >> 3D=3D >> >> >> wro=3D >> >>>> te: >> >>>>>> >> >>>>>> +1. The slight increase in programming difficulty of using POST v= s. G=3D >> =3D >> >> ET >> >>>>>> buys you a huge amount of flexibility in queries. It's not just a= bout=3D >> >> >>>>>> cache-prevention. >> >>>>>> >> >>>>> >> >>>>> All silver linings have their clouds... =A0The only unfortunate th= =3D >> in=3D >> >> g abo=3D >> >>>> ut >> >>>>> POST, in my view, is that the flexibility can trend you away from >> >>>>> interoperability as people add and change things at =A0different= =3D >> =3D >> 3DA=3D >> >> 0 speed=3D >> >>>> s at >> >>>>> different hosts. =A0If you want standard behavior the descending l= =3D >> is=3D >> >> t goe=3D >> >>>> s: >> >>>>> New Method, GET, POST, at least in my view. >> >>>>> >> >>>>> Since new methods are notoriously hard to get deployed, POST seems= lik=3D >> =3D >> >> e t=3D >> >>>> he >> >>>>> best choice if you want something that can handle any DNS operatio= n.=3D >> =3D >> >> >> =A0 I=3D >> >>>> f it >> >>>>> is meant to be only retrieval, then I would personally say that ke= epin=3D >> =3D >> >> g it >> >>>>> within GET is the best choice. >> >>>>> >> >>>>> I'm also increasingly of the opinion that this should have the val= idat=3D >> =3D >> >> ion >> >>>>> bits sets by default. =A0Allowing a web site to update the local D= =3D >> NS=3D >> >> cach=3D >> >>>> e for >> >>>>> a client system by including a reference and a DNS result for the = refe=3D >> =3D >> >> ren=3D >> >>>> ce >> >>>>> causes my paranoia to ratchet up a few notches. =A0The only other = d >> =3D >> e=3D >> >> fense >> >>>>> against it I see is using Web results only in same-origin web cont= exts=3D >> =3D >> >> , a=3D >> >>>> nd >> >>>>> that's going to be very hard to make work. >> >>>>> >> >>>> >> >>>> I am not sure I understand this concern fully. I guess you mean tha= t >> >>>> you want to use this only with CD =3D1 which also implies that you = w >> =3D >> an=3D >> >> t >> >>>> to use only with DNSSEC . Though this is the primary use case that >> >>>> this draft is trying to address, should we restrict it ? Previously= , >> >>>> your concern was cache poisoning of the HTTP proxies having an impa= ct >> >>>> on DNS. If we require HTTPS and POST, is this still a concern ? >> >>> >> >>> DO=3D1 implies DNSSEC. =A0Stubs/forwarders SHOULD NOT set CD=3D1. = =3D >> 3D=3D >> A0The >> >>> upstream validator needs to filter out the spoofed responses >> >>> on behalf of the stub/forwarder. >> >>> >> >>> Also it is just a "DNS message". UDP/TCP/HTTP/HTTPS is just the >> >>> transport for the DNS message. >> >>> >> >> >> >> If a validating stub resolver can set CD =3D 1 for UDP/TCP why not fo= r >> >> HTTP or HTTPS ? >> > >> > A validating stub resolver really doesn't want to set CD=3D1, by >> > default. =A0If it gets SERVFAIL back to a CD=3D0 query then resending >> > with CD=3D1, may help if the SERVFAIL was a validation failure caused >> > by a bad clock on the recursive server / out of date trust anchors. >> > A stub resolver *needs* the upstream server to weed out the bogus >> > responses due to spoofing or, more likely, operational stuff ups >> > and only pass through those that pass validation. =A0Remember a stub >> >> Why does a validating stub resolver care? > > Say example.com is served by a DNSSEC aware authoritative server > (D) and a DNSSEC unaware authoritative server (P). =A0The stub resolver Isn't this a broken configuration ? Why do we end up with this configuratio= n ? > asks for www.example.com/DO=3D1/CD=3D1. =A0The validating recurive server > get a answer from P (without DNSSEC records) and passes it on. > Validation fails. =A0The stub resolver asks for www.example.com/DO=3D1/CD= =3D1 > again and it gets the same answer (from thout DNSSEC records) the > CD=3D1 cache and again fails. =A0Rince, lather, repeat. > > Now if the stub asks for www.example.com/DO=3D1/CD=3D0 the validating > resolver will reject any answers from P and only pass on answers > from D (with DNSSEC record) which should then validate. > So, this is a validating resolver, sets CD=3D0 (ignoring what is said in RFC 4035), gets the "proper" responses, ignores the AD bit, validates the responses. Is this discussed in any document ? > Now if the recursive server doesn't validate or it validates as > insecure you are left with first senario hoping that you are getting > answers from the DNSSEC aware authoritative server. > > What would help would be a EDNS option to send to the recursive > server the closest trust anchor(s) and current time so that it can > validate responses in a consistant manner to the stub resolver. > This seems complex to me. Perhaps, the operational document should say that a dnssec signed zone should be served only by dnssec aware authoritative servers. If there is still an operational error, the validating resolver should just give up. For example, if i set DO=3D1/CD=3D1 and there are no RRSIGS, then abort and declare insecure. -mohan > Mark > >> If there was spoofing or other problems, it can find out itself. >> It is much easier to set CD=3D1 always. >> >> -mohan > -- > Mark Andrews, ISC > 1 Seymour St., Dundas Valley, NSW 2117, Australia > PHONE: +61 2 9871 4742 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 INTERNET: marka@is= c.org > From marka@isc.org Mon Oct 3 22:21: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 18DA521F8F37 for ; Mon, 3 Oct 2011 22:21:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.649 X-Spam-Level: X-Spam-Status: No, score=-1.649 tagged_above=-999 required=5 tests=[AWL=0.350, BAYES_00=-2.599, J_CHICKENPOX_13=0.6] 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 X62HsuyKB3Xi for ; Mon, 3 Oct 2011 22:21:41 -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 CDDC821F8F5C for ; Mon, 3 Oct 2011 22:21:40 -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 CA286C9422; Tue, 4 Oct 2011 05:24:14 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (unknown [IPv6:2001:470:1f00:820:6233:4bff:fe01:7585]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by bikeshed.isc.org (Postfix) with ESMTPSA id 20416216C33; Tue, 4 Oct 2011 05:24:14 +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 D92451492DC2; Tue, 4 Oct 2011 16:24:09 +1100 (EST) To: Mohan Parthasarathy From: Mark Andrews References: <201110010458.26859.vixie@isc.org> <8F26AB69-C5BD-47BD-B3F4-6D840E419A23@verisign.com> <201110031713.20103.vixie@isc.org> <54E677EE-0720-4220-9FB8-17EDE978E904@vpnc.org> <20111004001547.7ED7C149063F@drugs.dv.isc.org> <20111004025502.504DD14924EC@drugs.dv.isc.org> <20111004040259.324041492901@drugs.dv.isc.org> In-reply-to: Your message of "Mon, 03 Oct 2011 21:43:53 PDT." Date: Tue, 04 Oct 2011 16:24:09 +1100 Message-Id: <20111004052409.D92451492DC2@drugs.dv.isc.org> Cc: Paul Hoffman , DNSEXT Working Group 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: Tue, 04 Oct 2011 05:21:42 -0000 In message , Mohan Parthasarathy writes: > On Mon, Oct 3, 2011 at 9:02 PM, Mark Andrews wrote: > > > > In message , Mohan writes= > : > >> > >> > >> On Oct 3, 2011, at 7:55 PM, Mark Andrews wrote: > >> > >> > > >> > In message .gma= > >> il.com> > >> > , Mohan Parthasarathy writes: > >> >> On Mon, Oct 3, 2011 at 5:15 PM, Mark Andrews wrote: > >> >>> > >> >>> In message .gma= > >> i= > >> >> l.com>, Mohan Parthasarathy writes: > >> >>>> On Mon, Oct 3, 2011 at 10:32 AM, Ted Hardie wr= > ote:= > >> > >> >>>>> On Mon, Oct 3, 2011 at 10:21 AM, Paul Hoffman rg> = > >> 3D= > >> > >> >> wro= > >> >>>> te: > >> >>>>>> > >> >>>>>> +1. The slight increase in programming difficulty of using POST v= > s. G= > >> = > >> >> ET > >> >>>>>> buys you a huge amount of flexibility in queries. It's not just a= > bout= > >> > >> >>>>>> cache-prevention. > >> >>>>>> > >> >>>>> > >> >>>>> All silver linings have their clouds... The only unfortunate th= > = > >> in= > >> >> g abo= > >> >>>> ut > >> >>>>> POST, in my view, is that the flexibility can trend you away from > >> >>>>> interoperability as people add and change things at different= > = > >> = > >> 3DA= > >> >> 0 speed= > >> >>>> s at > >> >>>>> different hosts. If you want standard behavior the descending l= > = > >> is= > >> >> t goe= > >> >>>> s: > >> >>>>> New Method, GET, POST, at least in my view. > >> >>>>> > >> >>>>> Since new methods are notoriously hard to get deployed, POST seems= > lik= > >> = > >> >> e t= > >> >>>> he > >> >>>>> best choice if you want something that can handle any DNS operatio= > n.= > >> = > >> > >> >> I= > >> >>>> f it > >> >>>>> is meant to be only retrieval, then I would personally say that ke= > epin= > >> = > >> >> g it > >> >>>>> within GET is the best choice. > >> >>>>> > >> >>>>> I'm also increasingly of the opinion that this should have the val= > idat= > >> = > >> >> ion > >> >>>>> bits sets by default. Allowing a web site to update the local D= > = > >> NS= > >> >> cach= > >> >>>> e for > >> >>>>> a client system by including a reference and a DNS result for the = > refe= > >> = > >> >> ren= > >> >>>> ce > >> >>>>> causes my paranoia to ratchet up a few notches. The only other = > d > >> = > >> e= > >> >> fense > >> >>>>> against it I see is using Web results only in same-origin web cont= > exts= > >> = > >> >> , a= > >> >>>> nd > >> >>>>> that's going to be very hard to make work. > >> >>>>> > >> >>>> > >> >>>> I am not sure I understand this concern fully. I guess you mean tha= > t > >> >>>> you want to use this only with CD =1 which also implies that you = > w > >> = > >> an= > >> >> t > >> >>>> to use only with DNSSEC . Though this is the primary use case that > >> >>>> this draft is trying to address, should we restrict it ? Previously= > , > >> >>>> your concern was cache poisoning of the HTTP proxies having an impa= > ct > >> >>>> on DNS. If we require HTTPS and POST, is this still a concern ? > >> >>> > >> >>> DO=1 implies DNSSEC. Stubs/forwarders SHOULD NOT set CD=1. = > = > >> 3D= > >> A0The > >> >>> upstream validator needs to filter out the spoofed responses > >> >>> on behalf of the stub/forwarder. > >> >>> > >> >>> Also it is just a "DNS message". UDP/TCP/HTTP/HTTPS is just the > >> >>> transport for the DNS message. > >> >>> > >> >> > >> >> If a validating stub resolver can set CD = 1 for UDP/TCP why not fo= > r > >> >> HTTP or HTTPS ? > >> > > >> > A validating stub resolver really doesn't want to set CD=1, by > >> > default. If it gets SERVFAIL back to a CD=0 query then resending > >> > with CD=1, may help if the SERVFAIL was a validation failure caused > >> > by a bad clock on the recursive server / out of date trust anchors. > >> > A stub resolver *needs* the upstream server to weed out the bogus > >> > responses due to spoofing or, more likely, operational stuff ups > >> > and only pass through those that pass validation. Remember a stub > >> > >> Why does a validating stub resolver care? > > > > Say example.com is served by a DNSSEC aware authoritative server > > (D) and a DNSSEC unaware authoritative server (P). The stub resolver > > Isn't this a broken configuration ? Why do we end up with this configuratio= > n ? Because people make mistakes. I've definitely seen this sort of configuration error. Remember this misconfiguration is indistigishable from a spoof attack. Validators are expected to cope with spoof attacks. They are not expected to cope with MITM attacks other than to reject the bogus answers. > > asks for www.example.com/DO=1/CD=1. The validating recurive server > > get a answer from P (without DNSSEC records) and passes it on. > > Validation fails. The stub resolver asks for www.example.com/DO=1/CD= > =1 > > again and it gets the same answer (from thout DNSSEC records) the > > CD=1 cache and again fails. Rince, lather, repeat. > > > > Now if the stub asks for www.example.com/DO=1/CD=0 the validating > > resolver will reject any answers from P and only pass on answers > > from D (with DNSSEC record) which should then validate. > > So, this is a validating resolver, sets CD=0 (ignoring what is said in > RFC 4035), gets the "proper" responses, ignores the AD bit, > validates the responses. Is this discussed in any document ? No, its not ignoring what is said in RFC 4035, CD=1 is a SHOULD (4.9.2). In this case I'm recommending that defaulting to CD=0 as the default is what should be done and falling back to CD=1 in SERVFAIL is what should be done. AD should be ignored by a validating stub resolver. It's for stubs that trust the resolver, not stubs that validate. As for whether this is documented anywhere, apart from the archive of this list and dns/dnssec lists I doubt it. I've definitely mentioned this before. Mike St John's discussion of CD/DO setting is similar in nature if I'm remembering it correctly. Remember when RFC 4035 was written there was very little experience with validating stub resolvers. There still isn't much but defaulting to CD=1 is clearly wrong. Making stub validating resolvers work well may still require more work or what we have may be "good enough". > > Now if the recursive server doesn't validate or it validates as > > insecure you are left with first senario hoping that you are getting > > answers from the DNSSEC aware authoritative server. > > > > What would help would be a EDNS option to send to the recursive > > server the closest trust anchor(s) and current time so that it can > > validate responses in a consistant manner to the stub resolver. > > This seems complex to me. Perhaps, the operational document should say > that a dnssec signed zone should be served only by dnssec aware > authoritative servers. If there is still an operational error, the > validating resolver should just give up. For example, if i set > DO=1/CD=1 and there are no RRSIGS, then abort and declare insecure. Except you can't do that most of the time because there could be a zone cut that makes that name insecure. Mark > -mohan > > > Mark > > > >> If there was spoofing or other problems, it can find out itself. > >> It is much easier to set CD=1 always. > >> > >> -mohan > > -- > > Mark Andrews, ISC > > 1 Seymour St., Dundas Valley, NSW 2117, Australia > > PHONE: +61 2 9871 4742 =A0 =A0 =A0 =A0 =A0 =A0 =A0 INTERNET: marka@is= > c.org > > -- 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 Tue Oct 4 04:01: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 0B67A21F8C34 for ; Tue, 4 Oct 2011 04:01:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.585 X-Spam-Level: X-Spam-Status: No, score=-6.585 tagged_above=-999 required=5 tests=[AWL=0.014, 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 DsuyloEfICDz for ; Tue, 4 Oct 2011 04:01:41 -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 1F0DE21F8B16 for ; Tue, 4 Oct 2011 04:01:40 -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]:56393) by ppsw-51.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.158]:25) with esmtpa (EXTERNAL:fanf2) id 1RB2ni-0001D3-WQ (Exim 4.72) (return-path ); Tue, 04 Oct 2011 12:04:42 +0100 Received: from fanf2 (helo=localhost) by hermes-2.csi.cam.ac.uk (hermes.cam.ac.uk) with local-esmtp id 1RB2ni-0001oN-1O (Exim 4.67) (return-path ); Tue, 04 Oct 2011 12:04:42 +0100 Date: Tue, 4 Oct 2011 12:04:42 +0100 From: Tony Finch X-X-Sender: fanf2@hermes-2.csi.cam.ac.uk To: Alex Bligh In-Reply-To: Message-ID: References: <201110031713.20103.vixie@isc.org> <58EB32F9-08D2-4579-BC56-1423C00FC371@verisign.com> <201110031816.32959.vixie@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: 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: Tue, 04 Oct 2011 11:01:42 -0000 Alex Bligh wrote: > > I presume we could base64 encode POST data if we couldn't send it > binary, whereas IIRC we couldn't do much more than hex encode GET URLs. You can send it in binary, otherwise multipart/form-data file uploads would not work. > So +1 for POST here, with body content as close to UDP message format > as possible, Yes. > save that we should surely be able to junk a pile of UDP restrictions > (e.g. we can surely mandate EDNS, assume 'packet' size can 2^32 bytes, > etc.). You can't increase the DNS message size beyond 64KB. Tony. -- f.anthony.n.finch http://dotat.at/ Portland, Plymouth: Southwest 4 or 5, increasing 6 at times. Moderate, occasionally rough later in Plymouth. Occasional drizzle, fog patches for a time. Moderate or good, occasionally very poor. From alex@alex.org.uk Tue Oct 4 04:37: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 1F41821F8562 for ; Tue, 4 Oct 2011 04:37:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.574 X-Spam-Level: X-Spam-Status: No, score=-2.574 tagged_above=-999 required=5 tests=[AWL=0.025, 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 CKNwv3udfr8b for ; Tue, 4 Oct 2011 04:37:55 -0700 (PDT) Received: from mail.avalus.com (mail.avalus.com [IPv6:2001:41c8:10:1dd::10]) by ietfa.amsl.com (Postfix) with ESMTP id 4FE6D21F84F5 for ; Tue, 4 Oct 2011 04:37:50 -0700 (PDT) Received: from [192.168.100.15] (87-194-71-186.bethere.co.uk [87.194.71.186]) by mail.avalus.com (Postfix) with ESMTPSA id BA34CC56102; Tue, 4 Oct 2011 12:40:51 +0100 (BST) Date: Tue, 04 Oct 2011 12:40:50 +0100 From: Alex Bligh To: Tony Finch Message-ID: <0D33DC3D0533F844E21BE63E@Ximines.local> In-Reply-To: References: <201110031713.20103.vixie@isc.org> <58EB32F9-08D2-4579-BC56-1423C00FC371@verisign.com> <201110031816.32959.vixie@isc.org> X-Mailer: Mulberry/4.0.8 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Cc: 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 Reply-To: Alex Bligh List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Oct 2011 11:37:56 -0000 --On 4 October 2011 12:04:42 +0100 Tony Finch wrote: > You can't increase the DNS message size beyond 64KB. I was under the (mis) apprehension that was a UDP limitation, and that large AFXRs could exceed 64KB. Live and learn. -- Alex Bligh From fanf2@hermes.cam.ac.uk Tue Oct 4 04:46: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 96BEA21F8B07 for ; Tue, 4 Oct 2011 04:46:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.586 X-Spam-Level: X-Spam-Status: No, score=-6.586 tagged_above=-999 required=5 tests=[AWL=0.013, 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 V-EB9xT11h1E for ; Tue, 4 Oct 2011 04:46:58 -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 E365421F848E for ; Tue, 4 Oct 2011 04:46:57 -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]:44980) by ppsw-51.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.158]:25) with esmtpa (EXTERNAL:fanf2) id 1RB3VT-0006V2-Y7 (Exim 4.72) (return-path ); Tue, 04 Oct 2011 12:49:55 +0100 Received: from fanf2 (helo=localhost) by hermes-2.csi.cam.ac.uk (hermes.cam.ac.uk) with local-esmtp id 1RB3VT-0001Ox-IE (Exim 4.67) (return-path ); Tue, 04 Oct 2011 12:49:55 +0100 Date: Tue, 4 Oct 2011 12:49:55 +0100 From: Tony Finch X-X-Sender: fanf2@hermes-2.csi.cam.ac.uk To: Alex Bligh In-Reply-To: <0D33DC3D0533F844E21BE63E@Ximines.local> Message-ID: References: <201110031713.20103.vixie@isc.org> <58EB32F9-08D2-4579-BC56-1423C00FC371@verisign.com> <201110031816.32959.vixie@isc.org> <0D33DC3D0533F844E21BE63E@Ximines.local> User-Agent: Alpine 2.00 (LSU 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: Tony Finch Cc: 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: Tue, 04 Oct 2011 11:46:58 -0000 Alex Bligh wrote: > --On 4 October 2011 12:04:42 +0100 Tony Finch wrote: > > > You can't increase the DNS message size beyond 64KB. > > I was under the (mis) apprehension that was a UDP limitation, and that > large AFXRs could exceed 64KB. Live and learn. DNS over TCP has the same limit. If we want to maximise compatibility with existing DNS code we shouldn't change it. Tony. -- f.anthony.n.finch http://dotat.at/ Rockall, Malin: Southwesterly 5 to 7, occasionally gale 8. Very rough or high. Squally showers, rain later. Moderate or poor, occasionally good. From mansaxel@besserwisser.org Tue Oct 4 05:52: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 1DC7E21F8B8F for ; Tue, 4 Oct 2011 05:52:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.3 X-Spam-Level: X-Spam-Status: No, score=-2.3 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, 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 KBDIAYs5embG for ; Tue, 4 Oct 2011 05:52:24 -0700 (PDT) Received: from jaja.besserwisser.org (jaja.besserwisser.org [IPv6:2a01:298:4:0:211:43ff:fe36:1299]) by ietfa.amsl.com (Postfix) with ESMTP id 94A0921F8B81 for ; Tue, 4 Oct 2011 05:52:23 -0700 (PDT) Received: by jaja.besserwisser.org (Postfix, from userid 1004) id B11B1A1EE; Tue, 4 Oct 2011 14:55:24 +0200 (CEST) Date: Tue, 4 Oct 2011 14:55:24 +0200 From: =?utf-8?B?TcOlbnM=?= Nilsson To: Alex Bligh Message-ID: <20111004125524.GI12306@besserwisser.org> References: <201110031713.20103.vixie@isc.org> <58EB32F9-08D2-4579-BC56-1423C00FC371@verisign.com> <201110031816.32959.vixie@isc.org> <0D33DC3D0533F844E21BE63E@Ximines.local> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="6b3yLyRKT1M6kiA0" Content-Disposition: inline In-Reply-To: <0D33DC3D0533F844E21BE63E@Ximines.local> X-URL: http://vvv.besserwisser.org X-Purpose: More of everything NOW! X-happyness: Life is good. User-Agent: Mutt/1.5.20 (2009-06-14) 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: Tue, 04 Oct 2011 12:52:25 -0000 --6b3yLyRKT1M6kiA0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Subject: Re: [dnsext] draft-mohan-dns-query-xml-00.txt Date: Tue, Oct 04, 2= 011 at 12:40:50PM +0100 Quoting Alex Bligh (alex@alex.org.uk): >=20 >=20 > --On 4 October 2011 12:04:42 +0100 Tony Finch wrote: >=20 > >You can't increase the DNS message size beyond 64KB. >=20 > I was under the (mis) apprehension that was a UDP limitation, and that > large AFXRs could exceed 64KB. Live and learn. I've done AXFRen of 1/2 GB zones. Not practical, but doable. The 64K limit does not apply to AXFR, but, then again, AXFR is not like the other children... --=20 M=C3=A5ns Nilsson primary/secondary/besserwisser/machina MN-1334-RIPE +46 705 989668 Is it NOUVELLE CUISINE when 3 olives are struggling with a scallop in a plate of SAUCE MORNAY? --6b3yLyRKT1M6kiA0 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) iEYEARECAAYFAk6LAjwACgkQ02/pMZDM1cWDmgCdHd1L/1uUBeaptCzQeDH+jMg5 N9sAniE156hPeFArg8SGSMBZo1lEKQLN =GSoA -----END PGP SIGNATURE----- --6b3yLyRKT1M6kiA0-- From marka@isc.org Tue Oct 4 07:07: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 3656921F8B6E for ; Tue, 4 Oct 2011 07:07:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.869 X-Spam-Level: X-Spam-Status: No, score=-1.869 tagged_above=-999 required=5 tests=[AWL=0.430, 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 QldPuxGT2JqI for ; Tue, 4 Oct 2011 07:07:10 -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 B3F6521F8AFB for ; Tue, 4 Oct 2011 07:07:10 -0700 (PDT) Received: from bikeshed.isc.org (bikeshed.isc.org [IPv6:2001:4f8:3:d::19]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "bikeshed.isc.org", Issuer "ISC CA" (verified OK)) by mx.ams1.isc.org (Postfix) with ESMTPS id 140155F988D; Tue, 4 Oct 2011 14:09:54 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (unknown [IPv6:2001:470:1f00:820:6233:4bff:fe01:7585]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by bikeshed.isc.org (Postfix) with ESMTPSA id DBBB2216C33; Tue, 4 Oct 2011 14:09:51 +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 78825149C52E; Wed, 5 Oct 2011 01:09:48 +1100 (EST) To: =?utf-8?B?TcOlbnM=?= Nilsson From: Mark Andrews References: <201110031713.20103.vixie@isc.org> <58EB32F9-08D2-4579-BC56-1423C00FC371@verisign.com> <201110031816.32959.vixie@isc.org> <0D33DC3D0533F844E21BE63E@Ximines.local> <20111004125524.GI12306@besserwisser.org> In-reply-to: Your message of "Tue, 04 Oct 2011 14:55:24 +0200." <20111004125524.GI12306@besserwisser.org> Date: Wed, 05 Oct 2011 01:09:48 +1100 Message-Id: <20111004140948.78825149C52E@drugs.dv.isc.org> 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: Tue, 04 Oct 2011 14:07:11 -0000 In message <20111004125524.GI12306@besserwisser.org>, =?utf-8?B?TcOlbnM=?= Nils son writes: > Subject: Re: [dnsext] draft-mohan-dns-query-xml-00.txt Date: Tue, Oct 04, 2= > 011 at 12:40:50PM +0100 Quoting Alex Bligh (alex@alex.org.uk): > >=20 > >=20 > > --On 4 October 2011 12:04:42 +0100 Tony Finch wrote: > >=20 > > >You can't increase the DNS message size beyond 64KB. > >=20 > > I was under the (mis) apprehension that was a UDP limitation, and that > > large AFXRs could exceed 64KB. Live and learn. > > I've done AXFRen of 1/2 GB zones. Not practical, but doable. The 64K > limit does not apply to AXFR, but, then again, AXFR is not like the > other children... > > --=20 > M=C3=A5ns Nilsson primary/secondary/besserwisser/machina > MN-1334-RIPE +46 705 989668 > Is it NOUVELLE CUISINE when 3 olives are struggling with a scallop in a > plate of SAUCE MORNAY? If we ever want to go greater than 64 K, tcp length limits 0..11 make good escape sequences, just encode the number of length bytes with EDNS signaling to say we handle the longer length encodings. 00 03 XX XX XX 00 04 XX XX XX XX 00 05 XX XX XX XX XX 00 06 XX XX XX XX XX XX 00 07 XX XX XX XX XX XX XX 00 08 XX XX XX XX XX XX XX XX Mark -- 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 Tue Oct 4 08:05:59 2011 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2460621F8C4E for ; Tue, 4 Oct 2011 08:05:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.586 X-Spam-Level: X-Spam-Status: No, score=-6.586 tagged_above=-999 required=5 tests=[AWL=0.013, 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 jV3nzBcU0pVR for ; Tue, 4 Oct 2011 08:05:58 -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 4D9CF21F8C49 for ; Tue, 4 Oct 2011 08:05:58 -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]:33953) by ppsw-51.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.158]:25) with esmtpa (EXTERNAL:fanf2) id 1RB6cA-0001N5-Y8 (Exim 4.72) (return-path ); Tue, 04 Oct 2011 16:09:02 +0100 Received: from fanf2 (helo=localhost) by hermes-2.csi.cam.ac.uk (hermes.cam.ac.uk) with local-esmtp id 1RB6cA-00036h-IL (Exim 4.67) (return-path ); Tue, 04 Oct 2011 16:09:02 +0100 Date: Tue, 4 Oct 2011 16:09:02 +0100 From: Tony Finch X-X-Sender: fanf2@hermes-2.csi.cam.ac.uk To: Mark Andrews In-Reply-To: <20111004140948.78825149C52E@drugs.dv.isc.org> Message-ID: References: <201110031713.20103.vixie@isc.org> <58EB32F9-08D2-4579-BC56-1423C00FC371@verisign.com> <201110031816.32959.vixie@isc.org> <0D33DC3D0533F844E21BE63E@Ximines.local> <20111004125524.GI12306@besserwisser.org> <20111004140948.78825149C52E@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: 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: Tue, 04 Oct 2011 15:05:59 -0000 Mark Andrews wrote: > > If we ever want to go greater than 64 K, tcp length limits 0..11 > make good escape sequences, just encode the number of length bytes > with EDNS signaling to say we handle the longer length encodings. That's OK for large responses but not large UPDATE requests. Tony. -- f.anthony.n.finch http://dotat.at/ Portland, Plymouth: Southwest 4 or 5, increasing 6 at times. Moderate, occasionally rough later. Occasional drizzle, fog patches for a time. Moderate or good, occasionally very poor. From suruti94@gmail.com Tue Oct 4 12:47:17 2011 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 177AE21F8D94 for ; Tue, 4 Oct 2011 12:47:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.566 X-Spam-Level: X-Spam-Status: No, score=-3.566 tagged_above=-999 required=5 tests=[AWL=0.033, 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 t7sJqs6TZxt4 for ; Tue, 4 Oct 2011 12:47:16 -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 C31F121F8D84 for ; Tue, 4 Oct 2011 12:46:58 -0700 (PDT) Received: by pzk37 with SMTP id 37so2249729pzk.9 for ; Tue, 04 Oct 2011 12:50:04 -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=M9r30ronDIY2ZqvhEaU8O4dEMz/ImN5HyJI+Q1fH9WI=; b=GKoyCI24QTg8nKxI36KykSB32KDPeuIiRFh4H6W6FiRiOnY5ur6jaO5DgHWAw5NI6d 46eXQhwJi0CuLEQaShJVKVkQX/2jM8ETBGY+bxfCX2H44lyLgkQQxZHN31HTxGxGfy9g I7WI079jRu6Oxs2UMdiWy90XpbdCvBvKkvilU= MIME-Version: 1.0 Received: by 10.68.23.163 with SMTP id n3mr11805582pbf.89.1317757804591; Tue, 04 Oct 2011 12:50:04 -0700 (PDT) Received: by 10.68.46.200 with HTTP; Tue, 4 Oct 2011 12:50:04 -0700 (PDT) In-Reply-To: <20111004052409.D92451492DC2@drugs.dv.isc.org> References: <201110010458.26859.vixie@isc.org> <8F26AB69-C5BD-47BD-B3F4-6D840E419A23@verisign.com> <201110031713.20103.vixie@isc.org> <54E677EE-0720-4220-9FB8-17EDE978E904@vpnc.org> <20111004001547.7ED7C149063F@drugs.dv.isc.org> <20111004025502.504DD14924EC@drugs.dv.isc.org> <20111004040259.324041492901@drugs.dv.isc.org> <20111004052409.D92451492DC2@drugs.dv.isc.org> Date: Tue, 4 Oct 2011 12:50:04 -0700 Message-ID: From: Mohan Parthasarathy To: Mark Andrews Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Paul Hoffman , DNSEXT Working Group 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: Tue, 04 Oct 2011 19:47:17 -0000 > >> > asks for www.example.com/DO=3D1/CD=3D1. =A0The validating recurive ser= ver >> > get a answer from P (without DNSSEC records) and passes it on. >> > Validation fails. =A0The stub resolver asks for www.example.com/DO=3D1= /CD=3D >> =3D1 >> > again and it gets the same answer (from thout DNSSEC records) the >> > CD=3D1 cache and again fails. =A0Rince, lather, repeat. >> > >> > Now if the stub asks for www.example.com/DO=3D1/CD=3D0 the validating >> > resolver will reject any answers from P and only pass on answers >> > from D (with DNSSEC record) which should then validate. >> >> So, this is a validating resolver, sets CD=3D0 (ignoring what is said in >> RFC 4035), gets the "proper" responses, ignores the AD bit, >> validates the responses. Is this discussed in any document ? > > No, its not ignoring what is said in RFC 4035, CD=3D1 is a SHOULD > (4.9.2). =A0In this case I'm recommending that defaulting to CD=3D0 as > the default is what should be done and falling back to CD=3D1 in > SERVFAIL is what should be done. =A0AD should be ignored by a validating > stub resolver. =A0It's for stubs that trust the resolver, not stubs > that validate. > > As for whether this is documented anywhere, apart from the archive > of this list and dns/dnssec lists I doubt it. =A0I've definitely > mentioned this before. =A0Mike St John's discussion of CD/DO setting > is similar in nature if I'm remembering it correctly. > > Remember when RFC 4035 was written there was very little experience > with validating stub resolvers. =A0There still isn't much but defaulting > to CD=3D1 is clearly wrong. =A0Making stub validating resolvers work > well may still require more work or what we have may be "good > enough". > Why can't the recursive server fetch the "proper" response when it sees DOK=3D1/CD=3D1 ? It knows that a validating resolver is asking for DNSSEC records to validate itself. If it does not get from the first server, it can ask the next server and get it. Why should the behavior be different for CD=3D0/1 ? As long as DOK=3D1, it should do it. >> > Now if the recursive server doesn't validate or it validates as >> > insecure you are left with first senario hoping that you are getting >> > answers from the DNSSEC aware authoritative server. >> > >> > What would help would be a EDNS option to send to the recursive >> > server the closest trust anchor(s) and current time so that it can >> > validate responses in a consistant manner to the stub resolver. >> >> This seems complex to me. Perhaps, the operational document should say >> that a dnssec signed zone should be served only by dnssec aware >> authoritative servers. If there is still an operational error, the >> validating resolver should just give up. For example, if i set >> DO=3D1/CD=3D1 and there are no RRSIGS, then abort and declare insecure. > > Except you can't do that most of the time because there could be a > zone cut that makes that name insecure. > You should get a NSEC/NSEC3 in that case, right ? -mohan > Mark > >> -mohan >> >> > Mark >> > >> >> If there was spoofing or other problems, it can find out itself. >> >> It is much easier to set CD=3D1 always. >> >> >> >> -mohan >> > -- >> > Mark Andrews, ISC >> > 1 Seymour St., Dundas Valley, NSW 2117, Australia >> > PHONE: +61 2 9871 4742 =A0 =3DA0 =3DA0 =3DA0 =3DA0 =3DA0 =3DA0 =3DA0 I= NTERNET: marka@is=3D >> c.org >> > > -- > Mark Andrews, ISC > 1 Seymour St., Dundas Valley, NSW 2117, Australia > PHONE: +61 2 9871 4742 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 INTERNET: marka@is= c.org > From wwwrun@rfc-editor.org Tue Oct 4 13:35:54 2011 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BE65F21F8C61 for ; Tue, 4 Oct 2011 13:35:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.968 X-Spam-Level: X-Spam-Status: No, score=-99.968 tagged_above=-999 required=5 tests=[AWL=-2.368, BAYES_00=-2.599, GB_SUMOF=5, 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 Zmkt9DM09AGq for ; Tue, 4 Oct 2011 13:35:54 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1890:123a::1:2f]) by ietfa.amsl.com (Postfix) with ESMTP id 5C55321F8C57 for ; Tue, 4 Oct 2011 13:35:54 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 4016798C25F; Tue, 4 Oct 2011 13:39:00 -0700 (PDT) To: arnt@troll.no, levone@microsoft.com, rdroms.ietf@gmail.com, jari.arkko@piuha.net, ogud@ogud.com, ajs@anvilwalrusden.com From: RFC Errata System Message-Id: <20111004203900.4016798C25F@rfc-editor.org> Date: Tue, 4 Oct 2011 13:39:00 -0700 (PDT) Cc: Jordan.Brown@oracle.com, dnsext@ietf.org, rfc-editor@rfc-editor.org Subject: [dnsext] [Technical Errata Reported] RFC2782 (2984) 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, 04 Oct 2011 20:35:54 -0000 The following errata report has been submitted for RFC2782, "A DNS RR for specifying the location of services (DNS SRV)". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=2782&eid=2984 -------------------------------------- Type: Technical Reported by: Jordan Brown Section: Weight Original Text ------------- To select a target to be contacted next, arrange all SRV RRs (that have not been ordered yet) in any order, except that all those with weight 0 are placed at the beginning of the list. Compute the sum of the weights of those RRs, and with each RR associate the running sum in the selected order. Then choose a uniform random number between 0 and the sum computed (inclusive), and select the RR whose running sum value is the first in the selected order which is greater than or equal to the random number selected. The target host specified in the selected SRV RR is the next one to be contacted by the client. Remove this SRV RR from the set of the unordered SRV RRs and apply the described algorithm to the unordered SRV RRs to select the next target host. Continue the ordering process until there are no unordered SRV RRs. This process is repeated for each Priority. Corrected Text -------------- Correcting the text requires agreement on what to do with entries with weight=0, so I don't want to try to craft text until we have agreement there. Notes ----- The problem with this algorithm is that for a total weight T, it generates a random number 0..T and so allocates T+1 shares and gives the extra share to the first entry. Thus with weights {1, 1}, the first entry is selected 2/3 of the time while the second entry is selected 1/3 of the time. I suspect that this is an attempt to do *something* with entries with weight=0, but yields unobvious results there: for {0, 1, 1}, the three entries are each selected 1/3 of the time. I suggest: - Ordering weight=0 entries to the end. - Generating random numbers 0..(T-1). - Using a "greater" test rather than "greater or equal". - Selecting weight=0 entries in any order when all of the weight!=0 entries have been selected. Instructions: ------------- This errata is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party (IESG) can log in to change the status and edit the report, if necessary. -------------------------------------- RFC2782 (draft-ietf-dnsind-rfc2052bis-05) -------------------------------------- Title : A DNS RR for specifying the location of services (DNS SRV) Publication Date : February 2000 Author(s) : A. Gulbrandsen, P. Vixie, L. Esibov Category : PROPOSED STANDARD Source : DNS Extensions Area : Internet Stream : IETF Verifying Party : IESG From msheldon@godaddy.com Tue Oct 4 14:36: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 05BE821F8EE0 for ; Tue, 4 Oct 2011 14:36:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CtYuGgQrhczs for ; Tue, 4 Oct 2011 14:36:43 -0700 (PDT) Received: from smtpoutwbe05.prod.mesa1.secureserver.net (smtpoutwbe05.prod.mesa1.secureserver.net [208.109.78.207]) by ietfa.amsl.com (Postfix) with SMTP id 3671621F8ED9 for ; Tue, 4 Oct 2011 14:36:43 -0700 (PDT) Received: (qmail 20595 invoked from network); 4 Oct 2011 21:39:48 -0000 Received: from unknown (HELO gem-wbe09.prod.mesa1.secureserver.net) (64.202.189.48) by smtpoutwbe05.prod.mesa1.secureserver.net with SMTP; 4 Oct 2011 21:39:48 -0000 Received: (qmail 18813 invoked by uid 99); 4 Oct 2011 21:39:48 -0000 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" X-Originating-IP: 172.19.38.143 User-Agent: Web-Based Email 5.6.02 Message-Id: <20111004143947.205a61dff9fc1684c258b274662bb912.04bcda2f2f.wbe@email00.secureserver.net> From: "Michael Sheldon" To: dnsext@ietf.org Date: Tue, 04 Oct 2011 14:39:47 -0700 Mime-Version: 1.0 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: Tue, 04 Oct 2011 21:36:44 -0000 =0A=0A> -------- Original Message --------=0A> Subject: Re: [dnsext] draft-= mohan-dns-query-xml-00.txt=0A> From: M=C3=A5ns Nilsson =0A>=0A> Subject: Re: [dnsext] draft-mohan-dns-query-xml-00.txt Date= : Tue, Oct 04, 2011 at 12:40:50PM +0100 Quoting Alex Bligh (alex@alex.org.u= k):=0A> > =0A> > =0A> > --On 4 October 2011 12:04:42 +0100 Tony Finch wrote:=0A> > =0A> > >You can't increase the DNS message size beyo= nd 64KB.=0A> > =0A> > I was under the (mis) apprehension that was a UDP lim= itation, and that=0A> > large AFXRs could exceed 64KB. Live and learn.=0A> = =0A> I've done AXFRen of 1/2 GB zones. Not practical, but doable. The 64K= =0A> limit does not apply to AXFR, but, then again, AXFR is not like the=0A= > other children...=0A> =0A=0AThe 64K DNS message limit applies to *all* TC= P transactions. The TCP=0Alength field is the limiting factor at two bytes.= AXFR gets around this=0Aby using multiple DNS messages, but it is still li= mited to 64K per=0Amessage.=0A=0A*IF* this proposal survives, I agree with = the suggestion that we keep it=0Aas close to the current model as possible.= =0A=0AThat said, I haven't seen any compelling reason to support a protocol= =0Achange that seems solely for the purpose of fixing other people's=0Anetw= ork mis-configurations.=0A=0AMichael Sheldon=0ADev-DNS Services=0AGoDaddy.c= om=0A From vixie@isc.org Tue Oct 4 15:30: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 5924621F8F2B for ; Tue, 4 Oct 2011 15:30:40 -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 Fw2F4AB3qkCB for ; Tue, 4 Oct 2011 15:30:40 -0700 (PDT) Received: from nsa.vix.com (nsa.vix.com [IPv6:2001:4f8:3:30::3]) by ietfa.amsl.com (Postfix) with ESMTP id E96F721F8E76 for ; Tue, 4 Oct 2011 15:30:39 -0700 (PDT) Received: from nsa.vix.com (localhost [127.0.0.1]) by nsa.vix.com (Postfix) with ESMTP id 8B397A1063 for ; Tue, 4 Oct 2011 22:33:43 +0000 (UTC) (envelope-from vixie@isc.org) Received: from six.localnet (six.vix.com [IPv6:2001:4f8:3:30::2]) by nsa.vix.com (Postfix) with ESMTP id 625CFA1049 for ; Tue, 4 Oct 2011 22:33:43 +0000 (UTC) (envelope-from vixie@isc.org) From: Paul Vixie Organization: ISC To: dnsext@ietf.org Date: Tue, 4 Oct 2011 22:33:42 +0000 User-Agent: KMail/1.13.5 (FreeBSD/8.1-RELEASE; KDE/4.4.5; amd64; ; ) References: <0D33DC3D0533F844E21BE63E@Ximines.local> <20111004125524.GI12306@besserwisser.org> In-Reply-To: <20111004125524.GI12306@besserwisser.org> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-15" Content-Transfer-Encoding: quoted-printable Message-Id: <201110042233.43094.vixie@isc.org> X-Virus-Scanned: ClamAV using ClamSMTP 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: Tue, 04 Oct 2011 22:30:40 -0000 On Tuesday, October 04, 2011 12:55:24 M=E5ns Nilsson wrote: > > >You can't increase the DNS message size beyond 64KB. > >=20 > > I was under the (mis) apprehension that was a UDP limitation, and that > > large AFXRs could exceed 64KB. Live and learn. >=20 > I've done AXFRen of 1/2 GB zones. Not practical, but doable. The 64K > limit does not apply to AXFR, but, then again, AXFR is not like the > other children... an AXFR can have many messages, each will be 64KB or smaller, and no RRset = is=20 allowed to span a message. this means among other things that no RRset can= be=20 larger than ~64KB. the fact that RRsets larger than 64KB could also not be= =20 carried in a query (whether by TCP/53 or UDP/53) also enforces this=20 constraint. From Ray.Bellis@nominet.org.uk Tue Oct 4 15:33: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 1352721F8D3C for ; Tue, 4 Oct 2011 15:33:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.93 X-Spam-Level: X-Spam-Status: No, score=-8.93 tagged_above=-999 required=5 tests=[AWL=1.668, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 t5-mJeaKcqU8 for ; Tue, 4 Oct 2011 15:33:12 -0700 (PDT) Received: from mx4.nominet.org.uk (mx4.nominet.org.uk [213.248.199.24]) by ietfa.amsl.com (Postfix) with ESMTP id 2CEA721F8D39 for ; Tue, 4 Oct 2011 15:33:12 -0700 (PDT) DomainKey-Signature: s=main.dk.nominet.selector; d=nominet.org.uk; c=nofws; q=dns; h=X-IronPort-AV:Received:Received:From:To:CC:Subject: Thread-Topic:Thread-Index:Date:Message-ID:References: In-Reply-To:Accept-Language:Content-Language: X-MS-Has-Attach:X-MS-TNEF-Correlator:Content-Type: MIME-Version; b=YPIpGiTTJXCx6vWRWnkGNSD6j20b753bchcFLnmcC1Utv3wsZVPC6Iyx bYWMFlPgWhX2eA4B9+hPH7znS3LagOLLxQ8i9xkwdlp/7d2xf/WMguei7 a5IgB61xJ85Lj9/; DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nominet.org.uk; i=Ray.Bellis@nominet.org.uk; q=dns/txt; s=main.dkim.nominet.selector; t=1317767778; x=1349303778; h=from:sender:reply-to:subject:date:message-id:to:cc: mime-version:content-transfer-encoding:content-id: content-description:resent-date:resent-from:resent-sender: resent-to:resent-cc:resent-message-id:in-reply-to: references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:list-owner:list-archive; z=From:=20Ray=20Bellis=20 |Subject:=20Re:=20[dnsext]=20draft-mohan-dns-query-xml-00 .txt|Date:=20Tue,=204=20Oct=202011=2022:36:15=20+0000 |Message-ID:=20<772EA53B-2168-4226-8FAF-3D15CF265DA2@nomi net.org.uk>|To:=20Michael=20Sheldon=20|CC:=20""=20 |MIME-Version:=201.0|In-Reply-To:=20<20111004143947.205a6 1dff9fc1684c258b274662bb912.04bcda2f2f.wbe@email00.secure server.net>|References:=20<20111004143947.205a61dff9fc168 4c258b274662bb912.04bcda2f2f.wbe@email00.secureserver.net >; bh=vz2R4eXdqDyYSD7FQs0GhLlXUQHbOGBjmUXsiMORoB0=; b=iQ2DUuqw7ZS011KNaN/HD63UDb9KCPQ3uijPMg20Nozsa2WU9jOLNvN2 gGM/BMROsVgHaDCgK1AhKH+SDR/sIi2kdD7E1z1d3Javk3Ljxyltv8Yb/ ywL46FzLo3Df8sm; X-IronPort-AV: E=Sophos;i="4.68,487,1312153200"; d="scan'208,217";a="28800085" Received: from wds-exc2.okna.nominet.org.uk ([213.248.197.145]) by mx4.nominet.org.uk with ESMTP; 04 Oct 2011 23:36:17 +0100 Received: from WDS-EXC1.okna.nominet.org.uk ([fe80::1593:1394:a91f:8f5f]) by wds-exc2.okna.nominet.org.uk ([fe80::7577:eaca:5241:25d4%19]) with mapi; Tue, 4 Oct 2011 23:36:17 +0100 From: Ray Bellis To: Michael Sheldon Thread-Topic: [dnsext] draft-mohan-dns-query-xml-00.txt Thread-Index: AQHMgt4jfCZxnQpglE20eO4CZeWVeZVstY2A Date: Tue, 4 Oct 2011 22:36:15 +0000 Message-ID: <772EA53B-2168-4226-8FAF-3D15CF265DA2@nominet.org.uk> References: <20111004143947.205a61dff9fc1684c258b274662bb912.04bcda2f2f.wbe@email00.secureserver.net> In-Reply-To: <20111004143947.205a61dff9fc1684c258b274662bb912.04bcda2f2f.wbe@email00.secureserver.net> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_772EA53B216842268FAF3D15CF265DA2nominetorguk_" MIME-Version: 1.0 Cc: "" 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: Tue, 04 Oct 2011 22:33:13 -0000 --_000_772EA53B216842268FAF3D15CF265DA2nominetorguk_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable On 4 Oct 2011, at 17:39, Michael Sheldon wrote: The 64K DNS message limit applies to *all* TCP transactions. The TCP length field is the limiting factor at two bytes. AXFR gets around this by = using multiple DNS messages, but it is still limited to 64K per message. And compression pointers are of course only 14 bits, so are constrained to = point back only within the first 16K of any message. Ray --_000_772EA53B216842268FAF3D15CF265DA2nominetorguk_ Content-Type: text/html; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable
On 4 Oct 2011, at 17:39= , Michael Sheldon wrote:

The 64K DNS message limit a= pplies to *all* TCP transactions. The TCP
length field is the limiting f= actor at two bytes. AXFR gets around this by using multiple DNS messag= es, but it is still limited to 64K per message.

=
And compression pointers are of course only 14 bits, so are cons= trained to point back only within the first 16K of any message.
<= br>
Ray


= --_000_772EA53B216842268FAF3D15CF265DA2nominetorguk_-- From brian.peter.dickson@gmail.com Tue Oct 4 15:51: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 2233721F8F08 for ; Tue, 4 Oct 2011 15:51:25 -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 dbFLlaqkiU3C for ; Tue, 4 Oct 2011 15:51:24 -0700 (PDT) Received: from mail-bw0-f44.google.com (mail-bw0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id 5851A21F8F00 for ; Tue, 4 Oct 2011 15:51:24 -0700 (PDT) Received: by bkaq10 with SMTP id q10so1514404bka.31 for ; Tue, 04 Oct 2011 15:54: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=SzA9te0kjOug88/OY22BiCQuKu1mi7R9W7i8ntN8ODc=; b=jOTghdfNR6aqgagm1dyjb7dY4K9VqewbDrbYC/5i7TPZwa4JkM5ya5vdHntudbREfV Xk0t1nvrLn/s2ekzryWTppT47G7VXCrHkwclE1MWEypi65xCSNNfU8o73aJi27I+coFf bkwcq9wfWepPXeG2ErQeWy/lC/SRZxCX9I0q0= MIME-Version: 1.0 Received: by 10.204.128.88 with SMTP id j24mr1127167bks.74.1317768869912; Tue, 04 Oct 2011 15:54:29 -0700 (PDT) Received: by 10.204.157.27 with HTTP; Tue, 4 Oct 2011 15:54:29 -0700 (PDT) In-Reply-To: <20111004143947.205a61dff9fc1684c258b274662bb912.04bcda2f2f.wbe@email00.secureserver.net> References: <20111004143947.205a61dff9fc1684c258b274662bb912.04bcda2f2f.wbe@email00.secureserver.net> Date: Tue, 4 Oct 2011 18:54:29 -0400 Message-ID: From: Brian Dickson To: Michael Sheldon Content-Type: text/plain; charset=ISO-8859-1 Cc: 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: Tue, 04 Oct 2011 22:51:25 -0000 On Tue, Oct 4, 2011 at 5:39 PM, Michael Sheldon wrote: > That said, I haven't seen any compelling reason to support a protocol > change that seems solely for the purpose of fixing other people's > network mis-configurations. There are subtleties in the unintended consequences of messing with DNS. By "messing with", I refer to ISPs doing arbitrary stuff, including but not limited to NXDOMAIN or other forms of DNS hijacking. Blocking the DNSSEC portion of DNS responses, either deliberately or by lack of support, is another form of "messing with", and may also be used to hide the other (deliberate) activity. When DNSSEC stuff is blocked, not only does it reduce the trust in the answers, it re-opens the window of vulnerability that DNSSEC was meant to close. Not good. Widespread blocking of DNSSEC threatens the adoption and utility of DNSSEC. However ugly it might be, DNSSEC is important enough to warrant considering counter-counter-measures. This proposal is a very lightweight and elegant (IMHO) counter-counter-measure. It makes valid answers from either authority servers (if client == recursive server) or resolvers (if client == stub) possible to (a) get directly, and (b) trust and/or verify. In many use cases, there is no alternative, particularly when there is a local market monopoly or duopoly of such "bad actors". Even if you don't use DNSSEC, please don't stop others from using it or from making it possible to achieve widespread usage. And I gently encourage use of DNSSEC by any and all -- especially when your domain is your primary (sole?) source of revenue. (BTW - I am a happy customer, FWIW. But I'd be happier if you used DNSSEC.) Brian P.S. Note also, that mis-configurations are often deliberate, especially when performed by the state. This proposal at least makes feasible, the unblocking of state-sponsored censorship at the DNS level. From mohta@necom830.hpcl.titech.ac.jp Tue Oct 4 15:57: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 83B7F21F8BC4 for ; Tue, 4 Oct 2011 15:57:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.037 X-Spam-Level: X-Spam-Status: No, score=-0.037 tagged_above=-999 required=5 tests=[AWL=0.053, 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 YReZ7Cu5a8kn for ; Tue, 4 Oct 2011 15:57:49 -0700 (PDT) Received: from necom830.hpcl.titech.ac.jp (necom830.hpcl.titech.ac.jp [131.112.32.132]) by ietfa.amsl.com (Postfix) with SMTP id B0BC221F8D84 for ; Tue, 4 Oct 2011 15:57:48 -0700 (PDT) Received: (qmail 45072 invoked from network); 4 Oct 2011 23:16:01 -0000 Received: from necom830.hpcl.titech.ac.jp (HELO ?127.0.0.1?) (131.112.32.132) by necom830.hpcl.titech.ac.jp with SMTP; 4 Oct 2011 23:16:01 -0000 Message-ID: <4E8B9014.3060000@necom830.hpcl.titech.ac.jp> Date: Wed, 05 Oct 2011 08:00:36 +0900 From: Masataka Ohta User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: RFC Errata System References: <20111004203900.4016798C25F@rfc-editor.org> In-Reply-To: <20111004203900.4016798C25F@rfc-editor.org> Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit Cc: arnt@troll.no, Jordan.Brown@oracle.com, levone@microsoft.com, dnsext@ietf.org, jari.arkko@piuha.net, rdroms.ietf@gmail.com, ogud@ogud.com Subject: Re: [dnsext] [Technical Errata Reported] RFC2782 (2984) 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, 04 Oct 2011 22:57:49 -0000 RFC Errata System wrote: > Corrected Text > -------------- > Correcting the text requires agreement on what to do with entries with > weight=0, so I don't want to try to craft text until we have agreement there. >From examples of the RFC: ; NO other services are supported *._tcp SRV 0 0 0 . *._udp SRV 0 0 0 . it is obvious that weight=0 means that the RR must not be selected. > I suggest: > > - Ordering weight=0 entries to the end. > - Generating random numbers 0..(T-1). > - Using a "greater" test rather than "greater or equal". > - Selecting weight=0 entries in any order when all of the weight!=0 entries have been selected. I suggest: > - Generating random numbers 0..(T-1). > - Using a "greater" test rather than "greater or equal". Masataka Ohta From mohta@necom830.hpcl.titech.ac.jp Tue Oct 4 17:19: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 36A0221F8DB3 for ; Tue, 4 Oct 2011 17:19:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.038 X-Spam-Level: X-Spam-Status: No, score=-0.038 tagged_above=-999 required=5 tests=[AWL=0.052, 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 3hJe3ah5CYNx for ; Tue, 4 Oct 2011 17:19:48 -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 35E6621F8C0B for ; Tue, 4 Oct 2011 17:19:47 -0700 (PDT) Received: (qmail 45513 invoked from network); 5 Oct 2011 00:38:01 -0000 Received: from necom830.hpcl.titech.ac.jp (HELO ?127.0.0.1?) (131.112.32.132) by necom830.hpcl.titech.ac.jp with SMTP; 5 Oct 2011 00:38:01 -0000 Message-ID: <4E8BA347.7060208@necom830.hpcl.titech.ac.jp> Date: Wed, 05 Oct 2011 09:22:31 +0900 From: Masataka Ohta User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: Jordan Brown References: <20111004203900.4016798C25F@rfc-editor.org> <4E8B9014.3060000@necom830.hpcl.titech.ac.jp> <4E8B9515.3060503@oracle.com> In-Reply-To: <4E8B9515.3060503@oracle.com> Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit Cc: arnt@troll.no, levone@microsoft.com, dnsext@ietf.org, jari.arkko@piuha.net, rdroms.ietf@gmail.com, ogud@ogud.com, RFC Errata System Subject: Re: [dnsext] [Technical Errata Reported] RFC2782 (2984) 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, 05 Oct 2011 00:19:49 -0000 Jordan Brown wrote: >> From examples of the RFC: >> >> ; NO other services are supported >> *._tcp SRV 0 0 0 . >> *._udp SRV 0 0 0 . >> >> it is obvious that weight=0 means that the RR must not be >> selected. > > Perhaps, but on the other hand it also says: > > Domain > administrators SHOULD use Weight 0 when there isn't any server > selection to do, to make the RR easier to read for humans (less > noisy). In the presence of records containing weights greater > than 0, records with weight 0 should have a very small chance of > being selected. Hmmmm, as the RFC says: Domain administrators SHOULD use Weight 0 when there isn't any server selection to do, to make the RR easier to read for humans (less noisy). A Target of "." means that the service is decidedly not available at this domain. weight=0 in the examples I showed should not be significant, sorry. Then, I agree with you, except that - Selecting weight=0 entries in any order when all of the weight!=0 entries have been selected. should be: - Selecting weight=0 entries in random order when all of the weight!=0 entries have been selected. Masataka Ohta From marka@isc.org Tue Oct 4 17:45: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 AD46421F8B1A for ; Tue, 4 Oct 2011 17:45:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.091 X-Spam-Level: X-Spam-Status: No, score=-2.091 tagged_above=-999 required=5 tests=[AWL=0.508, 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 aT0NB5Ug-3Fn for ; Tue, 4 Oct 2011 17:45:40 -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 2A59321F8B17 for ; Tue, 4 Oct 2011 17:45:40 -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 96E07C9424 for ; Wed, 5 Oct 2011 00:48:33 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (unknown [IPv6:2001:470:1f00:820:6233:4bff:fe01:7585]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by bikeshed.isc.org (Postfix) with ESMTPSA id 326C8216C33; Wed, 5 Oct 2011 00:48:33 +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 F2441149EED3; Wed, 5 Oct 2011 11:48:31 +1100 (EST) To: Paul Vixie From: Mark Andrews References: <0D33DC3D0533F844E21BE63E@Ximines.local> <20111004125524.GI12306@besserwisser.org> <201110042233.43094.vixie@isc.org> In-reply-to: Your message of "Tue, 04 Oct 2011 22:33:42 -0000." <201110042233.43094.vixie@isc.org> Date: Wed, 05 Oct 2011 11:48:31 +1100 Message-Id: <20111005004831.F2441149EED3@drugs.dv.isc.org> Cc: 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, 05 Oct 2011 00:45:40 -0000 In message <201110042233.43094.vixie@isc.org>, Paul Vixie writes: > On Tuesday, October 04, 2011 12:55:24 M=E5ns Nilsson wrote: > > > > >You can't increase the DNS message size beyond 64KB. > > > = > > > > I was under the (mis) apprehension that was a UDP limitation, and that > > > large AFXRs could exceed 64KB. Live and learn. > > = > > > I've done AXFRen of 1/2 GB zones. Not practical, but doable. The 64K > > limit does not apply to AXFR, but, then again, AXFR is not like the > > other children... > > an AXFR can have many messages, each will be 64KB or smaller, and no RRset = > is = > > allowed to span a message. this means among other things that no RRset can= > be = > > larger than ~64KB. the fact that RRsets larger than 64KB could also not be = > > carried in a query (whether by TCP/53 or UDP/53) also enforces this = > > constraint. > _______________________________________________ > dnsext mailing list > dnsext@ietf.org > https://www.ietf.org/mailman/listinfo/dnsext RRsets are allowed to span messages in AXFR/IXFR. BIND 4 used to send one RR per message. That said the current practical limit is slightly less than 64K for a RRset without protocol extensions. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From dotis@mail-abuse.org Tue Oct 4 18:18:17 2011 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 31B8321F8C51 for ; Tue, 4 Oct 2011 18:18:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.383 X-Spam-Level: X-Spam-Status: No, score=-103.383 tagged_above=-999 required=5 tests=[AWL=-0.784, 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 Mf9qSdsMHxLG for ; Tue, 4 Oct 2011 18:18:16 -0700 (PDT) Received: from SJDC-SDIRelay2.sdi.trendmicro.com (sjdc-sdirelay2.sdi.trendmicro.com [150.70.68.59]) by ietfa.amsl.com (Postfix) with ESMTP id 8145421F8BF8 for ; Tue, 4 Oct 2011 18:18:16 -0700 (PDT) Received: from harry.mail-abuse.org (harry.mail-abuse.org [168.61.5.27]) by SJDC-SDIRelay2.sdi.trendmicro.com (Postfix) with ESMTP id 5705A308111 for ; Wed, 5 Oct 2011 01:21:21 +0000 (UTC) Received: from US-DOUGO-MAC.local (gateway1.sjc.mail-abuse.org [168.61.5.81]) by harry.mail-abuse.org (Postfix) with ESMTP id F0B5EA9443B for ; Wed, 5 Oct 2011 01:21:21 +0000 (UTC) Message-ID: <4E8BB111.5010004@mail-abuse.org> Date: Tue, 04 Oct 2011 18:21:21 -0700 From: Douglas Otis User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: dnsext@ietf.org References: <20111004203900.4016798C25F@rfc-editor.org> <4E8B9014.3060000@necom830.hpcl.titech.ac.jp> <4E8B9515.3060503@oracle.com> <4E8BA347.7060208@necom830.hpcl.titech.ac.jp> In-Reply-To: <4E8BA347.7060208@necom830.hpcl.titech.ac.jp> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [dnsext] [Technical Errata Reported] RFC2782 (2984) 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, 05 Oct 2011 01:18:17 -0000 On 10/4/11 5:22 PM, Masataka Ohta wrote: > Jordan Brown wrote: > >>> From examples of the RFC: >>> >>> ; NO other services are supported >>> *._tcp SRV 0 0 0 . >>> *._udp SRV 0 0 0 . >>> >>> it is obvious that weight=0 means that the RR must not be >>> selected. >> Perhaps, but on the other hand it also says: >> >> Domain >> administrators SHOULD use Weight 0 when there isn't any server >> selection to do, to make the RR easier to read for humans (less >> noisy). In the presence of records containing weights greater >> than 0, records with weight 0 should have a very small chance of >> being selected. > Hmmmm, as the RFC says: > > Domain > administrators SHOULD use Weight 0 when there isn't any server > selection to do, to make the RR easier to read for humans (less > noisy). > > A Target of "." means that the service is decidedly not > available at this domain. > > weight=0 in the examples I showed should not be significant, sorry. > > Then, I agree with you, except that > > - Selecting weight=0 entries in any order when all of > the weight!=0 entries have been selected. > > should be: > > - Selecting weight=0 entries in random order when all > of the weight!=0 entries have been selected. Even use of "." as a null target is problematic when this convention is ignored. What problem does a "." (null) service reference improve over simply not having an entry? The use of wildcards for _label._label services seems rather limited. -Doug From mohta@necom830.hpcl.titech.ac.jp Tue Oct 4 18:26: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 B603C21F8D4A for ; Tue, 4 Oct 2011 18:26:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.039 X-Spam-Level: X-Spam-Status: No, score=-0.039 tagged_above=-999 required=5 tests=[AWL=0.051, 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 cJmRytavoLNz for ; Tue, 4 Oct 2011 18:26:20 -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 3392721F8D46 for ; Tue, 4 Oct 2011 18:26:15 -0700 (PDT) Received: (qmail 45871 invoked from network); 5 Oct 2011 01:44:29 -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; 5 Oct 2011 01:44:29 -0000 Message-ID: <4E8BB2D9.10000@necom830.hpcl.titech.ac.jp> Date: Wed, 05 Oct 2011 10:28:57 +0900 From: Masataka Ohta User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: dnsext@ietf.org References: <20111004203900.4016798C25F@rfc-editor.org> <4E8B9014.3060000@necom830.hpcl.titech.ac.jp> <4E8B9515.3060503@oracle.com> <4E8BA347.7060208@necom830.hpcl.titech.ac.jp> <4E8BB111.5010004@mail-abuse.org> In-Reply-To: <4E8BB111.5010004@mail-abuse.org> Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit Subject: Re: [dnsext] [Technical Errata Reported] RFC2782 (2984) 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, 05 Oct 2011 01:26:20 -0000 Douglas Otis wrote: > Even use of "." as a null target is problematic when this > convention is ignored. Agreed. > What problem does a "." (null) service reference improve > over simply not having an entry? Not having an entry might mean Name is the Target. At least, I specified so in draft-ohta-urlsrv-00.txt. Masataka Ohta From mohta@necom830.hpcl.titech.ac.jp Tue Oct 4 20:53:04 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 2BE7221F8B6C for ; Tue, 4 Oct 2011 20:53:04 -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 9yJN15pGD8A5 for ; Tue, 4 Oct 2011 20:53:03 -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 58BA321F8B68 for ; Tue, 4 Oct 2011 20:53:03 -0700 (PDT) Received: (qmail 46648 invoked from network); 5 Oct 2011 04:11:18 -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; 5 Oct 2011 04:11:18 -0000 Message-ID: <4E8BD559.3060502@necom830.hpcl.titech.ac.jp> Date: Wed, 05 Oct 2011 12:56:09 +0900 From: Masataka Ohta User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: dnsext@ietf.org References: <20111004143947.205a61dff9fc1684c258b274662bb912.04bcda2f2f.wbe@email00.secureserver.net> In-Reply-To: Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit 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, 05 Oct 2011 03:53:04 -0000 Brian Dickson wrote: > Even if you don't use DNSSEC, please don't stop others from using it > or from making it possible to achieve widespread usage. > > And I gently encourage use of DNSSEC by any and all -- especially when > your domain is your primary (sole?) source of revenue. (BTW - I am a > happy customer, FWIW. But I'd be happier if you used DNSSEC.) You seems to be using DNSSEC. How do you make your clock securely synchronized with that of the root? Masataka Ohta From marka@isc.org Tue Oct 4 21:24: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 9031021F8B81 for ; Tue, 4 Oct 2011 21:24:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.218 X-Spam-Level: X-Spam-Status: No, score=-2.218 tagged_above=-999 required=5 tests=[AWL=0.381, 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 g9WgRvmOBhSZ for ; Tue, 4 Oct 2011 21:24:40 -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 1CF2C21F8B4F for ; Tue, 4 Oct 2011 21:24:40 -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 EC9BFC9422; Wed, 5 Oct 2011 04:27:30 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (unknown [IPv6:2001:470:1f00:820:6233:4bff:fe01:7585]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by bikeshed.isc.org (Postfix) with ESMTPSA id 5BAE9216C36; Wed, 5 Oct 2011 04:27:30 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (Postfix) with ESMTP id 4D8A514A46C1; Wed, 5 Oct 2011 15:27:28 +1100 (EST) To: Masataka Ohta From: Mark Andrews References: <20111004143947.205a61dff9fc1684c258b274662bb912.04bcda2f2f.wbe@email00.secureserver.net> <4E8BD559.3060502@necom830.hpcl.titech.ac.jp> In-reply-to: Your message of "Wed, 05 Oct 2011 12:56:09 +0900." <4E8BD559.3060502@necom830.hpcl.titech.ac.jp> Date: Wed, 05 Oct 2011 15:27:28 +1100 Message-Id: <20111005042728.4D8A514A46C1@drugs.dv.isc.org> Cc: 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, 05 Oct 2011 04:24:40 -0000 In message <4E8BD559.3060502@necom830.hpcl.titech.ac.jp>, Masataka Ohta writes: > Brian Dickson wrote: > > > Even if you don't use DNSSEC, please don't stop others from using it > > or from making it possible to achieve widespread usage. > > > > And I gently encourage use of DNSSEC by any and all -- especially when > > your domain is your primary (sole?) source of revenue. (BTW - I am a > > happy customer, FWIW. But I'd be happier if you used DNSSEC.) > > You seems to be using DNSSEC. > > How do you make your clock securely synchronized with that of > the root? Personally, I look at my wristwatch. DNSSEC only requires loose time syncronization. Most machines, provided they have a battery backed up clock, could run their entire life on the time as set by the manufacturer. > Masataka Ohta > _______________________________________________ > dnsext mailing list > dnsext@ietf.org > https://www.ietf.org/mailman/listinfo/dnsext -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From mohta@necom830.hpcl.titech.ac.jp Tue Oct 4 22:07:53 2011 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 651B521F858C for ; Tue, 4 Oct 2011 22:07:53 -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 E2l82xM5tigq for ; Tue, 4 Oct 2011 22:07:53 -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 9092921F8569 for ; Tue, 4 Oct 2011 22:07:51 -0700 (PDT) Received: (qmail 47087 invoked from network); 5 Oct 2011 05:26: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; 5 Oct 2011 05:26:07 -0000 Message-ID: <4E8BE6DF.5040201@necom830.hpcl.titech.ac.jp> Date: Wed, 05 Oct 2011 14:10:55 +0900 From: Masataka Ohta User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: Mark Andrews References: <20111004143947.205a61dff9fc1684c258b274662bb912.04bcda2f2f.wbe@email00.secureserver.net> <4E8BD559.3060502@necom830.hpcl.titech.ac.jp> <20111005042728.4D8A514A46C1@drugs.dv.isc.org> In-Reply-To: <20111005042728.4D8A514A46C1@drugs.dv.isc.org> Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit Cc: 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, 05 Oct 2011 05:07:53 -0000 Mark Andrews wrote: > Personally, I look at my wristwatch. You may but your computers can not. > DNSSEC only requires loose > time syncronization. Most machines, provided they have a battery > backed up clock, could run their entire life on the time as set > by the manufacturer. A problem is that, even though an hour of error is not significant to DNSSEC, it is significant to most other purposes, which means the clock is synchronized to external source. Masataka Ohta From lubos.slovak@nic.cz Wed Oct 5 01:15: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 EA24A21F8AB8 for ; Wed, 5 Oct 2011 01:15:22 -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 CDRDQj1GYVKi for ; Wed, 5 Oct 2011 01:15:22 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id 55F7821F862F for ; Wed, 5 Oct 2011 01:15:21 -0700 (PDT) Received: from [IPv6:2001:1488:ac14:1400:222:19ff:fe31:432a] (unknown [IPv6:2001:1488:ac14:1400:222:19ff:fe31:432a]) by mail.nic.cz (Postfix) with ESMTPSA id 1C3FE2A2B62 for ; Wed, 5 Oct 2011 10:18:21 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1317802701; bh=V5npl2nM5JDkrwp86sNqwVAH7i5/lTBe6x/lSib3OBo=; h=Message-ID:Date:From:MIME-Version:To:Subject:Content-Type: Content-Transfer-Encoding; b=TOoeGaLi1D/UhzbNdDHevMhSr5nSfl9vPXyGWfJu6EZ2511Ij5l7eYnsh+K3A41t5 AIXbYt5tLSk6OqICcIPBiTYcxaf1hqE8E8f6ObmJz5TXlNnMglyNhGaQW5B4SxTHPd tYAa6hf3/66LEH/fLFKBvSvLJq6xkQBNq72qFVrY= Message-ID: <4E8C12CC.3090701@nic.cz> Date: Wed, 05 Oct 2011 10:18:20 +0200 From: Lubos Slovak User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.21) Gecko/20110831 Thunderbird/3.1.13 MIME-Version: 1.0 To: dnsext@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: clamav-milter 0.96.5 at mail X-Virus-Status: Clean Subject: [dnsext] RETRY and EXPIRE clarification 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, 05 Oct 2011 08:15:23 -0000 Hi, I find the definition of RETRY and EXPIRE intervals in RFC 1035 quite vague and did not find any other RFC clarifying it. 1) Should the RETRY interval start when the REFRESH event occurred (this is a bit more deterministic) or when it is clear that the transfer failed, i.e. on timeout or error during transfer (this is maybe closer to the definition of RETRY in RFC 1035, part 3.3.13)? 2) What should happen if the EXPIRE interval elapses before the transfer is finished (assume large zone, transfer lasts for several minutes and EXPIRE is set too low - i.e. 1 minute)? Should the server cease to serve the zone? If yes, should it serve the zone again after the transfer is finished? Thanks a lot, Lubos From Ed.Lewis@neustar.biz Wed Oct 5 05:42:32 2011 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 923C921F8BEB for ; Wed, 5 Oct 2011 05:42:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.129 X-Spam-Level: X-Spam-Status: No, score=-105.129 tagged_above=-999 required=5 tests=[AWL=-0.944, BAYES_40=-0.185, 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 BaoWDlaw5UoJ for ; Wed, 5 Oct 2011 05:42:32 -0700 (PDT) Received: from stora.ogud.com (stora.ogud.com [66.92.146.20]) by ietfa.amsl.com (Postfix) with ESMTP id CD1BC21F8BE8 for ; Wed, 5 Oct 2011 05:42:31 -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 p95CjVO4050189; Wed, 5 Oct 2011 08:45:38 -0400 (EDT) (envelope-from Ed.Lewis@neustar.biz) Received: from [10.31.203.207] by Work-Laptop-2.local (PGP Universal service); Wed, 05 Oct 2011 08:45:40 -0400 X-PGP-Universal: processed; by Work-Laptop-2.local on Wed, 05 Oct 2011 08:45:40 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: <4E8C12CC.3090701@nic.cz> References: <4E8C12CC.3090701@nic.cz> Date: Wed, 5 Oct 2011 08:45:30 -0400 To: Lubos Slovak From: Edward Lewis Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.72 on 10.20.30.4 Cc: dnsext@ietf.org Subject: Re: [dnsext] RETRY and EXPIRE clarification 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, 05 Oct 2011 12:42:32 -0000 At 10:18 +0200 10/5/11, Lubos Slovak wrote: >Hi, > >I find the definition of RETRY and EXPIRE intervals in RFC 1035 >quite vague and did not find any other RFC clarifying it. First lesson in reading RFC 1034/1035 - don't take them that literally. They were descriptions of the system, not specifications. This was explained to me by one of the folks involved in writing them. >1) Should the RETRY interval start when the REFRESH event occurred (this >is a bit more deterministic) or when it is clear that the transfer failed, >i.e. on timeout or error during transfer (this is maybe closer to the >definition of RETRY in RFC 1035, part 3.3.13)? Doesn't really matter, I mean, how long does it take to fail a transfer? Let's say it's 90 seconds - if the retry is 43200 (12 hours), whether you try 1/2 a day later or 1/2 day plus 90 seconds later isn't going to change things. It looks cooler in the logs if the retries happen at the stroke of 1/2 day intervals, but it doesn't matter in the long run. >2) What should happen if the EXPIRE interval elapses before the transfer is >finished (assume large zone, transfer lasts for several minutes and EXPIRE is >set too low - i.e. 1 minute)? Should the server cease to serve the zone? If >yes, should it serve the zone again after the transfer is finished? Could and yeah. I suspect that while you are transferring the zone you can suspend checking the timer if you want and no one would complain. EXPIRE shouldn't be that low though. DNS wasn't built to be real time, when you have a server-cache-client architecture you can expect it to be that fast. (There's nothing wrong in trying to make DNS be real time. But you'll have to realize it takes some work as that wasn't the design goal. Kind of like trying to drag race pickup trucks. You can do it, but it isn't as easy or efficient as drag racing speedsters.) -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- 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 cet1@hermes.cam.ac.uk Wed Oct 5 06:47:01 2011 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AFE9C21F8B17 for ; Wed, 5 Oct 2011 06:47:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.367 X-Spam-Level: X-Spam-Status: No, score=-6.367 tagged_above=-999 required=5 tests=[AWL=0.232, 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 jxCechzGkGzE for ; Wed, 5 Oct 2011 06:47:01 -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 2179321F8AFD for ; Wed, 5 Oct 2011 06:47:00 -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]:43855) by ppsw-52.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.159]:25) with esmtpa (EXTERNAL:cet1) id 1RBRrK-0004oV-FA (Exim 4.72) (return-path ); Wed, 05 Oct 2011 14:50:06 +0100 Received: from prayer by hermes-2.csi.cam.ac.uk (hermes.cam.ac.uk) with local (PRAYER:cet1) id 1RBRrK-0000L4-MG (Exim 4.67) (return-path ); Wed, 05 Oct 2011 14:50:06 +0100 Received: from [131.111.11.47] by webmail.hermes.cam.ac.uk with HTTP (Prayer-1.3.4); 05 Oct 2011 14:50:06 +0100 Date: 05 Oct 2011 14:50:06 +0100 From: Chris Thompson To: Edward Lewis Message-ID: In-Reply-To: References: <4E8C12CC.3090701@nic.cz> X-Mailer: Prayer v1.3.4 Mime-Version: 1.0 Content-Type: text/plain; format=flowed; charset=ISO-8859-1 Sender: Chris Thompson Cc: dnsext@ietf.org Subject: Re: [dnsext] RETRY and EXPIRE clarification X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: cet1@cam.ac.uk List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Oct 2011 13:47:01 -0000 On Oct 5 2011, Edward Lewis wrote: >At 10:18 +0200 10/5/11, Lubos Slovak wrote: [..anip..] >>1) Should the RETRY interval start when the REFRESH event occurred (this >>is a bit more deterministic) or when it is clear that the transfer failed, >>i.e. on timeout or error during transfer (this is maybe closer to the >>definition of RETRY in RFC 1035, part 3.3.13)? > >Doesn't really matter, I mean, how long does it take to fail a >transfer? Let's say it's 90 seconds - if the retry is 43200 (12 >hours), whether you try 1/2 a day later or 1/2 day plus 90 seconds >later isn't going to change things. It looks cooler in the logs if >the retries happen at the stroke of 1/2 day intervals, but it doesn't >matter in the long run. That is in any case the sort of thing that leads to different processes getting into lock step and generating load spikes. It is better to dither the intervals a bit, as NIND has done for, lo, these many years: 432. [func] Added refresh/retry jitter. The actual refresh/ retry time is now a random value between 75% and 100% of the configured value. [That was already in BIND 9.1, at least.] -- Chris Thompson University of Cambridge Computing Service, Email: cet1@ucs.cam.ac.uk New Museums Site, Cambridge CB2 3QH, Phone: +44 1223 334715 United Kingdom. From petithug@acm.org Wed Oct 5 07:17:54 2011 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 20C1F21F8D0C for ; Wed, 5 Oct 2011 07:17:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.158 X-Spam-Level: X-Spam-Status: No, score=-99.158 tagged_above=-999 required=5 tests=[AWL=-2.850, BAYES_00=-2.599, GB_SUMOF=5, MISSING_HEADERS=1.292, 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 t5S4AH9IBqLk for ; Wed, 5 Oct 2011 07:17:50 -0700 (PDT) Received: from implementers.org (implementers.org [IPv6:2604:3400:dc1:41:216:3eff:fe5b:8240]) by ietfa.amsl.com (Postfix) with ESMTP id 0844721F8D00 for ; Wed, 5 Oct 2011 07:17:50 -0700 (PDT) Received: from [IPv6:2001:5c0:1111:4e00:213:d4ff:fe04:3e08] (unknown [IPv6:2001:5c0:1111:4e00:213:d4ff:fe04:3e08]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (Client CN "petithug", Issuer "implementers.org" (verified OK)) by implementers.org (Postfix) with ESMTPS id 47A8720878 for ; Wed, 5 Oct 2011 14:13:58 +0000 (UTC) Message-ID: <4E8C67C7.9050000@acm.org> Date: Wed, 05 Oct 2011 07:20:55 -0700 From: Marc Petit-Huguenin User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.21) Gecko/20110831 Iceowl/1.0b2 Icedove/3.1.13 MIME-Version: 1.0 CC: dnsext@ietf.org References: <20111004203900.4016798C25F@rfc-editor.org> In-Reply-To: <20111004203900.4016798C25F@rfc-editor.org> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: Re: [dnsext] [Technical Errata Reported] RFC2782 (2984) 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, 05 Oct 2011 14:17:54 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 The algorithm described in RFC 2782 is what it is, and people know how to configure the values in an SRV RR to achieve what they want. If some disagree with this algorithm, they should work on a rfc2782bis document, but not try to change the meaning of RFC 2782 in an errata. On 10/04/2011 01:39 PM, RFC Errata System wrote: > > The following errata report has been submitted for RFC2782, > "A DNS RR for specifying the location of services (DNS SRV)". > > -------------------------------------- > You may review the report below and at: > http://www.rfc-editor.org/errata_search.php?rfc=2782&eid=2984 > > -------------------------------------- > Type: Technical > Reported by: Jordan Brown > > Section: Weight > > Original Text > ------------- > To select a target to be contacted next, arrange all SRV RRs > (that have not been ordered yet) in any order, except that all > those with weight 0 are placed at the beginning of the list. > > Compute the sum of the weights of those RRs, and with each RR > associate the running sum in the selected order. Then choose a > uniform random number between 0 and the sum computed > (inclusive), and select the RR whose running sum value is the > first in the selected order which is greater than or equal to > the random number selected. The target host specified in the > selected SRV RR is the next one to be contacted by the client. > Remove this SRV RR from the set of the unordered SRV RRs and > apply the described algorithm to the unordered SRV RRs to select > the next target host. Continue the ordering process until there > are no unordered SRV RRs. This process is repeated for each > Priority. > > Corrected Text > -------------- > Correcting the text requires agreement on what to do with entries with > weight=0, so I don't want to try to craft text until we have agreement there. > > Notes > ----- > The problem with this algorithm is that for a total weight T, it generates a random number 0..T and so allocates T+1 shares and gives the extra share to the first entry. Thus with weights {1, 1}, the first entry is selected 2/3 of the time while the second entry is selected 1/3 of the time. > > I suspect that this is an attempt to do *something* with entries with weight=0, but yields unobvious results there: for {0, 1, 1}, the three entries are each selected 1/3 of the time. > > I suggest: > > - Ordering weight=0 entries to the end. > - Generating random numbers 0..(T-1). > - Using a "greater" test rather than "greater or equal". > - Selecting weight=0 entries in any order when all of the weight!=0 entries have been selected. > > Instructions: > ------------- > This errata is currently posted as "Reported". If necessary, please > use "Reply All" to discuss whether it should be verified or > rejected. When a decision is reached, the verifying party (IESG) > can log in to change the status and edit the report, if necessary. > > -------------------------------------- > RFC2782 (draft-ietf-dnsind-rfc2052bis-05) > -------------------------------------- > Title : A DNS RR for specifying the location of services (DNS SRV) > Publication Date : February 2000 > Author(s) : A. Gulbrandsen, P. Vixie, L. Esibov > Category : PROPOSED STANDARD > Source : DNS Extensions > Area : Internet > Stream : IETF > Verifying Party : IESG > _______________________________________________ > dnsext mailing list > dnsext@ietf.org > https://www.ietf.org/mailman/listinfo/dnsext > - -- Marc Petit-Huguenin Personal email: marc@petit-huguenin.org Professional email: petithug@acm.org Blog: http://blog.marc.petit-huguenin.org -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) iEYEARECAAYFAk6MZ8UACgkQ9RoMZyVa61dAXwCgnqxR0MkbR96ST1ZmAV6yScbT o8sAoIy9T7BJVbl+uW6PWPIWH3n1EC2K =adBX -----END PGP SIGNATURE----- From drc@virtualized.org Wed Oct 5 07:22:39 2011 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5FF5821F8C74 for ; Wed, 5 Oct 2011 07:22:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.456 X-Spam-Level: X-Spam-Status: No, score=-2.456 tagged_above=-999 required=5 tests=[AWL=0.143, 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 7eaqmeRHmC0i for ; Wed, 5 Oct 2011 07:22:38 -0700 (PDT) Received: from trantor.virtualized.org (trantor.virtualized.org [199.48.134.42]) by ietfa.amsl.com (Postfix) with ESMTP id 4FD9021F8D20 for ; Wed, 5 Oct 2011 07:22:38 -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 BF2E61704E; Wed, 5 Oct 2011 14:25:39 +0000 (UTC) Mime-Version: 1.0 (Apple Message framework v1244.3) Content-Type: text/plain; charset=us-ascii From: David Conrad In-Reply-To: Date: Wed, 5 Oct 2011 07:25:39 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <24EEC86B-DE62-477E-8E77-1A8683803667@virtualized.org> References: <20111004143947.205a61dff9fc1684c258b274662bb912.04bcda2f2f.wbe@email00.secureserver.net> To: Brian Dickson X-Mailer: Apple Mail (2.1244.3) Cc: DNSEXT Working Group 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, 05 Oct 2011 14:22:39 -0000 On Oct 4, 2011, at 3:54 PM, Brian Dickson wrote: > This proposal is a very lightweight and elegant (IMHO) = counter-counter-measure. Not really. It is a hack that, if implemented, will ensure there is no = pressure to actually fix broken infrastructures. Realistically: - states-sponsored censorship will continue to occur: states have a = tendency to insist on that sort of thing, with guns if necessary; - folks intentionally blocking working DNS to force the use of their = name servers will figure out a way to continue blocking DNS: I have = sufficient faith in the tenacity of such folks that all this will do is = result in a cat-and-mouse game (e.g., it won't be that hard to figure = out which HTTP{,S} server IP addresses to blacklist); - middlebox vendors and lazy DNS operators won't need to fix their DNS = implementations because there is now a HTTP{,S} bypass for the folks = that whine about such things; and - we now have to saddle DNSSEC server implementations (auth and = recursive) with yet more complexity. Permanently. This feels like the wrong way to solve this problem. Regards, -drc From petithug@acm.org Wed Oct 5 08:43:39 2011 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1CF051F0C38 for ; Wed, 5 Oct 2011 08:43:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.233 X-Spam-Level: X-Spam-Status: No, score=-102.233 tagged_above=-999 required=5 tests=[AWL=0.367, 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 VHSNM16ver2C for ; Wed, 5 Oct 2011 08:43:38 -0700 (PDT) Received: from implementers.org (implementers.org [IPv6:2604:3400:dc1:41:216:3eff:fe5b:8240]) by ietfa.amsl.com (Postfix) with ESMTP id 76E911F0C35 for ; Wed, 5 Oct 2011 08:43:38 -0700 (PDT) Received: from [IPv6:2001:5c0:1111:4e00:213:d4ff:fe04:3e08] (unknown [IPv6:2001:5c0:1111:4e00:213:d4ff:fe04:3e08]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (Client CN "petithug", Issuer "implementers.org" (verified OK)) by implementers.org (Postfix) with ESMTPS id 6D70020878; Wed, 5 Oct 2011 15:39:45 +0000 (UTC) Message-ID: <4E8C7BE2.7080107@acm.org> Date: Wed, 05 Oct 2011 08:46:42 -0700 From: Marc Petit-Huguenin User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.21) Gecko/20110831 Iceowl/1.0b2 Icedove/3.1.13 MIME-Version: 1.0 To: Jordan Brown References: <20111004203900.4016798C25F@rfc-editor.org> <4E8C55BC.2080203@petit-huguenin.org> <4E8C7A6E.9040206@oracle.com> In-Reply-To: <4E8C7A6E.9040206@oracle.com> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: arnt@troll.no, levone@microsoft.com, dnsext@ietf.org, jari.arkko@piuha.net, rdroms.ietf@gmail.com, ogud@ogud.com, RFC Errata System Subject: Re: [dnsext] [Technical Errata Reported] RFC2782 (2984) 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, 05 Oct 2011 15:43:39 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 10/05/2011 08:40 AM, Jordan Brown wrote: > On 10/05/11 06:03, Marc Petit-Huguenin wrote: > The algorithm described in RFC 2782 is what it is, and people know how to > configure the values in an SRV RR to achieve what they want. If some disagree > with this algorithm, they should work on a rfc2782bis document, but not try to > change the meaning of RFC 2782 in an errata. > >> Could be. I just wanted to point out the inconsistency in the specification; >> some parts say to choose proportionally (note the example that says that {1,3} >> yields {1/4, 3/4}, when it actually yields either {2/5, 3/5} or {1/5, 4/5} >> depending on the order reported) but the algorithm doesn't quite do that. > >> For small weights the difference is significant. For large weights it's not. Yes, so perhaps the errata should be to say something like "Try to use weights as high as possible, unless you use the value 0". - -- Marc Petit-Huguenin Personal email: marc@petit-huguenin.org Professional email: petithug@acm.org Blog: http://blog.marc.petit-huguenin.org -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) iEYEARECAAYFAk6Me94ACgkQ9RoMZyVa61cInQCfVYNTxTdipk5c9h7+lrtvojKH o64An1gURA5d1ekuLM4on480BANJCXxA =wTD8 -----END PGP SIGNATURE----- From bmanning@karoshi.com Wed Oct 5 08:43: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 D36681F0C38 for ; Wed, 5 Oct 2011 08:43:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.225 X-Spam-Level: X-Spam-Status: No, score=-6.225 tagged_above=-999 required=5 tests=[AWL=0.374, 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 wnbEVJ06lfq9 for ; Wed, 5 Oct 2011 08:43:42 -0700 (PDT) Received: from vacation.karoshi.com (vacation.karoshi.com [198.32.6.68]) by ietfa.amsl.com (Postfix) with ESMTP id E269D1F0C35 for ; Wed, 5 Oct 2011 08:43:41 -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 p95FjCEE004853; Wed, 5 Oct 2011 15:45:32 GMT Received: (from bmanning@localhost) by karoshi.com (8.12.8/8.12.8/Submit) id p95Fipoc004852; Wed, 5 Oct 2011 15:44:51 GMT Date: Wed, 5 Oct 2011 15:44:41 +0000 From: bmanning@vacation.karoshi.com To: David Conrad Message-ID: <20111005154441.GB3823@vacation.karoshi.com.> References: <20111004143947.205a61dff9fc1684c258b274662bb912.04bcda2f2f.wbe@email00.secureserver.net> <24EEC86B-DE62-477E-8E77-1A8683803667@virtualized.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <24EEC86B-DE62-477E-8E77-1A8683803667@virtualized.org> User-Agent: Mutt/1.4.1i Cc: DNSEXT Working Group 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, 05 Oct 2011 15:43:42 -0000 On Wed, Oct 05, 2011 at 07:25:39AM -0700, David Conrad wrote: > On Oct 4, 2011, at 3:54 PM, Brian Dickson wrote: > > This proposal is a very lightweight and elegant (IMHO) counter-counter-measure. > > Not really. It is a hack that, if implemented, will ensure there is no pressure to actually fix broken infrastructures. Realistically: > > - states-sponsored censorship will continue to occur: states have a tendency to insist on that sort of thing, with guns if necessary; > - folks intentionally blocking working DNS to force the use of their name servers will figure out a way to continue blocking DNS: I have sufficient faith in the tenacity of such folks that all this will do is result in a cat-and-mouse game (e.g., it won't be that hard to figure out which HTTP{,S} server IP addresses to blacklist); > - middlebox vendors and lazy DNS operators won't need to fix their DNS implementations because there is now a HTTP{,S} bypass for the folks that whine about such things; and > - we now have to saddle DNSSEC server implementations (auth and recursive) with yet more complexity. Permanently. complexity is a serious problem for maintaining a secure and auditable system. there is no clear, crisp engineering reason to persue this tactic... it is, as stated, a counter-counter measure... looks like an arms race to me, not useful engineering. > This feels like the wrong way to solve this problem. amen. (sorry - too religious - +1) /bill > > Regards, > -drc > > _______________________________________________ > dnsext mailing list > dnsext@ietf.org > https://www.ietf.org/mailman/listinfo/dnsext From Ed.Lewis@neustar.biz Wed Oct 5 08:45: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 305A81F0C38 for ; Wed, 5 Oct 2011 08:45:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.301 X-Spam-Level: X-Spam-Status: No, score=-106.301 tagged_above=-999 required=5 tests=[AWL=0.298, 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 9-EHbsm6uqk4 for ; Wed, 5 Oct 2011 08:45:33 -0700 (PDT) Received: from stora.ogud.com (stora.ogud.com [66.92.146.20]) by ietfa.amsl.com (Postfix) with ESMTP id 899A41F0C36 for ; Wed, 5 Oct 2011 08:45:33 -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 p95Fmabo051575; Wed, 5 Oct 2011 11:48:37 -0400 (EDT) (envelope-from Ed.Lewis@neustar.biz) Received: from [10.31.203.207] by Work-Laptop-2.local (PGP Universal service); Wed, 05 Oct 2011 11:48:37 -0400 X-PGP-Universal: processed; by Work-Laptop-2.local on Wed, 05 Oct 2011 11:48:37 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: References: <4E8C12CC.3090701@nic.cz> Date: Wed, 5 Oct 2011 11:46:24 -0400 To: From: Edward Lewis Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.72 on 10.20.30.4 Cc: Edward Lewis , dnsext@ietf.org Subject: Re: [dnsext] RETRY and EXPIRE clarification 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, 05 Oct 2011 15:45:34 -0000 At 14:50 +0100 10/5/11, Chris Thompson wrote: >That is in any case the sort of thing that leads to different processes >getting into lock step and generating load spikes. It is better to >dither the intervals a bit, as NIND has done for, lo, these many years: Unless a customer wants it to be precisely when they expect it to be. There's a lot to be said for predictability (and against dithering intervals in this case). If it results in spikes, you know why and you can take verifiable steps avoid it. OTOH, predictability isn't always desirable and dithering intervals is the answer. A lot depends on the problem domain's characteristics. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- 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 petithug@acm.org Wed Oct 5 09:08:17 2011 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7983B21F8C0A for ; Wed, 5 Oct 2011 09:08:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.242 X-Spam-Level: X-Spam-Status: No, score=-102.242 tagged_above=-999 required=5 tests=[AWL=0.358, 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 6g+yHNLqduM3 for ; Wed, 5 Oct 2011 09:08:15 -0700 (PDT) Received: from implementers.org (implementers.org [IPv6:2604:3400:dc1:41:216:3eff:fe5b:8240]) by ietfa.amsl.com (Postfix) with ESMTP id 73E4721F8B9C for ; Wed, 5 Oct 2011 09:08:15 -0700 (PDT) Received: from [IPv6:2001:5c0:1111:4e00:213:d4ff:fe04:3e08] (unknown [IPv6:2001:5c0:1111:4e00:213:d4ff:fe04:3e08]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (Client CN "petithug", Issuer "implementers.org" (verified OK)) by implementers.org (Postfix) with ESMTPS id 09F2A20878; Wed, 5 Oct 2011 16:04:22 +0000 (UTC) Message-ID: <4E8C81A9.9030401@acm.org> Date: Wed, 05 Oct 2011 09:11:21 -0700 From: Marc Petit-Huguenin User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.21) Gecko/20110831 Iceowl/1.0b2 Icedove/3.1.13 MIME-Version: 1.0 To: Jordan Brown References: <20111004203900.4016798C25F@rfc-editor.org> <4E8C55BC.2080203@petit-huguenin.org> <4E8C7A6E.9040206@oracle.com> In-Reply-To: <4E8C7A6E.9040206@oracle.com> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: levone@microsoft.com, dnsext@ietf.org, jari.arkko@piuha.net, rdroms.ietf@gmail.com, ogud@ogud.com, RFC Errata System Subject: Re: [dnsext] [Technical Errata Reported] RFC2782 (2984) 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, 05 Oct 2011 16:08:17 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 10/05/2011 08:40 AM, Jordan Brown wrote: > On 10/05/11 06:03, Marc Petit-Huguenin wrote: > The algorithm described in RFC 2782 is what it is, and people know how to > configure the values in an SRV RR to achieve what they want. If some disagree > with this algorithm, they should work on a rfc2782bis document, but not try to > change the meaning of RFC 2782 in an errata. > >> Could be. I just wanted to point out the inconsistency in the specification; >> some parts say to choose proportionally (note the example that says that {1,3} >> yields {1/4, 3/4}, when it actually yields either {2/5, 3/5} or {1/5, 4/5} >> depending on the order reported) but the algorithm doesn't quite do that. Well, { 3/10, 7/10 } if each client randomizes the order each time and restarts with a new list after each successful connection (which is another underspecification in RFC 2782 that IMO would justify an rfc2782bis). > >> For small weights the difference is significant. For large weights it's not. > > - -- Marc Petit-Huguenin Personal email: marc@petit-huguenin.org Professional email: petithug@acm.org Blog: http://blog.marc.petit-huguenin.org -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) iEYEARECAAYFAk6MgacACgkQ9RoMZyVa61d76gCdHCXl4t/j3G74A5IdwxLyfJlV aDIAoJ64nHnpz2CxxPwk8vFgM/NS18zB =58Dx -----END PGP SIGNATURE----- From Jordan.Brown@oracle.com Tue Oct 4 16:19: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 ACC0E21F8F03 for ; Tue, 4 Oct 2011 16:19:08 -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 ol-GuVbPvqtC for ; Tue, 4 Oct 2011 16:19:08 -0700 (PDT) Received: from rcsinet15.oracle.com (rcsinet15.oracle.com [148.87.113.117]) by ietfa.amsl.com (Postfix) with ESMTP id 0F40921F8EFD for ; Tue, 4 Oct 2011 16:19:07 -0700 (PDT) Received: from ucsinet23.oracle.com (ucsinet23.oracle.com [156.151.31.71]) by rcsinet15.oracle.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id p94NM8LS020138 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 4 Oct 2011 23:22:11 GMT Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158]) by ucsinet23.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id p94NM7ZS004911 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 4 Oct 2011 23:22:07 GMT Received: from abhmt119.oracle.com (abhmt119.oracle.com [141.146.116.71]) by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id p94NLxJl012221; Tue, 4 Oct 2011 18:21:59 -0500 Received: from [10.195.1.81] (/10.195.1.81) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 04 Oct 2011 16:21:58 -0700 Message-ID: <4E8B9515.3060503@oracle.com> Date: Tue, 04 Oct 2011 16:21:57 -0700 From: Jordan Brown User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.9.2.15) Gecko/20110304 Thunderbird/3.1.9 MIME-Version: 1.0 To: Masataka Ohta References: <20111004203900.4016798C25F@rfc-editor.org> <4E8B9014.3060000@necom830.hpcl.titech.ac.jp> In-Reply-To: <4E8B9014.3060000@necom830.hpcl.titech.ac.jp> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Source-IP: ucsinet23.oracle.com [156.151.31.71] X-CT-RefId: str=0001.0A090208.4E8B9524.0020,ss=1,re=0.000,fgs=0 X-Mailman-Approved-At: Wed, 05 Oct 2011 10:01:23 -0700 Cc: arnt@troll.no, levone@microsoft.com, dnsext@ietf.org, jari.arkko@piuha.net, rdroms.ietf@gmail.com, ogud@ogud.com, RFC Errata System Subject: Re: [dnsext] [Technical Errata Reported] RFC2782 (2984) 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, 04 Oct 2011 23:19:08 -0000 On 10/04/11 16:00, Masataka Ohta wrote: > RFC Errata System wrote: > >> Corrected Text >> -------------- >> Correcting the text requires agreement on what to do with entries with >> weight=0, so I don't want to try to craft text until we have agreement there. > > From examples of the RFC: > > ; NO other services are supported > *._tcp SRV 0 0 0 . > *._udp SRV 0 0 0 . > > it is obvious that weight=0 means that the RR must not be > selected. Perhaps, but on the other hand it also says: Domain administrators SHOULD use Weight 0 when there isn't any server selection to do, to make the RR easier to read for humans (less noisy). In the presence of records containing weights greater than 0, records with weight 0 should have a very small chance of being selected. > >> I suggest: >> >> - Ordering weight=0 entries to the end. >> - Generating random numbers 0..(T-1). >> - Using a "greater" test rather than "greater or equal". >> - Selecting weight=0 entries in any order when all of the weight!=0 entries have been selected. > > I suggest: > >> - Generating random numbers 0..(T-1). >> - Using a "greater" test rather than "greater or equal". > > Masataka Ohta From Jordan.Brown@oracle.com Wed Oct 5 08:37:39 2011 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7215621F8C46 for ; Wed, 5 Oct 2011 08:37:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.099 X-Spam-Level: X-Spam-Status: No, score=-4.099 tagged_above=-999 required=5 tests=[AWL=-2.500, BAYES_00=-2.599, GB_SUMOF=5, 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 BiuL3j01hJwZ for ; Wed, 5 Oct 2011 08:37:38 -0700 (PDT) Received: from acsinet15.oracle.com (acsinet15.oracle.com [141.146.126.227]) by ietfa.amsl.com (Postfix) with ESMTP id 7261621F8B7B for ; Wed, 5 Oct 2011 08:37:38 -0700 (PDT) Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237]) by acsinet15.oracle.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id p95FefSp008576 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 5 Oct 2011 15:40:43 GMT Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156]) by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id p95Fecf4018757 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 5 Oct 2011 15:40:39 GMT Received: from abhmt119.oracle.com (abhmt119.oracle.com [141.146.116.71]) by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id p95FeWN8001107; Wed, 5 Oct 2011 10:40:32 -0500 Received: from [10.195.1.81] (/10.195.1.81) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 05 Oct 2011 08:40:32 -0700 Message-ID: <4E8C7A6E.9040206@oracle.com> Date: Wed, 05 Oct 2011 08:40:30 -0700 From: Jordan Brown User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.9.2.15) Gecko/20110304 Thunderbird/3.1.9 MIME-Version: 1.0 To: Marc Petit-Huguenin References: <20111004203900.4016798C25F@rfc-editor.org> <4E8C55BC.2080203@petit-huguenin.org> In-Reply-To: <4E8C55BC.2080203@petit-huguenin.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Source-IP: acsinet21.oracle.com [141.146.126.237] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090208.4E8C7A7C.008C:SCFMA922111,ss=1,re=-4.000,fgs=0 X-Mailman-Approved-At: Wed, 05 Oct 2011 10:01:23 -0700 Cc: arnt@troll.no, levone@microsoft.com, dnsext@ietf.org, jari.arkko@piuha.net, rdroms.ietf@gmail.com, ogud@ogud.com, RFC Errata System Subject: Re: [dnsext] [Technical Errata Reported] RFC2782 (2984) 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, 05 Oct 2011 15:37:39 -0000 On 10/05/11 06:03, Marc Petit-Huguenin wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > The algorithm described in RFC 2782 is what it is, and people know how to > configure the values in an SRV RR to achieve what they want. If some disagree > with this algorithm, they should work on a rfc2782bis document, but not try to > change the meaning of RFC 2782 in an errata. Could be. I just wanted to point out the inconsistency in the specification; some parts say to choose proportionally (note the example that says that {1,3} yields {1/4, 3/4}, when it actually yields either {2/5, 3/5} or {1/5, 4/5} depending on the order reported) but the algorithm doesn't quite do that. For small weights the difference is significant. For large weights it's not. > > On 10/04/2011 01:39 PM, RFC Errata System wrote: >> >> The following errata report has been submitted for RFC2782, >> "A DNS RR for specifying the location of services (DNS SRV)". >> >> -------------------------------------- >> You may review the report below and at: >> http://www.rfc-editor.org/errata_search.php?rfc=2782&eid=2984 >> >> -------------------------------------- >> Type: Technical >> Reported by: Jordan Brown >> >> Section: Weight >> >> Original Text >> ------------- >> To select a target to be contacted next, arrange all SRV RRs >> (that have not been ordered yet) in any order, except that all >> those with weight 0 are placed at the beginning of the list. >> >> Compute the sum of the weights of those RRs, and with each RR >> associate the running sum in the selected order. Then choose a >> uniform random number between 0 and the sum computed >> (inclusive), and select the RR whose running sum value is the >> first in the selected order which is greater than or equal to >> the random number selected. The target host specified in the >> selected SRV RR is the next one to be contacted by the client. >> Remove this SRV RR from the set of the unordered SRV RRs and >> apply the described algorithm to the unordered SRV RRs to select >> the next target host. Continue the ordering process until there >> are no unordered SRV RRs. This process is repeated for each >> Priority. >> >> Corrected Text >> -------------- >> Correcting the text requires agreement on what to do with entries with >> weight=0, so I don't want to try to craft text until we have agreement there. >> >> Notes >> ----- >> The problem with this algorithm is that for a total weight T, it generates a random number 0..T and so allocates T+1 shares and gives the extra share to the first entry. Thus with weights {1, 1}, the first entry is selected 2/3 of the time while the second entry is selected 1/3 of the time. >> >> I suspect that this is an attempt to do *something* with entries with weight=0, but yields unobvious results there: for {0, 1, 1}, the three entries are each selected 1/3 of the time. >> >> I suggest: >> >> - Ordering weight=0 entries to the end. >> - Generating random numbers 0..(T-1). >> - Using a "greater" test rather than "greater or equal". >> - Selecting weight=0 entries in any order when all of the weight!=0 entries have been selected. >> >> Instructions: >> ------------- >> This errata is currently posted as "Reported". If necessary, please >> use "Reply All" to discuss whether it should be verified or >> rejected. When a decision is reached, the verifying party (IESG) >> can log in to change the status and edit the report, if necessary. >> >> -------------------------------------- >> RFC2782 (draft-ietf-dnsind-rfc2052bis-05) >> -------------------------------------- >> Title : A DNS RR for specifying the location of services (DNS SRV) >> Publication Date : February 2000 >> Author(s) : A. Gulbrandsen, P. Vixie, L. Esibov >> Category : PROPOSED STANDARD >> Source : DNS Extensions >> Area : Internet >> Stream : IETF >> Verifying Party : IESG >> _______________________________________________ >> dnsext mailing list >> dnsext@ietf.org >> https://www.ietf.org/mailman/listinfo/dnsext >> > > > - -- > Marc Petit-Huguenin > Personal email: marc@petit-huguenin.org > Professional email: petithug@acm.org > Blog: http://blog.marc.petit-huguenin.org > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.11 (GNU/Linux) > > iEYEARECAAYFAk6MVboACgkQ9RoMZyVa61fVRwCeKycrXn6Ceqfq9fczvT4jzRBb > grAAmwdkJqmDrBTOdEZ1hS0O7IyMd9bR > =cOUW > -----END PGP SIGNATURE----- From Jordan.Brown@oracle.com Wed Oct 5 08:45: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 ABAAA1F0C35 for ; Wed, 5 Oct 2011 08:45:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.349 X-Spam-Level: X-Spam-Status: No, score=-5.349 tagged_above=-999 required=5 tests=[AWL=1.250, 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 Rhq3-4Zy6+M2 for ; Wed, 5 Oct 2011 08:45:26 -0700 (PDT) Received: from acsinet15.oracle.com (acsinet15.oracle.com [141.146.126.227]) by ietfa.amsl.com (Postfix) with ESMTP id AC45911E8083 for ; Wed, 5 Oct 2011 08:45:26 -0700 (PDT) Received: from rtcsinet21.oracle.com (rtcsinet21.oracle.com [66.248.204.29]) by acsinet15.oracle.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id p95FmTnm019129 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 5 Oct 2011 15:48:31 GMT Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157]) by rtcsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id p95FmQfi001726 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 5 Oct 2011 15:48:26 GMT Received: from abhmt116.oracle.com (abhmt116.oracle.com [141.146.116.68]) by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id p95FmKcs028821; Wed, 5 Oct 2011 10:48:20 -0500 Received: from [10.195.1.81] (/10.195.1.81) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 05 Oct 2011 08:48:20 -0700 Message-ID: <4E8C7C43.7030106@oracle.com> Date: Wed, 05 Oct 2011 08:48:19 -0700 From: Jordan Brown User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.9.2.15) Gecko/20110304 Thunderbird/3.1.9 MIME-Version: 1.0 To: Marc Petit-Huguenin References: <20111004203900.4016798C25F@rfc-editor.org> <4E8C55BC.2080203@petit-huguenin.org> <4E8C7A6E.9040206@oracle.com> <4E8C7BE2.7080107@acm.org> In-Reply-To: <4E8C7BE2.7080107@acm.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Source-IP: rtcsinet21.oracle.com [66.248.204.29] X-CT-RefId: str=0001.0A090208.4E8C7C50.002C,ss=1,re=0.000,fgs=0 X-Mailman-Approved-At: Wed, 05 Oct 2011 10:01:23 -0700 Cc: arnt@troll.no, levone@microsoft.com, dnsext@ietf.org, jari.arkko@piuha.net, rdroms.ietf@gmail.com, ogud@ogud.com, RFC Errata System Subject: Re: [dnsext] [Technical Errata Reported] RFC2782 (2984) 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, 05 Oct 2011 15:45:27 -0000 On 10/05/11 08:46, Marc Petit-Huguenin wrote: > Yes, so perhaps the errata should be to say something like "Try to use weights > as high as possible, unless you use the value 0". Yes, that would be a reasonable response. From mohta@necom830.hpcl.titech.ac.jp Wed Oct 5 16:56: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 5DF7221F8D56 for ; Wed, 5 Oct 2011 16:56:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.042 X-Spam-Level: X-Spam-Status: No, score=-0.042 tagged_above=-999 required=5 tests=[AWL=0.048, 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 iBZxjvQ3zJzf for ; Wed, 5 Oct 2011 16:56:11 -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 7D86521F8D4F for ; Wed, 5 Oct 2011 16:56:11 -0700 (PDT) Received: (qmail 57453 invoked from network); 6 Oct 2011 00:14:41 -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 Oct 2011 00:14:41 -0000 Message-ID: <4E8CEF3A.1020708@necom830.hpcl.titech.ac.jp> Date: Thu, 06 Oct 2011 08:58:50 +0900 From: Masataka Ohta User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: Marc Petit-Huguenin References: <20111004203900.4016798C25F@rfc-editor.org> <4E8C67C7.9050000@acm.org> In-Reply-To: <4E8C67C7.9050000@acm.org> Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit Cc: dnsext@ietf.org Subject: Re: [dnsext] [Technical Errata Reported] RFC2782 (2984) 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, 05 Oct 2011 23:56:12 -0000 Marc Petit-Huguenin wrote: > The algorithm described in RFC 2782 is what it is, and people know how to > configure the values in an SRV RR to achieve what they want. Not at all. As the specification is on implementation details, logically inconsistent to the rest of the RFC, people should have no idea how to use weight=0. > If some disagree > with this algorithm, they should work on a rfc2782bis document, but not try to > change the meaning of RFC 2782 in an errata. The problem is that RFC2782 has internal inconsistency because of overspecification on implementation details. Masataka Ohta From marka@isc.org Thu Oct 6 15:59: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 4857111E808A for ; Thu, 6 Oct 2011 15:59:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.26 X-Spam-Level: X-Spam-Status: No, score=-2.26 tagged_above=-999 required=5 tests=[AWL=0.339, 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 9Mj5cRlhENkK for ; Thu, 6 Oct 2011 15:59:34 -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 B727811E8073 for ; Thu, 6 Oct 2011 15:59:34 -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 431685F98BF for ; Thu, 6 Oct 2011 23:02:34 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (unknown [IPv6:2001:470:1f00:820:6233:4bff:fe01:7585]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by bikeshed.isc.org (Postfix) with ESMTPSA id 2C188216C33 for ; Thu, 6 Oct 2011 23:02:32 +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 4633714C8E52 for ; Fri, 7 Oct 2011 10:02:30 +1100 (EST) To: dnsext@ietf.org From: Mark Andrews Date: Fri, 07 Oct 2011 10:02:30 +1100 Message-Id: <20111006230230.4633714C8E52@drugs.dv.isc.org> Subject: [dnsext] Suggested update to RFC 4035 section 4.9.2 Handling of the CD Bit 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, 06 Oct 2011 22:59:35 -0000 Old: 4.9.2. Handling of the CD Bit A non-validating security-aware stub resolver SHOULD NOT set the CD bit when sending queries unless it is requested by the application layer, as by definition, a non-validating stub resolver depends on the security-aware recursive name server to perform validation on its behalf. A validating security-aware stub resolver SHOULD set the CD bit, because otherwise the security-aware recursive name server will answer the query using the name server's local policy, which may prevent the stub resolver from receiving data that would be acceptable to the stub resolver's local policy. New: 4.9.2. Handling of the CD Bit A non-validating security-aware stub resolver SHOULD NOT set the CD bit when sending queries unless it is requested by the application layer, as by definition, a non-validating stub resolver depends on the security-aware recursive name server to perform validation on its behalf. A validating security-aware stub resolver SHOULD NOT set the CD bit on initial queries as this will allow upstream validating resolvers to reject answer which fail to validate and to try other sources. If the validating security-aware stub resolver receives a SERVFAIL response to the initial query it should requery with CD bit set in case the SERVFAIL was due to a bad clock or stale trust anchors in a upstream validating resolver. -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From suruti94@gmail.com Thu Oct 6 19:12: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 64BD321F8A58 for ; Thu, 6 Oct 2011 19:12:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.569 X-Spam-Level: X-Spam-Status: No, score=-3.569 tagged_above=-999 required=5 tests=[AWL=0.030, 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 Ucp7wIYZNqWa for ; Thu, 6 Oct 2011 19:12:32 -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 7322D21F8753 for ; Thu, 6 Oct 2011 19:12:32 -0700 (PDT) Received: by ggnk3 with SMTP id k3so2851186ggn.31 for ; Thu, 06 Oct 2011 19:15: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=WwyMcW9W0wzMcZQ+nCNntWfnSTIjiHW0FGdWSQqnNUg=; b=CjC4CqHkda0pTlCZhiBDhGtkFvCMSHIkBBbKdKJczXV2eEzXXpjQYlydt0WJ+ovjc+ //f23do/ZpOoZ1iVaFAPOdVlRI5y7ohxRE6Mosnb0DZFSGGPTUbZ0pJoq1IuBqO+hy3M kxRhmrbc2zZlYfHxKxuJpSN4qzuXN/lWUs0Pc= MIME-Version: 1.0 Received: by 10.68.23.163 with SMTP id n3mr9964248pbf.89.1317953744330; Thu, 06 Oct 2011 19:15:44 -0700 (PDT) Received: by 10.68.46.200 with HTTP; Thu, 6 Oct 2011 19:15:44 -0700 (PDT) In-Reply-To: <20111006230230.4633714C8E52@drugs.dv.isc.org> References: <20111006230230.4633714C8E52@drugs.dv.isc.org> Date: Thu, 6 Oct 2011 19:15:44 -0700 Message-ID: From: Mohan Parthasarathy To: Mark Andrews Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: dnsext@ietf.org Subject: Re: [dnsext] Suggested update to RFC 4035 section 4.9.2 Handling of the CD Bit 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, 07 Oct 2011 02:12:33 -0000 Mark, Thanks for bringing this up on a separate thread. On Thu, Oct 6, 2011 at 4:02 PM, Mark Andrews wrote: > > Old: 4.9.2. =A0Handling of the CD Bit > > =A0 A non-validating security-aware stub resolver SHOULD NOT set the CD > =A0 bit when sending queries unless it is requested by the application > =A0 layer, as by definition, a non-validating stub resolver depends on > =A0 the security-aware recursive name server to perform validation on its > =A0 behalf. > > =A0 A validating security-aware stub resolver SHOULD set the CD bit, > =A0 because otherwise the security-aware recursive name server will > =A0 answer the query using the name server's local policy, which may > =A0 prevent the stub resolver from receiving data that would be > =A0 acceptable to the stub resolver's local policy. > > > New: 4.9.2. =A0Handling of the CD Bit > > =A0 A non-validating security-aware stub resolver SHOULD NOT set the CD > =A0 bit when sending queries unless it is requested by the application > =A0 layer, as by definition, a non-validating stub resolver depends on > =A0 the security-aware recursive name server to perform validation on its > =A0 behalf. > > =A0 A validating security-aware stub resolver SHOULD NOT set the CD There are two problems with this: 1) Validation happens in two places which is really a waste of resources 2) CD bit is being overloaded (see below). As noted in the other thread, it is a misconfiguration. I guess you need a different bit or perhaps clarify the DO bit to mean that "I understand DNSSEC records, don't stop when the first authoritative server does not return the signature, try hard till no servers return any signatures". > =A0 bit on initial queries as this will allow upstream validating > =A0 resolvers to reject answer which fail to validate and to try > =A0 other sources. Why does setting/not-setting the CD bit influence the recursive server to not-try/try other sources ? Why can't the DO bit be used for that as explained above ? -mohan >=A0If the validating security-aware stub resolver > =A0 receives a SERVFAIL response to the initial query it should > =A0 requery with CD bit set in case the SERVFAIL was due to a bad > =A0 clock or stale trust anchors in a upstream validating resolver. > > -- > Mark Andrews, ISC > 1 Seymour St., Dundas Valley, NSW 2117, Australia > PHONE: =A0+61 2 9871 4742 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= INTERNET: marka@isc.org > _______________________________________________ > dnsext mailing list > dnsext@ietf.org > https://www.ietf.org/mailman/listinfo/dnsext > From marka@isc.org Thu Oct 6 20:46: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 80F0D21F8B90 for ; Thu, 6 Oct 2011 20:46:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.294 X-Spam-Level: X-Spam-Status: No, score=-2.294 tagged_above=-999 required=5 tests=[AWL=0.305, 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 5Qa2F7pkdhQL for ; Thu, 6 Oct 2011 20:46:10 -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 8AF6D21F8B8B for ; Thu, 6 Oct 2011 20:46:10 -0700 (PDT) Received: from bikeshed.isc.org (bikeshed.isc.org [IPv6:2001:4f8:3:d::19]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "bikeshed.isc.org", Issuer "ISC CA" (verified OK)) by mx.pao1.isc.org (Postfix) with ESMTPS id 2451BC941E; Fri, 7 Oct 2011 03:49:04 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (unknown [IPv6:2001:470:1f00:820:6233:4bff:fe01:7585]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by bikeshed.isc.org (Postfix) with ESMTPSA id 59F8B216C6B; Fri, 7 Oct 2011 03:49:03 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (Postfix) with ESMTP id DAC6D14D2096; Fri, 7 Oct 2011 14:48:58 +1100 (EST) To: Mohan Parthasarathy From: Mark Andrews References: <20111006230230.4633714C8E52@drugs.dv.isc.org> In-reply-to: Your message of "Thu, 06 Oct 2011 19:15:44 PDT." Date: Fri, 07 Oct 2011 14:48:58 +1100 Message-Id: <20111007034858.DAC6D14D2096@drugs.dv.isc.org> Cc: dnsext@ietf.org Subject: Re: [dnsext] Suggested update to RFC 4035 section 4.9.2 Handling of the CD Bit 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, 07 Oct 2011 03:46:11 -0000 In message , Mohan Parthasarathy writes: > Mark, > > Thanks for bringing this up on a separate thread. > > On Thu, Oct 6, 2011 at 4:02 PM, Mark Andrews wrote: > > > > Old: 4.9.2. =A0Handling of the CD Bit > > > > =A0 A non-validating security-aware stub resolver SHOULD NOT set the CD > > =A0 bit when sending queries unless it is requested by the application > > =A0 layer, as by definition, a non-validating stub resolver depends on > > =A0 the security-aware recursive name server to perform validation on its > > =A0 behalf. > > > > =A0 A validating security-aware stub resolver SHOULD set the CD bit, > > =A0 because otherwise the security-aware recursive name server will > > =A0 answer the query using the name server's local policy, which may > > =A0 prevent the stub resolver from receiving data that would be > > =A0 acceptable to the stub resolver's local policy. > > > > > > New: 4.9.2. =A0Handling of the CD Bit > > > > =A0 A non-validating security-aware stub resolver SHOULD NOT set the CD > > =A0 bit when sending queries unless it is requested by the application > > =A0 layer, as by definition, a non-validating stub resolver depends on > > =A0 the security-aware recursive name server to perform validation on its > > =A0 behalf. > > > > =A0 A validating security-aware stub resolver SHOULD NOT set the CD > > There are two problems with this: > > 1) Validation happens in two places which is really a waste of resources It is unavoidable unless you want to back and forwards lists of upstream servers that have been tried. Also a validating recursive server will most probably validate CD=1 queries anyway as part of adding the answers to its own cache. All this does is move when that validation occurs. You seem to be under the impression that caches don't need to validate if the end systems validate. This is a fallacy. For a cache to not be a DoS source it needs to protect itself from bad data. > 2) CD bit is being overloaded (see below). No it isn't. CD=0 already requires the recursive server to retry if it is validating. If you want to force validation from a non-validating recursive server we need to be able to pass trust anchors to it. > As noted in the other > thread, it is a misconfiguration. I guess you need a different bit or > perhaps clarify the DO bit to mean that "I understand DNSSEC records, > don't stop when the first authoritative server does not return the > signature, try hard till no servers return any signatures". Which just generates lots of unnecessary queries. Crypto is still much quicker than asking more upstream queries. 99.999% of the time the answer you get back does validate. > > =A0 bit on initial queries as this will allow upstream validating > > =A0 resolvers to reject answer which fail to validate and to try > > =A0 other sources. > > Why does setting/not-setting the CD bit influence the recursive server > to not-try/try other sources? CD=0 tells the upstream to only pass what it believe is good. A recursive server is supposed to treat any answer that doesn't validate as if it had never arrived. You then have a lost transaction and the resolver will retry the query. CD=1 tells the upstream to pass through what it got. Repeated CD=1 queries are not required to ask different authoritative servers. > Why can't the DO bit be used for that as explained above ? > > -mohan > > >=A0If the validating security-aware stub resolver > > =A0 receives a SERVFAIL response to the initial query it should > > =A0 requery with CD bit set in case the SERVFAIL was due to a bad > > =A0 clock or stale trust anchors in a upstream validating resolver. > > > > -- > > Mark Andrews, ISC > > 1 Seymour St., Dundas Valley, NSW 2117, Australia > > PHONE: =A0+61 2 9871 4742 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= > INTERNET: marka@isc.org > > _______________________________________________ > > dnsext mailing list > > dnsext@ietf.org > > https://www.ietf.org/mailman/listinfo/dnsext > > -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From Ed.Lewis@neustar.biz Fri Oct 7 07:03: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 3118921F8BBB for ; Fri, 7 Oct 2011 07:03:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.312 X-Spam-Level: X-Spam-Status: No, score=-106.312 tagged_above=-999 required=5 tests=[AWL=0.287, 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 DY7C4VlXHhcp for ; Fri, 7 Oct 2011 07:03:14 -0700 (PDT) Received: from stora.ogud.com (stora.ogud.com [66.92.146.20]) by ietfa.amsl.com (Postfix) with ESMTP id 6A36821F84E5 for ; Fri, 7 Oct 2011 07:03:14 -0700 (PDT) Received: from mzab-lt510.cis.neustar.com (nyttbox.md.ogud.com [10.20.30.4]) by stora.ogud.com (8.14.4/8.14.4) with ESMTP id p97E6QA4020264; Fri, 7 Oct 2011 10:06:26 -0400 (EDT) (envelope-from Ed.Lewis@neustar.biz) Received: from [192.168.128.72] by mzab-lt510.cis.neustar.com (PGP Universal service); Fri, 07 Oct 2011 10:06:27 -0400 X-PGP-Universal: processed; by mzab-lt510.cis.neustar.com on Fri, 07 Oct 2011 10:06:27 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: References: <4E8C12CC.3090701@nic.cz> Date: Fri, 7 Oct 2011 10:06:24 -0400 To: From: Edward Lewis Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.72 on 10.20.30.4 Cc: Edward Lewis Subject: [dnsext] New ID submitted 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, 07 Oct 2011 14:03:15 -0000 http://www.ietf.org/mail-archive/web/i-d-announce/current/msg40107.html Out of frustration trying to locate information on the more obscure RR type registrations at IANA, I drew up this draft. Comments? Yes, there are spelling errors...in the abstract. From the announcement: Title : IANA Allocated DNS RRtyp Codes without Documentation Author(s) : E. Lewis Filename : draft-lewis-dns-undocumented-types-00.txt Pages : 3 Date : 2011-10-06 In the IANA registry of Resource Record (RR) TYPEs, as of October 1, 2011, there are 10 type code values allocated with references that are individual email boxes and not stable documents. Some of the registrations represent works in progress and such a reference is viable. Some registrations are dormant or dead efforts. In all cases it would be helpful to have some refernce to material describing the type. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- 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 ajs@anvilwalrusden.com Fri Oct 7 07:11:38 2011 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EDD6D21F8696 for ; Fri, 7 Oct 2011 07:11:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.569 X-Spam-Level: X-Spam-Status: No, score=-2.569 tagged_above=-999 required=5 tests=[AWL=0.030, 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 e+S2qvemNqJk for ; Fri, 7 Oct 2011 07:11:38 -0700 (PDT) Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by ietfa.amsl.com (Postfix) with ESMTP id 3FBE921F85A4 for ; Fri, 7 Oct 2011 07:11:38 -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 6A8F21ECB41C for ; Fri, 7 Oct 2011 14:14:44 +0000 (UTC) Date: Fri, 7 Oct 2011 10:14:50 -0400 From: Andrew Sullivan To: dnsext@ietf.org Message-ID: <20111007141449.GA73072@shinkuro.com> References: <20111006230230.4633714C8E52@drugs.dv.isc.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20111006230230.4633714C8E52@drugs.dv.isc.org> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: [dnsext] Why are we re-opening this topic? Was: Suggested update to RFC 4035 section 4.9.2 Handling of the CD Bit 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, 07 Oct 2011 14:11:39 -0000 Dear colleagues, This is a procedural matter about decisions we have already made. On Fri, Oct 07, 2011 at 10:02:30AM +1100, Mark Andrews wrote: > > New: 4.9.2. Handling of the CD Bit > > A non-validating security-aware stub resolver SHOULD NOT set the CD > bit when sending queries unless it is requested by the application > layer We had a huge discussion about this some time ago, and even had a design team meeting about it. We came to a conclusion which was confirmed in face to face meetings and on the list. Despite the fact that dnssec-bis-updates has not made it out the door yet, I condiser this issue closed unless someone has some new argument to make about why the decision was the wrong one. I urge anyone who wants to make those arguments to refer to the previous discussions on this topic. If you raise something that was already addressed, I will point that out. Best regards, A -- Andrew Sullivan ajs@anvilwalrusden.com From ajs@anvilwalrusden.com Fri Oct 7 12:24:36 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 38B6921F8C32 for ; Fri, 7 Oct 2011 12:24:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.571 X-Spam-Level: X-Spam-Status: No, score=-2.571 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 mlbGp9Xq2gFn for ; Fri, 7 Oct 2011 12:24:35 -0700 (PDT) Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by ietfa.amsl.com (Postfix) with ESMTP id 8BF0B21F8C2F for ; Fri, 7 Oct 2011 12:24:35 -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 6F4BB1ECB41C for ; Fri, 7 Oct 2011 19:27:42 +0000 (UTC) Date: Fri, 7 Oct 2011 15:27:52 -0400 From: Andrew Sullivan To: dnsext@ietf.org Message-ID: <20111007192752.GO73072@shinkuro.com> References: <20111006230230.4633714C8E52@drugs.dv.isc.org> <20111007141449.GA73072@shinkuro.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20111007141449.GA73072@shinkuro.com> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [dnsext] Why are we re-opening this topic? Was: Suggested update to RFC 4035 section 4.9.2 Handling of the CD Bit 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, 07 Oct 2011 19:24:36 -0000 Dear colleagues, On Fri, Oct 07, 2011 at 10:14:50AM -0400, Andrew Sullivan wrote: > > We had a huge discussion about this some time ago, and even had a > design team meeting about it. A kind participant whom I shall call 'Dew Isle' pointed out to me that it's not very friendly to say "read the previous discussion" without even pointing out where that discussion was. Dew Isle is right, and apologies to all. Here's the beginning of the thread in the archive: http://www.ietf.org/mail-archive/web/dnsext/current/msg08864.html Note that while the discussion was on the namedroppers list, it appears that the old-time archives have been removed, so you'll have to use the IETF archive. Best regards, A -- Andrew Sullivan ajs@anvilwalrusden.com From marka@isc.org Fri Oct 7 15:46: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 D300521F8B5F for ; Fri, 7 Oct 2011 15:46:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.322 X-Spam-Level: X-Spam-Status: No, score=-2.322 tagged_above=-999 required=5 tests=[AWL=0.277, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P++hp2z0tEzp for ; Fri, 7 Oct 2011 15:46:44 -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 0440821F86EE for ; Fri, 7 Oct 2011 15:46:44 -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 C7AE25F98B6; Fri, 7 Oct 2011 22:49:44 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (unknown [IPv6:2001:470:1f00:820:6233:4bff:fe01:7585]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by bikeshed.isc.org (Postfix) with ESMTPSA id 84EDC216C6B; Fri, 7 Oct 2011 22:49:42 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (Postfix) with ESMTP id 6E9BD14DB73A; Sat, 8 Oct 2011 09:49:37 +1100 (EST) To: Andrew Sullivan From: Mark Andrews References: <20111006230230.4633714C8E52@drugs.dv.isc.org> <20111007141449.GA73072@shinkuro.com> <20111007192752.GO73072@shinkuro.com> In-reply-to: Your message of "Fri, 07 Oct 2011 15:27:52 EDT." <20111007192752.GO73072@shinkuro.com> Date: Sat, 08 Oct 2011 09:49:37 +1100 Message-Id: <20111007224937.6E9BD14DB73A@drugs.dv.isc.org> Cc: dnsext@ietf.org Subject: Re: [dnsext] Why are we re-opening this topic? Was: Suggested update to RFC 4035 section 4.9.2 Handling of the CD Bit 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, 07 Oct 2011 22:46:44 -0000 In message <20111007192752.GO73072@shinkuro.com>, Andrew Sullivan writes: > Dear colleagues, > > On Fri, Oct 07, 2011 at 10:14:50AM -0400, Andrew Sullivan wrote: > > > > We had a huge discussion about this some time ago, and even had a > > design team meeting about it. I know that. A non-stub validating resolver has access to multiple athoritative data sources. A validating stub resolver does NOT have *direct* access to multiple authoritative data sources. This can lead to accidental denials of service if the upstream learns data from a bad source and passes it on to the stub. Setting CD=0 on the initial query lets to upstream filter out what it believes to be bad then the stub resolver validates what is passed through. This may or may not validate but has a much higher probability of doing so. If the upstream doesn't pass through a answer that is possible to validate because it can't find one itself the stub then asks with CD=1 to avoid the upstreams validator. This is still not perfect as there may be cases where the stub resolver has TA to a island of trust that the upstream doesn't so the upstream can't help the stub by filtering out obviously bogus responses. The way to fix that is to have the stub pass the TA set it intends to use to the recursive server and have it use that TA set when it filters responses on the stub's behalf. Note this is still CD=0 as the upstream is validating. > A kind participant whom I shall call 'Dew Isle' pointed out to me that > it's not very friendly to say "read the previous discussion" without > even pointing out where that discussion was. Dew Isle is right, and > apologies to all. Here's the beginning of the thread in the archive: > > http://www.ietf.org/mail-archive/web/dnsext/current/msg08864.html > > Note that while the discussion was on the namedroppers list, it > appears that the old-time archives have been removed, so you'll have > to use the IETF archive. > > Best regards, > > A > > -- > Andrew Sullivan > ajs@anvilwalrusden.com > > _______________________________________________ > 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 weiler@tislabs.com Fri Oct 7 15:48: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 4267821F8C0A for ; Fri, 7 Oct 2011 15:48:42 -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 LHIOXidE0WKj for ; Fri, 7 Oct 2011 15:48:41 -0700 (PDT) Received: from walnut.tislabs.com (walnut.tislabs.com [192.94.214.200]) by ietfa.amsl.com (Postfix) with ESMTP id C3F0A21F8C07 for ; Fri, 7 Oct 2011 15:48:41 -0700 (PDT) Received: from nova.tislabs.com (unknown [10.66.1.77]) by walnut.tislabs.com (Postfix) with ESMTP id 551DA28B0040; Fri, 7 Oct 2011 18:51:56 -0400 (EDT) Received: from nova.tislabs.com (nova.tislabs.com [10.66.1.77]) by nova.tislabs.com (Postfix) with ESMTP id 3B2961F8032; Fri, 7 Oct 2011 18:51:56 -0400 (EDT) Date: Fri, 7 Oct 2011 18:51:56 -0400 (EDT) From: weiler@tislabs.com To: Edward Lewis In-Reply-To: Message-ID: References: <4E8C12CC.3090701@nic.cz> User-Agent: Alpine 2.00 (LRH 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: dnsext@ietf.org Subject: Re: [dnsext] New ID submitted 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, 07 Oct 2011 22:48:42 -0000 On Fri, 7 Oct 2011, Edward Lewis wrote: > In all cases it would be helpful to have some refernce to material > describing the type. I agree, but a new draft may not be the right way to do it. Several of these assignments were made under the RFC5395/6195 rules, and those RFCs say "IANA shall maintain a public archive of approved templates." The registry should point at that archive, not the names of people. And the archive should include static copies of documents cited (e.g. i-d's). I don't know if IANA is actually maintaining that archive or, if so, where. > ... there are 10 type code values allocated with references that > are individual email boxes and not stable documents. The TA RR is a slightly different beast, since the citation in the registry is to a stable doc. (You can get it in hardcopy through inter-library loan if you're desperate.) I think the TA RR (32768) is one of only two type codes allocated under the RFC2929 "Specification Required" rules, and the only one with a non-RFC reference. For ease of reference, I'd suggest that IANA just archive the specification document in the same place as the docs describing RRs assigned under 5395/6195. -- Sam From drc@virtualized.org Fri Oct 7 16:06: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 38DC321F8BEC for ; Fri, 7 Oct 2011 16:06:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.474 X-Spam-Level: X-Spam-Status: No, score=-2.474 tagged_above=-999 required=5 tests=[AWL=0.125, 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 D7qKVZ9XZpSg for ; Fri, 7 Oct 2011 16:06:47 -0700 (PDT) Received: from trantor.virtualized.org (trantor.virtualized.org [199.48.134.42]) by ietfa.amsl.com (Postfix) with ESMTP id 184CE21F8BF0 for ; Fri, 7 Oct 2011 16:06:47 -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 AA8861704E; Fri, 7 Oct 2011 23:10:00 +0000 (UTC) Mime-Version: 1.0 (Apple Message framework v1244.3) Content-Type: text/plain; charset=us-ascii From: David Conrad In-Reply-To: <20111007224937.6E9BD14DB73A@drugs.dv.isc.org> Date: Fri, 7 Oct 2011 16:09:58 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <0AB03978-C546-466B-9BA4-0C0F0194EAD1@virtualized.org> References: <20111006230230.4633714C8E52@drugs.dv.isc.org> <20111007141449.GA73072@shinkuro.com> <20111007192752.GO73072@shinkuro.com> <20111007224937.6E9BD14DB73A@drugs.dv.isc.org> To: Mark Andrews X-Mailer: Apple Mail (2.1244.3) Cc: DNSEXT Working Group Subject: Re: [dnsext] Why are we re-opening this topic? Was: Suggested update to RFC 4035 section 4.9.2 Handling of the CD Bit 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, 07 Oct 2011 23:06:48 -0000 Mark, On Oct 7, 2011, at 3:49 PM, Mark Andrews wrote: > In message <20111007192752.GO73072@shinkuro.com>, Andrew Sullivan = writes: >>> We had a huge discussion about this some time ago, and even had a >>> design team meeting about it. >=20 > I know that. For those of us not finely attuned to the CD bit, can you summarize what = has changed since the huge discussion and the design team meeting to = cause you to raise the issue? Thanks, -drc From marka@isc.org Sat Oct 8 05:24: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 C70A621F8A95 for ; Sat, 8 Oct 2011 05:24:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.345 X-Spam-Level: X-Spam-Status: No, score=-2.345 tagged_above=-999 required=5 tests=[AWL=0.254, 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 Ygq9SV1bBisO for ; Sat, 8 Oct 2011 05:24:05 -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 A245321F8663 for ; Sat, 8 Oct 2011 05:23: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.pao1.isc.org (Postfix) with ESMTPS id 19850C9423; Sat, 8 Oct 2011 12:26:58 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (unknown [IPv6:2001:470:1f00:820:6233:4bff:fe01:7585]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by bikeshed.isc.org (Postfix) with ESMTPSA id A0297216C6A; Sat, 8 Oct 2011 12:26:57 +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 EB10314DDC76; Sat, 8 Oct 2011 23:26:53 +1100 (EST) To: David Conrad From: Mark Andrews References: <20111006230230.4633714C8E52@drugs.dv.isc.org> <20111007141449.GA73072@shinkuro.com> <20111007192752.GO73072@shinkuro.com> <20111007224937.6E9BD14DB73A@drugs.dv.isc.org> <0AB03978-C546-466B-9BA4-0C0F0194EAD1@virtualized.org> In-reply-to: Your message of "Fri, 07 Oct 2011 16:09:58 PDT." <0AB03978-C546-466B-9BA4-0C0F0194EAD1@virtualized.org> Date: Sat, 08 Oct 2011 23:26:53 +1100 Message-Id: <20111008122653.EB10314DDC76@drugs.dv.isc.org> Cc: DNSEXT Working Group Subject: Re: [dnsext] Why are we re-opening this topic? Was: Suggested update to RFC 4035 section 4.9.2 Handling of the CD Bit X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Oct 2011 12:24:05 -0000 In message <0AB03978-C546-466B-9BA4-0C0F0194EAD1@virtualized.org>, David Conrad writes: > Mark, > > On Oct 7, 2011, at 3:49 PM, Mark Andrews wrote: > > In message <20111007192752.GO73072@shinkuro.com>, Andrew Sullivan = > writes: > >>> We had a huge discussion about this some time ago, and even had a > >>> design team meeting about it. > >=20 > > I know that. > > For those of us not finely attuned to the CD bit, can you summarize what = > has changed since the huge discussion and the design team meeting to = > cause you to raise the issue? More correctly I know there was a huge discussion about forwarder behaviour and CD and whether there is a covering trust anchor or not. No where in that discussion was there any discussion of the best behaviour for a stub resolver. Nor has there every been any discussion of the denial of service risks of just sending CD=1 queries to the recursive server from a stub resolver. Sending CD=0 is documented in RFC 4035. Now if you can find any real discussion anywhere of how a validating stub resolvers should set CD and the risks related to both setting please point it out. My recollections is we have only ever really thought about setting CD=1 and no proper analysis has ever been done. There are risks with both CD=0 and CD=1 for a stub resolver which is why I am recommending CD=0, then CD=1, as it provides the best mitigation strategy. 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 Sat Oct 8 13:42:57 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 55BC721F893C for ; Sat, 8 Oct 2011 13:42:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.114 X-Spam-Level: X-Spam-Status: No, score=-105.114 tagged_above=-999 required=5 tests=[AWL=-0.930, BAYES_40=-0.185, HTML_MESSAGE=0.001, 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 9JWLEfuqgp07 for ; Sat, 8 Oct 2011 13:42:56 -0700 (PDT) Received: from stora.ogud.com (stora.ogud.com [66.92.146.20]) by ietfa.amsl.com (Postfix) with ESMTP id B5EFC21F87E2 for ; Sat, 8 Oct 2011 13:42:55 -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 p98Kjv1l006959; Sat, 8 Oct 2011 16:45:59 -0400 (EDT) (envelope-from Ed.Lewis@neustar.biz) Received: from [192.168.1.100] by Work-Laptop-2.local (PGP Universal service); Sat, 08 Oct 2011 16:46:05 -0400 X-PGP-Universal: processed; by Work-Laptop-2.local on Sat, 08 Oct 2011 16:46:05 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: References: <4E8C12CC.3090701@nic.cz> Date: Sat, 8 Oct 2011 16:39:11 -0400 To: From: Edward Lewis Content-Type: multipart/alternative; boundary="============_-894015731==_ma============" X-Scanned-By: MIMEDefang 2.72 on 10.20.30.4 Cc: Edward Lewis , dnsext@ietf.org Subject: Re: [dnsext] New ID submitted X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Oct 2011 20:42:57 -0000 --============_-894015731==_ma============ Content-Type: text/plain; charset="us-ascii" ; format="flowed" At 18:51 -0400 10/7/11, wrote: >On Fri, 7 Oct 2011, Edward Lewis wrote: > >> In all cases it would be helpful to have some refernce to material >>describing the type. > >I agree, but a new draft may not be the right way to do it. The reason I submitted this draft was that I feel "something is better than nothing." All I said above is "it would helpful." > >Several of these assignments were made under the RFC5395/6195 rules, >and those RFCs say "IANA shall maintain a public archive of approved >templates." The registry should point at that archive, not the >names of people. And the archive should include static copies of >documents cited (e.g. i-d's). I don't know if IANA is actually >maintaining that archive or, if so, where. > >> ... there are 10 type code values allocated with references that >> are individual email boxes and not stable documents. > >The TA RR is a slightly different beast, since the citation in the >registry is to a stable doc. (You can get it in hardcopy through >inter-library loan if you're desperate.) > >I think the TA RR (32768) is one of only two type codes allocated >under the RFC2929 "Specification Required" rules, and the only one >with a non-RFC reference. For ease of reference, I'd suggest that >IANA just archive the specification document in the same place as >the docs describing RRs assigned under 5395/6195. Ok, there's more frustration in me than I put into the draft. I've been trying to get IANA to clean up the citations for DNS parameters longer than I've had my current job, which means it's been at least 7 years. The ATMA record took quite a while to iron out (and it was). That record was defined in a document owned by the ATM Association and available on that website. (I discovered the document by doing a web search and hitting a Microsoft page with the reference.) I tried to get the document listed at IANA. But then the ATM association website disappeared, "bought up" by the MPLS association. I began to try to get IANA to escrow the document. Later on the MPLS website went away too, replaced by another. Finally, IANA got "permission" from the owners of the document (whomever bought the MPLS-A that bought the ATM=A) to escrow the document. That is why you now see this: [ATMDOC] ATM Forum Technical Committee, "ATM Name System, V2.0", Doc ID: AF-DANS-0152.000, July 2000. Available from http://broadband-forum.org/ftp/pub/approved-specs/af-saa-0069.000.pdf and held in escrow by IANA. So, now, in this draft I'm just putting in some data (names of documents, brief syntax descriptions) and dropping the hint that it would be good to have better references in the registry. As far as trying to request IANA do this - I have and, well, life's too short. So I'm just trying to chip in, as a volunteer, and say to anyone coming along later, if you want to find these types, try these documents and these locations. No guarantees, no promises, and I'm not trying to change the world. This was the second or third time in my career I've had to track these down. I did this writing prototype code for RFC 2065 and 2535 versions of DNSSEC. I did it for my previous job for some reason. I'm doing it now for bookkeeping purposes. I figure if I had written this down the first time, I would have saved me some time. I'm just dropping bread crumbs. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- 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" --============_-894015731==_ma============ Content-Type: text/html; charset="us-ascii" Re: [dnsext] New ID submitted
At 18:51 -0400 10/7/11, <weiler@tislabs.com> wrote:
>On Fri, 7 Oct 2011, Edward Lewis wrote:
>
>> In all cases it would be helpful to have some refernce to material describing the type.
>
>I agree, but a new draft may not be the right way to do it.
The reason I submitted this draft was that I feel "something is better than nothing."  All I said above is "it would helpful."

>
>Several of these assignments were made under the RFC5395/6195 rules, and those RFCs say "IANA shall maintain a public archive of approved templates."  The registry should point at that archive, not the names of people.  And the archive should include static copies of documents cited (e.g. i-d's).  I don't know if IANA is actually maintaining that archive or, if so, where.
>
>> ... there are 10 type code values allocated with references that
>> are individual email boxes and not stable documents.
>
>The TA RR is a slightly different beast, since the citation in the registry is to a stable doc.  (You can get it in hardcopy through inter-library loan if you're desperate.)
>
>I think the TA RR (32768) is one of only two type codes allocated under the RFC2929 "Specification Required" rules, and the only one with a non-RFC reference.  For ease of reference, I'd suggest that IANA just archive the specification document in the same place as the docs describing RRs assigned under 5395/6195.

Ok, there's more frustration in me than I put into the draft.  I've been trying to get IANA to clean up the citations for DNS parameters longer than I've had my current job, which means it's been at least 7 years.

The ATMA record took quite a while to iron out (and it was).  That record was defined in a document owned by the ATM Association and available on that website.  (I discovered the document by doing a web search and hitting a Microsoft page with the reference.)  I tried to get the document listed at IANA.  But then the ATM association website disappeared, "bought up" by the MPLS association.  I began to try to get IANA to escrow the document.  Later on the MPLS website went away too, replaced by another.  Finally, IANA got "permission" from the owners of the document (whomever bought the MPLS-A that bought the ATM=A) to escrow the document.  That is why you now see this:

[ATMDOC]   ATM Forum Technical Committee, "ATM Name System, V2.0",
           Doc ID: AF-DANS-0152.000, July 2000. Available from
           http://broadband-forum.org/ftp/pub/approved-specs/af-saa-0069.000.pdf
           and held in escrow by IANA.
So, now, in this draft I'm just putting in some data (names of documents, brief syntax descriptions) and dropping the hint that it would be good to have better references in the registry.

As far as trying to request IANA do this - I have and, well, life's too short.  So I'm just trying to chip in, as a volunteer, and say to anyone coming along later, if you want to find these types, try these documents and these locations.  No guarantees, no promises, and I'm not trying to change the world.

This was the second or third time in my career I've had to track these down.  I did this writing prototype code for RFC 2065 and 2535 versions of DNSSEC.  I did it for my previous job for some reason.  I'm doing it now for bookkeeping purposes.  I figure if I had written this down the first time, I would have saved me some time.

I'm just dropping bread crumbs.

--
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
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"
--============_-894015731==_ma============-- From ajs@anvilwalrusden.com Sat Oct 8 14:21:18 2011 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E64E21F8B5B for ; Sat, 8 Oct 2011 14:21:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.571 X-Spam-Level: X-Spam-Status: No, score=-2.571 tagged_above=-999 required=5 tests=[AWL=0.028, 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 iaOJeIx4p1gi for ; Sat, 8 Oct 2011 14:21:18 -0700 (PDT) Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by ietfa.amsl.com (Postfix) with ESMTP id DEB9121F8B53 for ; Sat, 8 Oct 2011 14:21:17 -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 AF5561ECB420 for ; Sat, 8 Oct 2011 21:24:27 +0000 (UTC) Date: Sat, 8 Oct 2011 17:24:32 -0400 From: Andrew Sullivan To: dnsext@ietf.org Message-ID: <20111008212432.GB82710@shinkuro.com> References: <20111006230230.4633714C8E52@drugs.dv.isc.org> <20111007141449.GA73072@shinkuro.com> <20111007192752.GO73072@shinkuro.com> <20111007224937.6E9BD14DB73A@drugs.dv.isc.org> <0AB03978-C546-466B-9BA4-0C0F0194EAD1@virtualized.org> <20111008122653.EB10314DDC76@drugs.dv.isc.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20111008122653.EB10314DDC76@drugs.dv.isc.org> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [dnsext] Why are we re-opening this topic? Was: Suggested update to RFC 4035 section 4.9.2 Handling of the CD Bit X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Oct 2011 21:21:18 -0000 No hat. On Sat, Oct 08, 2011 at 11:26:53PM +1100, Mark Andrews wrote: > Nor has there every been any discussion of the denial of service > risks of just sending CD=1 queries to the recursive server from a > stub resolver. Sending CD=0 is documented in RFC 4035. [. . .] > There are risks with both CD=0 and CD=1 for a stub resolver which > is why I am recommending CD=0, then CD=1, as it provides the best > mitigation strategy. That seems to me like an operational or policy decision, and not a protocol matter. That is, your SHOULD NOT in your paragraph 2 is not the SHOULD NOT of RFC 2119, but a SHOULD NOT that means "I think this is the best idea." RFC 2119 SHOULD NOT is about interoperability, which is why it has the unusual meaning as defined in that RFC. There are different possible policies here, and I don't believe one of them ought to be enshrined as the protocol, because I can think of reasons why one might prefer the DoS risk (like, for instance, that you don't have a secure connection to upstream and you know it isn't validating anyway). I can see reasons to write a document (perhaps for DNSOP) on how to operate your validating (stub) resolver. Best regards, A -- Andrew Sullivan ajs@anvilwalrusden.com From marka@isc.org Sat Oct 8 15:35: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 F2A4921F8AA8 for ; Sat, 8 Oct 2011 15:35:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.364 X-Spam-Level: X-Spam-Status: No, score=-2.364 tagged_above=-999 required=5 tests=[AWL=0.235, 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 IjU09hp2TeKc for ; Sat, 8 Oct 2011 15:35:27 -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 0B93E21F8A96 for ; Sat, 8 Oct 2011 15:35:27 -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 4BC91C941E; Sat, 8 Oct 2011 22:38:24 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (unknown [IPv6:2001:470:1f00:820:6233:4bff:fe01:7585]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by bikeshed.isc.org (Postfix) with ESMTPSA id B5BBE216C6A; Sat, 8 Oct 2011 22:38:23 +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 F09F314DF5E1; Sun, 9 Oct 2011 09:38:20 +1100 (EST) To: Andrew Sullivan From: Mark Andrews References: <20111006230230.4633714C8E52@drugs.dv.isc.org> <20111007141449.GA73072@shinkuro.com> <20111007192752.GO73072@shinkuro.com> <20111007224937.6E9BD14DB73A@drugs.dv.isc.org> <0AB03978-C546-466B-9BA4-0C0F0194EAD1@virtualized.org> <20111008122653.EB10314DDC76@drugs.dv.isc.org> <20111008212432.GB82710@shinkuro.com> In-reply-to: Your message of "Sat, 08 Oct 2011 17:24:32 EDT." <20111008212432.GB82710@shinkuro.com> Date: Sun, 09 Oct 2011 09:38:20 +1100 Message-Id: <20111008223820.F09F314DF5E1@drugs.dv.isc.org> Cc: dnsext@ietf.org Subject: Re: [dnsext] Why are we re-opening this topic? Was: Suggested update to RFC 4035 section 4.9.2 Handling of the CD Bit X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Oct 2011 22:35:28 -0000 In message <20111008212432.GB82710@shinkuro.com>, Andrew Sullivan writes: > No hat. > > On Sat, Oct 08, 2011 at 11:26:53PM +1100, Mark Andrews wrote: > > > Nor has there every been any discussion of the denial of service > > risks of just sending CD=1 queries to the recursive server from a > > stub resolver. Sending CD=0 is documented in RFC 4035. > > [. . .] > > > There are risks with both CD=0 and CD=1 for a stub resolver which > > is why I am recommending CD=0, then CD=1, as it provides the best > > mitigation strategy. > > That seems to me like an operational or policy decision, and not a > protocol matter. That is, your SHOULD NOT in your paragraph 2 is not > the SHOULD NOT of RFC 2119, but a SHOULD NOT that means "I think this > is the best idea." RFC 2119 SHOULD NOT is about interoperability, > which is why it has the unusual meaning as defined in that RFC. There > are different possible policies here, and I don't believe one of them > ought to be enshrined as the protocol, because I can think of reasons > why one might prefer the DoS risk (like, for instance, that you don't > have a secure connection to upstream and you know it isn't validating > anyway). By that logic we should strike paragraph 2 of 4.9.2 (Handling of the CD Bit) A validating security-aware stub resolver SHOULD set the CD bit, because otherwise the security-aware recursive name server will answer the query using the name server's local policy, which may prevent the stub resolver from receiving data that would be acceptable to the stub resolver's local policy. That SHOULD is not required for interoperability. Now do we give good advice or do we give no advice? > I can see reasons to write a document (perhaps for DNSOP) on how to > operate your validating (stub) resolver. > Best regards, > > A > > -- > Andrew Sullivan > ajs@anvilwalrusden.com > _______________________________________________ > dnsext mailing list > dnsext@ietf.org > https://www.ietf.org/mailman/listinfo/dnsext -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From ajs@anvilwalrusden.com Sun Oct 9 07:04: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 C2A4F21F8AD9 for ; Sun, 9 Oct 2011 07:04:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.001 X-Spam-Level: X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[BAYES_50=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 cgK-vmQXTctl for ; Sun, 9 Oct 2011 07:04:10 -0700 (PDT) Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by ietfa.amsl.com (Postfix) with ESMTP id 53D4B21F8A97 for ; Sun, 9 Oct 2011 07:04:07 -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 2F2B61ECB41C for ; Sun, 9 Oct 2011 14:03:59 +0000 (UTC) Date: Sun, 9 Oct 2011 10:04:04 -0400 From: Andrew Sullivan To: dnsext@ietf.org Message-ID: <20111009135505.GA85221@shinkuro.com> References: <20111006230230.4633714C8E52@drugs.dv.isc.org> <20111007141449.GA73072@shinkuro.com> <20111007192752.GO73072@shinkuro.com> <20111007224937.6E9BD14DB73A@drugs.dv.isc.org> <0AB03978-C546-466B-9BA4-0C0F0194EAD1@virtualized.org> <20111008122653.EB10314DDC76@drugs.dv.isc.org> <20111008212432.GB82710@shinkuro.com> <20111008223820.F09F314DF5E1@drugs.dv.isc.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20111008223820.F09F314DF5E1@drugs.dv.isc.org> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [dnsext] Why are we re-opening this topic? Was: Suggested update to RFC 4035 section 4.9.2 Handling of the CD Bit 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, 09 Oct 2011 14:04:10 -0000 No hat. On Sun, Oct 09, 2011 at 09:38:20AM +1100, Mark Andrews wrote: > By that logic we should strike paragraph 2 of 4.9.2 (Handling of the CD Bit) > > A validating security-aware stub resolver SHOULD set the CD bit, > because otherwise the security-aware recursive name server will > answer the query using the name server's local policy, which may > prevent the stub resolver from receiving data that would be > acceptable to the stub resolver's local policy. > > That SHOULD is not required for interoperability. True, although it appears to me to be a consequence of the definition of validating security-aware stub resolver. But anyway, > Now do we give good advice or do we give no advice? as I argued before, the advice you are proposing is not in fact always good advice. It's a trade-off. -- Andrew Sullivan ajs@anvilwalrusden.com From marka@isc.org Sun Oct 9 16:01:30 2011 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0BC8D21F87FA for ; Sun, 9 Oct 2011 16:01:30 -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 rQVx34BLDTot for ; Sun, 9 Oct 2011 16:01:29 -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 7649121F87F0 for ; Sun, 9 Oct 2011 16:01:29 -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 B37435F98E6; Sun, 9 Oct 2011 23:01:12 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (unknown [IPv6:2001:470:1f00:820:6233:4bff:fe01:7585]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by bikeshed.isc.org (Postfix) with ESMTPSA id 4B995216C6A; Sun, 9 Oct 2011 23:01:10 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (Postfix) with ESMTP id 4756314E0BDE; Mon, 10 Oct 2011 08:34:31 +1100 (EST) To: Andrew Sullivan From: Mark Andrews References: <20111006230230.4633714C8E52@drugs.dv.isc.org> <20111007141449.GA73072@shinkuro.com> <20111007192752.GO73072@shinkuro.com> <20111007224937.6E9BD14DB73A@drugs.dv.isc.org> <0AB03978-C546-466B-9BA4-0C0F0194EAD1@virtualized.org> <20111008122653.EB10314DDC76@drugs.dv.isc.org> <20111008212432.GB82710@shinkuro.com> <20111008223820.F09F314DF5E1@drugs.dv.isc.org> <20111009135505.GA85221@shinkuro.com> In-reply-to: Your message of "Sun, 09 Oct 2011 10:04:04 EDT." <20111009135505.GA85221@shinkuro.com> Date: Mon, 10 Oct 2011 08:34:31 +1100 Message-Id: <20111009213431.4756314E0BDE@drugs.dv.isc.org> Cc: dnsext@ietf.org Subject: Re: [dnsext] Why are we re-opening this topic? Was: Suggested update to RFC 4035 section 4.9.2 Handling of the CD Bit 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, 09 Oct 2011 23:01:30 -0000 In message <20111009135505.GA85221@shinkuro.com>, Andrew Sullivan writes: > No hat. > > On Sun, Oct 09, 2011 at 09:38:20AM +1100, Mark Andrews wrote: > > > By that logic we should strike paragraph 2 of 4.9.2 (Handling of the CD Bit > ) > > > > A validating security-aware stub resolver SHOULD set the CD bit, > > because otherwise the security-aware recursive name server will > > answer the query using the name server's local policy, which may > > prevent the stub resolver from receiving data that would be > > acceptable to the stub resolver's local policy. > > > > That SHOULD is not required for interoperability. > > True, although it appears to me to be a consequence of the definition > of validating security-aware stub resolver. But anyway, > > > Now do we give good advice or do we give no advice? > > as I argued before, the advice you are proposing is not in fact always > good advice. It's a trade-off. It's *never* bad advice as it get you to do both CD=0 and then CD=1. Advising to do *just* CD=0 or CD=1 is bad advice. If the upstream doesn't have trust anchors then CD=0 or CD=1 is a moot question. If the upstream has trust anchors using just CD=1 is leaving the stub resolver open to a denial of service due to spoofing / misconfiguration of the parent especially if there is CD=1 cache. Similarly just CD=0 is leaving you exposed to bad clocks / stale trust anchors in the recursive server. With CD=0 then CD=1 you mitigate both failure modes. > -- > Andrew Sullivan > ajs@anvilwalrusden.com > _______________________________________________ > 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 suruti94@gmail.com Sun Oct 9 18:41: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 158D121F8B19 for ; Sun, 9 Oct 2011 18:41:41 -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 zDyji3ywE0ZP for ; Sun, 9 Oct 2011 18:41:40 -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 7996421F85A4 for ; Sun, 9 Oct 2011 18:41:40 -0700 (PDT) Received: by ywm3 with SMTP id 3so6131566ywm.31 for ; Sun, 09 Oct 2011 18:41:40 -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=mGQfhlqGeDmlMJO9ya4ZzznSpJrgr1L5JieNAh32xdw=; b=KT9KuxsTKg5yOZ6ujsLYt8eJClwcAy2e+x5xCqJ68RsyNT4Iq4a/Kcwv4N/24Px66e z/GN04DDvQjt7gyngl53J0IwHxAyu86ZP6Q6RRk12IaVVQPaxCHZUeb2WUn0C3vVJxCQ FyoNZLTAtnUJkOFB3zr9GicRTspEXMvtve9lM= MIME-Version: 1.0 Received: by 10.68.36.166 with SMTP id r6mr33166014pbj.77.1318210899805; Sun, 09 Oct 2011 18:41:39 -0700 (PDT) Received: by 10.68.43.37 with HTTP; Sun, 9 Oct 2011 18:41:39 -0700 (PDT) In-Reply-To: <20111009213431.4756314E0BDE@drugs.dv.isc.org> References: <20111006230230.4633714C8E52@drugs.dv.isc.org> <20111007141449.GA73072@shinkuro.com> <20111007192752.GO73072@shinkuro.com> <20111007224937.6E9BD14DB73A@drugs.dv.isc.org> <0AB03978-C546-466B-9BA4-0C0F0194EAD1@virtualized.org> <20111008122653.EB10314DDC76@drugs.dv.isc.org> <20111008212432.GB82710@shinkuro.com> <20111008223820.F09F314DF5E1@drugs.dv.isc.org> <20111009135505.GA85221@shinkuro.com> <20111009213431.4756314E0BDE@drugs.dv.isc.org> Date: Sun, 9 Oct 2011 18:41:39 -0700 Message-ID: From: Mohan Parthasarathy To: Mark Andrews Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: dnsext@ietf.org Subject: Re: [dnsext] Why are we re-opening this topic? Was: Suggested update to RFC 4035 section 4.9.2 Handling of the CD Bit 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, 10 Oct 2011 01:41:41 -0000 On Sun, Oct 9, 2011 at 2:34 PM, Mark Andrews wrote: > > In message <20111009135505.GA85221@shinkuro.com>, Andrew Sullivan writes: >> No hat. >> >> On Sun, Oct 09, 2011 at 09:38:20AM +1100, Mark Andrews wrote: >> >> > By that logic we should strike paragraph 2 of 4.9.2 (Handling of the C= D Bit >> ) >> > >> > =A0 =A0A validating security-aware stub resolver SHOULD set the CD bit= , >> > =A0 =A0because otherwise the security-aware recursive name server will >> > =A0 =A0answer the query using the name server's local policy, which ma= y >> > =A0 =A0prevent the stub resolver from receiving data that would be >> > =A0 =A0acceptable to the stub resolver's local policy. >> > >> > That SHOULD is not required for interoperability. >> >> True, although it appears to me to be a consequence of the definition >> of validating security-aware stub resolver. =A0But anyway, >> >> > Now do we give good advice or do we give no advice? >> >> as I argued before, the advice you are proposing is not in fact always >> good advice. =A0It's a trade-off. > > It's *never* bad advice as it get you to do both CD=3D0 and then CD=3D1. It would be a bad advice if it increases the complexity without real benefi= ts. > Advising to do *just* CD=3D0 or CD=3D1 is bad advice. =A0If the upstream > doesn't have trust anchors then CD=3D0 or CD=3D1 is a moot question. > If the upstream has trust anchors using just CD=3D1 is leaving the > stub resolver open to a denial of service due to spoofing / > misconfiguration of the parent especially if there is CD=3D1 cache. You seem to be implying a "CD=3D1 cache" and "CD=3D0 cache" i.e, a cache maintained differently for CD =3D1 or CD =3D 0. If the recursive sever populates the cache in the same way for both CD=3D0 and CD=3D1, then this issue does not arise. This seems to be much simpler to me rather than treating it differently. -mohan > Similarly just CD=3D0 is leaving you exposed to bad clocks / stale > trust anchors in the recursive server. =A0With CD=3D0 then CD=3D1 you > mitigate both failure modes. > >> -- >> Andrew Sullivan >> ajs@anvilwalrusden.com >> _______________________________________________ >> 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 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 INTERNET: marka@is= c.org > _______________________________________________ > dnsext mailing list > dnsext@ietf.org > https://www.ietf.org/mailman/listinfo/dnsext > From marka@isc.org Sun Oct 9 22:17:51 2011 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6D54521F8783 for ; Sun, 9 Oct 2011 22:17:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m-Tj3raqtkuh for ; Sun, 9 Oct 2011 22:17:50 -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 67D9521F8713 for ; Sun, 9 Oct 2011 22:17:50 -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 9D92F5F98B6; Mon, 10 Oct 2011 05:17:30 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (unknown [IPv6:2001:470:1f00:820:6233:4bff:fe01:7585]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by bikeshed.isc.org (Postfix) with ESMTPSA id 41DBE216C6A; Mon, 10 Oct 2011 05:17:28 +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 3A95214E5206; Mon, 10 Oct 2011 16:17:25 +1100 (EST) To: Mohan Parthasarathy From: Mark Andrews References: <20111006230230.4633714C8E52@drugs.dv.isc.org> <20111007141449.GA73072@shinkuro.com> <20111007192752.GO73072@shinkuro.com> <20111007224937.6E9BD14DB73A@drugs.dv.isc.org> <0AB03978-C546-466B-9BA4-0C0F0194EAD1@virtualized.org> <20111008122653.EB10314DDC76@drugs.dv.isc.org> <20111008212432.GB82710@shinkuro.com> <20111008223820.F09F314DF5E1@drugs.dv.isc.org> <20111009135505.GA85221@shinkuro.com> <20111009213431.4756314E0BDE@drugs.dv.isc.org> In-reply-to: Your message of "Sun, 09 Oct 2011 18:41:39 PDT." Date: Mon, 10 Oct 2011 16:17:25 +1100 Message-Id: <20111010051725.3A95214E5206@drugs.dv.isc.org> Cc: dnsext@ietf.org Subject: Re: [dnsext] Why are we re-opening this topic? Was: Suggested update to RFC 4035 section 4.9.2 Handling of the CD Bit 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, 10 Oct 2011 05:17:51 -0000 In message , Mohan Parthasarathy writes: > On Sun, Oct 9, 2011 at 2:34 PM, Mark Andrews wrote: > > > > In message <20111009135505.GA85221@shinkuro.com>, Andrew Sullivan writes: > >> No hat. > >> > >> On Sun, Oct 09, 2011 at 09:38:20AM +1100, Mark Andrews wrote: > >> > >> > By that logic we should strike paragraph 2 of 4.9.2 (Handling of the C= > D Bit > >> ) > >> > > >> > =A0 =A0A validating security-aware stub resolver SHOULD set the CD bit= > , > >> > =A0 =A0because otherwise the security-aware recursive name server will > >> > =A0 =A0answer the query using the name server's local policy, which ma= > y > >> > =A0 =A0prevent the stub resolver from receiving data that would be > >> > =A0 =A0acceptable to the stub resolver's local policy. > >> > > >> > That SHOULD is not required for interoperability. > >> > >> True, although it appears to me to be a consequence of the definition > >> of validating security-aware stub resolver. =A0But anyway, > >> > >> > Now do we give good advice or do we give no advice? > >> > >> as I argued before, the advice you are proposing is not in fact always > >> good advice. =A0It's a trade-off. > > > > It's *never* bad advice as it get you to do both CD=0 and then CD=1. > > It would be a bad advice if it increases the complexity without real benefi= > ts. The complexity of checking for SERVFAIL and reissuing the query with CD=1 is trivial compared to the complexity of validating a answer. This is no more complex that existing TC=1 checks and retrying with TCP. > > Advising to do *just* CD=0 or CD=1 is bad advice. =A0If the upstream > > doesn't have trust anchors then CD=0 or CD=1 is a moot question. > > If the upstream has trust anchors using just CD=1 is leaving the > > stub resolver open to a denial of service due to spoofing / > > misconfiguration of the parent especially if there is CD=1 cache. > > You seem to be implying a "CD=1 cache" and "CD=0 cache" i.e, a cache > maintained differently for CD =1 or CD = 0. If the recursive sever > populates the cache in the same way for both CD=0 and CD=1, then this > issue does not arise. This seems to be much simpler to me rather than > treating it differently. Even if server doesn't have a CD=1 cache there is no guarantee that a second query (with CD=1) will talk to a different authoritative server. CD=0 queries are guarantee to talk to multiple authoritative servers provided there is a trusted path from the servers TA if the first authoritative server tried is broken. Given I've seen signed zone configured with servers that don't speak DNSSEC and I've also seen repeated CD=1 queries fail to get answers with signature from such a configuration this is not idle speculation that avoidable validation failures will occur with CD=1 only queries. I'd argue that misconfigured authoritative servers are more common than misconfigured TAs as the latter affects ordinary queries and will result in complaints leading to the TA being fixed where as the former is hidden as validating recursive servers reject the answers from the bad server and only return those from the good servers. Mark > -mohan > > > Similarly just CD=0 is leaving you exposed to bad clocks / stale > > trust anchors in the recursive server. =A0With CD=0 then CD=1 you > > mitigate both failure modes. > > > >> -- > >> Andrew Sullivan > >> ajs@anvilwalrusden.com > >> _______________________________________________ > >> 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 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 INTERNET: marka@is= > c.org > > _______________________________________________ > > dnsext mailing list > > dnsext@ietf.org > > https://www.ietf.org/mailman/listinfo/dnsext > > -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From shane@isc.org Mon Oct 10 01:58: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 B21D921F8B46 for ; Mon, 10 Oct 2011 01:58:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.741 X-Spam-Level: X-Spam-Status: No, score=-0.741 tagged_above=-999 required=5 tests=[BAYES_20=-0.74, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sug8XlpHdVvs for ; Mon, 10 Oct 2011 01:58:27 -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 EA46C21F8B31 for ; Mon, 10 Oct 2011 01:58:26 -0700 (PDT) Received: from bikeshed.isc.org (bikeshed.isc.org [IPv6:2001:4f8:3:d::19]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "bikeshed.isc.org", Issuer "ISC CA" (verified OK)) by mx.pao1.isc.org (Postfix) with ESMTPS id 784A3C941E; Mon, 10 Oct 2011 08:58:06 +0000 (UTC) (envelope-from shane@isc.org) Received: from [IPv6:2001:610:719:1:beae:c5ff:fe43:aa00] (unknown [IPv6:2001:610:719:1:beae:c5ff:fe43:aa00]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by bikeshed.isc.org (Postfix) with ESMTPSA id 72776216C6A; Mon, 10 Oct 2011 08:58:05 +0000 (UTC) (envelope-from shane@isc.org) From: Shane Kerr To: Edward Lewis Date: Mon, 10 Oct 2011 10:58:02 +0200 In-Reply-To: References: <4E8C12CC.3090701@nic.cz> Organization: ISC Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.0.3 (3.0.3-1.fc15) Content-Transfer-Encoding: 7bit Message-ID: <1318237086.2457.13.camel@shane-desktop> Mime-Version: 1.0 Cc: dnsext@ietf.org Subject: Re: [dnsext] New ID submitted 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, 10 Oct 2011 08:58:27 -0000 Ed, I think this document is useful, and support it going forward. On Fri, 2011-10-07 at 10:06 -0400, Edward Lewis wrote: > http://www.ietf.org/mail-archive/web/i-d-announce/current/msg40107.html > > Out of frustration trying to locate information on the more obscure > RR type registrations at IANA, I drew up this draft. Comments? > > Yes, there are spelling errors...in the abstract. From the announcement: > > Title : IANA Allocated DNS RRtyp Codes without Documentation s/RRtyp/RRtype/ > Author(s) : E. Lewis > Filename : draft-lewis-dns-undocumented-types-00.txt > Pages : 3 > Date : 2011-10-06 We did some digging recently when documenting RRTypes for BIND 10. For EID and NIMLOC, there is this document: http://ana-3.lcs.mit.edu/~jnc/nimrod/dns.txt Which seems to be a -01 version of the draft listed in your document. There are some differences in the text (for example it says "protocol spec [[[ref to be supplied]]]" rather than "protocol [[[ref to be supplied]]]"), but I don't know if these are meaningful. (Surely not for such a vintage routing architecture.) For the rest, you came up with the same references we did. FWIW, our list of lower-priority RR types is here: http://bind10.isc.org/wiki/RRTypes We don't have all the ones you list, because I considered many of them to be works in progress (CDS, URI, CAA, ...). -- Shane From suruti94@gmail.com Mon Oct 10 11:10:55 2011 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5BFB621F84B1 for ; Mon, 10 Oct 2011 11:10: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 m6Xe9JU3DesU for ; Mon, 10 Oct 2011 11:10:54 -0700 (PDT) Received: from mail-qy0-f172.google.com (mail-qy0-f172.google.com [209.85.216.172]) by ietfa.amsl.com (Postfix) with ESMTP id 6206821F8A55 for ; Mon, 10 Oct 2011 11:10:54 -0700 (PDT) Received: by qyk32 with SMTP id 32so2163581qyk.10 for ; Mon, 10 Oct 2011 11:10:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=0z2t2e4Rb4INoY/Jmu2T0+csB8hPFU+jvFO+v+CqRCQ=; b=CZ+Kf1IO1krxfTvc40ml9DTs/FLX39N+Sdl+kgc+Vl9YJbSdQ8JdE3qKjUHdN34ukQ SoZ+25jq4EgfdAoMk/P3B2uLV/BDrmRqfvlTI/HN42eqk9wN0Obo66VmCeiDk4NKhwDb 55zmpGAeQQHgzRALNBoNJACOnK9gGfYerRHhk= MIME-Version: 1.0 Received: by 10.68.9.7 with SMTP id v7mr38621722pba.94.1318270253493; Mon, 10 Oct 2011 11:10:53 -0700 (PDT) Received: by 10.68.43.37 with HTTP; Mon, 10 Oct 2011 11:10:53 -0700 (PDT) In-Reply-To: <20111010051725.3A95214E5206@drugs.dv.isc.org> References: <20111006230230.4633714C8E52@drugs.dv.isc.org> <20111007141449.GA73072@shinkuro.com> <20111007192752.GO73072@shinkuro.com> <20111007224937.6E9BD14DB73A@drugs.dv.isc.org> <0AB03978-C546-466B-9BA4-0C0F0194EAD1@virtualized.org> <20111008122653.EB10314DDC76@drugs.dv.isc.org> <20111008212432.GB82710@shinkuro.com> <20111008223820.F09F314DF5E1@drugs.dv.isc.org> <20111009135505.GA85221@shinkuro.com> <20111009213431.4756314E0BDE@drugs.dv.isc.org> <20111010051725.3A95214E5206@drugs.dv.isc.org> Date: Mon, 10 Oct 2011 11:10:53 -0700 Message-ID: From: Mohan Parthasarathy To: Mark Andrews Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: dnsext@ietf.org Subject: Re: [dnsext] Why are we re-opening this topic? Was: Suggested update to RFC 4035 section 4.9.2 Handling of the CD Bit 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, 10 Oct 2011 18:10:55 -0000 On Sun, Oct 9, 2011 at 10:17 PM, Mark Andrews wrote: > > In message > , Mohan Parthasarathy writes: >> On Sun, Oct 9, 2011 at 2:34 PM, Mark Andrews wrote: >> > >> > In message <20111009135505.GA85221@shinkuro.com>, Andrew Sullivan writ= es: >> >> No hat. >> >> >> >> On Sun, Oct 09, 2011 at 09:38:20AM +1100, Mark Andrews wrote: >> >> >> >> > By that logic we should strike paragraph 2 of 4.9.2 (Handling of th= e C=3D >> D Bit >> >> ) >> >> > >> >> > =3DA0 =3DA0A validating security-aware stub resolver SHOULD set the= CD bit=3D >> , >> >> > =3DA0 =3DA0because otherwise the security-aware recursive name serv= er will >> >> > =3DA0 =3DA0answer the query using the name server's local policy, w= hich ma=3D >> y >> >> > =3DA0 =3DA0prevent the stub resolver from receiving data that would= be >> >> > =3DA0 =3DA0acceptable to the stub resolver's local policy. >> >> > >> >> > That SHOULD is not required for interoperability. >> >> >> >> True, although it appears to me to be a consequence of the definition >> >> of validating security-aware stub resolver. =3DA0But anyway, >> >> >> >> > Now do we give good advice or do we give no advice? >> >> >> >> as I argued before, the advice you are proposing is not in fact alway= s >> >> good advice. =3DA0It's a trade-off. >> > >> > It's *never* bad advice as it get you to do both CD=3D0 and then CD=3D= 1. >> >> It would be a bad advice if it increases the complexity without real ben= efi=3D >> ts. > > The complexity of checking for SERVFAIL and reissuing the query > with CD=3D1 is trivial compared to the complexity of validating a > answer. =A0This is no more complex that existing TC=3D1 checks and > retrying with TCP. > I agree that for the sub itself, this is very similar to TC=3D1 retry with TCP. But I was not speaking with respect to the stub alone. See below. >> > Advising to do *just* CD=3D0 or CD=3D1 is bad advice. =3DA0If the upst= ream >> > doesn't have trust anchors then CD=3D0 or CD=3D1 is a moot question. >> > If the upstream has trust anchors using just CD=3D1 is leaving the >> > stub resolver open to a denial of service due to spoofing / >> > misconfiguration of the parent especially if there is CD=3D1 cache. >> >> You seem to be implying a "CD=3D1 cache" and "CD=3D0 cache" i.e, a cache >> maintained differently for CD =3D1 or CD =3D 0. If the recursive sever >> populates the cache in the same way for both CD=3D0 and CD=3D1, then thi= s >> issue does not arise. This seems to be much simpler to me rather than >> treating it differently. > > Even if server doesn't have a CD=3D1 cache there is no guarantee that > a second query (with CD=3D1) will talk to a different authoritative > server. =A0CD=3D0 queries are guarantee to talk to multiple authoritative > servers provided there is a trusted path from the servers TA if the > first authoritative server tried is broken. > As per dnssec-bis updates section 5.9, the validating resolver always sets the CD bit irrespective of what is in the incoming query. It means that there is just one cache. Do implementation really have a separate cache ? If it always sets CD=3D1 (which does not alter with your proposal), then it needs to handle this case because there could be a bunch of queries (with CD=3D1 or CD=3D0) blocked on waiting for this resolution to complete ? Isn't the case you are talking about "no" signatures rather than invalid signatures ? Why is "CD=3D0" query making it talk to a different authoritative server and not "CD=3D1" query in this case ? Let us say that there are two authoritative servers G (Good) and the B (Bad) for some signed zone. G speaks DNSSEC whereas B does not. I have two stubs one of which sets the CD bit. 1) A recursive server receives a query with CD =3D 0/DOK =3D 1. It talks to B first and as it cannot validate without signatures, it talks to G, validates the result and inserts into the cache. 2) A recursive server receives a query with CD =3D 1/DOK =3D 1. Assuming that there is a single cache, then it returns the response from the cache. Now if (2) happens first i.e., it receives a query with CD=3D1/DOK=3D1, you are arguing that it would talk to B first, it does not receive any signatures and it would just return without trying G. And on receiving query with CD=3D0, it would retry with G ? Is there anything in RFC 4035 that describes this behavior explicitly ? =10I would expect that setting DO=3D1 (which might have happened because the stub might have a priori knowledge that a given zone is signed) means that it relies on the recursive server to return "some" signature at least. So, the concern is that if someone spoofs an answer, the recursive server returns the response without any signatures while there was valid signatures. This spoof did not make the stub accept the answer, just "discard" it. It is a DoS, but it happens due to misconfiguration which should not be that common. > > Given I've seen signed zone configured with servers that don't speak > DNSSEC and I've also seen repeated CD=3D1 queries fail to get answers > with signature from such a configuration this is not idle speculation > that avoidable validation failures will occur with CD=3D1 only queries. > Do we know how often this happens ? I know it is hard to predict the future, but if this is very common, does it not make sense for the recursive servers handle this case ? -mohan > I'd argue that misconfigured authoritative servers are more common > than misconfigured TAs as the latter affects ordinary queries and > will result in complaints leading to the TA being fixed where as > the former is hidden as validating recursive servers reject the > answers from the bad server and only return those from the good > servers. > > Mark > >> -mohan >> >> > Similarly just CD=3D0 is leaving you exposed to bad clocks / stale >> > trust anchors in the recursive server. =3DA0With CD=3D0 then CD=3D1 yo= u >> > mitigate both failure modes. >> > >> >> -- >> >> Andrew Sullivan >> >> ajs@anvilwalrusden.com >> >> _______________________________________________ >> >> 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 =3DA0 =3DA0 =3DA0 =3DA0 =3DA0 =3DA0 =3DA0 =3DA0= INTERNET: marka@is=3D >> c.org >> > _______________________________________________ >> > 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 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 INTERNET: marka@is= c.org > From mohta@necom830.hpcl.titech.ac.jp Mon Oct 10 13:52: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 BDFE521F8CAB for ; Mon, 10 Oct 2011 13:52:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.09 X-Spam-Level: X-Spam-Status: No, score=-0.09 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w0yXrIOYEfb4 for ; Mon, 10 Oct 2011 13:52:51 -0700 (PDT) Received: from necom830.hpcl.titech.ac.jp (necom830.hpcl.titech.ac.jp [131.112.32.132]) by ietfa.amsl.com (Postfix) with SMTP id 0C1C321F8CAA for ; Mon, 10 Oct 2011 13:52:50 -0700 (PDT) Received: (qmail 14787 invoked from network); 10 Oct 2011 21:02:57 -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; 10 Oct 2011 21:02:57 -0000 Message-ID: <4E93593E.2010304@necom830.hpcl.titech.ac.jp> Date: Tue, 11 Oct 2011 05:44:46 +0900 From: Masataka Ohta User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: dnsext@ietf.org References: <20111006230230.4633714C8E52@drugs.dv.isc.org> <20111007141449.GA73072@shinkuro.com> <20111007192752.GO73072@shinkuro.com> <20111007224937.6E9BD14DB73A@drugs.dv.isc.org> <0AB03978-C546-466B-9BA4-0C0F0194EAD1@virtualized.org> <20111008122653.EB10314DDC76@drugs.dv.isc.org> <20111008212432.GB82710@shinkuro.com> <20111008223820.F09F314DF5E1@drugs.dv.isc.org> <20111009135505.GA85221@shinkuro.com> <20111009213431.4756314E0BDE@drugs.dv.isc.org> In-Reply-To: <20111009213431.4756314E0BDE@drugs.dv.isc.org> Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit Subject: Re: [dnsext] Why are we re-opening this topic? Was: Suggested update to RFC 4035 section 4.9.2 Handling of the CD Bit 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, 10 Oct 2011 20:52:51 -0000 Mark Andrews wrote: > It's *never* bad advice as it get you to do both CD=0 and then CD=1. > Advising to do *just* CD=0 or CD=1 is bad advice. If the upstream > doesn't have trust anchors then CD=0 or CD=1 is a moot question. > If the upstream has trust anchors using just CD=1 is leaving the > stub resolver open to a denial of service due to spoofing / > misconfiguration of the parent especially if there is CD=1 cache. > Similarly just CD=0 is leaving you exposed to bad clocks / stale > trust anchors in the recursive server. With CD=0 then CD=1 you > mitigate both failure modes. Such arguments are meaningful, only if clients are forced to broken servers. So, my question has been: How can a client know an address of an HTTP server? Along with another unanswered question: How can a client know secure time? I can't see any realistic use case defined in enough details. Masataka Ohta From marka@isc.org Mon Oct 10 15:00: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 6E3E121F8C0A for ; Mon, 10 Oct 2011 15:00:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nfmG9u+J7irj for ; Mon, 10 Oct 2011 15:00:50 -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 E8F4221F8C09 for ; Mon, 10 Oct 2011 15:00:49 -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 5182B5F98A2; Mon, 10 Oct 2011 22:00:34 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (unknown [IPv6:2001:470:1f00:820:6233:4bff:fe01:7585]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by bikeshed.isc.org (Postfix) with ESMTPSA id CA37F216C6C; Mon, 10 Oct 2011 22:00:31 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (Postfix) with ESMTP id F1E2614EB649; Tue, 11 Oct 2011 09:00:27 +1100 (EST) To: Mohan Parthasarathy From: Mark Andrews References: <20111006230230.4633714C8E52@drugs.dv.isc.org> <20111007141449.GA73072@shinkuro.com> <20111007192752.GO73072@shinkuro.com> <20111007224937.6E9BD14DB73A@drugs.dv.isc.org> <0AB03978-C546-466B-9BA4-0C0F0194EAD1@virtualized.org> <20111008122653.EB10314DDC76@drugs.dv.isc.org> <20111008212432.GB82710@shinkuro.com> <20111008223820.F09F314DF5E1@drugs.dv.isc.org> <20111009135505.GA85221@shinkuro.com> <20111009213431.4756314E0BDE@drugs.dv.isc.org> <20111010051725.3A95214E5206@drugs.dv.isc.org> In-reply-to: Your message of "Mon, 10 Oct 2011 11:10:53 PDT." Date: Tue, 11 Oct 2011 09:00:27 +1100 Message-Id: <20111010220027.F1E2614EB649@drugs.dv.isc.org> Cc: dnsext@ietf.org Subject: Re: [dnsext] Why are we re-opening this topic? Was: Suggested update to RFC 4035 section 4.9.2 Handling of the CD Bit 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, 10 Oct 2011 22:00:51 -0000 In message , Mohan Parthasarathy writes: > On Sun, Oct 9, 2011 at 10:17 PM, Mark Andrews wrote: > > > > In message gmail.com> > > , Mohan Parthasarathy writes: > >> On Sun, Oct 9, 2011 at 2:34 PM, Mark Andrews wrote: > >> > > >> > In message <20111009135505.GA85221@shinkuro.com>, Andrew Sullivan writ= > es: > >> >> No hat. > >> >> > >> >> On Sun, Oct 09, 2011 at 09:38:20AM +1100, Mark Andrews wrote: > >> >> > >> >> > By that logic we should strike paragraph 2 of 4.9.2 (Handling of th= > e C= > >> D Bit > >> >> ) > >> >> > > >> >> > =A0 =A0A validating security-aware stub resolver SHOULD set the= > CD bit= > >> , > >> >> > =A0 =A0because otherwise the security-aware recursive name serv= > er will > >> >> > =A0 =A0answer the query using the name server's local policy, w= > hich ma= > >> y > >> >> > =A0 =A0prevent the stub resolver from receiving data that would= > be > >> >> > =A0 =A0acceptable to the stub resolver's local policy. > >> >> > > >> >> > That SHOULD is not required for interoperability. > >> >> > >> >> True, although it appears to me to be a consequence of the definition > >> >> of validating security-aware stub resolver. =A0But anyway, > >> >> > >> >> > Now do we give good advice or do we give no advice? > >> >> > >> >> as I argued before, the advice you are proposing is not in fact alway= > s > >> >> good advice. =A0It's a trade-off. > >> > > >> > It's *never* bad advice as it get you to do both CD=0 and then CD== > 1. > >> > >> It would be a bad advice if it increases the complexity without real ben= > efi= > >> ts. > > > > The complexity of checking for SERVFAIL and reissuing the query > > with CD=1 is trivial compared to the complexity of validating a > > answer. =A0This is no more complex that existing TC=1 checks and > > retrying with TCP. > > > I agree that for the sub itself, this is very similar to TC=1 retry > with TCP. But I was not speaking with respect to the stub alone. See > below. > > > >> > Advising to do *just* CD=0 or CD=1 is bad advice. =A0If the upst= > ream > >> > doesn't have trust anchors then CD=0 or CD=1 is a moot question. > >> > If the upstream has trust anchors using just CD=1 is leaving the > >> > stub resolver open to a denial of service due to spoofing / > >> > misconfiguration of the parent especially if there is CD=1 cache. > >> > >> You seem to be implying a "CD=1 cache" and "CD=0 cache" i.e, a cache > >> maintained differently for CD =1 or CD = 0. If the recursive sever > >> populates the cache in the same way for both CD=0 and CD=1, then thi= > s > >> issue does not arise. This seems to be much simpler to me rather than > >> treating it differently. > > > > Even if server doesn't have a CD=1 cache there is no guarantee that > > a second query (with CD=1) will talk to a different authoritative > > server. =A0CD=0 queries are guarantee to talk to multiple authoritative > > servers provided there is a trusted path from the servers TA if the > > first authoritative server tried is broken. > > > As per dnssec-bis updates section 5.9, the validating resolver always > sets the CD bit irrespective of what is in the incoming query. It > means that there is just one cache. Do implementation really have a > separate cache ? If it always sets CD=1 (which does not alter with > your proposal), then it needs to handle this case because there could > be a bunch of queries (with CD=1 or CD=0) blocked on waiting for this > resolution to complete ? Validating recusive servers are NOT required to cache the responses to CD=1 queries. The MAY validate them and cache them. If they don't cache them then the next query for the same tuple may go to the same authoritative server creating a effectively unvalidatd cache. There is no requirement to randomise authoritative server selection and even if there was there is no guarantee that same server will not be reselected. > Isn't the case you are talking about "no" signatures rather than > invalid signatures ? No. It's anything which causes a validation failure. No signatures is just one example. > Why is "CD=0" query making it talk to a different authoritative server > and not "CD=1" query in this case ? CD=0 responses are validated *before* being returned and if they fail validation are treated as if they didn't occur (the response was lost) and the recursive server moves on to the next server for that zone and tries again. CD=1 responses, to queries that are not in the cache, are passed back UNVALIDATED. > Let us say > that there are two authoritative servers G (Good) and the B (Bad) for > some signed zone. G speaks DNSSEC whereas B does not. I have two stubs > one of which sets the CD bit. > 1) A recursive server receives a query with CD = 0/DOK = 1. It talks > to B first and as it cannot validate without signatures, it talks to > G, validates the result and inserts into the cache. > > 2) A recursive server receives a query with CD = 1/DOK = 1. Assuming > that there is a single cache, then it returns the response from the > cache. > > Now if (2) happens first i.e., it receives a query with CD=1/DOK=1, > you are arguing that it would talk to B first, it does not receive any > signatures and it would just return without trying G. Yes. > And on receiving query with CD=0, it would retry with G ? Yes. > Is there anything in RFC 4035 that describes this behavior explicitly ? Explicity to retry multiple servers, no. Which is yet another thing that has been overlooked in RFC 4035. That said you will find the validating recursive servers do try multiple authoritative sources on validation failures. If you don't you will get bug reports about unnessary SERVFAILs being returned. RFC 4035 mainly deals with how to validate individual response and how react to individual queries. It says nothing about how to recover from validation failures. The word "retry" does not appear. > I would expect that setting DO=1 (which might have happened because > the stub might have a priori knowledge that a given zone is signed) > means that it relies on the recursive server to return "some" > signature at least. No. That is not required. The a priori knowledge is that there is a trust anchor at or above the zone that contains the answer. There may or may not be a insecure delegation between the trust anchor and the zone that contains the answer. > So, the concern is that if someone spoofs an answer, the recursive > server returns the response without any signatures while there was > valid signatures. This spoof did not make the stub accept the answer, > just "discard" it. It is a DoS, but it happens due to misconfiguration > which should not be that common. We have plenty of evidence that DNSSEC misconfigurations happen. Some of these are recoverable by trying multiple upstream services. > > Given I've seen signed zone configured with servers that don't speak > > DNSSEC and I've also seen repeated CD=1 queries fail to get answers > > with signature from such a configuration this is not idle speculation > > that avoidable validation failures will occur with CD=1 only queries. > > > > Do we know how often this happens ? I know it is hard to predict the > future, but if this is very common, does it not make sense for the > recursive servers handle this case ? > > -mohan > > > I'd argue that misconfigured authoritative servers are more common > > than misconfigured TAs as the latter affects ordinary queries and > > will result in complaints leading to the TA being fixed where as > > the former is hidden as validating recursive servers reject the > > answers from the bad server and only return those from the good > > servers. > > > > Mark > > > >> -mohan > >> > >> > Similarly just CD=0 is leaving you exposed to bad clocks / stale > >> > trust anchors in the recursive server. =A0With CD=0 then CD=1 yo= > u > >> > mitigate both failure modes. > >> > > >> >> -- > >> >> Andrew Sullivan > >> >> ajs@anvilwalrusden.com > >> >> _______________________________________________ > >> >> 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 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= > INTERNET: marka@is= > >> c.org > >> > _______________________________________________ > >> > dnsext mailing list > >> > dnsext@ietf.org > >> > https://www.ietf.org/mailman/listinfo/dnsext > >> > > > -- > > Mark Andrews, ISC > > 1 Seymour St., Dundas Valley, NSW 2117, Australia > > PHONE: +61 2 9871 4742 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 INTERNET: marka@is= > c.org > > -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From suruti94@gmail.com Mon Oct 10 18:59:19 2011 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4EA7C21F8CB3 for ; Mon, 10 Oct 2011 18:59:19 -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 9xKWqgqGvY-5 for ; Mon, 10 Oct 2011 18:59:18 -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 6060721F8CB0 for ; Mon, 10 Oct 2011 18:59:18 -0700 (PDT) Received: by pzk37 with SMTP id 37so18516101pzk.9 for ; Mon, 10 Oct 2011 18:59:18 -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=B7utToq5B7BbuM+RfrYkvKEPh4xPNuzoXjea270bpcA=; b=VOQsm5Y2gw6jToNr3WTqPrPRbiREsA92Tnnr2+f2Yn7LG71FRu2BFlPPdkm9cz1Mok UO4YVx441F0y+MUvd2PCDzOp6lOVYnvauHahshQo0Vt6LBID2ea9OdyV4gpq11SSoDVt PhuvdBzWuJVZLt5/TNmt6XXcWBSC4ePHORwMw= MIME-Version: 1.0 Received: by 10.68.19.34 with SMTP id b2mr41143528pbe.60.1318298357962; Mon, 10 Oct 2011 18:59:17 -0700 (PDT) Received: by 10.68.43.37 with HTTP; Mon, 10 Oct 2011 18:59:17 -0700 (PDT) In-Reply-To: <20111010220027.F1E2614EB649@drugs.dv.isc.org> References: <20111006230230.4633714C8E52@drugs.dv.isc.org> <20111007141449.GA73072@shinkuro.com> <20111007192752.GO73072@shinkuro.com> <20111007224937.6E9BD14DB73A@drugs.dv.isc.org> <0AB03978-C546-466B-9BA4-0C0F0194EAD1@virtualized.org> <20111008122653.EB10314DDC76@drugs.dv.isc.org> <20111008212432.GB82710@shinkuro.com> <20111008223820.F09F314DF5E1@drugs.dv.isc.org> <20111009135505.GA85221@shinkuro.com> <20111009213431.4756314E0BDE@drugs.dv.isc.org> <20111010051725.3A95214E5206@drugs.dv.isc.org> <20111010220027.F1E2614EB649@drugs.dv.isc.org> Date: Mon, 10 Oct 2011 18:59:17 -0700 Message-ID: From: Mohan Parthasarathy To: Mark Andrews Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: dnsext@ietf.org Subject: Re: [dnsext] Why are we re-opening this topic? Was: Suggested update to RFC 4035 section 4.9.2 Handling of the CD Bit 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, 11 Oct 2011 01:59:19 -0000 >> >> > Advising to do *just* CD=3D0 or CD=3D1 is bad advice. =3DA0If the u= pst=3D >> ream >> >> > doesn't have trust anchors then CD=3D0 or CD=3D1 is a moot question= . >> >> > If the upstream has trust anchors using just CD=3D1 is leaving the >> >> > stub resolver open to a denial of service due to spoofing / >> >> > misconfiguration of the parent especially if there is CD=3D1 cache. >> >> >> >> You seem to be implying a "CD=3D1 cache" and "CD=3D0 cache" i.e, a ca= che >> >> maintained differently for CD =3D1 or CD =3D 0. If the recursive seve= r >> >> populates the cache in the same way for both CD=3D0 and CD=3D1, then = thi=3D >> s >> >> issue does not arise. This seems to be much simpler to me rather than >> >> treating it differently. >> > >> > Even if server doesn't have a CD=3D1 cache there is no guarantee that >> > a second query (with CD=3D1) will talk to a different authoritative >> > server. =3DA0CD=3D0 queries are guarantee to talk to multiple authorit= ative >> > servers provided there is a trusted path from the servers TA if the >> > first authoritative server tried is broken. >> > >> As per dnssec-bis updates section 5.9, the validating resolver always >> sets the CD bit irrespective of what is in the incoming query. It >> means that there is just one cache. Do implementation really have a >> separate cache ? If it always sets CD=3D1 (which does not alter with >> your proposal), then it needs to handle this case because there could >> be a bunch of queries (with CD=3D1 or CD=3D0) blocked on waiting for thi= s >> resolution to complete ? > > Validating recusive servers are NOT required to cache the responses > to CD=3D1 queries. =A0The MAY validate them and cache them. =A0If they Again this is not mentioned anywhere in RFC 4035. It does have references to BAD cache and it is a SHOULD now. It would be odd to have a BAD cache and not a GOOD cache. > don't cache them then the next query for the same tuple may go to > the same authoritative server creating a effectively unvalidatd > cache. =A0There is no requirement to randomise authoritative server > selection and even if there was there is no guarantee that same > server will not be reselected. > Validating resolver always sets CD=3D1 as per dnssec-bis updates document and any reasonable recursive server would implement caching. If so, how can it work if it does not try multiple auth servers ? The design meeting notes "Always set" policy applied to all validating resolvers but you are only requiring change for stub resolvers. But based on your argument, don't you require that this applies to any validating resolver as it is possible to have multiple recursive resolvers between the stub and the authoritative server ? >> Isn't the case you are talking about "no" signatures rather than >> invalid signatures ? > > No. =A0It's anything which causes a validation failure. =A0No signatures > is just one example. > Ok. > >> Why is "CD=3D0" query making it talk to a different authoritative server >> and not "CD=3D1" query in this case ? > > CD=3D0 responses are validated *before* being returned and if they > fail validation are treated as if they didn't occur (the response > was lost) and the recursive server moves on to the next server for > that zone and tries again. > > CD=3D1 responses, to queries that are not in the cache, are passed back > UNVALIDATED. > This is also under specified in RFC 4035. >> Let us say >> that there are two authoritative servers G (Good) and the B (Bad) for >> some signed zone. G speaks DNSSEC whereas B does not. I have two stubs >> one of which sets the CD bit. > >> 1) A recursive server receives a query with CD =3D 0/DOK =3D 1. It talks >> to B first and as it cannot validate without signatures, it talks to >> G, validates the result and inserts into the cache. >> >> 2) A recursive server receives a query with CD =3D 1/DOK =3D 1. Assuming >> that there is a single cache, then it returns the response from the >> cache. >> >> Now if (2) happens first i.e., it receives a query with CD=3D1/DOK=3D1, >> you are arguing that it would talk to B first, it does not receive any >> signatures and it would just return without trying G. > > Yes. > >> And on receiving query with CD=3D0, it would retry with G ? > > Yes. > >> Is there anything in RFC 4035 that describes this behavior explicitly ? > > Explicity to retry multiple servers, no. =A0Which is yet another thing > that has been overlooked in RFC 4035. =A0That said you will find the > validating recursive servers do try multiple authoritative sources > on validation failures. =A0If you don't you will get bug reports about > unnessary SERVFAILs being returned. =A0RFC 4035 mainly deals with how > to validate individual response and how react to individual queries. > It says nothing about how to recover from validation failures. =A0The > word "retry" does not appear. > Yes. >> I would expect that setting DO=3D1 (which might have happened because >> the stub might have a priori knowledge that a given zone is signed) >> means that it relies on the recursive server to return "some" >> signature at least. > > No. =A0That is not required. =A0The a priori knowledge is that there > is a trust anchor at or above the zone that contains the answer. > There may or may not be a insecure delegation between the trust > anchor and the zone that contains the answer. > >> So, the concern is that if someone spoofs an answer, the recursive >> server returns the response without any signatures while there was >> valid signatures. This spoof did not make the stub accept the answer, >> just "discard" it. It is a DoS, but it happens due to misconfiguration >> which should not be that common. > > We have plenty of evidence that DNSSEC misconfigurations happen. =A0Some > of these are recoverable by trying multiple upstream services. > We are not disagreeing about this itself. But what triggers this in the recursive server ? -mohan >> > Given I've seen signed zone configured with servers that don't speak >> > DNSSEC and I've also seen repeated CD=3D1 queries fail to get answers >> > with signature from such a configuration this is not idle speculation >> > that avoidable validation failures will occur with CD=3D1 only queries= . >> > >> >> Do we know how often this happens ? I know it is hard to predict the >> future, but if this is very common, does it not make sense =A0for the >> recursive servers handle this case ? >> >> -mohan >> >> > I'd argue that misconfigured authoritative servers are more common >> > than misconfigured TAs as the latter affects ordinary queries and >> > will result in complaints leading to the TA being fixed where as >> > the former is hidden as validating recursive servers reject the >> > answers from the bad server and only return those from the good >> > servers. >> > >> > Mark >> > >> >> -mohan >> >> >> >> > Similarly just CD=3D0 is leaving you exposed to bad clocks / stale >> >> > trust anchors in the recursive server. =3DA0With CD=3D0 then CD=3D1= yo=3D >> u >> >> > mitigate both failure modes. >> >> > >> >> >> -- >> >> >> Andrew Sullivan >> >> >> ajs@anvilwalrusden.com >> >> >> _______________________________________________ >> >> >> 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 =3DA0 =3DA0 =3DA0 =3DA0 =3DA0 =3DA0 =3DA0 = =3DA0=3D >> =A0INTERNET: marka@is=3D >> >> c.org >> >> > _______________________________________________ >> >> > 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 =3DA0 =3DA0 =3DA0 =3DA0 =3DA0 =3DA0 =3DA0 =3DA0= INTERNET: marka@is=3D >> c.org >> > > -- > Mark Andrews, ISC > 1 Seymour St., Dundas Valley, NSW 2117, Australia > PHONE: +61 2 9871 4742 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 INTERNET: marka@is= c.org > From marka@isc.org Mon Oct 10 19:31: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 6C54521F8C8A for ; Mon, 10 Oct 2011 19:31:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[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 XhZtvT2msSoP for ; Mon, 10 Oct 2011 19:31:50 -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 EDED721F8C89 for ; Mon, 10 Oct 2011 19:31:49 -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 7B7805F98D3; Tue, 11 Oct 2011 02:31:27 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (unknown [IPv6:2001:470:1f00:820:6233:4bff:fe01:7585]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by bikeshed.isc.org (Postfix) with ESMTPSA id 72752216C6A; Tue, 11 Oct 2011 02:31:15 +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 1525914F1754; Tue, 11 Oct 2011 13:31:12 +1100 (EST) To: Mohan Parthasarathy From: Mark Andrews References: <20111006230230.4633714C8E52@drugs.dv.isc.org> <20111007141449.GA73072@shinkuro.com> <20111007192752.GO73072@shinkuro.com> <20111007224937.6E9BD14DB73A@drugs.dv.isc.org> <0AB03978-C546-466B-9BA4-0C0F0194EAD1@virtualized.org> <20111008122653.EB10314DDC76@drugs.dv.isc.org> <20111008212432.GB82710@shinkuro.com> <20111008223820.F09F314DF5E1@drugs.dv.isc.org> <20111009135505.GA85221@shinkuro.com> <20111009213431.4756314E0BDE@drugs.dv.isc.org> <20111010051725.3A95214E5206@drugs.dv.isc.org> <20111010220027.F1E2614EB649@drugs.dv.isc.org> In-reply-to: Your message of "Mon, 10 Oct 2011 18:59:17 PDT." Date: Tue, 11 Oct 2011 13:31:12 +1100 Message-Id: <20111011023112.1525914F1754@drugs.dv.isc.org> Cc: dnsext@ietf.org Subject: Re: [dnsext] Why are we re-opening this topic? Was: Suggested update to RFC 4035 section 4.9.2 Handling of the CD Bit 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, 11 Oct 2011 02:31:51 -0000 In message , Mohan Parthasarathy writes: > > >> >> > Advising to do *just* CD=0 or CD=1 is bad advice. If the u= > pst= > >> ream > >> >> > doesn't have trust anchors then CD=0 or CD=1 is a moot question= > . > >> >> > If the upstream has trust anchors using just CD=1 is leaving the > >> >> > stub resolver open to a denial of service due to spoofing / > >> >> > misconfiguration of the parent especially if there is CD=1 cache. > >> >> > >> >> You seem to be implying a "CD=1 cache" and "CD=0 cache" i.e, a ca= > che > >> >> maintained differently for CD =1 or CD = 0. If the recursive seve= > r > >> >> populates the cache in the same way for both CD=0 and CD=1, then = > thi= > >> s > >> >> issue does not arise. This seems to be much simpler to me rather than > >> >> treating it differently. > >> > > >> > Even if server doesn't have a CD=1 cache there is no guarantee that > >> > a second query (with CD=1) will talk to a different authoritative > >> > server. CD=0 queries are guarantee to talk to multiple authorit= > ative > >> > servers provided there is a trusted path from the servers TA if the > >> > first authoritative server tried is broken. > >> > > >> As per dnssec-bis updates section 5.9, the validating resolver always > >> sets the CD bit irrespective of what is in the incoming query. It > >> means that there is just one cache. Do implementation really have a > >> separate cache ? If it always sets CD=1 (which does not alter with > >> your proposal), then it needs to handle this case because there could > >> be a bunch of queries (with CD=1 or CD=0) blocked on waiting for thi= > s > >> resolution to complete ? > > > > Validating recusive servers are NOT required to cache the responses > > to CD=1 queries. The MAY validate them and cache them. If they > > Again this is not mentioned anywhere in RFC 4035. It does have > references to BAD cache and it is a SHOULD now. It would be odd to > have a BAD cache and not a GOOD cache. > > > don't cache them then the next query for the same tuple may go to > > the same authoritative server creating a effectively unvalidatd > > cache. There is no requirement to randomise authoritative server > > selection and even if there was there is no guarantee that same > > server will not be reselected. > > Validating resolver always sets CD=1 as per dnssec-bis updates > document and any reasonable recursive server would implement caching. > If so, how can it work if it does not try multiple auth servers ? > > The design meeting notes "Always set" policy applied to all validating > resolvers but you are only requiring change for stub resolvers. But > based on your argument, don't you require that this applies to any > validating resolver as it is possible to have multiple recursive > resolvers between the stub and the authoritative server ? It may well be useful but that would be re-opening the topic. At the moment I'm talking about stub behaviour and I'm looking to make "validating stub" <-> "validating recursive server" <-> "authoritative server" work reliably in the face of common errors. > >> Isn't the case you are talking about "no" signatures rather than > >> invalid signatures ? > > > > No. It's anything which causes a validation failure. No signatures > > is just one example. > > > Ok. > > > > >> Why is "CD=0" query making it talk to a different authoritative server > >> and not "CD=1" query in this case ? > > > > CD=0 responses are validated *before* being returned and if they > > fail validation are treated as if they didn't occur (the response > > was lost) and the recursive server moves on to the next server for > > that zone and tries again. > > > > CD=1 responses, to queries that are not in the cache, are passed back > > UNVALIDATED. > > This is also under specified in RFC 4035. > > >> Let us say > >> that there are two authoritative servers G (Good) and the B (Bad) for > >> some signed zone. G speaks DNSSEC whereas B does not. I have two stubs > >> one of which sets the CD bit. > > > >> 1) A recursive server receives a query with CD = 0/DOK = 1. It talks > >> to B first and as it cannot validate without signatures, it talks to > >> G, validates the result and inserts into the cache. > >> > >> 2) A recursive server receives a query with CD = 1/DOK = 1. Assuming > >> that there is a single cache, then it returns the response from the > >> cache. > >> > >> Now if (2) happens first i.e., it receives a query with CD=1/DOK=1, > >> you are arguing that it would talk to B first, it does not receive any > >> signatures and it would just return without trying G. > > > > Yes. > > > >> And on receiving query with CD=0, it would retry with G ? > > > > Yes. > > > >> Is there anything in RFC 4035 that describes this behavior explicitly ? > > > > Explicity to retry multiple servers, no. Which is yet another thing > > that has been overlooked in RFC 4035. That said you will find the > > validating recursive servers do try multiple authoritative sources > > on validation failures. If you don't you will get bug reports about > > unnessary SERVFAILs being returned. RFC 4035 mainly deals with how > > to validate individual response and how react to individual queries. > > It says nothing about how to recover from validation failures. The > > word "retry" does not appear. > > Yes. > > >> I would expect that setting DO=1 (which might have happened because > >> the stub might have a priori knowledge that a given zone is signed) > >> means that it relies on the recursive server to return "some" > >> signature at least. > > > > No. That is not required. The a priori knowledge is that there > > is a trust anchor at or above the zone that contains the answer. > > There may or may not be a insecure delegation between the trust > > anchor and the zone that contains the answer. > > > >> So, the concern is that if someone spoofs an answer, the recursive > >> server returns the response without any signatures while there was > >> valid signatures. This spoof did not make the stub accept the answer, > >> just "discard" it. It is a DoS, but it happens due to misconfiguration > >> which should not be that common. > > > > We have plenty of evidence that DNSSEC misconfigurations happen. Some > > of these are recoverable by trying multiple upstream services. > > We are not disagreeing about this itself. But what triggers this in > the recursive server ? Please re-read my comments above. RFC 4035 does not specify how to recover from validation failures. It expects developers to something "sensible". Mark > -mohan > > >> > Given I've seen signed zone configured with servers that don't speak > >> > DNSSEC and I've also seen repeated CD=1 queries fail to get answers > >> > with signature from such a configuration this is not idle speculation > >> > that avoidable validation failures will occur with CD=1 only queries= > . > >> > > >> > >> Do we know how often this happens ? I know it is hard to predict the > >> future, but if this is very common, does it not make sense for the > >> recursive servers handle this case ? > >> > >> -mohan > >> > >> > I'd argue that misconfigured authoritative servers are more common > >> > than misconfigured TAs as the latter affects ordinary queries and > >> > will result in complaints leading to the TA being fixed where as > >> > the former is hidden as validating recursive servers reject the > >> > answers from the bad server and only return those from the good > >> > servers. > >> > > >> > Mark > >> > > >> >> -mohan > >> >> > >> >> > Similarly just CD=0 is leaving you exposed to bad clocks / stale > >> >> > trust anchors in the recursive server. With CD=0 then CD=1= > yo= > >> u > >> >> > mitigate both failure modes. > >> >> > > >> >> >> -- > >> >> >> Andrew Sullivan > >> >> >> ajs@anvilwalrusden.com > >> >> >> _______________________________________________ > >> >> >> 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@is= > >> >> c.org > >> >> > _______________________________________________ > >> >> > 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@is= > >> c.org > >> > > > -- > > Mark Andrews, ISC > > 1 Seymour St., Dundas Valley, NSW 2117, Australia > > PHONE: +61 2 9871 4742 INTERNET: marka@is= > c.org > > -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From ajs@anvilwalrusden.com Tue Oct 11 08:04: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 38A1821F8E29 for ; Tue, 11 Oct 2011 08:04:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.299 X-Spam-Level: X-Spam-Status: No, score=-1.299 tagged_above=-999 required=5 tests=[AWL=1.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 up+gm+pPYzAP for ; Tue, 11 Oct 2011 08:04:02 -0700 (PDT) Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by ietfa.amsl.com (Postfix) with ESMTP id 4DB3A21F8E20 for ; Tue, 11 Oct 2011 08:04:02 -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 E7B261ECB41C for ; Tue, 11 Oct 2011 15:03:53 +0000 (UTC) Date: Tue, 11 Oct 2011 11:03:59 -0400 From: Andrew Sullivan To: dnsext@ietf.org Message-ID: <20111011150359.GD97086@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] ICANN Variant Issues Project case study reports 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, 11 Oct 2011 15:04:03 -0000 No hat. Dear colleagues, I'm going to send related messages to four IETF lists where I suspect there might be people who are interested: dnsext, dnsop, apps-discuss, and idnabis. My apologies to those of you who get it more than once. For those of you who have been following or otherwise interested in the ICANN Variant Issues Project, the case study reports are up. The public comment period is open until 14 November. The Project is aimed at sorting out, for some scripts, what people mean when they talk about "variant names" in the DNS. For this WG, it seems to me that there might be useful fodder in these reports to help with the WG item of the (currently expired) draft-ietf-dnsext-aliasing-requirements. As a matter of full disclosure, I point out that I have been involved with these reports, providing some observations about the (technical) feasibility of various things people wanted to do. I provided advice, but of course the teams actually responsible for the reports were free to do as they wished with my advice (including ignore it). I encourage those of you who are interested in the topic to read the reports and make any comments you think are useful in the public comment forum, or (for that matter) by discussing things on the open ICANN list devoted to the project (https://mm.icann.org/mailman/listinfo/vip). Note that the usual ICANN processes don't include the discussion on the mailing list as public comments, so if you want your comments to be considered formally, you'll need to post them in the appropriate area. Best regards, Andrew -- Andrew Sullivan ajs@anvilwalrusden.com From ajs@anvilwalrusden.com Tue Oct 11 08:21: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 AD96321F8BE8 for ; Tue, 11 Oct 2011 08:21:13 -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 JIeQvolb1fyv for ; Tue, 11 Oct 2011 08:21:13 -0700 (PDT) Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by ietfa.amsl.com (Postfix) with ESMTP id 70EA421F8BD3 for ; Tue, 11 Oct 2011 08:21:13 -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 892F01ECB41C for ; Tue, 11 Oct 2011 15:21:05 +0000 (UTC) Date: Tue, 11 Oct 2011 11:21:03 -0400 From: Andrew Sullivan To: dnsext@ietf.org Message-ID: <20111011152102.GA98234@crankycanuck.ca> References: <20111011150359.GD97086@shinkuro.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20111011150359.GD97086@shinkuro.com> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [dnsext] ICANN Variant Issues Project case study reports 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, 11 Oct 2011 15:21:13 -0000 And because I am a moron, I forgot to post the links to the reports themselves. Here they are. Arabic: Chinese: Cyrillic: Devanagari: Greek: Latin: On Tue, Oct 11, 2011 at 11:03:59AM -0400, Andrew Sullivan wrote: > No hat. > > Dear colleagues, > > I'm going to send related messages to four IETF lists where I suspect > there might be people who are interested: dnsext, dnsop, apps-discuss, > and idnabis. My apologies to those of you who get it more than once. > > For those of you who have been following or otherwise interested in > the ICANN Variant Issues Project, the case study reports are up. The > public comment period is open until 14 November. The Project is aimed > at sorting out, for some scripts, what people mean when they talk > about "variant names" in the DNS. > > For this WG, it seems to me that there might be useful fodder in these > reports to help with the WG item of the (currently expired) > draft-ietf-dnsext-aliasing-requirements. > > As a matter of full disclosure, I point out that I have been involved > with these reports, providing some observations about the (technical) > feasibility of various things people wanted to do. I provided advice, > but of course the teams actually responsible for the reports were free > to do as they wished with my advice (including ignore it). > > I encourage those of you who are interested in the topic to read the > reports and make any comments you think are useful in the public > comment forum, or (for that matter) by discussing things on the open > ICANN list devoted to the project > (https://mm.icann.org/mailman/listinfo/vip). Note that the usual > ICANN processes don't include the discussion on the mailing list as > public comments, so if you want your comments to be considered > formally, you'll need to post them in the appropriate area. > > Best regards, > > Andrew > > -- > Andrew Sullivan > ajs@anvilwalrusden.com > _______________________________________________ > dnsext mailing list > dnsext@ietf.org > https://www.ietf.org/mailman/listinfo/dnsext -- Andrew Sullivan ajs@crankycanuck.ca From Ed.Lewis@neustar.biz Tue Oct 11 11:15:53 2011 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1736621F8A7D for ; Tue, 11 Oct 2011 11:15:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gmeVWJIsUU6H for ; Tue, 11 Oct 2011 11:15:51 -0700 (PDT) Received: from stora.ogud.com (stora.ogud.com [66.92.146.20]) by ietfa.amsl.com (Postfix) with ESMTP id 6540A21F8C95 for ; Tue, 11 Oct 2011 11:15:51 -0700 (PDT) Received: from work-laptop-2 (nyttbox.md.ogud.com [10.20.30.4]) by stora.ogud.com (8.14.4/8.14.4) with ESMTP id p9BIFmwk032667; Tue, 11 Oct 2011 14:15:48 -0400 (EDT) (envelope-from Ed.Lewis@neustar.biz) Received: from [10.31.200.234] by work-laptop-2 (PGP Universal service); Tue, 11 Oct 2011 14:15:49 -0400 X-PGP-Universal: processed; by work-laptop-2 on Tue, 11 Oct 2011 14:15:49 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: <1318237086.2457.13.camel@shane-desktop> References: <4E8C12CC.3090701@nic.cz> <1318237086.2457.13.camel@shane-desktop> Date: Tue, 11 Oct 2011 14:15:46 -0400 To: Shane Kerr From: Edward Lewis Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.72 on 10.20.30.4 Cc: Edward Lewis , dnsext@ietf.org Subject: Re: [dnsext] New ID submitted 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, 11 Oct 2011 18:15:53 -0000 Thanks for the update. Note that I'm not calling these "unimportant", just "undocumented." ;) At 10:58 +0200 10/10/11, Shane Kerr wrote: >Ed, > >I think this document is useful, and support it going forward. > >On Fri, 2011-10-07 at 10:06 -0400, Edward Lewis wrote: >> http://www.ietf.org/mail-archive/web/i-d-announce/current/msg40107.html >> >> Out of frustration trying to locate information on the more obscure >> RR type registrations at IANA, I drew up this draft. Comments? >> >> Yes, there are spelling errors...in the abstract. From the announcement: >> >> Title : IANA Allocated DNS RRtyp Codes without Documentation > >s/RRtyp/RRtype/ > >> Author(s) : E. Lewis >> Filename : draft-lewis-dns-undocumented-types-00.txt >> Pages : 3 >> Date : 2011-10-06 > >We did some digging recently when documenting RRTypes for BIND 10. > >For EID and NIMLOC, there is this document: > >http://ana-3.lcs.mit.edu/~jnc/nimrod/dns.txt > >Which seems to be a -01 version of the draft listed in your document. >There are some differences in the text (for example it says "protocol >spec [[[ref to be supplied]]]" rather than "protocol [[[ref to be >supplied]]]"), but I don't know if these are meaningful. (Surely not for >such a vintage routing architecture.) > >For the rest, you came up with the same references we did. > >FWIW, our list of lower-priority RR types is here: > >http://bind10.isc.org/wiki/RRTypes > >We don't have all the ones you list, because I considered many of them >to be works in progress (CDS, URI, CAA, ...). > >-- >Shane -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- 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 msheldon@godaddy.com Wed Oct 12 14:41:07 2011 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 90DD121F8A96 for ; Wed, 12 Oct 2011 14:41:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.74 X-Spam-Level: X-Spam-Status: No, score=-100.74 tagged_above=-999 required=5 tests=[BAYES_20=-0.74, 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 J37mJtqWO8GV for ; Wed, 12 Oct 2011 14:41:07 -0700 (PDT) Received: from smtpoutwbe08.prod.mesa1.secureserver.net (smtpoutwbe08.prod.mesa1.secureserver.net [208.109.78.210]) by ietfa.amsl.com (Postfix) with SMTP id F217621F8726 for ; Wed, 12 Oct 2011 14:41:06 -0700 (PDT) Received: (qmail 30331 invoked from network); 12 Oct 2011 21:41:02 -0000 Received: from unknown (HELO gem-wbe09.prod.mesa1.secureserver.net) (64.202.189.48) by smtpoutwbe08.prod.mesa1.secureserver.net with SMTP; 12 Oct 2011 21:41:02 -0000 Received: (qmail 16757 invoked by uid 99); 12 Oct 2011 21:41:02 -0000 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" X-Originating-IP: 172.19.38.143 User-Agent: Web-Based Email 5.6.03 Message-Id: <20111012144101.205a61dff9fc1684c258b274662bb912.3f5e55ecf1.wbe@email00.secureserver.net> From: "Michael Sheldon" To: dnsext@ietf.org Date: Wed, 12 Oct 2011 14:41:01 -0700 Mime-Version: 1.0 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, 12 Oct 2011 21:41:07 -0000 =0A=0A> -------- Original Message --------=0A> Subject: Re: [dnsext] draft-= mohan-dns-query-xml-00.txt=0A> From: Brian Dickson =0A=0A> This proposal is a very lightweight and elegant (IMHO)=0A=0A= I consider it to be neither of those things. Compared to standard DNS=0Apro= tocols it is very heavyweight, and is as elegant as a dancing bear.=0A=0AIn= my opinion, it's just a new avenue for denial of service attacks.=0A=0AAnd= for any entity who is intentionally blocking, it is less than=0Atrivial to= block this, since they are probably already filtering http=0Atraffic.=0A= =0AMichael Sheldon=0ADev-DNS Services=0AGoDaddy.com=0A From Ed.Lewis@neustar.biz Thu Oct 13 08:16: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 D403421F8ADC for ; Thu, 13 Oct 2011 08:16:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.948 X-Spam-Level: X-Spam-Status: No, score=-105.948 tagged_above=-999 required=5 tests=[AWL=0.649, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 O7YjyvB9XsA6 for ; Thu, 13 Oct 2011 08:16:25 -0700 (PDT) Received: from stora.ogud.com (stora.ogud.com [66.92.146.20]) by ietfa.amsl.com (Postfix) with ESMTP id 0EEBF21F8AB8 for ; Thu, 13 Oct 2011 08:16:16 -0700 (PDT) Received: from ccur-lt61.cis.neustar.com (nyttbox.md.ogud.com [10.20.30.4]) by stora.ogud.com (8.14.4/8.14.4) with ESMTP id p9DFGEAI049857; Thu, 13 Oct 2011 11:16:15 -0400 (EDT) (envelope-from Ed.Lewis@neustar.biz) Received: from [192.168.129.103] by ccur-lt61.cis.neustar.com (PGP Universal service); Thu, 13 Oct 2011 11:16:15 -0400 X-PGP-Universal: processed; by ccur-lt61.cis.neustar.com on Thu, 13 Oct 2011 11:16:15 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: <20111012144101.205a61dff9fc1684c258b274662bb912.3f5e55ecf1.wbe@email00.se cureserver.net> References: <20111012144101.205a61dff9fc1684c258b274662bb912.3f5e55ecf1.wbe@email00.se cureserver.net> Date: Thu, 13 Oct 2011 11:16:12 -0400 To: From: Edward Lewis Content-Type: multipart/alternative; boundary="============_-893603521==_ma============" X-Scanned-By: MIMEDefang 2.72 on 10.20.30.4 Cc: ed.lewis@neustar.biz Subject: [dnsext] Related to section 5.1 of dnssec-bis-updates (-14) 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, 13 Oct 2011 15:16:25 -0000 --============_-893603521==_ma============ Content-Type: text/plain; charset="us-ascii" ; format="flowed" In this section of the still-a-draft update to the DNSSEC definition of RFC 4033-4035 an issue has arisen that needs to be addressed. # http://tools.ietf.org/html/draft-ietf-dnsext-dnssec-bis-updates-14 # #5.1. Errors in Canonical Form Type Code List # # When canonicalizing DNS names, DNS names in the RDATA section of NSEC # and RRSIG resource records are not downcased. # # [RFC4034] Section 6.2 item 3 has a list of resource record types for # which DNS names in the RDATA are downcased for purposes of DNSSEC # canonical form (for both ordering and signing). That list # erroneously contains NSEC and RRSIG. According to [RFC3755], DNS # names in the RDATA of NSEC and RRSIG should not be downcased. # # The same section also erroneously lists HINFO, and twice at that. # Since HINFO records contain no domain names, they are not subject to # downcasing. For the purposes of this email a "major implementation" refers to a widely distributed general purpose implementation of DNS. It's become apparent that two major implementations of validators have differed on downcaseing the RRSIG. We've been trying to determine why this problem hasn't surfaced in a real-world outage. It seems that all major implementations of signers down case the RRSIG before signing. Treat this as a suggestion. Unexcuse RRSIG from the list of names that avoid downcasing. (NSEC is not a problem.) Any thoughts? -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- 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" --============_-893603521==_ma============ Content-Type: text/html; charset="us-ascii" Related to section 5.1 of dnssec-bis-updates (-14)
In this section of the still-a-draft update to the DNSSEC definition of RFC 4033-4035 an issue has arisen that needs to be addressed.

# http://tools.ietf.org/html/draft-ietf-dnsext-dnssec-bis-updates-14
#
#5.1.  Errors in Canonical Form Type Code List
#
#   When canonicalizing DNS names, DNS names in the RDATA section of NSEC
#   and RRSIG resource records are not downcased.
#
#   [RFC4034] Section 6.2 item 3 has a list of resource record types for
#   which DNS names in the RDATA are downcased for purposes of DNSSEC
#   canonical form (for both ordering and signing).  That list
#   erroneously contains NSEC and RRSIG.  According to [RFC3755], DNS
#   names in the RDATA of NSEC and RRSIG should not be downcased.
#
#   The same section also erroneously lists HINFO, and twice at that.
#   Since HINFO records contain no domain names, they are not subject to
#   downcasing.

For the purposes of this email a "major implementation" refers to a widely distributed general purpose implementation of DNS.  It's become apparent that two major implementations of validators have differed on downcaseing the RRSIG.

We've been trying to determine why this problem hasn't surfaced in a real-world outage.  It seems that all major implementations of signers down case the RRSIG before signing.

Treat this as a suggestion.  Unexcuse RRSIG from the list of names that avoid downcasing.  (NSEC is not a problem.)  Any thoughts?
--
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
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"
--============_-893603521==_ma============-- From Ed.Lewis@neustar.biz Fri Oct 14 05:20:59 2011 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 96A2E21F85A4 for ; Fri, 14 Oct 2011 05:20:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.166 X-Spam-Level: X-Spam-Status: No, score=-106.166 tagged_above=-999 required=5 tests=[AWL=0.433, 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 PKB2kyh6mew7 for ; Fri, 14 Oct 2011 05:20:58 -0700 (PDT) Received: from stora.ogud.com (stora.ogud.com [66.92.146.20]) by ietfa.amsl.com (Postfix) with ESMTP id 84A8621F84D5 for ; Fri, 14 Oct 2011 05:20:58 -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 p9ECKsiK057541; Fri, 14 Oct 2011 08:20:54 -0400 (EDT) (envelope-from Ed.Lewis@neustar.biz) Received: from [10.31.200.142] by Work-Laptop-2.local (PGP Universal service); Fri, 14 Oct 2011 08:20:56 -0400 X-PGP-Universal: processed; by Work-Laptop-2.local on Fri, 14 Oct 2011 08:20:56 -0400 Mime-Version: 1.0 Message-Id: Date: Fri, 14 Oct 2011 08:20:51 -0400 To: dnsext@ietf.org From: Edward Lewis Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.72 on 10.20.30.4 Cc: ed.lewis@neustar.biz Subject: [dnsext] Fwd: I-D ACTION:draft-lewis-dns-undocumented-types-01.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, 14 Oct 2011 12:20:59 -0000 Updated with comments from three folks. I would submit this as an individual submission, but I guess an AD might drop it at the foot of this WG. To get ahead of the curve, do the chairs want to consider this for adoption or would this pass into the hopper without WG consideration? >From: >To: >Subject: I-D ACTION:draft-lewis-dns-undocumented-types-01.txt >Date: Thu, 13 Oct 2011 14:15:07 -0700 > >A new Internet-Draft is available from the on-line Internet-Drafts >directories. > > > Title : IANA Allocated DNS RRtype Codes Without Documentation > Author(s) : E. Lewis > Filename : draft-lewis-dns-undocumented-types-01.txt > Pages : 3 > Date : 2011-10-13 > >In the IANA registry of Resource Record (RR) TYPEs, as of October 1, >2011, there are 10 type code values allocated with references that >are individual email boxes and not stable documents. Some of the >registrations represent works in progress and such a reference is >viable. Some registrations are dormant or dead efforts. In all >cases it would be helpful to have some reference to material >describing the type. > >A URL for this Internet-Draft is: >http://www.ietf.org/internet-drafts/draft-lewis-dns-undocumented-types-01.txt > >Internet-Drafts are also available by anonymous FTP at: >ftp://ftp.ietf.org/internet-drafts/ -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- 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 wouter@nlnetlabs.nl Mon Oct 17 05:48: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 4880821F8B9E for ; Mon, 17 Oct 2011 05:48:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.39 X-Spam-Level: X-Spam-Status: No, score=-2.39 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001, SARE_RMML_Stock1=0.21] 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 EcSr4jQMIAuS for ; Mon, 17 Oct 2011 05:48:21 -0700 (PDT) Received: from open.nlnetlabs.nl (open.nlnetlabs.nl [IPv6:2001:7b8:206:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 8510421F8B95 for ; Mon, 17 Oct 2011 05:48:21 -0700 (PDT) Received: from gary.nlnetlabs.nl (gary.nlnetlabs.nl [IPv6:2001:7b8:206:1:216:76ff:feb8:1853]) (authenticated bits=0) by open.nlnetlabs.nl (8.14.4/8.14.4) with ESMTP id p9HCmJTw030087 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Mon, 17 Oct 2011 14:48:20 +0200 (CEST) (envelope-from wouter@nlnetlabs.nl) Message-ID: <4E9C2413.3030000@nlnetlabs.nl> Date: Mon, 17 Oct 2011 14:48:19 +0200 From: "W.C.A. Wijngaards" User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.23) Gecko/20110928 Fedora/3.1.15-1.fc14 Lightning/1.0b3pre Thunderbird/3.1.15 MIME-Version: 1.0 To: dnsext@ietf.org References: <20111006230230.4633714C8E52@drugs.dv.isc.org> <20111007141449.GA73072@shinkuro.com> <20111007192752.GO73072@shinkuro.com> <20111007224937.6E9BD14DB73A@drugs.dv.isc.org> <0AB03978-C546-466B-9BA4-0C0F0194EAD1@virtualized.org> <20111008122653.EB10314DDC76@drugs.dv.isc.org> <20111008212432.GB82710@shinkuro.com> <20111008223820.F09F314DF5E1@drugs.dv.isc.org> <20111009135505.GA85221@shinkuro.com> <20111009213431.4756314E0BDE@drugs.dv.isc.org> <20111010051725.3A95214E5206@drugs.dv.isc.org> <20111010220027.F1E2614EB649@drugs.dv.isc.org> In-Reply-To: <20111010220027.F1E2614EB649@drugs.dv.isc.org> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (open.nlnetlabs.nl [IPv6:2001:7b8:206:1::1]); Mon, 17 Oct 2011 14:48:20 +0200 (CEST) Subject: Re: [dnsext] Why are we re-opening this topic? Was: Suggested update to RFC 4035 section 4.9.2 Handling of the CD Bit 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, 17 Oct 2011 12:48:22 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi Mark, Mohan, On 10/11/2011 12:00 AM, Mark Andrews wrote: > CD=0 responses are validated *before* being returned and if they > fail validation are treated as if they didn't occur (the response > was lost) and the recursive server moves on to the next server for > that zone and tries again. > > CD=1 responses, to queries that are not in the cache, are passed back > UNVALIDATED. No, CD=1 responses are "not withheld" if they fail validation. Thus you can cache it, you can validate it and retry. Best regards, Wouter -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iQIcBAEBAgAGBQJOnCQTAAoJEJ9vHC1+BF+NT4EQAIiflA8jI4jrWBdWfV+rDtkc yLfU+fy5XOHCyRWlViL13nXilav66AJX50r2mbWxxaZ7ouSJnpabcwa5srHPET1+ ZK3cQQliX3ypLXzAiTFUi78apwLKSeELEvMOKX9qii9GVk/ewnnV096ykCcB8iyf yWii2mLtRFcABApSgA8dJfAwB306GMnCZFOnfluEyB+Gltzc5aruhm2/RhaNyO0d sRKwuJn5YR/E3tyzvY+kZgcrpqdzokrbGgbtIlvZhaF8ZASLDVBXG/1/kwW/BKGy 9BnBy+M487Yz2Lewu31fp9V61V4C/pcnkY+1zewAyJF/G/jayzo/vT0lZV5dRyxq 0if2dKjVVU962A/xDHKD59ERDVfyDd1LBT9pZNctxva6Dnjx21Ma+0cT10Y+BXb+ 2mPz94GIUSyg8iosL2hezBtQz27tL4Qndq/0DHE63SKD1Gi29kMGeSqAQRtXpqYU PRavs6sQeLkHPx22G4Q66K9zzhEBsLaG/GTuRTxxn0KNzWx1YoKvDTZmzUM8OBtC ts6VA9ZKHcOTE0tCM/12jjlPkQRlTBAQfl7lSJL/K1q1dNiclKVl4lX1I9GfXMRm RR/rMi1H/hTB8loh3+ZBCydzCFeRIRi3NSyVFk3oHYzHXOAg37nbizbYXExtz1LP jHpwm3oOPzSETtEHmzNC =NfTi -----END PGP SIGNATURE----- From marka@isc.org Mon Oct 17 06:47:11 2011 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D40DC21F8B79 for ; Mon, 17 Oct 2011 06:47:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.464 X-Spam-Level: X-Spam-Status: No, score=-2.464 tagged_above=-999 required=5 tests=[AWL=-0.075, BAYES_00=-2.599, SARE_RMML_Stock1=0.21] 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 9dXao8vM-ODp for ; Mon, 17 Oct 2011 06:47:11 -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 2A51A21F8B72 for ; Mon, 17 Oct 2011 06:47:11 -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 94C635F984C; Mon, 17 Oct 2011 13:46:55 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (unknown [IPv6:2001:470:1f00:820:6233:4bff:fe01:7585]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by bikeshed.isc.org (Postfix) with ESMTPSA id 6C631216C6D; Mon, 17 Oct 2011 13:46:53 +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 816981569E8F; Tue, 18 Oct 2011 00:46:50 +1100 (EST) To: "W.C.A. Wijngaards" From: Mark Andrews References: <20111006230230.4633714C8E52@drugs.dv.isc.org> <20111007141449.GA73072@shinkuro.com> <20111007192752.GO73072@shinkuro.com> <20111007224937.6E9BD14DB73A@drugs.dv.isc.org> <0AB03978-C546-466B-9BA4-0C0F0194EAD1@virtualized.org> <20111008122653.EB10314DDC76@drugs.dv.isc.org> <20111008212432.GB82710@shinkuro.com> <20111008223820.F09F314DF5E1@drugs.dv.isc.org> <20111009135505.GA85221@shinkuro.com> <20111009213431.4756314E0BDE@drugs.dv.isc.org> <20111010051725.3A95214E5206@drugs.dv.isc.org> <20111010220027.F1E2614EB649@drugs.dv.isc.org> <4E9C2413.3030000@nlnetlabs.nl> In-reply-to: Your message of "Mon, 17 Oct 2011 14:48:19 +0200." <4E9C2413.3030000@nlnetlabs.nl> Date: Tue, 18 Oct 2011 00:46:50 +1100 Message-Id: <20111017134650.816981569E8F@drugs.dv.isc.org> Cc: dnsext@ietf.org Subject: Re: [dnsext] Why are we re-opening this topic? Was: Suggested update to RFC 4035 section 4.9.2 Handling of the CD Bit 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, 17 Oct 2011 13:47:11 -0000 In message <4E9C2413.3030000@nlnetlabs.nl>, "W.C.A. Wijngaards" writes: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Hi Mark, Mohan, > > On 10/11/2011 12:00 AM, Mark Andrews wrote: > > CD=0 responses are validated *before* being returned and if they > > fail validation are treated as if they didn't occur (the response > > was lost) and the recursive server moves on to the next server for > > that zone and tries again. > > > > CD=1 responses, to queries that are not in the cache, are passed back > > UNVALIDATED. > > No, CD=1 responses are "not withheld" if they fail validation. > > Thus you can cache it, you can validate it and retry. And when the stub retries there is no state to prevent the recursive server asking the same broken upstream again and again and again .... There is no requirement for a recursive server to attempt to validate a response to a CD=1 query from downstream or if it attempts to validate the response to retry a different upstream if the validation fails. > Best regards, > Wouter > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.11 (GNU/Linux) > Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ > > iQIcBAEBAgAGBQJOnCQTAAoJEJ9vHC1+BF+NT4EQAIiflA8jI4jrWBdWfV+rDtkc > yLfU+fy5XOHCyRWlViL13nXilav66AJX50r2mbWxxaZ7ouSJnpabcwa5srHPET1+ > ZK3cQQliX3ypLXzAiTFUi78apwLKSeELEvMOKX9qii9GVk/ewnnV096ykCcB8iyf > yWii2mLtRFcABApSgA8dJfAwB306GMnCZFOnfluEyB+Gltzc5aruhm2/RhaNyO0d > sRKwuJn5YR/E3tyzvY+kZgcrpqdzokrbGgbtIlvZhaF8ZASLDVBXG/1/kwW/BKGy > 9BnBy+M487Yz2Lewu31fp9V61V4C/pcnkY+1zewAyJF/G/jayzo/vT0lZV5dRyxq > 0if2dKjVVU962A/xDHKD59ERDVfyDd1LBT9pZNctxva6Dnjx21Ma+0cT10Y+BXb+ > 2mPz94GIUSyg8iosL2hezBtQz27tL4Qndq/0DHE63SKD1Gi29kMGeSqAQRtXpqYU > PRavs6sQeLkHPx22G4Q66K9zzhEBsLaG/GTuRTxxn0KNzWx1YoKvDTZmzUM8OBtC > ts6VA9ZKHcOTE0tCM/12jjlPkQRlTBAQfl7lSJL/K1q1dNiclKVl4lX1I9GfXMRm > RR/rMi1H/hTB8loh3+ZBCydzCFeRIRi3NSyVFk3oHYzHXOAg37nbizbYXExtz1LP > jHpwm3oOPzSETtEHmzNC > =NfTi > -----END PGP SIGNATURE----- > _______________________________________________ > dnsext mailing list > dnsext@ietf.org > https://www.ietf.org/mailman/listinfo/dnsext -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From ajs@anvilwalrusden.com Mon Oct 17 07:04: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 E32A621F87F0 for ; Mon, 17 Oct 2011 07:04:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.37 X-Spam-Level: X-Spam-Status: No, score=-2.37 tagged_above=-999 required=5 tests=[AWL=0.229, 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 6GPVHOw-Ee7M for ; Mon, 17 Oct 2011 07:04:44 -0700 (PDT) Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by ietfa.amsl.com (Postfix) with ESMTP id 64ACD21F8B72 for ; Mon, 17 Oct 2011 07:04:44 -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 21A2F1ECB41D for ; Mon, 17 Oct 2011 14:04:35 +0000 (UTC) Date: Mon, 17 Oct 2011 10:04:38 -0400 From: Andrew Sullivan To: dnsext@ietf.org Message-ID: <20111017140437.GA7743@shinkuro.com> References: <20111008212432.GB82710@shinkuro.com> <20111008223820.F09F314DF5E1@drugs.dv.isc.org> <20111009135505.GA85221@shinkuro.com> <20111009213431.4756314E0BDE@drugs.dv.isc.org> <20111010051725.3A95214E5206@drugs.dv.isc.org> <20111010220027.F1E2614EB649@drugs.dv.isc.org> <4E9C2413.3030000@nlnetlabs.nl> <20111017134650.816981569E8F@drugs.dv.isc.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20111017134650.816981569E8F@drugs.dv.isc.org> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [dnsext] Why are we re-opening this topic? Was: Suggested update to RFC 4035 section 4.9.2 Handling of the CD Bit 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, 17 Oct 2011 14:04:45 -0000 No hat On Tue, Oct 18, 2011 at 12:46:50AM +1100, Mark Andrews wrote: > > And when the stub retries there is no state to prevent the recursive > server asking the same broken upstream again and again and again This is true of any breakage. If the authoritative servers are under DoS, you have the same problem, no? DoS on authoritative servers is at least as common as DNSSEC misconfiguration. The plain fact is that DNSSEC makes the DNS more fragile. Why is this news, and why do you think that your recommendation is the only sensible response to this? I still don't understand that. > There is no requirement for a recursive server to attempt to validate > a response to a CD=1 query from downstream or if it attempts to > validate the response to retry a different upstream if the validation > fails. Of course not. Best, A -- Andrew Sullivan ajs@anvilwalrusden.com From wouter@nlnetlabs.nl Mon Oct 17 07:07: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 6751221F8B73 for ; Mon, 17 Oct 2011 07:07:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.495 X-Spam-Level: X-Spam-Status: No, score=-2.495 tagged_above=-999 required=5 tests=[AWL=0.105, 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 jdsyHYt9aFB2 for ; Mon, 17 Oct 2011 07:07:09 -0700 (PDT) Received: from open.nlnetlabs.nl (open.nlnetlabs.nl [IPv6:2001:7b8:206:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 70E3621F8B71 for ; Mon, 17 Oct 2011 07:07:09 -0700 (PDT) Received: from gary.nlnetlabs.nl (gary.nlnetlabs.nl [IPv6:2001:7b8:206:1:216:76ff:feb8:1853]) (authenticated bits=0) by open.nlnetlabs.nl (8.14.4/8.14.4) with ESMTP id p9HE77dp041869 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Mon, 17 Oct 2011 16:07:08 +0200 (CEST) (envelope-from wouter@nlnetlabs.nl) Message-ID: <4E9C368B.3050208@nlnetlabs.nl> Date: Mon, 17 Oct 2011 16:07:07 +0200 From: "W.C.A. Wijngaards" User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.23) Gecko/20110928 Fedora/3.1.15-1.fc14 Lightning/1.0b3pre Thunderbird/3.1.15 MIME-Version: 1.0 To: Mark Andrews References: <20111006230230.4633714C8E52@drugs.dv.isc.org> <20111007141449.GA73072@shinkuro.com> <20111007192752.GO73072@shinkuro.com> <20111007224937.6E9BD14DB73A@drugs.dv.isc.org> <0AB03978-C546-466B-9BA4-0C0F0194EAD1@virtualized.org> <20111008122653.EB10314DDC76@drugs.dv.isc.org> <20111008212432.GB82710@shinkuro.com> <20111008223820.F09F314DF5E1@drugs.dv.isc.org> <20111009135505.GA85221@shinkuro.com> <20111009213431.4756314E0BDE@drugs.dv.isc.org> <20111010051725.3A95214E5206@drugs.dv.isc.org> <20111010220027.F1E2614EB649@drugs.dv.isc.org> <4E9C2413.3030000@nlnetlabs.nl> <20111017134650.816981569E8F@drugs.dv.isc.org> In-Reply-To: <20111017134650.816981569E8F@drugs.dv.isc.org> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (open.nlnetlabs.nl [IPv6:2001:7b8:206:1::1]); Mon, 17 Oct 2011 16:07:08 +0200 (CEST) Cc: dnsext@ietf.org Subject: Re: [dnsext] Why are we re-opening this topic? Was: Suggested update to RFC 4035 section 4.9.2 Handling of the CD Bit 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, 17 Oct 2011 14:07:10 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi Mark, Mohan failed to tell you and I seem to fail, but I'll give it a retry. >> On 10/17/2011 03:46 PM, Mark Andrews wrote: > In message <4E9C2413.3030000@nlnetlabs.nl>, "W.C.A. Wijngaards" writes: > No, CD=1 responses are "not withheld" if they fail validation. > > Thus you can cache it, you can validate it and retry. > >> And when the stub retries there is no state to prevent the recursive >> server asking the same broken upstream again and again and again >> .... Well there is, because you can cache the final answer? Of course. >> There is no requirement for a recursive server to attempt to validate >> a response to a CD=1 query from downstream or if it attempts to >> validate the response to retry a different upstream if the validation >> fails. There is no requirement, but you seem to want to protect your cache from unwanted dos due to configuration mistakes so that downstream validators get signatures? Then, you can validate it anyway, even though /this/ requestor is not interested in blocking bogus, it is interested in the validation retries, because DO=1 (it wants signatures). Best regards, Wouter -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iQIcBAEBAgAGBQJOnDaLAAoJEJ9vHC1+BF+NBK4P/20NgUhLGjCv1ngPeFpe6+EK oDEUbyZ8O4MmGJd+PsTaRrtgSgMtglXVvTp6FbevNYYbha/tiLxdr9FJi3oHBtJR rV8oxoOmw0lyfiubO3S46OC+2GcE/mm4FIIvA1A3cd7YditSp9zFRAWV0pITdbSd TMHvRiCFp6Z8b4s7OzNg23WJ182YWoFQWuWYRl0Xomja+vr+bKNHYvNaTo9urIoj 1ZOftl/fPNNsDq5v1/LMTYONamy0b9y1PAQr9t3teB30NZ0thJaEuK+G++OnYqlF OS8ImpsMqFGIugZLEvV7bM2wGAYlF1nlII5GcQRBIYhZyxvPDiSX8tvgNkAsB/Xn QhE4Zp2JPAOTEHbKXuEKw8SKfhWHDOb3NXrKzN7SLVur7v/fHSW2nWldksUqUHs3 TuFFCfWQIZ6rHJZSarKStZbzESJUo6dAWapw5yqeU7aHrG2+hLMtTqLdn87hzoR5 JOzzr9cPRdiZWKbEs3+7fZKRE/caD/0HPNLH8hIpueNudhsvkiHUp9lp6tRftQSC bMYKdnNg+N0XugLdTq35FZwkbP+GjqEhZzspF6tlLggF8/u3O021yU+jlaK1QTft Cp2wXK3lTPnjcu16gb9oRQd+tbwOOjVYkgtO6u9h+0Ho9kBli0qWqqNiC88k9MmB RKjSOby2ojhWQvafFb9S =ikYp -----END PGP SIGNATURE----- From richard@highwayman.com Mon Oct 17 10:36:18 2011 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E4CC21F8B81 for ; Mon, 17 Oct 2011 10:36:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_93=0.6] 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 05KcS0LIkjyz for ; Mon, 17 Oct 2011 10:36:18 -0700 (PDT) Received: from anchor-post-3.mail.demon.net (anchor-post-3.mail.demon.net [195.173.77.134]) by ietfa.amsl.com (Postfix) with ESMTP id B6E2B21F8B54 for ; Mon, 17 Oct 2011 10:36:17 -0700 (PDT) Received: from happyday.demon.co.uk ([80.177.121.10] helo=happyday.al.cl.cam.ac.uk) by anchor-post-3.mail.demon.net with esmtp (Exim 4.69) id 1RFr6Y-0002B3-oG for dnsext@ietf.org; Mon, 17 Oct 2011 17:36:02 +0000 Message-ID: Date: Mon, 17 Oct 2011 18:35:02 +0100 To: dnsext@ietf.org From: Richard Clayton MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-Mailer: Turnpike Integrated Version 5.03 M Subject: [dnsext] Call for Papers: Securing and Trusting Internet Names, SATIN 2012 X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Richard Clayton List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Oct 2011 17:36:18 -0000 The usual apologies if you see multiple copies of this CFP, but the inhabitants of this mailing list are more likely than most to wish to submit papers! Call for Papers: Securing and Trusting Internet Names, SATIN 2012 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D When: Thursday 22 & Friday 23 March 2012 Note that IETF 83 is in Paris, CZ the following week Where: National Physical Laboratory (NPL) Teddington, London, UK Timetable: Submissions due: Sun 22 Jan 2012, 11:59 PST Notification of Acceptance: Wed 22 Feb 2012 Final Papers Due: Mon 13 Mar 2012 Overview =3D=3D=3D=3D=3D=3D=3D=3D The domain name system, on which the Internet entirely relies, has always been inherently insecure. Spoofing of IP source addresses means that any wide area UDP protocol (such as DNS) can be forged. Cache poisoning attacks can be made less likely but not prevented altogether. ISPs, or others who can intercept traffic, can redirect end users to sites of their choosing. Users can choose (or have forced upon them) DNS services that suppress access to sites for policy reasons. DNSSEC, which addresses some of these issues, has been under development for years - but is finally ready for use; although some of the finer details are still being worked out. However, even at the current scale of deployment, implementation issues are creating unexpected levels of traffic, and that is before the bad guys make any contribution. Meanwhile DNSCURVE is being promoted as a lightweight method of securing the links to and between name servers, which addresses some, but by no means all, of the security issues. DNSSEC is also being seen by some as a distributed, secure, key distribution system, which could support new applications, or replace existing mechanisms for establishing trust in the identity of endpoints. The IETF's DANE working group is already addressing these issues. Others merely see DNSSEC as a way of defeating marketers who want to inject targeted advertising into browser sessions. But how effective will these ideas be if we continue with our existing APIs and stub resolvers? There are significant issues with DNS besides just its integrity. DNS services can be used to amplify denial-of-service attacks to create very substantial traffic flows. Malware has also been using the DNS for rendezvous arrangements, and has avoided countermeasures by exploiting the DNS system through "fluxing" and other techniques. There are also signs of a "tragedy of the commons" as legitimate companies fill the DNS with large numbers of names, or set low TTLs, to give a performance "edge". Meanwhile, some applications pre-fetch DNS answers, with little heed to the impact on the infrastructure. This latter technique raises privacy issues, as indeed does the proposal to 'leak' partial identities of requestors who contact recursive resolvers, with the aim of providing different answers to machines in different blocks of address space. All of this makes DNS, once amongst the most boring of topics, into one of the more exciting. The first running of this workshop in April 2011 was a big success, and this second event will be equally significant. Topics =3D=3D=3D=3D=3D=3D SATIN aims to provide a forum for academic work on the security of the DNS alongside industry presentations on practical experiences in providing name services. This workshop will expose the academics to the real problems that industry is encountering, and show industry what academia has to offer them. To improve the flow of information (and as was most successful at the first SATIN workshop) presentations will be restricted to 15 minutes with 15 minutes of general discussion to follow. Submissions must be made under either an "academic" or "industry" label (relating entirely to the content rather than the affiliations of any author), because the two types will be judged by different standards. Academic work will be viewed as an "extended abstract" and should aim to meet the general standard for acceptance into normal conferences in the field. However, since this is a workshop, early results and initial ideas are welcomed. Industry submissions should be relevant, insightful, and technical, and should provide information that cannot be gleaned from reading sales brochures or manuals. In all cases, real-world operational, implementation, and experimental results will be preferred, and these results should inform the DNS protocol development process wherever relevant or possible. Topics of interest include but are not limited to: Attacks on naming services DNSSEC DNSCURVE Alternative methods of securing name services APIs for DNS resolvers Using DNS as a platform for other applications Denial of service and the DNS Malware and the DNS DNS caching on the modern Internet Privacy and the DNS Application behaviour and the DNS Security economics of naming services Passive DNS Operational experience Measurement studies New threats and challenges Questions regarding whether a topic would be suitable are welcome and=20 should be sent to the programme chair, richard.clayton AT npl.co.uk Workshop Organizers =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Programme Chair: Richard Clayton NPL and University of Cambridge Programme Committee: Nevil Brownlee, University of Auckland Ben Laurie Google Anne-Marie Eklund L=F6winder .SE (The Internet Infrastructure Foundation) Dan Massey Colorado State University Douglas Maughan Department of Homeland Security Andrew W Moore University of Cambridge Jose Nazario Arbor Networks Roberto Perdisci University of Georgia Dave Piscitello ICANN Paul Vixie ISC Nicholas Weaver ICSI & UC Berkeley Jonathan Williams NPL Submissions =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D All submissions must be in IEEE two column format and no longer than eight (8) 8.5'' x 11'' pages, including figures, tables, and references. That means that the text must be set in two columns in 10 point type on 12 point (single-spaced) leading, with the text block being no more than 7.2'' wide by 9.6'' deep. Author names and affiliations should appear on the title page. The use of LaTeX and the IEEEtrans.cls file to create submissions is very strongly encouraged: http://conferences.npl.co.uk/satin/format.html Submissions must be submitted in PDF format via the SATIN 2012 website: http://conferences.npl.co.uk/satin/submit.html Simultaneous submission of the same work to multiple venues, submission of previously published work, or plagiarism, is dishonest and/or fraudulent and action may be taken if this occurs. Note, however, that we expect that many papers accepted for SATIN will eventually be extended as full papers suitable for presentation at other conferences. About the National Physical Laboratory =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D The National Physical Laboratory (NPL) is one of the UK's leading science and research facilities. It is a world-leading centre of excellence in developing and applying the most accurate standards, science and technology available. NPL occupies a unique position as the UK's National Measurement Institute and sits at the intersection between scientific discovery and real world application. Its expertise and original research have underpinned quality of life, innovation and competitiveness for UK citizens and business for more than a century. NPL is collaborating with the University of Cambridge in a three year programme to develop robust and accurate measurements of Internet security mechanisms. Measuring and understanding the deployment of DNSSEC and other trust mechanisms for Internet names is a key part of this ongoing programme. More at: http://conferences.npl.co.uk/satin/ --=20 Dr Richard Clayton tel: +44 1223 763570, mobile: +44 7887 794090 Computer Laboratory, University of Cambridge, CB3 0FD National Physical Laboratory, Hampton Road, Teddington, TW11 0LW From mansaxel@besserwisser.org Mon Oct 17 15:35: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 C985111E8095 for ; Mon, 17 Oct 2011 15:35:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.811 X-Spam-Level: X-Spam-Status: No, score=-0.811 tagged_above=-999 required=5 tests=[BAYES_05=-1.11, MIME_8BIT_HEADER=0.3, 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 vxPSCbVzorOy for ; Mon, 17 Oct 2011 15:35:34 -0700 (PDT) Received: from jaja.besserwisser.org (jaja.besserwisser.org [IPv6:2a01:298:4:0:211:43ff:fe36:1299]) by ietfa.amsl.com (Postfix) with ESMTP id 4AA5B11E8082 for ; Mon, 17 Oct 2011 15:35:33 -0700 (PDT) Received: by jaja.besserwisser.org (Postfix, from userid 1004) id 8A1869F3A; Tue, 18 Oct 2011 00:35:30 +0200 (CEST) Date: Tue, 18 Oct 2011 00:35:30 +0200 From: =?utf-8?B?TcOlbnM=?= Nilsson To: Richard Clayton Message-ID: <20111017223530.GE13774@besserwisser.org> References: MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="ZInfyf7laFu/Kiw7" Content-Disposition: inline In-Reply-To: X-URL: http://vvv.besserwisser.org X-Purpose: More of everything NOW! X-happyness: Life is good. User-Agent: Mutt/1.5.20 (2009-06-14) Cc: dnsext@ietf.org Subject: Re: [dnsext] Call for Papers: Securing and Trusting Internet Names, SATIN 2012 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, 17 Oct 2011 22:35:34 -0000 --ZInfyf7laFu/Kiw7 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Subject: [dnsext] Call for Papers: Securing and Trusting Internet Names, SA= TIN 2012 Date: Mon, Oct 17, 2011 at 06:35:02PM +0100 Quoting Richard Clayto= n (richard@highwayman.com): >=20 > Call for Papers: Securing and Trusting Internet Names, SATIN 2012 > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >=20 > When: Thursday 22 & Friday 23 March 2012 > Note that IETF 83 is in Paris, CZ the following week ^^^^^^^^^ Ok? --=20 M=C3=A5ns Nilsson primary/secondary/besserwisser/machina MN-1334-RIPE +46 705 989668 But they went to MARS around 1953!! --ZInfyf7laFu/Kiw7 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) iEYEARECAAYFAk6crbIACgkQ02/pMZDM1cUt9gCeOwdz0x1pwr/ByGZ6OkaTc0Qx oSAAoJHrj7sJesn+Kli1gU2Vg+uz+A0+ =4cOg -----END PGP SIGNATURE----- --ZInfyf7laFu/Kiw7-- From johnl@iecc.com Mon Oct 17 16:27: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 0CB1A11E8096 for ; Mon, 17 Oct 2011 16:27:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.094 X-Spam-Level: X-Spam-Status: No, score=-109.094 tagged_above=-999 required=5 tests=[AWL=0.616, BAYES_05=-1.11, 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 so70iBEgdqDN for ; Mon, 17 Oct 2011 16:27:15 -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 8F92C11E8095 for ; Mon, 17 Oct 2011 16:27:15 -0700 (PDT) Received: (qmail 47712 invoked from network); 17 Oct 2011 23:27:14 -0000 Received: from gal.iecc.com (64.57.183.53) by mail2.iecc.com with SMTP; 17 Oct 2011 23:27:14 -0000 Received: (qmail 8260 invoked from network); 17 Oct 2011 23:27:14 -0000 Received: from leila.iecc.com (64.57.183.34) by mail1.iecc.com with QMQP; 17 Oct 2011 23:27:14 -0000 Date: 17 Oct 2011 23:26:52 -0000 Message-ID: <20111017232652.13942.qmail@joyce.lan> From: "John Levine" To: dnsext@ietf.org In-Reply-To: <20111017223530.GE13774@besserwisser.org> Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 7bit Subject: Re: [dnsext] Call for Papers: Securing and Trusting Internet Names, SATIN 2012 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, 17 Oct 2011 23:27:16 -0000 >> Note that IETF 83 is in Paris, CZ the following week > >Ok? Prague is the Paris of central Europe, or something like that. R's, John From marka@isc.org Mon Oct 17 18:32: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 58E4311E80AF for ; Mon, 17 Oct 2011 18:32:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.562 X-Spam-Level: X-Spam-Status: No, score=-2.562 tagged_above=-999 required=5 tests=[AWL=0.037, 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 AM2hLB8S6khR for ; Mon, 17 Oct 2011 18:32:11 -0700 (PDT) Received: from mx.pao1.isc.org (mx.pao1.isc.org [IPv6:2001:4f8:0:2::2b]) by ietfa.amsl.com (Postfix) with ESMTP id D97AD11E80BC for ; Mon, 17 Oct 2011 18:32:09 -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 B7553C941E; Tue, 18 Oct 2011 01:31:57 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (unknown [IPv6:2001:470:1f00:820:6233:4bff:fe01:7585]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by bikeshed.isc.org (Postfix) with ESMTPSA id 64F5B216C6B; Tue, 18 Oct 2011 01:31:55 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (Postfix) with ESMTP id 504451578BF9; Tue, 18 Oct 2011 12:31:44 +1100 (EST) To: "W.C.A. Wijngaards" From: Mark Andrews References: <20111006230230.4633714C8E52@drugs.dv.isc.org> <20111007141449.GA73072@shinkuro.com> <20111007192752.GO73072@shinkuro.com> <20111007224937.6E9BD14DB73A@drugs.dv.isc.org> <0AB03978-C546-466B-9BA4-0C0F0194EAD1@virtualized.org> <20111008122653.EB10314DDC76@drugs.dv.isc.org> <20111008212432.GB82710@shinkuro.com> <20111008223820.F09F314DF5E1@drugs.dv.isc.org> <20111009135505.GA85221@shinkuro.com> <20111009213431.4756314E0BDE@drugs.dv.isc.org> <20111010051725.3A95214E5206@drugs.dv.isc.org> <20111010220027.F1E2614EB649@drugs.dv.isc.org> <4E9C2413.3030000@nlnetlabs.nl> <20111017134650.816981569E8F@drugs.dv.isc.org> <4E9C368B.3050208@nlnetlabs.nl> In-reply-to: Your message of "Mon, 17 Oct 2011 16:07:07 +0200." <4E9C368B.3050208@nlnetlabs.nl> Date: Tue, 18 Oct 2011 12:31:44 +1100 Message-Id: <20111018013144.504451578BF9@drugs.dv.isc.org> Cc: dnsext@ietf.org Subject: Re: [dnsext] Why are we re-opening this topic? Was: Suggested update to RFC 4035 section 4.9.2 Handling of the CD Bit 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, 18 Oct 2011 01:32:12 -0000 In message <4E9C368B.3050208@nlnetlabs.nl>, "W.C.A. Wijngaards" writes: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Hi Mark, > > Mohan failed to tell you and I seem to fail, but I'll give it a retry. > > >> On 10/17/2011 03:46 PM, Mark Andrews wrote: > > In message <4E9C2413.3030000@nlnetlabs.nl>, "W.C.A. Wijngaards" writes: > > No, CD=1 responses are "not withheld" if they fail validation. > > > > Thus you can cache it, you can validate it and retry. > > > >> And when the stub retries there is no state to prevent the recursive > >> server asking the same broken upstream again and again and again > >> .... > > Well there is, because you can cache the final answer? Of course. > > >> There is no requirement for a recursive server to attempt to validate > >> a response to a CD=1 query from downstream or if it attempts to > >> validate the response to retry a different upstream if the validation > >> fails. > > There is no requirement, but you seem to want to protect your cache from > unwanted dos due to configuration mistakes so that downstream validators > get signatures? Then, you can validate it anyway, even though /this/ > requestor is not interested in blocking bogus, it is interested in the > validation retries, because DO=1 (it wants signatures). No. I want to protect the stub from DoS and misconconfigurations. The stub is one step removed from the source of the bad data so it can't take *effective* corrective measures itself as it is required to talk to the world through the recursive server. It needs to get the recursive server to take the corrective measures on its behalf, by setting CD=1, then validate the answer returned to detect any attacks on the reply packets from the recursive server. Setup 10 servers for a zone with ameservers in a different zone to stop the recursive server validating answers from the zone as a side effect. Make 9 of them have out of date signatures (old key). The ask a validating recursive server for a answers using CD=1 and see how many responses have a signatures with the correct key tag. Repeat with CD=0. > Best regards, > Wouter > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.11 (GNU/Linux) > Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ > > iQIcBAEBAgAGBQJOnDaLAAoJEJ9vHC1+BF+NBK4P/20NgUhLGjCv1ngPeFpe6+EK > oDEUbyZ8O4MmGJd+PsTaRrtgSgMtglXVvTp6FbevNYYbha/tiLxdr9FJi3oHBtJR > rV8oxoOmw0lyfiubO3S46OC+2GcE/mm4FIIvA1A3cd7YditSp9zFRAWV0pITdbSd > TMHvRiCFp6Z8b4s7OzNg23WJ182YWoFQWuWYRl0Xomja+vr+bKNHYvNaTo9urIoj > 1ZOftl/fPNNsDq5v1/LMTYONamy0b9y1PAQr9t3teB30NZ0thJaEuK+G++OnYqlF > OS8ImpsMqFGIugZLEvV7bM2wGAYlF1nlII5GcQRBIYhZyxvPDiSX8tvgNkAsB/Xn > QhE4Zp2JPAOTEHbKXuEKw8SKfhWHDOb3NXrKzN7SLVur7v/fHSW2nWldksUqUHs3 > TuFFCfWQIZ6rHJZSarKStZbzESJUo6dAWapw5yqeU7aHrG2+hLMtTqLdn87hzoR5 > JOzzr9cPRdiZWKbEs3+7fZKRE/caD/0HPNLH8hIpueNudhsvkiHUp9lp6tRftQSC > bMYKdnNg+N0XugLdTq35FZwkbP+GjqEhZzspF6tlLggF8/u3O021yU+jlaK1QTft > Cp2wXK3lTPnjcu16gb9oRQd+tbwOOjVYkgtO6u9h+0Ho9kBli0qWqqNiC88k9MmB > RKjSOby2ojhWQvafFb9S > =ikYp > -----END PGP SIGNATURE----- -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From marka@isc.org Mon Oct 17 18:42:54 2011 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 23BA511E80BA for ; Mon, 17 Oct 2011 18:42:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.565 X-Spam-Level: X-Spam-Status: No, score=-2.565 tagged_above=-999 required=5 tests=[AWL=0.034, 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 DJk2vya65ySX for ; Mon, 17 Oct 2011 18:42:53 -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 70CFB11E80AF for ; Mon, 17 Oct 2011 18:42:53 -0700 (PDT) Received: from bikeshed.isc.org (bikeshed.isc.org [IPv6:2001:4f8:3:d::19]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "bikeshed.isc.org", Issuer "ISC CA" (verified OK)) by mx.pao1.isc.org (Postfix) with ESMTPS id EFFD4C941E; Tue, 18 Oct 2011 01:42:24 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (unknown [IPv6:2001:470:1f00:820:6233:4bff:fe01:7585]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by bikeshed.isc.org (Postfix) with ESMTPSA id 4B2BE216C6A; Tue, 18 Oct 2011 01:42:24 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (Postfix) with ESMTP id C0E871578C86; Tue, 18 Oct 2011 12:42:21 +1100 (EST) To: Andrew Sullivan From: Mark Andrews References: <20111008212432.GB82710@shinkuro.com> <20111008223820.F09F314DF5E1@drugs.dv.isc.org> <20111009135505.GA85221@shinkuro.com> <20111009213431.4756314E0BDE@drugs.dv.isc.org> <20111010051725.3A95214E5206@drugs.dv.isc.org> <20111010220027.F1E2614EB649@drugs.dv.isc.org> <4E9C2413.3030000@nlnetlabs.nl> <20111017134650.816981569E8F@drugs.dv.isc.org> <20111017140437.GA7743@shinkuro.com> In-reply-to: Your message of "Mon, 17 Oct 2011 10:04:38 EDT." <20111017140437.GA7743@shinkuro.com> Date: Tue, 18 Oct 2011 12:42:21 +1100 Message-Id: <20111018014221.C0E871578C86@drugs.dv.isc.org> Cc: dnsext@ietf.org Subject: Re: [dnsext] Why are we re-opening this topic? Was: Suggested update to RFC 4035 section 4.9.2 Handling of the CD Bit 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, 18 Oct 2011 01:42:54 -0000 In message <20111017140437.GA7743@shinkuro.com>, Andrew Sullivan writes: > No hat > > On Tue, Oct 18, 2011 at 12:46:50AM +1100, Mark Andrews wrote: > > > > And when the stub retries there is no state to prevent the recursive > > server asking the same broken upstream again and again and again > > This is true of any breakage. If the authoritative servers are under > DoS, you have the same problem, no? DoS on authoritative servers is > at least as common as DNSSEC misconfiguration. > > The plain fact is that DNSSEC makes the DNS more fragile. Why is this > news, and why do you think that your recommendation is the only > sensible response to this? I still don't understand that. 10 server A0-A8 out of date, A9 up to date. Auth Servers <- breakage -> Recusive Server <- clean -> Stub <- example/a/cd=1,do=1 <- example/a/cd=1,do=1 A0 example/a/cd=1,do=1(bad) -> example/a/cd=1,do=1(bad) -> <- example/a/cd=1,do=1 <- example/a/cd=1,do=1 A1 example/a/cd=1,do=1(bad) -> example/a/cd=1,do=1(bad) -> <- example/a/cd=1,do=1 <- example/a/cd=1,do=1 A2 example/a/cd=1,do=1(bad) -> example/a/cd=1,do=1(bad) -> Give up. Auth Servers <- breakage -> Recusive Server <- clean -> Stub <- example/a/cd=0,do=1 <- example/a/cd=1,do=1 A0 example/a/cd=1,do=1(bad) -> <- example/a/cd=1,do=1 A1 example/a/cd=1,do=1(bad) -> <- example/a/cd=1,do=1 A2 example/a/cd=1,do=1(bad) -> ... A9 example/a/cd=0,do=1(good) -> example/a/cd=0,do=1(good) -> Succeed. > > There is no requirement for a recursive server to attempt to validate > > a response to a CD=1 query from downstream or if it attempts to > > validate the response to retry a different upstream if the validation > > fails. > > Of course not. > > Best, > > A > > -- > Andrew Sullivan > ajs@anvilwalrusden.com > > _______________________________________________ > 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 suruti94@gmail.com Mon Oct 17 19:35: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 AE0A31F0C4B for ; Mon, 17 Oct 2011 19:35:33 -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 lpIt7wTsPTo2 for ; Mon, 17 Oct 2011 19:35:33 -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 15AD11F0C43 for ; Mon, 17 Oct 2011 19:35:33 -0700 (PDT) Received: by yxj19 with SMTP id 19so159076yxj.31 for ; Mon, 17 Oct 2011 19:35:31 -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=9/xbOuApkZO+Tdwvn7HNTPt4DHNcS9W8EuO2Xba7EVE=; b=sC6kaM8c60orrf0/KzA9scWPj3Gu9XX4bcF6rKD1kNoUo4ePQaNwyIvvLAKza7QwwA qTLCFcRXxhBDc2KAUABTvtFuumgLKJuskaxt2ctFyUS9HTOjX9VjfUIK2BEwYEeUWNrI jqlfM0vahh/n/w3i7m/PSILeZnRUqIXXkt2ug= MIME-Version: 1.0 Received: by 10.182.147.4 with SMTP id tg4mr153685obb.60.1318905331420; Mon, 17 Oct 2011 19:35:31 -0700 (PDT) Received: by 10.182.75.9 with HTTP; Mon, 17 Oct 2011 19:35:31 -0700 (PDT) In-Reply-To: <20111018014221.C0E871578C86@drugs.dv.isc.org> References: <20111008212432.GB82710@shinkuro.com> <20111008223820.F09F314DF5E1@drugs.dv.isc.org> <20111009135505.GA85221@shinkuro.com> <20111009213431.4756314E0BDE@drugs.dv.isc.org> <20111010051725.3A95214E5206@drugs.dv.isc.org> <20111010220027.F1E2614EB649@drugs.dv.isc.org> <4E9C2413.3030000@nlnetlabs.nl> <20111017134650.816981569E8F@drugs.dv.isc.org> <20111017140437.GA7743@shinkuro.com> <20111018014221.C0E871578C86@drugs.dv.isc.org> Date: Mon, 17 Oct 2011 19:35:31 -0700 Message-ID: From: Mohan Parthasarathy To: Mark Andrews Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: dnsext@ietf.org Subject: Re: [dnsext] Why are we re-opening this topic? Was: Suggested update to RFC 4035 section 4.9.2 Handling of the CD Bit 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, 18 Oct 2011 02:35:33 -0000 On Mon, Oct 17, 2011 at 6:42 PM, Mark Andrews wrote: > > In message <20111017140437.GA7743@shinkuro.com>, Andrew Sullivan writes: >> No hat >> >> On Tue, Oct 18, 2011 at 12:46:50AM +1100, Mark Andrews wrote: >> > >> > And when the stub retries there is no state to prevent the recursive >> > server asking the same broken upstream again and again and again >> >> This is true of any breakage. =A0If the authoritative servers are under >> DoS, you have the same problem, no? =A0DoS on authoritative servers is >> at least as common as DNSSEC misconfiguration. >> >> The plain fact is that DNSSEC makes the DNS more fragile. =A0Why is this >> news, and why do you think that your recommendation is the only >> sensible response to this? =A0I still don't understand that. > > =A010 server A0-A8 out of date, A9 up to date. > > =A0Auth Servers <- breakage -> =A0Recusive Server <- clean -> Stub > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0<- example/a/cd=3D1,do=3D1 > =A0 =A0 =A0 =A0<- example/a/cd=3D1,do=3D1 > =A0A0 > =A0 =A0 =A0 =A0example/a/cd=3D1,do=3D1(bad) -> > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0example/a/= cd=3D1,do=3D1(bad) -> > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0<- example/a/cd=3D1,do=3D1 > =A0 =A0 =A0 =A0<- example/a/cd=3D1,do=3D1 > =A0A1 > =A0 =A0 =A0 =A0example/a/cd=3D1,do=3D1(bad) -> > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0example/a/= cd=3D1,do=3D1(bad) -> > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0<- example/a/cd=3D1,do=3D1 > =A0 =A0 =A0 =A0<- example/a/cd=3D1,do=3D1 > =A0A2 > =A0 =A0 =A0 =A0example/a/cd=3D1,do=3D1(bad) -> > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0example/a/= cd=3D1,do=3D1(bad) -> > > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Give up. This is confusing. Why did it stop at A2 ? Why didn't it return after trying A0 or A5 ? If this is arbitrary then the recursive server is broken. If the recursive server wants to cache the response and avoid DoS, then stopping here seems broken to me. -mohan > > > =A0Auth Servers <- breakage -> =A0Recusive Server <- clean -> Stub > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0<- example/a/cd=3D0,do=3D1 > =A0 =A0 =A0 =A0<- example/a/cd=3D1,do=3D1 > =A0A0 > =A0 =A0 =A0 =A0example/a/cd=3D1,do=3D1(bad) -> > =A0 =A0 =A0 =A0<- example/a/cd=3D1,do=3D1 > =A0A1 > =A0 =A0 =A0 =A0example/a/cd=3D1,do=3D1(bad) -> > =A0 =A0 =A0 =A0<- example/a/cd=3D1,do=3D1 > =A0A2 > =A0 =A0 =A0 =A0example/a/cd=3D1,do=3D1(bad) -> > > =A0 =A0 =A0 =A0... > > =A0A9 > =A0 =A0 =A0 =A0example/a/cd=3D0,do=3D1(good) -> > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0example/a/= cd=3D0,do=3D1(good) -> > > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Succeed. > > > >> > There is no requirement for a recursive server to attempt to validate >> > a response to a CD=3D1 query from downstream or if it attempts to >> > validate the response to retry a different upstream if the validation >> > fails. >> >> Of course not. >> >> Best, >> >> A >> >> -- >> Andrew Sullivan >> ajs@anvilwalrusden.com >> >> _______________________________________________ >> 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 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 INTERNET: marka@is= c.org > _______________________________________________ > dnsext mailing list > dnsext@ietf.org > https://www.ietf.org/mailman/listinfo/dnsext > From marka@isc.org Mon Oct 17 19:53: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 9CB121F0C62 for ; Mon, 17 Oct 2011 19:53:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.568 X-Spam-Level: X-Spam-Status: No, score=-2.568 tagged_above=-999 required=5 tests=[AWL=0.031, 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 D3YhSNvrModK for ; Mon, 17 Oct 2011 19:53:16 -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 B929C1F0C5F for ; Mon, 17 Oct 2011 19:53:15 -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 9E49AC9422; Tue, 18 Oct 2011 02:53:01 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (unknown [IPv6:2001:470:1f00:820:6233:4bff:fe01:7585]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by bikeshed.isc.org (Postfix) with ESMTPSA id CF57D216C6A; Tue, 18 Oct 2011 02:53:00 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (Postfix) with ESMTP id 9B41A157C571; Tue, 18 Oct 2011 13:52:57 +1100 (EST) To: Mohan Parthasarathy From: Mark Andrews References: <20111008212432.GB82710@shinkuro.com> <20111008223820.F09F314DF5E1@drugs.dv.isc.org> <20111009135505.GA85221@shinkuro.com> <20111009213431.4756314E0BDE@drugs.dv.isc.org> <20111010051725.3A95214E5206@drugs.dv.isc.org> <20111010220027.F1E2614EB649@drugs.dv.isc.org> <4E9C2413.3030000@nlnetlabs.nl> <20111017134650.816981569E8F@drugs.dv.isc.org> <20111017140437.GA7743@shinkuro.com> <20111018014221.C0E871578C86@drugs.dv.isc.org> In-reply-to: Your message of "Mon, 17 Oct 2011 19:35:31 PDT." Date: Tue, 18 Oct 2011 13:52:57 +1100 Message-Id: <20111018025257.9B41A157C571@drugs.dv.isc.org> Cc: dnsext@ietf.org Subject: Re: [dnsext] Why are we re-opening this topic? Was: Suggested update to RFC 4035 section 4.9.2 Handling of the CD Bit 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, 18 Oct 2011 02:53:16 -0000 In message , Mohan Parthasarathy writes: > On Mon, Oct 17, 2011 at 6:42 PM, Mark Andrews wrote: > > > > In message <20111017140437.GA7743@shinkuro.com>, Andrew Sullivan writes: > >> No hat > >> > >> On Tue, Oct 18, 2011 at 12:46:50AM +1100, Mark Andrews wrote: > >> > > >> > And when the stub retries there is no state to prevent the recursive > >> > server asking the same broken upstream again and again and again > >> > >> This is true of any breakage. If the authoritative servers are under > >> DoS, you have the same problem, no? DoS on authoritative servers is > >> at least as common as DNSSEC misconfiguration. > >> > >> The plain fact is that DNSSEC makes the DNS more fragile. Why is this > >> news, and why do you think that your recommendation is the only > >> sensible response to this? I still don't understand that. > > > > 10 server A0-A8 out of date, A9 up to date. > > > > Auth Servers <- breakage -> Recusive Server <- clean -> Stub > > = > <- example/a/cd=3D1,do=3D1 > > <- example/a/cd=3D1,do=3D1 > > A0 > > example/a/cd=3D1,do=3D1(bad) -> > > example/a/= > cd=3D1,do=3D1(bad) -> > > = > <- example/a/cd=3D1,do=3D1 > > <- example/a/cd=3D1,do=3D1 > > A1 > > example/a/cd=3D1,do=3D1(bad) -> > > example/a/= > cd=3D1,do=3D1(bad) -> > > = > <- example/a/cd=3D1,do=3D1 > > <- example/a/cd=3D1,do=3D1 > > A2 > > example/a/cd=3D1,do=3D1(bad) -> > > example/a/= > cd=3D1,do=3D1(bad) -> > > > > Give up. > > This is confusing. Why did it stop at A2 ? Why didn't it return after > trying A0 or A5 ? If this is arbitrary then the recursive server is > broken. If the recursive server wants to cache the response and avoid > DoS, then stopping here seems broken to me. At some stage the stub has to give up. Remember the recursive server doesn't have to cycle through the authoritative servers. It can just ask A0 forever with CD=1 queries and *never* talk to A9. With CD=0 queries the recursive server knows which authoritative servers it has tried and which ones it hasn't. CD=1 has stateless retries. CD=0 has stateful retries. Mark > -mohan > > > Auth Servers <- breakage -> Recusive Server <- clean -> Stub > > = > <- example/a/cd=3D0,do=3D1 > > <- example/a/cd=3D1,do=3D1 > > A0 > > example/a/cd=3D1,do=3D1(bad) -> > > <- example/a/cd=3D1,do=3D1 > > A1 > > example/a/cd=3D1,do=3D1(bad) -> > > <- example/a/cd=3D1,do=3D1 > > A2 > > example/a/cd=3D1,do=3D1(bad) -> > > > > ... > > > > A9 > > example/a/cd=3D0,do=3D1(good) -> > > example/a/= > cd=3D0,do=3D1(good) -> > > > > Succeed. > > > > > > > >> > There is no requirement for a recursive server to attempt to validate > >> > a response to a CD=3D1 query from downstream or if it attempts to > >> > validate the response to retry a different upstream if the validation > >> > fails. > >> > >> Of course not. > >> > >> Best, > >> > >> A > >> > >> -- > >> Andrew Sullivan > >> ajs@anvilwalrusden.com > >> > >> _______________________________________________ > >> 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@is= > c.org > > _______________________________________________ > > 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 suruti94@gmail.com Mon Oct 17 20:16:30 2011 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F4C911E80AF for ; Mon, 17 Oct 2011 20:16:30 -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 FaV6mQLDYpyx for ; Mon, 17 Oct 2011 20:16:29 -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 4264811E8085 for ; Mon, 17 Oct 2011 20:16:29 -0700 (PDT) Received: by gyh20 with SMTP id 20so182740gyh.31 for ; Mon, 17 Oct 2011 20:16:29 -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=WIcVUE2ZCqdcM7E0JYFnwqC8SNE1NMYmqlsGtx8T14g=; b=qJ2Ws3SL8rP/yGRTUyfBTmnMBpZT1Qx7t4fD2q6NPk1c32C+IAPyXbZIWL8rfcRC6p 75q/SM38u9Jmsk4Pbj/Uffu3h1ewaxfzJe6ZN+nHaeum/Ykau6d27V5I5jJiTRzcsSu5 HyDBGNyAnMS+5iWyPb1dyZrGH6unSqHsRg19o= MIME-Version: 1.0 Received: by 10.182.227.7 with SMTP id rw7mr199262obc.70.1318907788884; Mon, 17 Oct 2011 20:16:28 -0700 (PDT) Received: by 10.182.75.9 with HTTP; Mon, 17 Oct 2011 20:16:28 -0700 (PDT) In-Reply-To: <20111018025257.9B41A157C571@drugs.dv.isc.org> References: <20111008212432.GB82710@shinkuro.com> <20111008223820.F09F314DF5E1@drugs.dv.isc.org> <20111009135505.GA85221@shinkuro.com> <20111009213431.4756314E0BDE@drugs.dv.isc.org> <20111010051725.3A95214E5206@drugs.dv.isc.org> <20111010220027.F1E2614EB649@drugs.dv.isc.org> <4E9C2413.3030000@nlnetlabs.nl> <20111017134650.816981569E8F@drugs.dv.isc.org> <20111017140437.GA7743@shinkuro.com> <20111018014221.C0E871578C86@drugs.dv.isc.org> <20111018025257.9B41A157C571@drugs.dv.isc.org> Date: Mon, 17 Oct 2011 20:16:28 -0700 Message-ID: From: Mohan Parthasarathy To: Mark Andrews Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: dnsext@ietf.org Subject: Re: [dnsext] Why are we re-opening this topic? Was: Suggested update to RFC 4035 section 4.9.2 Handling of the CD Bit 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, 18 Oct 2011 03:16:30 -0000 On Mon, Oct 17, 2011 at 7:52 PM, Mark Andrews wrote: > > In message , Mohan Parthasarathy writes: >> On Mon, Oct 17, 2011 at 6:42 PM, Mark Andrews wrote: >> > >> > In message <20111017140437.GA7743@shinkuro.com>, Andrew Sullivan write= s: >> >> No hat >> >> >> >> On Tue, Oct 18, 2011 at 12:46:50AM +1100, Mark Andrews wrote: >> >> > >> >> > And when the stub retries there is no state to prevent the recursiv= e >> >> > server asking the same broken upstream again and again and again >> >> >> >> This is true of any breakage. =A0If the authoritative servers are und= er >> >> DoS, you have the same problem, no? =A0DoS on authoritative servers i= s >> >> at least as common as DNSSEC misconfiguration. >> >> >> >> The plain fact is that DNSSEC makes the DNS more fragile. =A0Why is t= his >> >> news, and why do you think that your recommendation is the only >> >> sensible response to this? =A0I still don't understand that. >> > >> > =A010 server A0-A8 out of date, A9 up to date. >> > >> > =A0Auth Servers <- breakage -> =A0Recusive Server <- clean -> Stub >> > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =3D >> =A0 =A0<- example/a/cd=3D3D1,do=3D3D1 >> > =A0 =A0 =A0 =A0<- example/a/cd=3D3D1,do=3D3D1 >> > =A0A0 >> > =A0 =A0 =A0 =A0example/a/cd=3D3D1,do=3D3D1(bad) -> >> > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0example= /a/=3D >> cd=3D3D1,do=3D3D1(bad) -> >> > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =3D >> =A0 =A0<- example/a/cd=3D3D1,do=3D3D1 >> > =A0 =A0 =A0 =A0<- example/a/cd=3D3D1,do=3D3D1 >> > =A0A1 >> > =A0 =A0 =A0 =A0example/a/cd=3D3D1,do=3D3D1(bad) -> >> > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0example= /a/=3D >> cd=3D3D1,do=3D3D1(bad) -> >> > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =3D >> =A0 =A0<- example/a/cd=3D3D1,do=3D3D1 >> > =A0 =A0 =A0 =A0<- example/a/cd=3D3D1,do=3D3D1 >> > =A0A2 >> > =A0 =A0 =A0 =A0example/a/cd=3D3D1,do=3D3D1(bad) -> >> > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0example= /a/=3D >> cd=3D3D1,do=3D3D1(bad) -> >> > >> > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Give up. >> >> This is confusing. Why did it stop at A2 ? Why didn't it return after >> trying A0 or A5 ? If this is arbitrary then the recursive server is >> broken. If the recursive server wants to cache the response and avoid >> DoS, then stopping here seems broken to me. > > At some stage the stub has to give up. =A0Remember the recursive server > doesn't have to cycle through the authoritative servers. =A0It can > just ask A0 forever with CD=3D1 queries and *never* talk to A9. > > With CD=3D0 queries the recursive server knows which authoritative > servers it has tried and which ones it hasn't. > > CD=3D1 has stateless retries. > CD=3D0 has stateful retries. > See "5.9. Always set the CD bit on Queries" in dnssec-bis updates. Recursive server setting the CD bit on upstream queries is not dependent on the incoming query. -mohan > Mark > >> -mohan >> >> > =A0Auth Servers <- breakage -> =A0Recusive Server <- clean -> Stub >> > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =3D >> =A0 =A0<- example/a/cd=3D3D0,do=3D3D1 >> > =A0 =A0 =A0 =A0<- example/a/cd=3D3D1,do=3D3D1 >> > =A0A0 >> > =A0 =A0 =A0 =A0example/a/cd=3D3D1,do=3D3D1(bad) -> >> > =A0 =A0 =A0 =A0<- example/a/cd=3D3D1,do=3D3D1 >> > =A0A1 >> > =A0 =A0 =A0 =A0example/a/cd=3D3D1,do=3D3D1(bad) -> >> > =A0 =A0 =A0 =A0<- example/a/cd=3D3D1,do=3D3D1 >> > =A0A2 >> > =A0 =A0 =A0 =A0example/a/cd=3D3D1,do=3D3D1(bad) -> >> > >> > =A0 =A0 =A0 =A0... >> > >> > =A0A9 >> > =A0 =A0 =A0 =A0example/a/cd=3D3D0,do=3D3D1(good) -> >> > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0example= /a/=3D >> cd=3D3D0,do=3D3D1(good) -> >> > >> > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Succeed. >> > >> > >> > >> >> > There is no requirement for a recursive server to attempt to valida= te >> >> > a response to a CD=3D3D1 query from downstream or if it attempts to >> >> > validate the response to retry a different upstream if the validati= on >> >> > fails. >> >> >> >> Of course not. >> >> >> >> Best, >> >> >> >> A >> >> >> >> -- >> >> Andrew Sullivan >> >> ajs@anvilwalrusden.com >> >> >> >> _______________________________________________ >> >> 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 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 INTERNET: marka= @is=3D >> c.org >> > _______________________________________________ >> > 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 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 INTERNET: marka@is= c.org > From marka@isc.org Mon Oct 17 20:43:26 2011 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7CD4D11E8083 for ; Mon, 17 Oct 2011 20:43:26 -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 wUaq2UfEXpfc for ; Mon, 17 Oct 2011 20:43:25 -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 A220411E8080 for ; Mon, 17 Oct 2011 20:43:25 -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 002D6C941E; Tue, 18 Oct 2011 03:43:09 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (unknown [IPv6:2001:470:1f00:820:6233:4bff:fe01:7585]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by bikeshed.isc.org (Postfix) with ESMTPSA id 0BFE1216C6A; Tue, 18 Oct 2011 03:43:09 +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 A727A157CB88; Tue, 18 Oct 2011 14:43:06 +1100 (EST) To: Mohan Parthasarathy From: Mark Andrews References: <20111008212432.GB82710@shinkuro.com> <20111008223820.F09F314DF5E1@drugs.dv.isc.org> <20111009135505.GA85221@shinkuro.com> <20111009213431.4756314E0BDE@drugs.dv.isc.org> <20111010051725.3A95214E5206@drugs.dv.isc.org> <20111010220027.F1E2614EB649@drugs.dv.isc.org> <4E9C2413.3030000@nlnetlabs.nl> <20111017134650.816981569E8F@drugs.dv.isc.org> <20111017140437.GA7743@shinkuro.com> <20111018014221.C0E871578C86@drugs.dv.isc.org> <20111018025257.9B41A157C571@drugs.dv.isc.org> In-reply-to: Your message of "Mon, 17 Oct 2011 20:16:28 PDT." Date: Tue, 18 Oct 2011 14:43:06 +1100 Message-Id: <20111018034306.A727A157CB88@drugs.dv.isc.org> Cc: dnsext@ietf.org Subject: Re: [dnsext] Why are we re-opening this topic? Was: Suggested update to RFC 4035 section 4.9.2 Handling of the CD Bit 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, 18 Oct 2011 03:43:26 -0000 In message , Mohan Parthasarathy writes: > On Mon, Oct 17, 2011 at 7:52 PM, Mark Andrews wrote: > > > > In message l.com>, Mohan Parthasarathy writes: > >> On Mon, Oct 17, 2011 at 6:42 PM, Mark Andrews wrote: > >> > > >> > In message <20111017140437.GA7743@shinkuro.com>, Andrew Sullivan write= > s: > >> >> No hat > >> >> > >> >> On Tue, Oct 18, 2011 at 12:46:50AM +1100, Mark Andrews wrote: > >> >> > > >> >> > And when the stub retries there is no state to prevent the recursiv= > e > >> >> > server asking the same broken upstream again and again and again > >> >> > >> >> This is true of any breakage. If the authoritative servers are und= > er > >> >> DoS, you have the same problem, no? DoS on authoritative servers i= > s > >> >> at least as common as DNSSEC misconfiguration. > >> >> > >> >> The plain fact is that DNSSEC makes the DNS more fragile. Why is t= > his > >> >> news, and why do you think that your recommendation is the only > >> >> sensible response to this? I still don't understand that. > >> > > >> > 10 server A0-A8 out of date, A9 up to date. > >> > > >> > Auth Servers <- breakage -> Recusive Server <- clean -> Stub > >> > = > = > >> <- example/a/cd=1,do=1 > >> > <- example/a/cd=1,do=1 > >> > A0 > >> > example/a/cd=1,do=1(bad) -> > >> > example= > /a/= > >> cd=1,do=1(bad) -> > >> > = > = > >> <- example/a/cd=1,do=1 > >> > <- example/a/cd=1,do=1 > >> > A1 > >> > example/a/cd=1,do=1(bad) -> > >> > example= > /a/= > >> cd=1,do=1(bad) -> > >> > = > = > >> <- example/a/cd=1,do=1 > >> > <- example/a/cd=1,do=1 > >> > A2 > >> > example/a/cd=1,do=1(bad) -> > >> > example= > /a/= > >> cd=1,do=1(bad) -> > >> > > >> > Give up. > >> > >> This is confusing. Why did it stop at A2 ? Why didn't it return after > >> trying A0 or A5 ? If this is arbitrary then the recursive server is > >> broken. If the recursive server wants to cache the response and avoid > >> DoS, then stopping here seems broken to me. > > > > At some stage the stub has to give up. Remember the recursive server > > doesn't have to cycle through the authoritative servers. It can > > just ask A0 forever with CD=1 queries and *never* talk to A9. > > > > With CD=0 queries the recursive server knows which authoritative > > servers it has tried and which ones it hasn't. > > > > CD=1 has stateless retries. > > CD=0 has stateful retries. > > See "5.9. Always set the CD bit on Queries" in dnssec-bis updates. > Recursive server setting the CD bit on upstream queries is not > dependent on the incoming query. And what does that have to do with my statements? The examples *had* CD=1 upstream queries. CD=1 queries, from the stub, has stateless retries. CD=0 queries, from the stub, has stateful retries. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From suruti94@gmail.com Mon Oct 17 21:02:53 2011 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 38D9A11E8083 for ; Mon, 17 Oct 2011 21:02:53 -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 ll23gZBaZhwH for ; Mon, 17 Oct 2011 21:02:52 -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 7CA1C11E8080 for ; Mon, 17 Oct 2011 21:02:52 -0700 (PDT) Received: by ggnv1 with SMTP id v1so212852ggn.31 for ; Mon, 17 Oct 2011 21:02:52 -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=THbH0Hq+eflBWhYJ81449DekOPAZDY9o8MhJQQNQTwk=; b=OoF9HRK+iqg4723na2kO31Z5DGDiaKbAAP7tXtxypTmqBgfvSch99w6DPWm2w3YSnp LpojcVedZuMVWQzBlFNiDCUXjaUsTtiG3mUXWEZ8+fEKOgW5yVqUU3JblR6YVU4Rz4XR QP6ChiZ2ri+u3ZTqRz7X/L7IlW7ET9WRJdQSk= MIME-Version: 1.0 Received: by 10.182.11.9 with SMTP id m9mr312181obb.0.1318910571807; Mon, 17 Oct 2011 21:02:51 -0700 (PDT) Received: by 10.182.75.9 with HTTP; Mon, 17 Oct 2011 21:02:51 -0700 (PDT) In-Reply-To: <20111018034306.A727A157CB88@drugs.dv.isc.org> References: <20111008212432.GB82710@shinkuro.com> <20111008223820.F09F314DF5E1@drugs.dv.isc.org> <20111009135505.GA85221@shinkuro.com> <20111009213431.4756314E0BDE@drugs.dv.isc.org> <20111010051725.3A95214E5206@drugs.dv.isc.org> <20111010220027.F1E2614EB649@drugs.dv.isc.org> <4E9C2413.3030000@nlnetlabs.nl> <20111017134650.816981569E8F@drugs.dv.isc.org> <20111017140437.GA7743@shinkuro.com> <20111018014221.C0E871578C86@drugs.dv.isc.org> <20111018025257.9B41A157C571@drugs.dv.isc.org> <20111018034306.A727A157CB88@drugs.dv.isc.org> Date: Mon, 17 Oct 2011 21:02:51 -0700 Message-ID: From: Mohan Parthasarathy To: Mark Andrews Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: dnsext@ietf.org Subject: Re: [dnsext] Why are we re-opening this topic? Was: Suggested update to RFC 4035 section 4.9.2 Handling of the CD Bit 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, 18 Oct 2011 04:02:53 -0000 On Mon, Oct 17, 2011 at 8:43 PM, Mark Andrews wrote: > > In message , Mohan Parthasarathy writes: >> On Mon, Oct 17, 2011 at 7:52 PM, Mark Andrews wrote: >> > >> > In message > l.com>, Mohan Parthasarathy writes: >> >> On Mon, Oct 17, 2011 at 6:42 PM, Mark Andrews wrote: >> >> > >> >> > In message <20111017140437.GA7743@shinkuro.com>, Andrew Sullivan wr= ite=3D >> s: >> >> >> No hat >> >> >> >> >> >> On Tue, Oct 18, 2011 at 12:46:50AM +1100, Mark Andrews wrote: >> >> >> > >> >> >> > And when the stub retries there is no state to prevent the recur= siv=3D >> e >> >> >> > server asking the same broken upstream again and again and again >> >> >> >> >> >> This is true of any breakage. =A0If the authoritative servers are = und=3D >> er >> >> >> DoS, you have the same problem, no? =A0DoS on authoritative server= s i=3D >> s >> >> >> at least as common as DNSSEC misconfiguration. >> >> >> >> >> >> The plain fact is that DNSSEC makes the DNS more fragile. =A0Why i= s t=3D >> his >> >> >> news, and why do you think that your recommendation is the only >> >> >> sensible response to this? =A0I still don't understand that. >> >> > >> >> > =A010 server A0-A8 out of date, A9 up to date. >> >> > >> >> > =A0Auth Servers <- breakage -> =A0Recusive Server <- clean -> Stub >> >> > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =3D >> =A0 =3D >> >> =A0 =A0<- example/a/cd=3D1,do=3D1 >> >> > =A0 =A0 =A0 =A0<- example/a/cd=3D1,do=3D1 >> >> > =A0A0 >> >> > =A0 =A0 =A0 =A0example/a/cd=3D1,do=3D1(bad) -> >> >> > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0exam= ple=3D >> /a/=3D >> >> cd=3D1,do=3D1(bad) -> >> >> > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =3D >> =A0 =3D >> >> =A0 =A0<- example/a/cd=3D1,do=3D1 >> >> > =A0 =A0 =A0 =A0<- example/a/cd=3D1,do=3D1 >> >> > =A0A1 >> >> > =A0 =A0 =A0 =A0example/a/cd=3D1,do=3D1(bad) -> >> >> > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0exam= ple=3D >> /a/=3D >> >> cd=3D1,do=3D1(bad) -> >> >> > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =3D >> =A0 =3D >> >> =A0 =A0<- example/a/cd=3D1,do=3D1 >> >> > =A0 =A0 =A0 =A0<- example/a/cd=3D1,do=3D1 >> >> > =A0A2 >> >> > =A0 =A0 =A0 =A0example/a/cd=3D1,do=3D1(bad) -> >> >> > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0exam= ple=3D >> /a/=3D >> >> cd=3D1,do=3D1(bad) -> >> >> > >> >> > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Give up. >> >> >> >> This is confusing. Why did it stop at A2 ? Why didn't it return after >> >> trying A0 or A5 ? If this is arbitrary then the recursive server is >> >> broken. If the recursive server wants to cache the response and avoid >> >> DoS, then stopping here seems broken to me. >> > >> > At some stage the stub has to give up. =A0Remember the recursive serve= r >> > doesn't have to cycle through the authoritative servers. =A0It can >> > just ask A0 forever with CD=3D1 queries and *never* talk to A9. >> > >> > With CD=3D0 queries the recursive server knows which authoritative >> > servers it has tried and which ones it hasn't. >> > >> > CD=3D1 has stateless retries. >> > CD=3D0 has stateful retries. >> >> See "5.9. =A0Always set the CD bit on Queries" in dnssec-bis updates. >> Recursive server setting the CD bit on upstream queries is not >> dependent on the incoming query. > > And what does that have to do with my statements? =A0The examples > *had* CD=3D1 upstream queries. > > CD=3D1 queries, from the stub, has stateless retries. > CD=3D0 queries, from the stub, has stateful retries. > If the recursive always sets CD=3D1 on its upstream queries irrespective of what the stub set in its query, then it is much easier, less complex to just implement one behavior i.e try the authoritative servers, validate the signatures, cache the response. Why should it be stateless in one case and stateful in another case ? Nothing in the spec talks about stateful vs stateless. -mohan > > Mark > -- > Mark Andrews, ISC > 1 Seymour St., Dundas Valley, NSW 2117, Australia > PHONE: +61 2 9871 4742 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 INTERNET: marka@is= c.org > From ajs@anvilwalrusden.com Mon Oct 17 21:04: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 E6FC21F0C5E for ; Mon, 17 Oct 2011 21:04:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.399 X-Spam-Level: X-Spam-Status: No, score=-2.399 tagged_above=-999 required=5 tests=[AWL=0.200, 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 i99N96T+awW4 for ; Mon, 17 Oct 2011 21:04:33 -0700 (PDT) Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by ietfa.amsl.com (Postfix) with ESMTP id 0C45A1F0C5D for ; Mon, 17 Oct 2011 21:04:32 -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 EE2731ECB41D for ; Tue, 18 Oct 2011 04:04:22 +0000 (UTC) Date: Tue, 18 Oct 2011 00:04:29 -0400 From: Andrew Sullivan To: dnsext@ietf.org Message-ID: <20111018040429.GM7743@shinkuro.com> References: <20111009135505.GA85221@shinkuro.com> <20111009213431.4756314E0BDE@drugs.dv.isc.org> <20111010051725.3A95214E5206@drugs.dv.isc.org> <20111010220027.F1E2614EB649@drugs.dv.isc.org> <4E9C2413.3030000@nlnetlabs.nl> <20111017134650.816981569E8F@drugs.dv.isc.org> <20111017140437.GA7743@shinkuro.com> <20111018014221.C0E871578C86@drugs.dv.isc.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20111018014221.C0E871578C86@drugs.dv.isc.org> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [dnsext] Why are we re-opening this topic? Was: Suggested update to RFC 4035 section 4.9.2 Handling of the CD Bit 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, 18 Oct 2011 04:04:34 -0000 Hi, This is a hat-doffing post. With my hat on, I say that this thread in no way seems to be an argument about the previously-closed issues; so they remain closed. With my hat partway off, I have to say that I'm ever less convinced that there's something new here, but I'm open to argument (possibly from someone who can make the argument I think might be underlying Mark's view, but that hasn't been made yet). With my hat fully off, see below. On Tue, Oct 18, 2011 at 12:42:21PM +1100, Mark Andrews wrote: > > In message <20111017140437.GA7743@shinkuro.com>, Andrew Sullivan writes: > 10 server A0-A8 out of date, A9 up to date. > > Auth Servers <- breakage -> Recusive Server <- clean -> Stub > <- example/a/cd=1,do=1 > <- example/a/cd=1,do=1 . . . > A2 > example/a/cd=1,do=1(bad) -> > example/a/cd=1,do=1(bad) -> > > Give up. Ok. So what? Why is this wrong? I get it that the client didn't get an answer. Well, tough. Don't mess up your zone maintenance. But moreover, > Auth Servers <- breakage -> Recusive Server <- clean -> Stub > <- example/a/cd=0,do=1 > <- example/a/cd=1,do=1 . . .your answer here is that the stub sends with cd=0 and therefore blindly assumes the upstream is safe. Either that, or it sends everything _twice_: once with CD=0 and the second time with CD=1 in order to see whether it's in contact with a "safe" upstream. I can't see how this is the only obvious right policy. A -- Andrew Sullivan ajs@anvilwalrusden.com From ajs@anvilwalrusden.com Mon Oct 17 21:18: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 8418311E8080 for ; Mon, 17 Oct 2011 21:18:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.421 X-Spam-Level: X-Spam-Status: No, score=-2.421 tagged_above=-999 required=5 tests=[AWL=0.178, 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 1Zy66xSwKUk9 for ; Mon, 17 Oct 2011 21:18:37 -0700 (PDT) Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by ietfa.amsl.com (Postfix) with ESMTP id B336011E80AF for ; Mon, 17 Oct 2011 21:18:36 -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 8BFE91ECB41D for ; Tue, 18 Oct 2011 04:18:27 +0000 (UTC) Date: Tue, 18 Oct 2011 00:18:34 -0400 From: Andrew Sullivan To: dnsext@ietf.org Message-ID: <20111018041833.GN7743@shinkuro.com> References: <20111010051725.3A95214E5206@drugs.dv.isc.org> <20111010220027.F1E2614EB649@drugs.dv.isc.org> <4E9C2413.3030000@nlnetlabs.nl> <20111017134650.816981569E8F@drugs.dv.isc.org> <20111017140437.GA7743@shinkuro.com> <20111018014221.C0E871578C86@drugs.dv.isc.org> <20111018025257.9B41A157C571@drugs.dv.isc.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20111018025257.9B41A157C571@drugs.dv.isc.org> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: [dnsext] Other views request from chair (was : Why are we re-opening. . .) 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, 18 Oct 2011 04:18:37 -0000 Dear colleagues, On Tue, Oct 18, 2011 at 01:52:57PM +1100, Mark Andrews wrote: > > CD=1 has stateless retries. > CD=0 has stateful retries. Because I have a feeble (not to say febrile) brain, I fail to understand the argument implicit above. As near as I can tell, Mark is arguing from the position that a particular implementation choice is what the protocol demands. I'm not seeing this demand -- neither in the original RFCs nor in the existing dnssec-bis-updates draft; but I'm fully prepared to admit that I'm missing something, since I'm usually missing something. As co-chair, I hereby ask others to weigh in on this discussion if they have a view. If I don't hear anything from others than those who have participated, I will take that (as shepherd of dnssec-bis-updates) to be evidence that people do not think the proposed additions to the dnssec-bis-updates draft should be added, and will direct the editors of that draft to ignore this discussion for their purposes. Best, A -- Andrew Sullivan ajs@anvilwalrusden.com From brian.peter.dickson@gmail.com Mon Oct 17 22:35:30 2011 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B33511E8091 for ; Mon, 17 Oct 2011 22:35:30 -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 ywQUVFbcfhcy for ; Mon, 17 Oct 2011 22:35:29 -0700 (PDT) Received: from mail-bw0-f44.google.com (mail-bw0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id 0FD3E11E808E for ; Mon, 17 Oct 2011 22:35:28 -0700 (PDT) Received: by bkas6 with SMTP id s6so403597bka.31 for ; Mon, 17 Oct 2011 22:35:28 -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=mnpiBpY3uTWRa073vB2uS9jKT3vp5H9pnGyWXMUJQps=; b=cjiK3MBk911ImuFPh3dnGLvJqNFamXD4t9j6fmFRc0Fe4bMiTZROnQl6LC5w9CNWJ6 lzEagHUStPNrByjGb1rJh5h0G0MTuz/ymvOg7PKeKd2h6yC/EoITa6xd/ZBtE7fMjcpy ROoZcTQOshxDaKCw8hJEZV1ewRG5ehbngv4LA= MIME-Version: 1.0 Received: by 10.223.61.211 with SMTP id u19mr1733129fah.29.1318916128075; Mon, 17 Oct 2011 22:35:28 -0700 (PDT) Received: by 10.223.16.78 with HTTP; Mon, 17 Oct 2011 22:35:27 -0700 (PDT) In-Reply-To: <20111018041833.GN7743@shinkuro.com> References: <20111010051725.3A95214E5206@drugs.dv.isc.org> <20111010220027.F1E2614EB649@drugs.dv.isc.org> <4E9C2413.3030000@nlnetlabs.nl> <20111017134650.816981569E8F@drugs.dv.isc.org> <20111017140437.GA7743@shinkuro.com> <20111018014221.C0E871578C86@drugs.dv.isc.org> <20111018025257.9B41A157C571@drugs.dv.isc.org> <20111018041833.GN7743@shinkuro.com> Date: Tue, 18 Oct 2011 01:35:27 -0400 Message-ID: From: Brian Dickson To: Andrew Sullivan Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: dnsext@ietf.org Subject: Re: [dnsext] Other views request from chair (was : Why are we re-opening. . .) 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, 18 Oct 2011 05:35:30 -0000 Okay, glad to comment without previously being active in the conversation..= . On Tue, Oct 18, 2011 at 12:18 AM, Andrew Sullivan wrote: > Dear colleagues, > > On Tue, Oct 18, 2011 at 01:52:57PM +1100, Mark Andrews wrote: >> >> CD=3D1 has stateless retries. >> CD=3D0 has stateful retries. > > Because I have a feeble (not to say febrile) brain, I fail to > understand the argument implicit above. =A0As near as I can tell, Mark > is arguing from the position that a particular implementation choice > is what the protocol demands. =A0I'm not seeing this demand -- neither > in the original RFCs nor in the existing dnssec-bis-updates draft; but > I'm fully prepared to admit that I'm missing something, since I'm > usually missing something. I'll try to summarize, not what Mark has said, or what anyone else has said, but what needs to be said. Kind of. Basically, what CD=3D0 says, and what CD=3D1 says, are unfortunately neither diametrically opposed, nor orthogonal, at least when combined with the following other bits: RD=3D1 (I'm a stub) DO=3D1 (I'm asking for DNSSEC too) If the combo was (CD=3D0, validate for me, and DO=3D0, I'm not validating), the behavior requested is well-defined, IMHO. Or, if RD=3D0, well, why are we talking to a recursive server? So, the problem is, that the desired behavior doesn't appear to be signaled or signal-able, by use of the CD bit. Or rather, the use of the CD bit is somewhat ambiguous. And this appears to be the case only when RD=3D1 and DO=3D1. Mark's logic is correct. I looked through 4035, and followed the various branches (3.2, et al) to see if anything is contradicted or contraindicated. He is also correct that the current 4035 use of RFC2119 language, in respect to stubs and CD bit, is off the mark. The proscribed behavior is not based on interoperability, and based on presumptions about the uniformity of validation succeeding. The choice of CD=3D0 first should only fail to return good data (i.e.return data to the stub, which will pass the stub's validation) if there is a discrepancy between TAs, or if the recursive resolver has failed to validate all responses or has no responses. Following this up with CD=3D1 will disambiguate the reasons if CD=3D0 does not give good data, at which point the stub should have reliable success-or-failure - which does not depend on the implementation choices on the recursive server. Doing CD=3D1 first may lead the stub down the wrong path, and whether it does is dependent on implementation choices. CD=3D0 is much more well-defined, and thus unlikely to be mis-implemented or in any way dependent on implementers' choices. IMHO. So, I'd suggest finding suitable language to encode what Mark says, and adding it to -bis. > As co-chair, I hereby ask others to weigh in on this discussion if > they have a view. =A0If I don't hear anything from others than those who > have participated, I will take that (as shepherd of > dnssec-bis-updates) to be evidence that people do not think the > proposed additions to the dnssec-bis-updates draft should be added, > and will direct the editors of that draft to ignore this discussion > for their purposes. > > Best, > > A Okay, hopefully I have been able to provide useful input into this. My strong preference is to find places where DNS (or DNSSEC) have need for improvement, and improving them. IMHO, this is one such place, and a low-hanging fruit at that. Sincerely, Brian From marka@isc.org Mon Oct 17 22:43: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 1E45A11E808E for ; Mon, 17 Oct 2011 22:43:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.572 X-Spam-Level: X-Spam-Status: No, score=-2.572 tagged_above=-999 required=5 tests=[AWL=0.027, 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 ZvmhtwjPZ9Ia for ; Mon, 17 Oct 2011 22:43:12 -0700 (PDT) Received: from mx.pao1.isc.org (mx.pao1.isc.org [IPv6:2001:4f8:0:2::2b]) by ietfa.amsl.com (Postfix) with ESMTP id 4AF6F11E8089 for ; Mon, 17 Oct 2011 22:43:12 -0700 (PDT) Received: from bikeshed.isc.org (bikeshed.isc.org [IPv6:2001:4f8:3:d::19]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "bikeshed.isc.org", Issuer "ISC CA" (verified OK)) by mx.pao1.isc.org (Postfix) with ESMTPS id EB745C9422; Tue, 18 Oct 2011 05:42:55 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (unknown [IPv6:2001:470:1f00:820:6233:4bff:fe01:7585]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by bikeshed.isc.org (Postfix) with ESMTPSA id 3960E216C6B; Tue, 18 Oct 2011 05:42:55 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (Postfix) with ESMTP id 1EF21157D5EB; Tue, 18 Oct 2011 16:42:52 +1100 (EST) To: Andrew Sullivan From: Mark Andrews References: <20111009135505.GA85221@shinkuro.com> <20111009213431.4756314E0BDE@drugs.dv.isc.org> <20111010051725.3A95214E5206@drugs.dv.isc.org> <20111010220027.F1E2614EB649@drugs.dv.isc.org> <4E9C2413.3030000@nlnetlabs.nl> <20111017134650.816981569E8F@drugs.dv.isc.org> <20111017140437.GA7743@shinkuro.com> <20111018014221.C0E871578C86@drugs.dv.isc.org> <20111018040429.GM7743@shinkuro.com> In-reply-to: Your message of "Tue, 18 Oct 2011 00:04:29 EDT." <20111018040429.GM7743@shinkuro.com> Date: Tue, 18 Oct 2011 16:42:52 +1100 Message-Id: <20111018054252.1EF21157D5EB@drugs.dv.isc.org> Cc: dnsext@ietf.org Subject: Re: [dnsext] Why are we re-opening this topic? Was: Suggested update to RFC 4035 section 4.9.2 Handling of the CD Bit 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, 18 Oct 2011 05:43:13 -0000 In message <20111018040429.GM7743@shinkuro.com>, Andrew Sullivan writes: > Hi, > > This is a hat-doffing post. With my hat on, I say that this thread in > no way seems to be an argument about the previously-closed issues; so > they remain closed. With my hat partway off, I have to say that I'm > ever less convinced that there's something new here, but I'm open to > argument (possibly from someone who can make the argument I think > might be underlying Mark's view, but that hasn't been made yet). With > my hat fully off, see below. > > On Tue, Oct 18, 2011 at 12:42:21PM +1100, Mark Andrews wrote: > > > > In message <20111017140437.GA7743@shinkuro.com>, Andrew Sullivan writes: > > > 10 server A0-A8 out of date, A9 up to date. > > > > Auth Servers <- breakage -> Recusive Server <- clean -> Stub > > <- example/a/cd=1,do=1 > > <- example/a/cd=1,do=1 > > . . . > > > A2 > > example/a/cd=1,do=1(bad) -> > > example/a/cd=1,do=1(bad) -> > > > > Give up. > > Ok. So what? Why is this wrong? I get it that the client didn't get > an answer. Well, tough. Don't mess up your zone maintenance. But > moreover, The current spec only works reliably if *all* the answers the recursive server gets are *good*. I'm trying to make it work with real world senarios. > > Auth Servers <- breakage -> Recusive Server <- clean -> Stub > > <- example/a/cd=0,do=1 > > <- example/a/cd=1,do=1 > > . . .your answer here is that the stub sends with cd=0 and therefore > blindly assumes the upstream is safe. No. CD=0 says nothing, nada, diddly squat about whether the client is going to validate or not. All that is required for the client to validate is that DO=1 so that it will get the signature in the response. You keep making this logic error that because CD=1 indicates that the client intends to validate, that CD=0 indicates that it doesn't intend to validate. This is incorrect logic. DNS64 has this logic error in it. A => B does not mean that !A => !B. The only assumption I am making is that the recursive server has some trust anchors. If it doesn't then CD=0 is no different to CD=1. If we want to solve the case where the recursive server has no trust anchors, I have a solution (below) but that is a whole new RFC and possibly a bump in EDNS version numbers. It also solves the different trust achors problem and different time problem, that the current CD=1 query is trying to solve, and you never send CD=1 queries unless the recursive server doesn't understand the extension. If the recursive server doesn't undertand the extension (detectably with a EDNS version bump) the stub would fallback to the behaviour I am recommending here so this exercise is not a waste of time but it maybe not enough. The stub selects its closest trust anchors (as DS's) and sends it in a EDNS1 messager to the recursive server along with its idea of the current time.