From Ed.Lewis@neustar.biz Fri Nov 4 08:33: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 D01F721F8B70 for ; Fri, 4 Nov 2011 08:33:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.436 X-Spam-Level: X-Spam-Status: No, score=-106.436 tagged_above=-999 required=5 tests=[AWL=0.162, 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 2ViB1qs6lGCl for ; Fri, 4 Nov 2011 08:33:07 -0700 (PDT) Received: from stora.ogud.com (stora.ogud.com [66.92.146.20]) by ietfa.amsl.com (Postfix) with ESMTP id 34DAA21F8C44 for ; Fri, 4 Nov 2011 08:33:06 -0700 (PDT) Received: from sgoo-lt500.cis.neustar.com (nyttbox.md.ogud.com [10.20.30.4]) by stora.ogud.com (8.14.4/8.14.4) with ESMTP id pA4FX2D2030714; Fri, 4 Nov 2011 11:33:03 -0400 (EDT) (envelope-from Ed.Lewis@neustar.biz) Received: from [192.168.128.112] by sgoo-lt500.cis.neustar.com (PGP Universal service); Fri, 04 Nov 2011 11:33:03 -0400 X-PGP-Universal: processed; by sgoo-lt500.cis.neustar.com on Fri, 04 Nov 2011 11:33:03 -0400 Mime-Version: 1.0 Message-Id: Date: Fri, 4 Nov 2011 11:31:09 -0400 To: From: Edward Lewis Content-Type: multipart/alternative; boundary="============_-891701713==_ma============" X-Scanned-By: MIMEDefang 2.72 on 10.20.30.4 Cc: ed.lewis@neustar.biz Subject: [dnsext] CNAME/DNAME and NXDOMAIN X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Nov 2011 15:33:07 -0000 --============_-891701713==_ma============ Content-Type: text/plain; charset="us-ascii" ; format="flowed" Recent experiments on the Internet brought up a question regarding the handling of CNAME and DNAME answers that lead to negative responses. This is an old issue, nothing new, but it seems that there's some confusion among popular implementations. Citing the oldest text, RFC 1034/4.3.2: If the "*" label does not exist, check whether the name we are looking for is the original QNAME in the query or a name we have followed due to a CNAME. If the name is original, set an authoritative name error in the response and exit. Otherwise just exit. This says that if a CNAME chain leads to a non-existent name, the RCODE reflects that the original name's status, not the end. This rule applies to authoritative servers. In RFC 2308 (NCACHE), section 2.1, caches are instructed to set the RCODE to NXDOMAIN if the target of the CNAME chain does not exist. This is not a contradiction because this pertains to recursive servers. Now with DNSSEC on-board we have another angle of confusion. When the target does not exist, there's the matter of the NSEC/NSEC3 record sets needed. This is in addition to the SOA record and RCODE setting. And to further twist this, in accordance with the real life situation that launched this quest, the QNAME owning the CNAME/DNAME is in an different zone than the target but the name servers for both zones are the same. With the help of Olafur, I've set up a test case unconnected to the live situation to help illustrate this. The reason for this level of misdirection is that I'm in now way connected to the real example and I don't want to finger point, especially because I think the "fault" here lies in the implementations and not in the operator's actions. What I'm asking for is people to issue these two digs and look at the output. I believe the output, which differ from each other, should have an RCODE of No Error, an Answer Section with the CNAME and signature, and an Authority section with an NSEC and RRSIG(NSEC) to prove why a wildcard is consulted. One answer has that plus NSEC3 records showing that the targer does not exist. The other answer has that plus the SOA and SOA RRSIG with the RCODE set to Name Error. If you ask a recursive server for this (in the real example), the latter response is correct. But the servers being asked here are (acting as) authorities. dig @geysir.ogud.com www.dnametest.nseczone.dstestdomain092811.us. AAAA +dnssec dig @stora.ogud.com www.dnametest.nseczone.dstestdomain092811.us. AAAA +dnssec The real situation involves DNAME, not CNAME, but I chose to test on CNAME because it's more clearly documented in the text. I haven't found the "smoking gun" passage that says the NXDOMAIN rule for CNAME applies to DNAME but common sense say it does. I'd like to know of these two implementations "go to far" in generating the answer, according to the specifications. The answers are both right and do not cause an operational interruption. I'll leave off identifying the implementations. They might be discoverable via the usual methods, I don't think any steps were taken to stop that. But for the sake of this little experiment, it's good to not know at first. I'll say the two are very popular and you probably can guess them before I finish this paragraph. I just checked - yes, the versions are visible. ;) PS - the test zone here is properly delegated but not to Olafur's servers, so you need the "@nameserver" to hit them. If you leave that off you hit our servers, which have nothing to do with the test. (I.e., I'm not trying to compares ours to the open source ones.) -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- 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" --============_-891701713==_ma============ Content-Type: text/html; charset="us-ascii" CNAME/DNAME and NXDOMAIN
Recent experiments on the Internet brought up a question regarding the handling of CNAME and DNAME answers that lead to negative responses.  This is an old issue, nothing new, but it seems that there's some confusion among popular implementations.

Citing the oldest text, RFC 1034/4.3.2:

            If the "*" label does not exist, check whether the name
            we are looking for is the original QNAME in the query
            or a name we have followed due to a CNAME.  If the name
            is original, set an authoritative name error in the
            response and exit.  Otherwise just exit.

This says that if a CNAME chain leads to a non-existent name, the RCODE reflects that the original name's status, not the end.  This rule applies to authoritative servers.

In RFC 2308 (NCACHE), section 2.1, caches are instructed to set the RCODE to NXDOMAIN if the target of the CNAME chain does not exist.  This is not a contradiction because this pertains to recursive servers.

Now with DNSSEC on-board we have another angle of confusion.  When the target does not exist, there's the matter of the NSEC/NSEC3 record sets needed.  This is in addition to the SOA record and RCODE setting.

And to further twist this, in accordance with the real life situation that launched this quest, the QNAME owning the CNAME/DNAME is in an different zone than the target but the name servers for both zones are the same.

With the help of Olafur, I've set up a test case unconnected to the live situation to help illustrate this.  The reason for this level of misdirection is that I'm in now way connected to the real example and I don't want to finger point, especially because I think the "fault" here lies in the implementations and not in the operator's actions.

What I'm asking for is people to issue these two digs and look at the output.  I believe the output, which differ from each other, should have an RCODE of No Error, an Answer Section with the CNAME and signature, and an Authority section with an NSEC and RRSIG(NSEC) to prove why a wildcard is consulted.  One answer has that plus NSEC3 records showing that the targer does not exist. The other answer has that plus the SOA and SOA RRSIG with the RCODE set to Name Error.

If you ask a recursive server for this (in the real example), the latter response is correct.  But the servers being asked here are (acting as) authorities.

dig @geysir.ogud.com www.dnametest.nseczone.dstestdomain092811.us. AAAA +dnssec

dig @stora.ogud.com www.dnametest.nseczone.dstestdomain092811.us. AAAA +dnssec

The real situation involves DNAME, not CNAME, but I chose to test on CNAME because it's more clearly documented in the text.  I haven't found the "smoking gun" passage that says the NXDOMAIN rule for CNAME applies to DNAME but common sense say it does.

I'd like to know of these two implementations "go to far" in generating the answer, according to the specifications.  The answers are both right and do not cause an operational interruption.

I'll leave off identifying the implementations.  They might be discoverable via the usual methods, I don't think any steps were taken to stop that.  But for the sake of this little experiment, it's good to not know at first.  I'll say the two are very popular and you probably can guess them before I finish this paragraph.

I just checked - yes, the versions are visible. ;)

PS - the test zone here is properly delegated but not to Olafur's servers, so you need the "@nameserver" to hit them.  If you leave that off you hit our servers, which have nothing to do with the test.  (I.e., I'm not trying to compares ours to the open source ones.)
--
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
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"
--============_-891701713==_ma============-- From marka@isc.org Fri Nov 4 16:17: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 A7E4721F8ADE for ; Fri, 4 Nov 2011 16:17:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.619 X-Spam-Level: X-Spam-Status: No, score=-2.619 tagged_above=-999 required=5 tests=[AWL=-0.020, 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 a+amlW8KslVq for ; Fri, 4 Nov 2011 16:17:30 -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 3CE7221F8AD1 for ; Fri, 4 Nov 2011 16:17:30 -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 BFA18C9425; Fri, 4 Nov 2011 23:17:17 +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 87687216C6A; Fri, 4 Nov 2011 23:17:17 +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 AA38F16AD6F6; Sat, 5 Nov 2011 10:17:15 +1100 (EST) To: Edward Lewis From: Mark Andrews References: In-reply-to: Your message of "Fri, 04 Nov 2011 11:31:09 EDT." Date: Sat, 05 Nov 2011 10:17:15 +1100 Message-Id: <20111104231715.AA38F16AD6F6@drugs.dv.isc.org> Cc: dnsext@ietf.org Subject: Re: [dnsext] CNAME/DNAME and NXDOMAIN X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Nov 2011 23:17:30 -0000 Both answers are self consistant and neither should cause a problem. Following CNAME records, when not recursing for the client, is a security issue as the target of the CNAME may not be delegated to the same machine leading to potential, accidental, cache poisioning. We (ISC) have looked at not following CNAME records when generating such replies. We already discard the rest of the response and requery for the target of the CNAME. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From marka@isc.org Thu Nov 10 18:50: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 6034011E8099 for ; Thu, 10 Nov 2011 18:50:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[AWL=-0.002, 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 QxaDe-GN++gM for ; Thu, 10 Nov 2011 18:50:41 -0800 (PST) Received: from mx.ams1.isc.org (mx.ams1.isc.org [IPv6:2001:500:60::65]) by ietfa.amsl.com (Postfix) with ESMTP id D488C11E8080 for ; Thu, 10 Nov 2011 18:50:40 -0800 (PST) Received: from bikeshed.isc.org (bikeshed.isc.org [IPv6:2001:4f8:3:d::19]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "bikeshed.isc.org", Issuer "ISC CA" (verified OK)) by mx.ams1.isc.org (Postfix) with ESMTPS id E2FC25F98AF for ; Fri, 11 Nov 2011 02:50:26 +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 EEFE5216C71 for ; Fri, 11 Nov 2011 02:50: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 B689B17061FA for ; Fri, 11 Nov 2011 13:50:07 +1100 (EST) To: dnsext@ietf.org From: Mark Andrews Date: Fri, 11 Nov 2011 13:50:07 +1100 Message-Id: <20111111025007.B689B17061FA@drugs.dv.isc.org> Subject: [dnsext] BADVER/FORMERR X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Nov 2011 02:50:41 -0000 I was looking for a good way to test for EDNS support and hacked dig to send out a empty question section when the EDNS version was set to 255 and got what I believe to be incorrect responses from K and L. EDNS version processing is supposed to take precedence over examining the query section as the EDNS version can influence the interpretion of the question section. I believe the correct response should be BADVERS. Adding a question elicited BADVERS. Do others agree with my interpretion of rcode precedence? Mark marka% bin/dig/dig +edns=255 +norec @k.root-servers.net ; <<>> DiG 9.9.0b1 <<>> +edns=255 +norec @k.root-servers.net ; (2 servers found) ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: FORMERR, id: 40361 ;; flags: qr; QUERY: 0, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0 ;; Query time: 255 msec ;; SERVER: 2001:7fd::1#53(2001:7fd::1) ;; WHEN: Fri Nov 11 13:34:50 2011 ;; MSG SIZE rcvd: 12 marka% bin/dig/dig +edns=255 +norec @l.root-servers.net ; <<>> DiG 9.9.0b1 <<>> +edns=255 +norec @l.root-servers.net ; (2 servers found) ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: FORMERR, id: 34663 ;; flags: qr; QUERY: 0, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0 ;; Query time: 175 msec ;; SERVER: 2001:500:3::42#53(2001:500:3::42) ;; WHEN: Fri Nov 11 13:35:08 2011 ;; MSG SIZE rcvd: 12 -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From Ray.Bellis@nominet.org.uk Fri Nov 11 04:43: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 0C42F21F87D9 for ; Fri, 11 Nov 2011 04:43:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.662 X-Spam-Level: X-Spam-Status: No, score=-7.662 tagged_above=-999 required=5 tests=[AWL=-1.063, 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 6rWhzKmaDckb for ; Fri, 11 Nov 2011 04:43:58 -0800 (PST) Received: from mx1.knowthenet.org.uk (mx1.knowthenet.org.uk [213.248.199.2]) by ietfa.amsl.com (Postfix) with ESMTP id B756821F86DD for ; Fri, 11 Nov 2011 04:43:53 -0800 (PST) DomainKey-Signature: s=main.dk.nominet.selector; d=nominet.org.uk; c=nofws; q=dns; h=X-IronPort-AV:Received:Received:From:To: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: Content-Transfer-Encoding:MIME-Version; b=eO35IFjZhC6533s+rEPztO2QyVLxWDp71MtLv0o18/nwqFlcUNTt4jaZ QUfoUQXcg+p52liily4kaoYqtlKYSL6E4GogastGuKXg0A2I9zWriQl1x N9lhF/Fo97PTH9r; 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=1321015437; x=1352551437; 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]=20BADVER/FORMERR|Date:=20Fri, =2011=20Nov=202011=2012:42:24=20+0000|Message-ID:=20<8B7F 972437853B40865000D86857B1D118DC4B13@wds-exc1.okna.nomine t.org.uk>|To:=20Mark=20Andrews=20,=20"dnse xt@ietf.org"=20|MIME-Version:=201.0 |Content-Transfer-Encoding:=20quoted-printable |In-Reply-To:=20<20111111025007.B689B17061FA@drugs.dv.isc .org>|References:=20<20111111025007.B689B17061FA@drugs.dv .isc.org>; bh=2n/xwMuRx5yuQEsfdRf/wvMM7cleEoHh4hwYFvApPxk=; b=aL1hc2Rpkyih2Tgdy1OwIctVpVQbHv1UuDKrk5c0P+eLGjlGy/fcHf7d T+XUzR8MTkyMfCuED8KIZdXCDpci7JTZWRMi0UBDe2Iixrdrq0hCzdd87 fG+DOTONeEM/Y2K; X-IronPort-AV: E=Sophos;i="4.69,494,1315177200"; d="scan'208";a="36515307" Received: from wds-exc2.okna.nominet.org.uk ([213.248.197.145]) by mx3.nominet.org.uk with ESMTP; 11 Nov 2011 12:43:52 +0000 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; Fri, 11 Nov 2011 12:43:51 +0000 From: Ray Bellis To: Mark Andrews , "dnsext@ietf.org" Thread-Topic: [dnsext] BADVER/FORMERR Thread-Index: AQHMoBzA5mAz8aYz4U6U8KCek//FTpWnnoCV Date: Fri, 11 Nov 2011 12:42:24 +0000 Message-ID: <8B7F972437853B40865000D86857B1D118DC4B13@wds-exc1.okna.nominet.org.uk> References: <20111111025007.B689B17061FA@drugs.dv.isc.org> In-Reply-To: <20111111025007.B689B17061FA@drugs.dv.isc.org> Accept-Language: en-GB, en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [dnsext] BADVER/FORMERR X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Nov 2011 12:43:59 -0000 > EDNS version processing is supposed to take precedence=0A= > over examining the query section=0A= =0A= Defined where? I don't see anything like that in RFC 2308.=0A= =0A= > as the EDNS version can influence the interpretion of the=0A= > question section. =0A= =0A= Ditto.=0A= =0A= Just out of interest, are there any _existing_ legitimate circumstances whe= re QDCOUNT !=3D 1 ?=0A= =0A= Ray=0A= From fweimer@bfk.de Fri Nov 11 04:47: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 3785821F86A0 for ; Fri, 11 Nov 2011 04:47:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vSbVyrTfJpRY for ; Fri, 11 Nov 2011 04:47:38 -0800 (PST) Received: from mx01.bfk.de (mx01.bfk.de [193.227.124.2]) by ietfa.amsl.com (Postfix) with ESMTP id 9AFBB21F85F1 for ; Fri, 11 Nov 2011 04:47:38 -0800 (PST) Received: from mx00.int.bfk.de ([10.119.110.2]) by mx01.bfk.de with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) id 1ROqW9-0002rq-HC; Fri, 11 Nov 2011 12:47:37 +0000 Received: by bfk.de with local id 1ROqW9-0001k3-DQ; Fri, 11 Nov 2011 12:47:37 +0000 From: Florian Weimer To: Mark Andrews References: <20111111025007.B689B17061FA@drugs.dv.isc.org> Date: Fri, 11 Nov 2011 12:47:37 +0000 In-Reply-To: <20111111025007.B689B17061FA@drugs.dv.isc.org> (Mark Andrews's message of "Fri, 11 Nov 2011 13:50:07 +1100") Message-ID: <82bosij05y.fsf@mid.bfk.de> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: dnsext@ietf.org Subject: Re: [dnsext] BADVER/FORMERR X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Nov 2011 12:47:39 -0000 * Mark Andrews: > the EDNS version can influence the interpretion of the question > section. Only in a very limited ways because the EDNS version is accessible only *after* the question section has been parsed. --=20 Florian Weimer BFK edv-consulting GmbH http://www.bfk.de/ Kriegsstra=DFe 100 tel: +49-721-96201-1 D-76133 Karlsruhe fax: +49-721-96201-99 From msk@cloudmark.com Fri Nov 11 23:46:46 2011 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0060911E8073 for ; Fri, 11 Nov 2011 23:46:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.808 X-Spam-Level: X-Spam-Status: No, score=-102.808 tagged_above=-999 required=5 tests=[AWL=-0.209, 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 r8lwiMLy3ulJ for ; Fri, 11 Nov 2011 23:46:45 -0800 (PST) Received: from ht2-outbound.cloudmark.com (ht2-outbound.cloudmark.com [72.5.239.36]) by ietfa.amsl.com (Postfix) with ESMTP id 927EF21F8448 for ; Fri, 11 Nov 2011 23:46:45 -0800 (PST) Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by spite.corp.cloudmark.com ([172.22.10.72]) with mapi; Fri, 11 Nov 2011 23:46:45 -0800 From: "Murray S. Kucherawy" To: "dnsext@ietf.org" Date: Fri, 11 Nov 2011 23:46:43 -0800 Thread-Topic: [dnsext] RFC 4408 question Thread-Index: AcyUyQ2jPrRW8elDTACJEE+1wmrMuwMK4yDg Message-ID: References: <4EA98CA8.8050507@ogud.com> In-Reply-To: <4EA98CA8.8050507@ogud.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [dnsext] RFC 4408 question X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 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, 12 Nov 2011 07:46:46 -0000 > -----Original Message----- > From: dnsext-bounces@ietf.org [mailto:dnsext-bounces@ietf.org] On Behalf = Of Olafur Gudmundsson > Sent: Thursday, October 27, 2011 9:54 AM > To: dnsext@ietf.org > Subject: Re: [dnsext] RFC 4408 question >=20 > This is an real interesting question in particular if we consider it in > the wider context of what is a "white space" in a Text-like DNS record. > [...] > I do not think that FWS is the right definition in the DNS context, as > I worry what will happen to various implementation if someone wants to > use CR/LF as a separator in SPF or TXT record :-) >=20 > As David Conrad says implementations should be able to deal with both > as separators thus, feel free to file an errata on RFC4408 clarifying > that "space" and "tab" are both valid separators, and nothing else. I concur. There is an spf-discuss mailing list already (hosted outside the IETF), and= there is a fledgling effort to revise SPF spinning up as well which means = there should be an IETF-hosted list popping up soon as well. This would be= great to bring up in either or both places. -MSK From marka@isc.org Sat Nov 12 00:49:47 2011 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4235521F85C7 for ; Sat, 12 Nov 2011 00:49:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[AWL=-0.002, 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 a-lY9P-G5co1 for ; Sat, 12 Nov 2011 00:49:46 -0800 (PST) Received: from mx.ams1.isc.org (mx.ams1.isc.org [IPv6:2001:500:60::65]) by ietfa.amsl.com (Postfix) with ESMTP id 77AF121F85B9 for ; Sat, 12 Nov 2011 00:49:46 -0800 (PST) Received: from bikeshed.isc.org (bikeshed.isc.org [IPv6:2001:4f8:3:d::19]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "bikeshed.isc.org", Issuer "ISC CA" (verified OK)) by mx.ams1.isc.org (Postfix) with ESMTPS id B70845F98B7; Sat, 12 Nov 2011 08:49:32 +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 1FD07216C84; Sat, 12 Nov 2011 08:49: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 A6299171131B; Sat, 12 Nov 2011 19:49:28 +1100 (EST) To: Ray Bellis From: Mark Andrews References: <20111111025007.B689B17061FA@drugs.dv.isc.org> <8B7F972437853B40865000D86857B1D118DC4B13@wds-exc1.okna.nominet.org.uk> In-reply-to: Your message of "Fri, 11 Nov 2011 12:42:24 -0000." <8B7F972437853B40865000D86857B1D118DC4B13@wds-exc1.okna.nominet.org.uk> Date: Sat, 12 Nov 2011 19:49:28 +1100 Message-Id: <20111112084928.A6299171131B@drugs.dv.isc.org> Cc: "dnsext@ietf.org" Subject: Re: [dnsext] BADVER/FORMERR X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 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, 12 Nov 2011 08:49:47 -0000 In message <8B7F972437853B40865000D86857B1D118DC4B13@wds-exc1.okna.nominet.org.uk>, Ray Bellis writes: > > EDNS version processing is supposed to take precedence > > over examining the query section > > Defined where? I don't see anything like that in RFC 2308. EDNS is RFC 2671. If you don't support the EDNS version in the request you must send back BADVER. At that point trying to process the question section, whatever it is, is moot as the RCODE has already been set. > > as the EDNS version can influence the interpretion of the > > question section. > > Ditto. > > Just out of interest, are there any _existing_ legitimate circumstances where > QDCOUNT != 1 ? Seeing if a server is alive. Getting the EDNS UDP size prior to sending a UPDATE. Getting the EDNS version prior to anything. If I set qcount=2 with ./in/a and ./in/aaaa and edns=50 the correct rcode for a edns=0 server is BADVER. -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From Ray.Bellis@nominet.org.uk Sat Nov 12 06:12:06 2011 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6065A21F84B5 for ; Sat, 12 Nov 2011 06:12:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.606 X-Spam-Level: X-Spam-Status: No, score=-7.606 tagged_above=-999 required=5 tests=[AWL=-1.007, 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 6w647mg9igef for ; Sat, 12 Nov 2011 06:12:05 -0800 (PST) Received: from mx1.knowthenet.org.uk (mx1.knowthenet.org.uk [213.248.199.2]) by ietfa.amsl.com (Postfix) with ESMTP id 5A0F021F848E for ; Sat, 12 Nov 2011 06:12:05 -0800 (PST) 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: Content-ID:Content-Transfer-Encoding:MIME-Version; b=MafxN0OFxt+8CqhgPASeNEMXADMtxPcq+o+LgwdEWaUH2CDUDOs3Nkwt ZBDmGz1wkfRWS8A3zY4rTlbGQCJFyedMYPEMI7K38IvIkT3gpsMDF2BcW F6F09bKgyiQIWob; 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=1321107125; x=1352643125; 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]=20BADVER/FORMERR|Date:=20Sat, =2012=20Nov=202011=2014:11:54=20+0000|Message-ID:=20|To:=20Ma rk=20Andrews=20|CC:=20"dnsext@ietf.org"=20 |MIME-Version:=201.0 |Content-Transfer-Encoding:=20quoted-printable |Content-ID:=20<99a746b4-8f33-4a42-99cb-377bb799dab5> |In-Reply-To:=20<20111112084928.A6299171131B@drugs.dv.isc .org>|References:=20<20111111025007.B689B17061FA@drugs.dv .isc.org>=0D=0A=20<8B7F972437853B40865000D86857B1D118DC4B 13@wds-exc1.okna.nominet.org.uk>=0D=0A=20<20111112084928. A6299171131B@drugs.dv.isc.org>; bh=TDRLFQWdORrFGmstRe7XpuWS2jcm/ge7wpSy7RoHd48=; b=5MwYW+AXjXmUClcYyHmP+9gGq8QMEHXwHClOcnz+EqodYeZShHX6Qhgg JP8U70hYlUHjB0MsGCWvKVCyrKSQzmLBQY3Spgj8xCH3+4D5PwRaTJHFd weiaZlFBHpfMjig; X-IronPort-AV: E=Sophos;i="4.69,499,1315177200"; d="scan'208";a="36551071" Received: from wds-exc2.okna.nominet.org.uk ([213.248.197.145]) by mx3.nominet.org.uk with ESMTP; 12 Nov 2011 14:12:04 +0000 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; Sat, 12 Nov 2011 14:11:56 +0000 From: Ray Bellis To: Mark Andrews Thread-Topic: [dnsext] BADVER/FORMERR Thread-Index: AQHMoBzA5mAz8aYz4U6U8KCek//FTpWnnoCVgAFRcVqAAFnkAA== Date: Sat, 12 Nov 2011 14:11:54 +0000 Message-ID: References: <20111111025007.B689B17061FA@drugs.dv.isc.org> <8B7F972437853B40865000D86857B1D118DC4B13@wds-exc1.okna.nominet.org.uk> <20111112084928.A6299171131B@drugs.dv.isc.org> In-Reply-To: <20111112084928.A6299171131B@drugs.dv.isc.org> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-ID: <99a746b4-8f33-4a42-99cb-377bb799dab5> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "dnsext@ietf.org" Subject: Re: [dnsext] BADVER/FORMERR X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 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, 12 Nov 2011 14:12:06 -0000 On 12 Nov 2011, at 16:49, Mark Andrews wrote: >=20 > EDNS is RFC 2671. Yes, 2308 was a mistake. I did of course mean RFC 2671. > If you don't support the EDNS version in the > request you must send back BADVER. At that point trying to process > the question section, whatever it is, is moot as the RCODE has > already been set. Again, I ask, where is this defined? I can't see anything in _2671_ that says that processing of the EDNS versio= n number takes priority over any other input checking that might be perform= ed by a server. As far as I can see, the only pertinent text in 2671, and the (expired) 267= 1bis draft is this: "If a responder does not implement the VERSION level of the request, then i= t answers with RCODE=3DBADVERS" which doesn't even have a 2119-level compliance requirement word in it. >> Just out of interest, are there any _existing_ legitimate circumstances = where >> QDCOUNT !=3D 1 ? >=20 > Seeing if a server is alive. > Getting the EDNS UDP size prior to sending a UPDATE.=20 > Getting the EDNS version prior to anything. > If I set qcount=3D2 with ./in/a and ./in/aaaa and edns=3D50 the correct > rcode for a edns=3D0 server is BADVER. Why not something else? Because *BIND* doesn't do it that way? Ray From drc@virtualized.org Sat Nov 12 08:58:21 2011 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C919321F86FF for ; Sat, 12 Nov 2011 08:58:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kgVokB794byC for ; Sat, 12 Nov 2011 08:58:21 -0800 (PST) Received: from trantor.virtualized.org (trantor.virtualized.org [IPv6:2607:fc50:1000:9700::dead:beef]) by ietfa.amsl.com (Postfix) with ESMTP id 6C75B21F84B9 for ; Sat, 12 Nov 2011 08:58:21 -0800 (PST) Received: from [10.0.1.5] (c-24-4-109-25.hsd1.ca.comcast.net [24.4.109.25]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: drc) by trantor.virtualized.org (Postfix) with ESMTPSA id 0B81617069; Sat, 12 Nov 2011 16:58:18 +0000 (UTC) Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=us-ascii From: David Conrad In-Reply-To: Date: Sat, 12 Nov 2011 08:58:12 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <16A062CB-4297-45CF-9AEC-E48FEF87F3FF@virtualized.org> References: <20111111025007.B689B17061FA@drugs.dv.isc.org> <8B7F972437853B40865000D86857B1D118DC4B13@wds-exc1.okna.nominet.org.uk> <20111112084928.A6299171131B@drugs.dv.isc.org> To: Ray Bellis X-Mailer: Apple Mail (2.1251.1) Cc: "dnsext@ietf.org Group" Subject: Re: [dnsext] BADVER/FORMERR X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 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, 12 Nov 2011 16:58:21 -0000 Ray, On Nov 12, 2011, at 6:11 AM, Ray Bellis wrote: > "If a responder does not implement the VERSION level of the request, = then it answers with RCODE=3DBADVERS" > which doesn't even have a 2119-level compliance requirement word in = it. Is a 2119 word required? >> If I set qcount=3D2 with ./in/a and ./in/aaaa and edns=3D50 the = correct >> rcode for a edns=3D0 server is BADVER. >=20 > Why not something else? Because *BIND* doesn't do it that way? I suspect it is better to focus on what makes the most sense from a = protocol perspective rather than what particular implementations might = have done. Since EDNS is an extension mechanism and QDCOUNT was defined in the base = specification, it would seem to make sense to me to check EDNS version = before determining whether the QDCOUNT value makes sense (after all, a = future EDNS version could redefine the semantics of QDCOUNT). What would be your argument for the reverse? Regards, -drc From Ray.Bellis@nominet.org.uk Sat Nov 12 09:12: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 0614621F84BC for ; Sat, 12 Nov 2011 09:12:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.556 X-Spam-Level: X-Spam-Status: No, score=-7.556 tagged_above=-999 required=5 tests=[AWL=-0.957, 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 vBKk2gs4FSWX for ; Sat, 12 Nov 2011 09:12:00 -0800 (PST) Received: from mx1.knowthenet.org.uk (mx1.knowthenet.org.uk [213.248.199.2]) by ietfa.amsl.com (Postfix) with ESMTP id 1903021F84B5 for ; Sat, 12 Nov 2011 09:11:51 -0800 (PST) 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: Content-ID:Content-Transfer-Encoding:MIME-Version; b=vsPJuq3fCp+MAXLIbRUugnoi8+rOVFPe8pzRGDUcuwqClPmH4Mb+BPS9 rKHwbFll/n2DJuxYLugTrp7ofHf/wJH16h07luqRzrwvj8v/HzU7JlM/z UWqbsRG0Fluy50W; 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=1321117920; x=1352653920; 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]=20BADVER/FORMERR|Date:=20Sat, =2012=20Nov=202011=2017:11:45=20+0000|Message-ID:=20<78F6 51AF-4E8F-44E6-8666-A52EC85ECEAA@nominet.org.uk>|To:=20Da vid=20Conrad=20|CC:=20"dnsext@ietf.o rg=20Group"=20|MIME-Version:=201.0 |Content-Transfer-Encoding:=20quoted-printable |Content-ID:=20<9c15d0ca-968e-4c5d-be5a-7efde1e0acd6> |In-Reply-To:=20<16A062CB-4297-45CF-9AEC-E48FEF87F3FF@vir tualized.org>|References:=20<20111111025007.B689B17061FA@ drugs.dv.isc.org>=0D=0A=20<8B7F972437853B40865000D86857B1 D118DC4B13@wds-exc1.okna.nominet.org.uk>=0D=0A=20<2011111 2084928.A6299171131B@drugs.dv.isc.org>=0D=0A=20=0D=0A=20<16A0 62CB-4297-45CF-9AEC-E48FEF87F3FF@virtualized.org>; bh=KeXZ3pQa1Gb6+gPEwu6gORNN/yvXG15ZAARNiBQZGfc=; b=yQQW7YVYgls7lbmZotAqBHCfyIZCCQqK6FTqVpxktFCkEA8bI6PjD9zV 6i1HtkMtQI1vCtMezTpluj/yTLYaRIrMf2J9i8Izq+TDx2WZwjq9Ghi+C xcrR/CS8ZnRaMW7; X-IronPort-AV: E=Sophos;i="4.69,500,1315177200"; d="scan'208";a="36559452" Received: from wds-exc2.okna.nominet.org.uk ([213.248.197.145]) by mx3.nominet.org.uk with ESMTP; 12 Nov 2011 17:11:51 +0000 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; Sat, 12 Nov 2011 17:11:49 +0000 From: Ray Bellis To: David Conrad Thread-Topic: [dnsext] BADVER/FORMERR Thread-Index: AQHMoBzA5mAz8aYz4U6U8KCek//FTpWnnoCVgAFRcVqAAFnkAIAALncAgAADyYA= Date: Sat, 12 Nov 2011 17:11:45 +0000 Message-ID: <78F651AF-4E8F-44E6-8666-A52EC85ECEAA@nominet.org.uk> References: <20111111025007.B689B17061FA@drugs.dv.isc.org> <8B7F972437853B40865000D86857B1D118DC4B13@wds-exc1.okna.nominet.org.uk> <20111112084928.A6299171131B@drugs.dv.isc.org> <16A062CB-4297-45CF-9AEC-E48FEF87F3FF@virtualized.org> In-Reply-To: <16A062CB-4297-45CF-9AEC-E48FEF87F3FF@virtualized.org> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-ID: <9c15d0ca-968e-4c5d-be5a-7efde1e0acd6> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "dnsext@ietf.org Group" Subject: Re: [dnsext] BADVER/FORMERR X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 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, 12 Nov 2011 17:12:01 -0000 On 13 Nov 2011, at 00:58, David Conrad wrote: > What would be your argument for the reverse? Mark complained that two of the root servers gave "incorrect" answers when = sent unknown EDNS versions. I'm merely asking that he justify his assertion that EDNS version processin= g MUST take priority over anything else, because I don't see it in the stan= dards. >From a software implementation point of view it's _massively_ simpler and m= ore efficient to send back an immediate FORMERR if QDCOUNT !=3D 1 than it i= s to have to parse everything else up to and including the OPT RR (includin= g compression pointers) in order to give back a BADVERS error. Ray From ogud@ogud.com Sat Nov 12 11:01:24 2011 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 652FA21F893C for ; Sat, 12 Nov 2011 11:01:24 -0800 (PST) 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=[AWL=0.000, 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 3twRpc8sq3sK for ; Sat, 12 Nov 2011 11:01:24 -0800 (PST) Received: from stora.ogud.com (stora.ogud.com [66.92.146.20]) by ietfa.amsl.com (Postfix) with ESMTP id C1EC121F861E for ; Sat, 12 Nov 2011 11:01:23 -0800 (PST) Received: from [IPv6:::1] (nyttbox.md.ogud.com [10.20.30.4]) by stora.ogud.com (8.14.4/8.14.4) with ESMTP id pACJ1KgV017109 for ; Sat, 12 Nov 2011 14:01:22 -0500 (EST) (envelope-from ogud@ogud.com) Message-ID: <4EBEC277.7070306@ogud.com> Date: Sat, 12 Nov 2011 14:01:11 -0500 From: Olafur Gudmundsson User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: dnsext@ietf.org References: <20111111025007.B689B17061FA@drugs.dv.isc.org> In-Reply-To: <20111111025007.B689B17061FA@drugs.dv.isc.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.72 on 10.20.30.4 Subject: Re: [dnsext] BADVER/FORMERR X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 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, 12 Nov 2011 19:01:24 -0000 On 10/11/2011 21:50, Mark Andrews wrote: > > I was looking for a good way to test for EDNS support and hacked > dig to send out a empty question section when the EDNS version was > set to 255 and got what I believe to be incorrect responses from K > and L. EDNS version processing is supposed to take precedence over > examining the query section as the EDNS version can influence the > interpretion of the question section. I believe the correct response > should be BADVERS. Adding a question elicited BADVERS. > > Do others agree with my interpretion of rcode precedence? > Formerr is perfectly valid return code. It is the first error you detect and you can stop processing right then. (This assumes that the QR=0) Reasoning: You sent a question that is not a real question I see nothing in ENDS0 rfcs that say you need to look into the opt record if the DNS packet is malformed, QR=0 and QDCOUNT=0 is malformed packet IMHO. Olafur From marka@isc.org Sat Nov 12 14:14: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 42B7521F8663 for ; Sat, 12 Nov 2011 14:14:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.301 X-Spam-Level: X-Spam-Status: No, score=-2.301 tagged_above=-999 required=5 tests=[AWL=-0.302, BAYES_00=-2.599, J_CHICKENPOX_57=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 scIjddOpdKp1 for ; Sat, 12 Nov 2011 14:14:58 -0800 (PST) Received: from mx.ams1.isc.org (mx.ams1.isc.org [IPv6:2001:500:60::65]) by ietfa.amsl.com (Postfix) with ESMTP id 8D0A721F8593 for ; Sat, 12 Nov 2011 14:14:58 -0800 (PST) Received: from bikeshed.isc.org (bikeshed.isc.org [IPv6:2001:4f8:3:d::19]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "bikeshed.isc.org", Issuer "ISC CA" (verified OK)) by mx.ams1.isc.org (Postfix) with ESMTPS id 5AB625F984C; Sat, 12 Nov 2011 22:14:36 +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 03399216C85; Sat, 12 Nov 2011 22:14:05 +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 861341712639; Sun, 13 Nov 2011 09:14:05 +1100 (EST) To: Olafur Gudmundsson From: Mark Andrews References: <20111111025007.B689B17061FA@drugs.dv.isc.org> <4EBEC277.7070306@ogud.com> In-reply-to: Your message of "Sat, 12 Nov 2011 14:01:11 CDT." <4EBEC277.7070306@ogud.com> Date: Sun, 13 Nov 2011 09:14:05 +1100 Message-Id: <20111112221405.861341712639@drugs.dv.isc.org> Cc: dnsext@ietf.org Subject: Re: [dnsext] BADVER/FORMERR X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 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, 12 Nov 2011 22:14:59 -0000 In message <4EBEC277.7070306@ogud.com>, Olafur Gudmundsson writes: > On 10/11/2011 21:50, Mark Andrews wrote: > > > > I was looking for a good way to test for EDNS support and hacked > > dig to send out a empty question section when the EDNS version was > > set to 255 and got what I believe to be incorrect responses from K > > and L. EDNS version processing is supposed to take precedence over > > examining the query section as the EDNS version can influence the > > interpretion of the question section. I believe the correct response > > should be BADVERS. Adding a question elicited BADVERS. > > > > Do others agree with my interpretion of rcode precedence? > > > > > Formerr is perfectly valid return code. > It is the first error you detect and you can stop processing > right then. > (This assumes that the QR=0) > > Reasoning: You sent a question that is not a real question > I see nothing in ENDS0 rfcs that say you need to look into the > opt record if the DNS packet is malformed, QR=0 and QDCOUNT=0 > is malformed packet IMHO. Even if FORMERR is returned, the response is also missing the OPT record which is required to be sent by EDNS aware servers. If you can't parse the packet to get to the OPT record then a 12 octet FORMERR is appropriate. This packet is parsable. VERSION Indicates the implementation level of whoever sets it. Full conformance with this specification is indicated by version "0." Requestors are encouraged to set this to the lowest implemented level capable of expressing a transaction, to minimize the responder and network load of discovering the greatest common implementation level between requestor and responder. A requestor's version numbering strategy should ideally be a run time configuration option. If a responder does not implement the VERSION level of the request, then it answers with RCODE=BADVERS. All responses will be limited in format to the VERSION level of the request, but the VERSION of each response will be the highest implementation level of the responder. In this way a requestor will learn the implementation level of a responder as a side effect of every response, including error responses, including RCODE=BADVERS. > Olafur > _______________________________________________ > 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 ogud@ogud.com Sat Nov 12 19:58: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 2B1F321F84D4 for ; Sat, 12 Nov 2011 19:58:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.299 X-Spam-Level: X-Spam-Status: No, score=-106.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_57=0.6, 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 mWsh-oNkZl5E for ; Sat, 12 Nov 2011 19:58:14 -0800 (PST) Received: from stora.ogud.com (stora.ogud.com [66.92.146.20]) by ietfa.amsl.com (Postfix) with ESMTP id 608C01F0C3F for ; Sat, 12 Nov 2011 19:58:14 -0800 (PST) Received: from [IPv6:::1] (nyttbox.md.ogud.com [10.20.30.4]) by stora.ogud.com (8.14.4/8.14.4) with ESMTP id pAD3w9g4019949; Sat, 12 Nov 2011 22:58:10 -0500 (EST) (envelope-from ogud@ogud.com) Message-ID: <4EBF4046.5070708@ogud.com> Date: Sat, 12 Nov 2011 22:57:58 -0500 From: Olafur Gudmundsson User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: Mark Andrews References: <20111111025007.B689B17061FA@drugs.dv.isc.org> <4EBEC277.7070306@ogud.com> <20111112221405.861341712639@drugs.dv.isc.org> In-Reply-To: <20111112221405.861341712639@drugs.dv.isc.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.72 on 10.20.30.4 Cc: dnsext@ietf.org Subject: Re: [dnsext] BADVER/FORMERR X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 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, 13 Nov 2011 03:58:15 -0000 On 12/11/2011 17:14, Mark Andrews wrote: > In message<4EBEC277.7070306@ogud.com>, Olafur Gudmundsson writes: >> On 10/11/2011 21:50, Mark Andrews wrote: >>> >>> I was looking for a good way to test for EDNS support and hacked >>> dig to send out a empty question section when the EDNS version was >>> set to 255 and got what I believe to be incorrect responses from K >>> and L. EDNS version processing is supposed to take precedence over >>> examining the query section as the EDNS version can influence the >>> interpretion of the question section. I believe the correct response >>> should be BADVERS. Adding a question elicited BADVERS. >>> >>> Do others agree with my interpretion of rcode precedence? >>> >> >> >> Formerr is perfectly valid return code. >> It is the first error you detect and you can stop processing >> right then. >> (This assumes that the QR=0) >> >> Reasoning: You sent a question that is not a real question >> I see nothing in ENDS0 rfcs that say you need to look into the >> opt record if the DNS packet is malformed, QR=0 and QDCOUNT=0 >> is malformed packet IMHO. > > Even if FORMERR is returned, the response is also missing the OPT > record which is required to be sent by EDNS aware servers. If you > can't parse the packet to get to the OPT record then a 12 octet > FORMERR is appropriate. This packet is parsable. > > VERSION Indicates the implementation level of whoever sets > it. Full conformance with this specification is > indicated by version "0." Requestors are encouraged > to set this to the lowest implemented level capable > of expressing a transaction, to minimize the > responder and network load of discovering the > greatest common implementation level between > requestor and responder. A requestor's version > numbering strategy should ideally be a run time > configuration option. > > If a responder does not implement the VERSION level > of the request, then it answers with RCODE=BADVERS. > All responses will be limited in format to the > VERSION level of the request, but the VERSION of each > response will be the highest implementation level of > the responder. In this way a requestor will learn > the implementation level of a responder as a side > effect of every response, including error responses, > including RCODE=BADVERS. > #1 I can reason that it is OK to stop parsing a packet after an format error is detected . The text above does not clearly support your interpretation nor mine. (I might even be tempted to say, randomly dropping the packet is also acceptable). Sending Refused is also in contention, but not helpful. #2 From your original message you seemed to be asking about the error code, not if the missing OPT record was appropriate. Strictly speaking given how narrow the error reporting channel in DNS is either interpretation is acceptable i.e. First Error detected or Most Significant error, responders should be ready to handle both. But at the same time I understand your desire to have an easy way to detect the ENDS0 version. Olafur From matthijs@nlnetlabs.nl Mon Nov 14 02:42:46 2011 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A61411E8157 for ; Mon, 14 Nov 2011 02:42:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lsVIHpfNgWnX for ; Mon, 14 Nov 2011 02:42:46 -0800 (PST) Received: from open.nlnetlabs.nl (open.nlnetlabs.nl [IPv6:2001:7b8:206:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id A429711E8162 for ; Mon, 14 Nov 2011 02:42:45 -0800 (PST) Received: from [IPv6:2001:7b8:206:1:219:d1ff:feb1:85e8] (zoidberg.nlnetlabs.nl [IPv6:2001:7b8:206:1:219:d1ff:feb1:85e8]) (authenticated bits=0) by open.nlnetlabs.nl (8.14.4/8.14.4) with ESMTP id pAEAghTF028758; Mon, 14 Nov 2011 11:42:44 +0100 (CET) (envelope-from matthijs@nlnetlabs.nl) Message-ID: <4EC0F0A3.1090501@nlnetlabs.nl> Date: Mon, 14 Nov 2011 11:42:43 +0100 From: Matthijs Mekking User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.23) Gecko/20110922 Thunderbird/3.1.15 MIME-Version: 1.0 To: Mark Andrews References: <20111104231715.AA38F16AD6F6@drugs.dv.isc.org> In-Reply-To: <20111104231715.AA38F16AD6F6@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, 14 Nov 2011 11:42:44 +0100 (CET) Cc: Edward Lewis , dnsext@ietf.org Subject: Re: [dnsext] CNAME/DNAME and NXDOMAIN X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Nov 2011 10:42:46 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 11/05/2011 12:17 AM, Mark Andrews wrote: > > Both answers are self consistant and neither should cause a problem. > > Following CNAME records, when not recursing for the client, is a > security issue as the target of the CNAME may not be delegated to > the same machine leading to potential, accidental, cache poisioning. An authoritative server should follow CNAME records while the target is actually being served. If it is delegated to another machine, you return the chain of CNAMEs until then. The recursive name server can continue recursing. > We (ISC) have looked at not following CNAME records when generating > such replies. We already discard the rest of the response and > requery for the target of the CNAME. So you would query the same machine, despite that server is giving you a chain? Refocusing on Ed Lewis initial question, regarding the RCODE. One server is giving NXDOMAIN, the other NOERROR. Given the fact that CNAME records where followed, the status code should not be switched to NXDOMAIN. This is conform the server algorithm in RFC2672. Also, it was questioned if this should be changed in the dname-bis document: http://www.ietf.org/mail-archive/web/dnsext/current/msg09224.html Although the response was minimal, the suggestion was to make no change. For NSD, because it is not considered an NXDOMAIN response (following step 3c of the server algorithm), the SOA record is not added to the Authority Section. Though, the target does not exist, so the NSEC3 records are still added. I don't know if adding the NSEC3 records is the right thing to do, I seem to be unable to find the text what to do in this specific case. Although, both NSD and BIND seem to be in some sort of agreement that the records are needed. Best regards, Matthijs -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJOwPCjAAoJEA8yVCPsQCW5PjwIAKB5FYDCBkGgml/o2EoKyxDw KY4cSquPk2u7JAN3GBW3Q5v2xU+6vATg/JrYjDmKjTH+IElT2lmoNVKRNe5C42/i 4UvoyIwMgF9LIVp0pnaPLE1RaGyCurqVkQiFZ7OqNtmB5rLzncXMYAtc2fKQfnYQ oiNsjaKGHoVcJAmYBQHQ26Y+FwL8kD8PELVBU666jkOJQp2S1xQhqxgzfzOswUtS 7cXkob79yTC4BgB/Fqmdfyt326In+jstpfYE3vAnmfpvaKzOYYp7pnX56k54YC7x 39sZoum9njlxSShLTCEWGR7eUL7TlyZIVgwWh7xUE01hUwDxbk/uazTLZAZC2xQ= =2W0Q -----END PGP SIGNATURE----- From marc.lampo@eurid.eu Mon Nov 14 05:56: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 93A8111E8190 for ; Mon, 14 Nov 2011 05:56:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.15 X-Spam-Level: X-Spam-Status: No, score=-9.15 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MSGID_MULTIPLE_AT=1.449, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aRygm7cvmqE5 for ; Mon, 14 Nov 2011 05:56:48 -0800 (PST) Received: from barra.eurid.eu (mx.eurid.eu [212.190.206.103]) by ietfa.amsl.com (Postfix) with ESMTP id 8BEC911E818C for ; Mon, 14 Nov 2011 05:56:46 -0800 (PST) X-ASG-Debug-ID: 1321279002-03694975c2be820001-uIE7UK Received: from zimbra.eurid.eu (zcs-master.vt.eurid.eu [10.19.100.121]) by barra.eurid.eu with ESMTP id ZdEHoiXiBvTKdj55; Mon, 14 Nov 2011 14:56:42 +0100 (CET) X-Barracuda-Envelope-From: marc.lampo@eurid.eu X-ASG-Whitelist: Client Received: from localhost (localhost.localdomain [127.0.0.1]) by zimbra.eurid.eu (Postfix) with ESMTP id 960AEE4062; Mon, 14 Nov 2011 14:56:42 +0100 (CET) X-Virus-Scanned: amavisd-new at techmail.eurid.eu Received: from zimbra.eurid.eu ([127.0.0.1]) by localhost (zimbra.eurid.eu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IVH+8m0tfy7K; Mon, 14 Nov 2011 14:56:42 +0100 (CET) Received: from zimbra.eurid.eu (zimbra.eurid.eu [10.19.100.120]) by zimbra.eurid.eu (Postfix) with ESMTP id 83FFBE4050; Mon, 14 Nov 2011 14:56:42 +0100 (CET) From: "Marc Lampo" To: "'Mark Andrews'" , References: <20111111025007.B689B17061FA@drugs.dv.isc.org> In-Reply-To: <20111111025007.B689B17061FA@drugs.dv.isc.org> Date: Mon, 14 Nov 2011 14:56:42 +0100 (CET) X-ASG-Orig-Subj: RE: [dnsext] BADVER/FORMERR Message-ID: <026401cca2d5$3d91a270$b8b4e750$@lampo@eurid.eu> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 X-Mailer: Zimbra 6.0.14_GA_2928 (ZimbraConnectorForOutlook/5.0.3064.18) Thread-Index: AcygHJ7CKGisjtstS3+MeMi9nXBecgCtst7w Content-Language: en-za X-Originating-IP: [172.20.5.51] X-Barracuda-Connect: zcs-master.vt.eurid.eu[10.19.100.121] X-Barracuda-Start-Time: 1321279002 X-Barracuda-URL: http://172.20.1.190:8000/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at eurid.eu Subject: Re: [dnsext] BADVER/FORMERR X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Nov 2011 13:56:48 -0000 Hello Mark, Interesting path you are following ... >From my position (in the Internet with respect to anycast servers), I get answers you consider not correct from All of a, h, k and l root-servers.net. Additionally, when I query a.root-servers.net. with QDCOUNT == 1, the rcode becomes indeed BADVERS (extended : value 16), but amazingly the name servers additionally sets the lowest bit in the flags : "non-authenticaded data: Acceptable" (that's the CD bit, if I'm not mistaken). The problem seems to be : "which error precedes which error ?" (as there is only one possibility for "rcode" in the packet) So, first detect the QDCOUNT == 0 and return FORMERR because of that, or, also detect that EDNS type is 255, so : undefined and return BADVERS because of that. But what I fail to see is : why send EDNS with value 255 ? Why not simply a regular EDNS0 ? Because in that case (only one error), the authoritative name server can always add EDNS0 in its reply with the UDP payload (you are interested in in the first place). We don't *have* to send an EDNS with bad version number in order to obtain the information ? Or do you want to *force* EDNS0 in the reply by sending a query that results in a Returncode >15 so that EDNS0 is needed to get that returncode back ? Kind regards, Marc -----Original Message----- From: Mark Andrews [mailto:marka@isc.org] Sent: 11 November 2011 03:50 AM To: dnsext@ietf.org Subject: [dnsext] BADVER/FORMERR I was looking for a good way to test for EDNS support and hacked dig to send out a empty question section when the EDNS version was set to 255 and got what I believe to be incorrect responses from K and L. EDNS version processing is supposed to take precedence over examining the query section as the EDNS version can influence the interpretion of the question section. I believe the correct response should be BADVERS. Adding a question elicited BADVERS. Do others agree with my interpretion of rcode precedence? Mark marka% bin/dig/dig +edns=255 +norec @k.root-servers.net ; <<>> DiG 9.9.0b1 <<>> +edns=255 +norec @k.root-servers.net ; (2 servers found) ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: FORMERR, id: 40361 ;; flags: qr; QUERY: 0, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0 ;; Query time: 255 msec ;; SERVER: 2001:7fd::1#53(2001:7fd::1) ;; WHEN: Fri Nov 11 13:34:50 2011 ;; MSG SIZE rcvd: 12 marka% bin/dig/dig +edns=255 +norec @l.root-servers.net ; <<>> DiG 9.9.0b1 <<>> +edns=255 +norec @l.root-servers.net ; (2 servers found) ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: FORMERR, id: 34663 ;; flags: qr; QUERY: 0, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0 ;; Query time: 175 msec ;; SERVER: 2001:500:3::42#53(2001:500:3::42) ;; WHEN: Fri Nov 11 13:35:08 2011 ;; MSG SIZE rcvd: 12 -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From internet-drafts@ietf.org Mon Nov 14 06:50: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 AB98811E82A7; Mon, 14 Nov 2011 06:50:17 -0800 (PST) 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 kAqpObwFnLHL; Mon, 14 Nov 2011 06:50:16 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B17711E82A3; Mon, 14 Nov 2011 06:50:16 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.63 Message-ID: <20111114145016.8235.28459.idtracker@ietfa.amsl.com> Date: Mon, 14 Nov 2011 06:50:16 -0800 Cc: dnsext@ietf.org Subject: [dnsext] I-D Action: draft-ietf-dnsext-rfc2672bis-dname-25.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, 14 Nov 2011 14:50:17 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the DNS Extensions Working Group of the I= ETF. Title : DNAME Redirection in the DNS Author(s) : Scott Rose Wouter Wijngaards Filename : draft-ietf-dnsext-rfc2672bis-dname-25.txt Pages : 22 Date : 2011-11-14 The DNAME record provides redirection for a sub-tree of the domain name tree in the DNS system. That is, all names that end with a particular suffix are redirected to another part of the DNS. This is a revision to the original specification in RFC 2672 (which this document obsoletes) as well as updating RFC 3363 and RFC 4294 to align with this revision. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dnsext-rfc2672bis-dname-25.t= xt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-dnsext-rfc2672bis-dname-25.txt From scottr.nist@gmail.com Mon Nov 14 06:57: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 DBDFD1F0C42 for ; Mon, 14 Nov 2011 06:57:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZAkDCzgTQCph for ; Mon, 14 Nov 2011 06:57:33 -0800 (PST) Received: from smtp.nist.gov (rimp2.nist.gov [129.6.16.227]) by ietfa.amsl.com (Postfix) with ESMTP id 4FEAD1F0C34 for ; Mon, 14 Nov 2011 06:57:33 -0800 (PST) Received: from 107-140.antd.nist.gov (107-140.antd.nist.gov [129.6.140.107]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id pAEEvIuj031459 for ; Mon, 14 Nov 2011 09:57:19 -0500 From: Scott Rose Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Mon, 14 Nov 2011 09:57:18 -0500 References: <20111114145016.8235.28459.idtracker@ietfa.amsl.com> To: DNSEXT Working Group Message-Id: <0EB23916-DEDA-4899-8ECE-E89F4DEBBF80@gmail.com> Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: scottr.nist@gmail.com Subject: [dnsext] Fwd: I-D Action: draft-ietf-dnsext-rfc2672bis-dname-25.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, 14 Nov 2011 14:57:34 -0000 This revised version was to address comments made during the AD review. = Mostly some wording changes, but there is also a new appendix section = with major changes from RFC 2672 and this document. Scott Begin forwarded message: > From: internet-drafts@ietf.org > Date: November 14, 2011 9:50:16 AM EST > To: i-d-announce@ietf.org > Cc: dnsext@ietf.org > Subject: [dnsext] I-D Action: = draft-ietf-dnsext-rfc2672bis-dname-25.txt >=20 > A New Internet-Draft is available from the on-line Internet-Drafts = directories. This draft is a work item of the DNS Extensions Working = Group of the IETF. >=20 > Title : DNAME Redirection in the DNS > Author(s) : Scott Rose > Wouter Wijngaards > Filename : draft-ietf-dnsext-rfc2672bis-dname-25.txt > Pages : 22 > Date : 2011-11-14 >=20 > The DNAME record provides redirection for a sub-tree of the domain > name tree in the DNS system. That is, all names that end with a > particular suffix are redirected to another part of the DNS. This = is > a revision to the original specification in RFC 2672 (which this > document obsoletes) as well as updating RFC 3363 and RFC 4294 to > align with this revision. >=20 >=20 >=20 > A URL for this Internet-Draft is: > = http://www.ietf.org/internet-drafts/draft-ietf-dnsext-rfc2672bis-dname-25.= txt >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > This Internet-Draft can be retrieved at: > = ftp://ftp.ietf.org/internet-drafts/draft-ietf-dnsext-rfc2672bis-dname-25.t= xt > _______________________________________________ > dnsext mailing list > dnsext@ietf.org > https://www.ietf.org/mailman/listinfo/dnsext From each@isc.org Mon Nov 14 11:06:31 2011 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7DEC711E834F for ; Mon, 14 Nov 2011 11:06:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r2RiE+6asmH4 for ; Mon, 14 Nov 2011 11:06:31 -0800 (PST) Received: from mx.ams1.isc.org (mx.ams1.isc.org [IPv6:2001:500:60::65]) by ietfa.amsl.com (Postfix) with ESMTP id 81E3E11E834D for ; Mon, 14 Nov 2011 11:06:29 -0800 (PST) Received: from bikeshed.isc.org (bikeshed.isc.org [IPv6:2001:4f8:3:d::19]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "bikeshed.isc.org", Issuer "ISC CA" (verified OK)) by mx.ams1.isc.org (Postfix) with ESMTPS id 1CAEB5F98B7; Mon, 14 Nov 2011 19:06:07 +0000 (UTC) (envelope-from each@isc.org) Received: by bikeshed.isc.org (Postfix, from userid 10292) id 2F980216C71; Mon, 14 Nov 2011 19:06:06 +0000 (UTC) Date: Mon, 14 Nov 2011 19:06:06 +0000 From: Evan Hunt To: Matthijs Mekking Message-ID: <20111114190606.GA7540@isc.org> References: <20111104231715.AA38F16AD6F6@drugs.dv.isc.org> <4EC0F0A3.1090501@nlnetlabs.nl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4EC0F0A3.1090501@nlnetlabs.nl> User-Agent: Mutt/1.4.2.3i Cc: Edward Lewis , dnsext@ietf.org Subject: Re: [dnsext] CNAME/DNAME and NXDOMAIN X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Nov 2011 19:06:31 -0000 > > We (ISC) have looked at not following CNAME records when generating > > such replies. We already discard the rest of the response and > > requery for the target of the CNAME. > > So you would query the same machine, despite that server is giving you a > chain? A server may claim, through misconfiguration or malice, to be authoritative for the target of a CNAME when it isn't. For example, suppose 'cname.example.com' points to 'target.example.com', but 'target.example.com' is actually a zone cut and is delegated to some other server entirely. The only way to find out is to with a followup query. -- Evan Hunt -- each@isc.org Internet Systems Consortium, Inc. From nweaver@icsi.berkeley.edu Mon Nov 14 11:17: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 BEA6F11E836F for ; Mon, 14 Nov 2011 11:17:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.534 X-Spam-Level: X-Spam-Status: No, score=-2.534 tagged_above=-999 required=5 tests=[AWL=0.065, 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 VYHGHlr318fd for ; Mon, 14 Nov 2011 11:17:50 -0800 (PST) Received: from rock.ICSI.Berkeley.EDU (rock.ICSI.Berkeley.EDU [192.150.186.19]) by ietfa.amsl.com (Postfix) with ESMTP id 1161F11E836B for ; Mon, 14 Nov 2011 11:17:50 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by rock.ICSI.Berkeley.EDU (Postfix) with ESMTP id E14FD2C4026; Mon, 14 Nov 2011 11:17:49 -0800 (PST) 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 MKJF6KlVHRBB; Mon, 14 Nov 2011 11:17:49 -0800 (PST) Received: from gala.icir.org (gala [192.150.187.49]) (Authenticated sender: nweaver) by rock.ICSI.Berkeley.EDU (Postfix) with ESMTP id 4C6012C4002; Mon, 14 Nov 2011 11:17:49 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=us-ascii From: Nicholas Weaver In-Reply-To: <20111114190606.GA7540@isc.org> Date: Mon, 14 Nov 2011 11:17:49 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <35209477-7CA0-4459-BDF1-8917536A6077@icsi.berkeley.edu> References: <20111104231715.AA38F16AD6F6@drugs.dv.isc.org> <4EC0F0A3.1090501@nlnetlabs.nl> <20111114190606.GA7540@isc.org> To: Evan Hunt X-Mailer: Apple Mail (2.1251.1) Cc: Edward Lewis , dnsext@ietf.org Subject: Re: [dnsext] CNAME/DNAME and NXDOMAIN X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Nov 2011 19:17:50 -0000 On Nov 14, 2011, at 11:06 AM, Evan Hunt wrote: >>> We (ISC) have looked at not following CNAME records when generating >>> such replies. We already discard the rest of the response and >>> requery for the target of the CNAME. >>=20 >> So you would query the same machine, despite that server is giving = you a >> chain? >=20 > A server may claim, through misconfiguration or malice, to > be authoritative for the target of a CNAME when it isn't. > For example, suppose 'cname.example.com' points to > 'target.example.com', but 'target.example.com' is actually a > zone cut and is delegated to some other server entirely. The > only way to find out is to with a followup query. There's three main themes we've seen with netalyzr: a) Requery regardless b) Accept when the name is internal or equal (eg, the system is = authoritative for foo.com, and the cname refers to = anything.{optional}.foo.com) c) Accept when the server has already been identified as the authority = for the target domain (eg, the system is authoritative for foo.com AND = bar.com, the resolver knows this by previous queries, and the CNAME is = in the form example.foo.com CNAME example.bar.com, example.bar.com A = 1.2.3.4). Notably Google Public DNS does C. From marka@isc.org Mon Nov 14 14:23: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 12DDF11E82AC for ; Mon, 14 Nov 2011 14:23:33 -0800 (PST) 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.104, 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 ayAEKYy1kzmD for ; Mon, 14 Nov 2011 14:23:32 -0800 (PST) Received: from mx.ams1.isc.org (mx.ams1.isc.org [IPv6:2001:500:60::65]) by ietfa.amsl.com (Postfix) with ESMTP id 6951611E820F for ; Mon, 14 Nov 2011 14:23:30 -0800 (PST) Received: from bikeshed.isc.org (bikeshed.isc.org [IPv6:2001:4f8:3:d::19]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "bikeshed.isc.org", Issuer "ISC CA" (verified OK)) by mx.ams1.isc.org (Postfix) with ESMTPS id 526975F98A2; Mon, 14 Nov 2011 22:23: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 08722216C6B; Mon, 14 Nov 2011 22:23: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 F0159171B01D; Tue, 15 Nov 2011 09:23:02 +1100 (EST) To: "Marc Lampo" From: Mark Andrews References: <20111111025007.B689B17061FA@drugs.dv.isc.org> <026401cca2d5$3d91a270$b8b4e750$@lampo@eurid.eu> In-reply-to: Your message of "Mon, 14 Nov 2011 14:56:42 BST." <026401cca2d5$3d91a270$b8b4e750$@lampo@eurid.eu> Date: Tue, 15 Nov 2011 09:23:02 +1100 Message-Id: <20111114222302.F0159171B01D@drugs.dv.isc.org> Cc: dnsext@ietf.org Subject: Re: [dnsext] BADVER/FORMERR X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Nov 2011 22:23:33 -0000 In message <026401cca2d5$3d91a270$b8b4e750$@lampo@eurid.eu>, "Marc Lampo" writes: > Hello Mark, > > Interesting path you are following ... > > >From my position (in the Internet with respect to anycast servers), > I get answers you consider not correct from > All of a, h, k and l root-servers.net. > > Additionally, when I query a.root-servers.net. with QDCOUNT == 1, > the rcode becomes indeed BADVERS (extended : value 16), > but amazingly the name servers additionally sets the lowest bit in the > flags : > "non-authenticaded data: Acceptable" (that's the CD bit, if I'm not > mistaken). > > The problem seems to be : "which error precedes which error ?" > (as there is only one possibility for "rcode" in the packet) > So, first detect the QDCOUNT == 0 and return FORMERR because of that, > or, also detect that EDNS type is 255, so : undefined and return BADVERS > because of that. 255 is reserved not wrong. > But what I fail to see is : why send EDNS with value 255 ? I want to send a query which will force the EDNS version on the OPT record to be *changed* by the server at the remote end. There are too many nameservers out there that don't understand EDNS yet still return OPT records from the query. You can see them by changing the EDNS UDP size and seeing the change reflected back to you. I'm also looking to do this with smallest sized packets that I can. > Why not simply a regular EDNS0 ? > Because in that case (only one error), > the authoritative name server can always add EDNS0 in its reply with the > UDP payload > (you are interested in in the first place). > We don't *have* to send an EDNS with bad version number in order to obtain > the information ? > Or do you want to *force* EDNS0 in the reply by sending a query > that results in a Returncode >15 so that EDNS0 is needed to get that > returncode back ? > > > Kind regards, > > Marc > > > -----Original Message----- > From: Mark Andrews [mailto:marka@isc.org] > Sent: 11 November 2011 03:50 AM > To: dnsext@ietf.org > Subject: [dnsext] BADVER/FORMERR > > > I was looking for a good way to test for EDNS support and hacked > dig to send out a empty question section when the EDNS version was > set to 255 and got what I believe to be incorrect responses from K > and L. EDNS version processing is supposed to take precedence over > examining the query section as the EDNS version can influence the > interpretion of the question section. I believe the correct response > should be BADVERS. Adding a question elicited BADVERS. > > Do others agree with my interpretion of rcode precedence? > > Mark > > marka% bin/dig/dig +edns=255 +norec @k.root-servers.net > > ; <<>> DiG 9.9.0b1 <<>> +edns=255 +norec @k.root-servers.net > ; (2 servers found) > ;; global options: +cmd > ;; Got answer: > ;; ->>HEADER<<- opcode: QUERY, status: FORMERR, id: 40361 > ;; flags: qr; QUERY: 0, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0 > > ;; Query time: 255 msec > ;; SERVER: 2001:7fd::1#53(2001:7fd::1) > ;; WHEN: Fri Nov 11 13:34:50 2011 > ;; MSG SIZE rcvd: 12 > > marka% bin/dig/dig +edns=255 +norec @l.root-servers.net > > ; <<>> DiG 9.9.0b1 <<>> +edns=255 +norec @l.root-servers.net > ; (2 servers found) > ;; global options: +cmd > ;; Got answer: > ;; ->>HEADER<<- opcode: QUERY, status: FORMERR, id: 34663 > ;; flags: qr; QUERY: 0, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0 > > ;; Query time: 175 msec > ;; SERVER: 2001:500:3::42#53(2001:500:3::42) > ;; WHEN: Fri Nov 11 13:35:08 2011 > ;; MSG SIZE rcvd: 12 > > -- > Mark Andrews, ISC > 1 Seymour St., Dundas Valley, NSW 2117, Australia > PHONE: +61 2 9871 4742 INTERNET: marka@isc.org > -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From rwfranks@gmail.com Mon Nov 14 20:35: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 4C1F911E8191 for ; Mon, 14 Nov 2011 20:35:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.977 X-Spam-Level: X-Spam-Status: No, score=-102.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kesgBqDVxG9P for ; Mon, 14 Nov 2011 20:35:09 -0800 (PST) Received: from mail-gx0-f172.google.com (mail-gx0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id A047211E8160 for ; Mon, 14 Nov 2011 20:35:09 -0800 (PST) Received: by ggnr5 with SMTP id r5so1954855ggn.31 for ; Mon, 14 Nov 2011 20:35:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type; bh=CxMXf0t1QIdjXYujAcx3Fv3oztbR6kwS6TH+rvHyy20=; b=Qtj4vT8TrhgC0jwYh8iWgwDiq3+obmcEhb5QN3TqBSK1hYtRClcrgIEOLbEo7tIRIj mme4W46ULnyHxegquxabq2/Pbg91LP6wW/+MVBySCSLIPuin2x4KgFeuyZxd8F1BWOeX batofChOS4GqBfDFxebecDPm+AHYvSXOqYdrk= Received: by 10.182.2.225 with SMTP id 1mr5731265obx.30.1321331709096; Mon, 14 Nov 2011 20:35:09 -0800 (PST) MIME-Version: 1.0 Sender: rwfranks@gmail.com Received: by 10.182.216.69 with HTTP; Mon, 14 Nov 2011 20:34:48 -0800 (PST) In-Reply-To: <20111114222302.F0159171B01D@drugs.dv.isc.org> References: <20111111025007.B689B17061FA@drugs.dv.isc.org> <20111114222302.F0159171B01D@drugs.dv.isc.org> From: Dick Franks Date: Tue, 15 Nov 2011 04:34:48 +0000 X-Google-Sender-Auth: 0dkGPvKy63keLU8PoDbTey77OeU Message-ID: To: Mark Andrews Content-Type: text/plain; charset=UTF-8 Cc: Marc Lampo , dnsext@ietf.org Subject: Re: [dnsext] BADVER/FORMERR X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 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, 15 Nov 2011 04:35:10 -0000 IMHO, we should consider separately whether FORMERR is a proper response to a query with zero QDCOUNT. The text of RFC1035 (4.1.2) describes the question section thus: The question section is used to carry the "question" in most queries, i.e., the parameters that define what is being asked. The section contains QDCOUNT (usually 1) entries, each of the following format ... This certainly does not exclude the possibility of an empty question section in a query packet and hence there is no justification for responding with FORMERR. No additional legislation should be necessary; implementations which return FORMERR in response to zero QDCOUNT are non-compliant with RFC1035. Client-side code which relies upon such behaviour is similarly non-compliant. --Dick From Ray.Bellis@nominet.org.uk Mon Nov 14 21:56: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 3E62411E811B for ; Mon, 14 Nov 2011 21:56:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.566 X-Spam-Level: X-Spam-Status: No, score=-7.566 tagged_above=-999 required=5 tests=[AWL=-0.967, 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 1rMSgzHaMOQ9 for ; Mon, 14 Nov 2011 21:56:00 -0800 (PST) Received: from mx1.knowthenet.org.uk (mx1.knowthenet.org.uk [213.248.199.2]) by ietfa.amsl.com (Postfix) with ESMTP id D6D1711E8085 for ; Mon, 14 Nov 2011 21:55:59 -0800 (PST) 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: Content-ID:Content-Transfer-Encoding:MIME-Version; b=L75+Jo5pnfPJ6z3csh6J6F7N502oKmpA0NoVvU2fzygd6HPe3bbyL03c xXfXpI1p3tClh+18jB+Gnl09lPWtAp/j1ehTnkLIQgCHxsx4aqPUyQqGb oPJi1AZFJ4PVfXP; 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=1321336560; x=1352872560; 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]=20BADVER/FORMERR|Date:=20Tue, =2015=20Nov=202011=2005:55:57=20+0000|Message-ID:=20|To:=20Di ck=20Franks=20|CC:=20"dnsext@ietf.org =20Group"=20|MIME-Version:=201.0 |Content-Transfer-Encoding:=20quoted-printable |Content-ID:=20 |In-Reply-To:=20|References:=20<20111111025007 .B689B17061FA@drugs.dv.isc.org>=0D=0A=20<20111114222302.F 0159171B01D@drugs.dv.isc.org>=0D=0A=20; bh=wi442ha4GHVARHII6EKBXK6cqlEKCkYn7LyYcwwReoY=; b=uHD+9Dj/I27+26qZ/d18SKNqIHJ7e7rUGQqs5WDsKSSWiQFYyRlxFoqU 9IfMRKIlxf4ZIhVBNBYo7jJhqscJ2b53wM3viRWcCHa9T1NRM3PhJtsZX RiM6kRFypNjp9Y/; X-IronPort-AV: E=Sophos;i="4.69,513,1315177200"; d="scan'208";a="36611886" Received: from wds-exc2.okna.nominet.org.uk ([213.248.197.145]) by mx3.nominet.org.uk with ESMTP; 15 Nov 2011 05:55:58 +0000 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, 15 Nov 2011 05:55:57 +0000 From: Ray Bellis To: Dick Franks Thread-Topic: [dnsext] BADVER/FORMERR Thread-Index: AQHMoxv45mAz8aYz4U6U8KCek//FTpWtWZgAgAAWrIA= Date: Tue, 15 Nov 2011 05:55:57 +0000 Message-ID: References: <20111111025007.B689B17061FA@drugs.dv.isc.org> <20111114222302.F0159171B01D@drugs.dv.isc.org> In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "dnsext@ietf.org Group" Subject: Re: [dnsext] BADVER/FORMERR X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 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, 15 Nov 2011 05:56:01 -0000 On 15 Nov 2011, at 12:34, Dick Franks wrote: > IMHO, we should consider separately whether FORMERR is a proper > response to a query with zero QDCOUNT. or _anything_ other than QDCOUNT =3D=3D 1 >=20 > The text of RFC1035 (4.1.2) describes the question section thus: >=20 > The question section is used to carry the "question" in most queries, > i.e., the parameters that define what is being asked. The section > contains QDCOUNT (usually 1) entries, each of the following format ... >=20 > This certainly does not exclude the possibility of an empty question > section in a query packet and hence there is no justification for > responding with FORMERR. Actually, it's vague in RFC 1035. RFC 1034 is quite specific about "_the_ query name" (singular) in the conte= xt of standard query processing (see e.g. =A73.7) I therefore interpret that parenthetical comment as applying to other OPCOD= E values than "QUERY". For example IQUERY does (did) use QDCOUNT =3D=3D 0. > No additional legislation should be necessary; implementations which > return FORMERR in response to zero QDCOUNT are non-compliant with > RFC1035. Client-side code which relies upon such behaviour is > similarly non-compliant. The semantics for QDCOUNT !=3D 1 are not defined for "QUERY" so (IMHO) FORM= ERR is appropriate. Ray From marc.lampo@eurid.eu Mon Nov 14 23:51: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 0DEEC1F0CFF for ; Mon, 14 Nov 2011 23:51:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.401 X-Spam-Level: X-Spam-Status: No, score=0.401 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, MSGID_MULTIPLE_AT=1.449, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k1DfLv5D8gUE for ; Mon, 14 Nov 2011 23:51:33 -0800 (PST) Received: from cuda.eurid.eu (unknown [62.41.4.80]) by ietfa.amsl.com (Postfix) with ESMTP id DF8831F0C47 for ; Mon, 14 Nov 2011 23:51:31 -0800 (PST) X-ASG-Debug-ID: 1321343488-02dadd06686fa40001-uIE7UK Received: from zimbra.eurid.eu (zcs-master.vt.eurid.eu [10.19.100.121]) by cuda.eurid.eu with ESMTP id zkS2hmKLQpkv6qi1; Tue, 15 Nov 2011 08:51:28 +0100 (CET) X-Barracuda-Envelope-From: marc.lampo@eurid.eu X-ASG-Whitelist: Client Received: from localhost (localhost.localdomain [127.0.0.1]) by zimbra.eurid.eu (Postfix) with ESMTP id B2A68E4073; Tue, 15 Nov 2011 08:51:28 +0100 (CET) X-Virus-Scanned: amavisd-new at techmail.eurid.eu Received: from zimbra.eurid.eu ([127.0.0.1]) by localhost (zimbra.eurid.eu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JVntb+ibIE5u; Tue, 15 Nov 2011 08:51:28 +0100 (CET) Received: from zimbra.eurid.eu (zimbra.eurid.eu [10.19.100.120]) by zimbra.eurid.eu (Postfix) with ESMTP id A01FEE4050; Tue, 15 Nov 2011 08:51:28 +0100 (CET) From: "Marc Lampo" To: "'Mark Andrews'" References: <20111111025007.B689B17061FA@drugs.dv.isc.org> <026401cca2d5$3d91a270$b8b4e750$@lampo@eurid.eu> <20111114222302.F0159171B01D@drugs.dv.isc.org> In-Reply-To: <20111114222302.F0159171B01D@drugs.dv.isc.org> Date: Tue, 15 Nov 2011 08:51:28 +0100 (CET) X-ASG-Orig-Subj: RE: [dnsext] BADVER/FORMERR Message-ID: <009a01cca36b$6224d170$266e7450$@lampo@eurid.eu> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 X-Mailer: Zimbra 6.0.14_GA_2928 (ZimbraConnectorForOutlook/5.0.3064.18) Thread-Index: AcyjHB0gLi0DLgBqTQCAB64U6SNZQAATwd9Q Content-Language: en-za X-Originating-IP: [172.20.5.51] X-Barracuda-Connect: zcs-master.vt.eurid.eu[10.19.100.121] X-Barracuda-Start-Time: 1321343488 X-Barracuda-URL: http://10.31.100.125:8000/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at eurid.eu Cc: dnsext@ietf.org Subject: Re: [dnsext] BADVER/FORMERR X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 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, 15 Nov 2011 07:51:34 -0000 Point taken - about what you want to achieve with such a query. However, according to IANA, numbers 1...255 are unassigned ! --> I see no indication of value 255 being reserved ? Registry Name: EDNS version Number (8 bits) Reference: [RFC2671] Registration Procedures: Standards Action Registry: Range Description Reference -------- ----------------------- --------- 0 EDNS version 0 [RFC2671] 1-255 Unassigned (cfr : http://www.iana.org/assignments/dns-parameters) Kind regards, Marc -----Original Message----- From: Mark Andrews [mailto:marka@isc.org] Sent: 14 November 2011 11:23 PM To: Marc Lampo Cc: dnsext@ietf.org Subject: Re: [dnsext] BADVER/FORMERR In message <026401cca2d5$3d91a270$b8b4e750$@lampo@eurid.eu>, "Marc Lampo" writes: > Hello Mark, > > Interesting path you are following ... > > >From my position (in the Internet with respect to anycast servers), > I get answers you consider not correct from > All of a, h, k and l root-servers.net. > > Additionally, when I query a.root-servers.net. with QDCOUNT == 1, > the rcode becomes indeed BADVERS (extended : value 16), > but amazingly the name servers additionally sets the lowest bit in the > flags : > "non-authenticaded data: Acceptable" (that's the CD bit, if I'm not > mistaken). > > The problem seems to be : "which error precedes which error ?" > (as there is only one possibility for "rcode" in the packet) > So, first detect the QDCOUNT == 0 and return FORMERR because of that, > or, also detect that EDNS type is 255, so : undefined and return BADVERS > because of that. 255 is reserved not wrong. > But what I fail to see is : why send EDNS with value 255 ? I want to send a query which will force the EDNS version on the OPT record to be *changed* by the server at the remote end. There are too many nameservers out there that don't understand EDNS yet still return OPT records from the query. You can see them by changing the EDNS UDP size and seeing the change reflected back to you. I'm also looking to do this with smallest sized packets that I can. > Why not simply a regular EDNS0 ? > Because in that case (only one error), > the authoritative name server can always add EDNS0 in its reply with the > UDP payload > (you are interested in in the first place). > We don't *have* to send an EDNS with bad version number in order to obtain > the information ? > Or do you want to *force* EDNS0 in the reply by sending a query > that results in a Returncode >15 so that EDNS0 is needed to get that > returncode back ? > > > Kind regards, > > Marc > > > -----Original Message----- > From: Mark Andrews [mailto:marka@isc.org] > Sent: 11 November 2011 03:50 AM > To: dnsext@ietf.org > Subject: [dnsext] BADVER/FORMERR > > > I was looking for a good way to test for EDNS support and hacked > dig to send out a empty question section when the EDNS version was > set to 255 and got what I believe to be incorrect responses from K > and L. EDNS version processing is supposed to take precedence over > examining the query section as the EDNS version can influence the > interpretion of the question section. I believe the correct response > should be BADVERS. Adding a question elicited BADVERS. > > Do others agree with my interpretion of rcode precedence? > > Mark > > marka% bin/dig/dig +edns=255 +norec @k.root-servers.net > > ; <<>> DiG 9.9.0b1 <<>> +edns=255 +norec @k.root-servers.net > ; (2 servers found) > ;; global options: +cmd > ;; Got answer: > ;; ->>HEADER<<- opcode: QUERY, status: FORMERR, id: 40361 > ;; flags: qr; QUERY: 0, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0 > > ;; Query time: 255 msec > ;; SERVER: 2001:7fd::1#53(2001:7fd::1) > ;; WHEN: Fri Nov 11 13:34:50 2011 > ;; MSG SIZE rcvd: 12 > > marka% bin/dig/dig +edns=255 +norec @l.root-servers.net > > ; <<>> DiG 9.9.0b1 <<>> +edns=255 +norec @l.root-servers.net > ; (2 servers found) > ;; global options: +cmd > ;; Got answer: > ;; ->>HEADER<<- opcode: QUERY, status: FORMERR, id: 34663 > ;; flags: qr; QUERY: 0, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0 > > ;; Query time: 175 msec > ;; SERVER: 2001:500:3::42#53(2001:500:3::42) > ;; WHEN: Fri Nov 11 13:35:08 2011 > ;; MSG SIZE rcvd: 12 > > -- > Mark Andrews, ISC > 1 Seymour St., Dundas Valley, NSW 2117, Australia > PHONE: +61 2 9871 4742 INTERNET: marka@isc.org > -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From marka@isc.org Tue Nov 15 03:08: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 6915111E809D for ; Tue, 15 Nov 2011 03:08:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.441 X-Spam-Level: X-Spam-Status: No, score=-2.441 tagged_above=-999 required=5 tests=[AWL=0.158, 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 WRlNQDkdyXRn for ; Tue, 15 Nov 2011 03:08:17 -0800 (PST) Received: from mx.pao1.isc.org (mx.pao1.isc.org [IPv6:2001:4f8:0:2::2b]) by ietfa.amsl.com (Postfix) with ESMTP id 533411F0C5C for ; Tue, 15 Nov 2011 03:08:17 -0800 (PST) Received: from bikeshed.isc.org (bikeshed.isc.org [IPv6:2001:4f8:3:d::19]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "bikeshed.isc.org", Issuer "ISC CA" (verified OK)) by mx.pao1.isc.org (Postfix) with ESMTPS id 168E1C941E; Tue, 15 Nov 2011 11:08:03 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (unknown [IPv6:2001:470:1f00:820:6233:4bff:fe01:7585]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by bikeshed.isc.org (Postfix) with ESMTPSA id 3F015216C6A; Tue, 15 Nov 2011 11:08:02 +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 3AAC11734FFC; Tue, 15 Nov 2011 22:08:00 +1100 (EST) To: "Marc Lampo" From: Mark Andrews References: <20111111025007.B689B17061FA@drugs.dv.isc.org> <026401cca2d5$3d91a270$b8b4e750$@lampo@eurid.eu> <20111114222302.F0159171B01D@drugs.dv.isc.org> <009a01cca36b$6224d170$266e7450$@lampo@eurid.eu> In-reply-to: Your message of "Tue, 15 Nov 2011 08:51:28 BST." <009a01cca36b$6224d170$266e7450$@lampo@eurid.eu> Date: Tue, 15 Nov 2011 22:08:00 +1100 Message-Id: <20111115110800.3AAC11734FFC@drugs.dv.isc.org> Cc: dnsext@ietf.org Subject: Re: [dnsext] BADVER/FORMERR X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 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, 15 Nov 2011 11:08:22 -0000 In message <009a01cca36b$6224d170$266e7450$@lampo@eurid.eu>, "Marc Lampo" writes: > Point taken - about what you want to achieve with such a query. > > However, according to IANA, numbers 1...255 are unassigned ! > --> I see no indication of value 255 being reserved ? It doesn't matter if it assigned or reserved. It is supposed to elicit BADVER from the server 255 is yet to be defined. > Registry Name: EDNS version Number (8 bits) > Reference: [RFC2671] > Registration Procedures: Standards Action > > Registry: > Range Description Reference > -------- ----------------------- --------- > 0 EDNS version 0 [RFC2671] > 1-255 Unassigned > (cfr : http://www.iana.org/assignments/dns-parameters) > > Kind regards, > > Marc > > -----Original Message----- > From: Mark Andrews [mailto:marka@isc.org] > Sent: 14 November 2011 11:23 PM > To: Marc Lampo > Cc: dnsext@ietf.org > Subject: Re: [dnsext] BADVER/FORMERR > > > In message <026401cca2d5$3d91a270$b8b4e750$@lampo@eurid.eu>, "Marc Lampo" > writes: > > Hello Mark, > > > > Interesting path you are following ... > > > > >From my position (in the Internet with respect to anycast servers), > > I get answers you consider not correct from > > All of a, h, k and l root-servers.net. > > > > Additionally, when I query a.root-servers.net. with QDCOUNT == 1, > > the rcode becomes indeed BADVERS (extended : value 16), > > but amazingly the name servers additionally sets the lowest bit in the > > flags : > > "non-authenticaded data: Acceptable" (that's the CD bit, if I'm not > > mistaken). > > > > The problem seems to be : "which error precedes which error ?" > > (as there is only one possibility for "rcode" in the packet) > > So, first detect the QDCOUNT == 0 and return FORMERR because of that, > > or, also detect that EDNS type is 255, so : undefined and return BADVERS > > because of that. > > 255 is reserved not wrong. > > > But what I fail to see is : why send EDNS with value 255 ? > > I want to send a query which will force the EDNS version on the OPT > record to be *changed* by the server at the remote end. There are > too many nameservers out there that don't understand EDNS yet still > return OPT records from the query. You can see them by changing > the EDNS UDP size and seeing the change reflected back to you. > > I'm also looking to do this with smallest sized packets that I can. > > > Why not simply a regular EDNS0 ? > > Because in that case (only one error), > > the authoritative name server can always add EDNS0 in its reply with the > > UDP payload > > (you are interested in in the first place). > > We don't *have* to send an EDNS with bad version number in order to > obtain > > the information ? > > Or do you want to *force* EDNS0 in the reply by sending a query > > that results in a Returncode >15 so that EDNS0 is needed to get that > > returncode back ? > > > > > > Kind regards, > > > > Marc > > > > > > -----Original Message----- > > From: Mark Andrews [mailto:marka@isc.org] > > Sent: 11 November 2011 03:50 AM > > To: dnsext@ietf.org > > Subject: [dnsext] BADVER/FORMERR > > > > > > I was looking for a good way to test for EDNS support and hacked > > dig to send out a empty question section when the EDNS version was > > set to 255 and got what I believe to be incorrect responses from K > > and L. EDNS version processing is supposed to take precedence over > > examining the query section as the EDNS version can influence the > > interpretion of the question section. I believe the correct response > > should be BADVERS. Adding a question elicited BADVERS. > > > > Do others agree with my interpretion of rcode precedence? > > > > Mark > > > > marka% bin/dig/dig +edns=255 +norec @k.root-servers.net > > > > ; <<>> DiG 9.9.0b1 <<>> +edns=255 +norec @k.root-servers.net > > ; (2 servers found) > > ;; global options: +cmd > > ;; Got answer: > > ;; ->>HEADER<<- opcode: QUERY, status: FORMERR, id: 40361 > > ;; flags: qr; QUERY: 0, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0 > > > > ;; Query time: 255 msec > > ;; SERVER: 2001:7fd::1#53(2001:7fd::1) > > ;; WHEN: Fri Nov 11 13:34:50 2011 > > ;; MSG SIZE rcvd: 12 > > > > marka% bin/dig/dig +edns=255 +norec @l.root-servers.net > > > > ; <<>> DiG 9.9.0b1 <<>> +edns=255 +norec @l.root-servers.net > > ; (2 servers found) > > ;; global options: +cmd > > ;; Got answer: > > ;; ->>HEADER<<- opcode: QUERY, status: FORMERR, id: 34663 > > ;; flags: qr; QUERY: 0, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0 > > > > ;; Query time: 175 msec > > ;; SERVER: 2001:500:3::42#53(2001:500:3::42) > > ;; WHEN: Fri Nov 11 13:35:08 2011 > > ;; MSG SIZE rcvd: 12 > > > > -- > > Mark Andrews, ISC > > 1 Seymour St., Dundas Valley, NSW 2117, Australia > > PHONE: +61 2 9871 4742 INTERNET: marka@isc.org > > > -- > Mark Andrews, ISC > 1 Seymour St., Dundas Valley, NSW 2117, Australia > PHONE: +61 2 9871 4742 INTERNET: marka@isc.org -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From rwfranks@gmail.com Tue Nov 15 10:33: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 860B911E80A6 for ; Tue, 15 Nov 2011 10:33:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.977 X-Spam-Level: X-Spam-Status: No, score=-102.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YixFleO61gqT for ; Tue, 15 Nov 2011 10:33:21 -0800 (PST) Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by ietfa.amsl.com (Postfix) with ESMTP id 99A4E11E80A3 for ; Tue, 15 Nov 2011 10:33:18 -0800 (PST) Received: by ywt34 with SMTP id 34so6688718ywt.31 for ; Tue, 15 Nov 2011 10:33:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type :content-transfer-encoding; bh=b2pY87aVdNPBrnm4NilU1Vr7N34uzete/tKZ3MQFScs=; b=GFjHY5WBylTWspsOjnbsJkzNx9rXDUNLOR/ZoXitPXuhven2yBH/ae3UqQoOU91BRW /Wj5yZA9+uriZ3LqVh5ayXDVHuhWTPkM/bxzGMaBwlP+kt1FvJcxiwhRGeEVKv5owjux I2vE+Tg7jr+hoLhC69rXRhBEX4K1NxH+TT2R4= Received: by 10.224.189.129 with SMTP id de1mr18907725qab.18.1321381998103; Tue, 15 Nov 2011 10:33:18 -0800 (PST) MIME-Version: 1.0 Sender: rwfranks@gmail.com Received: by 10.229.2.195 with HTTP; Tue, 15 Nov 2011 10:32:57 -0800 (PST) In-Reply-To: References: <20111111025007.B689B17061FA@drugs.dv.isc.org> <20111114222302.F0159171B01D@drugs.dv.isc.org> From: Dick Franks Date: Tue, 15 Nov 2011 18:32:57 +0000 X-Google-Sender-Auth: mP9g7PHjVGpioFXgXQka32K3SqU Message-ID: To: Ray Bellis Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: dnsext Subject: Re: [dnsext] BADVER/FORMERR X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 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, 15 Nov 2011 18:33:22 -0000 On 15 November 2011 05:55, Ray Bellis wrote: > > Actually, it's vague in RFC 1035. > RFC1035 (warts and all) is, until someone feels brave enough to rewrite it, the base specification. The question section is defined to be a list of question items. If the intention had been to require exactly one question, it would have been specified in the same way as the header, and QDCOUNT eliminated entirely. > RFC 1034 is quite specific about "_the_ query name" (singular) in the con= text of standard query processing (see e.g. =C2=A73.7) > RFC1034 =C2=A73.7 is not relevant here. The concept of "standard query processing" is meaningless if the question section is empty. > I therefore interpret that parenthetical comment as applying to other OPC= ODE values than "QUERY". =C2=A0For example IQUERY does (did) use QDCOUNT = =3D=3D 0. > I would interpret it as a non-normative comment (usually!). RFC1035 =C2=A74.1.2 is describing the structure of the question section in general, not QUERY in particular. Unless there is an obscure RFC lurking somewhere which specifically forbids an empty question section, then RFC1035 wins and a whole worldful of implementations are non-compliant. > The semantics for QDCOUNT !=3D 1 are not defined for "QUERY" so (IMHO) FO= RMERR is appropriate. > The semantics for QDCOUNT > 1 are certainly not defined for QUERY. Part of Mark A's argument is that the semantics for QDCOUNT =3D 0 should be considered well defined because no standard query processing is involved if there is no question to process. Furthermore, he noted that an empty question section is (trivially) parsable, and cites three plausible scenarios where such a query might be useful. --Dick From msheldon@godaddy.com Tue Nov 15 14:31: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 3731011E80FD for ; Tue, 15 Nov 2011 14:31:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.669 X-Spam-Level: X-Spam-Status: No, score=-101.669 tagged_above=-999 required=5 tests=[AWL=0.930, 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 TzaseSoA42fK for ; Tue, 15 Nov 2011 14:30:58 -0800 (PST) Received: from smtpoutwbe06.prod.mesa1.secureserver.net (smtpoutwbe06.prod.mesa1.secureserver.net [208.109.78.208]) by ietfa.amsl.com (Postfix) with SMTP id E8CCE11E80F1 for ; Tue, 15 Nov 2011 14:30:57 -0800 (PST) Received: (qmail 2860 invoked from network); 15 Nov 2011 22:30:57 -0000 Received: from unknown (HELO gem-wbe32.prod.mesa1.secureserver.net) (64.202.189.144) by smtpoutwbe06.prod.mesa1.secureserver.net with SMTP; 15 Nov 2011 22:30:57 -0000 Received: (qmail 14575 invoked by uid 99); 15 Nov 2011 22:30:56 -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.04 Message-Id: <20111115153055.205a61dff9fc1684c258b274662bb912.4a8b265d31.wbe@email00.secureserver.net> From: "Michael Sheldon" To: "dnsext" Date: Tue, 15 Nov 2011 15:30:55 -0700 Mime-Version: 1.0 Subject: Re: [dnsext] BADVER/FORMERR X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 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, 15 Nov 2011 22:31:12 -0000 > -------- Original Message --------=0A> Subject: Re: [dnsext] BADVER/FORME= RR=0A> From: Dick Franks =0A> Date: Tue, November 15, 201= 1 11:32 am=0A> To: Ray Bellis =0A> Cc: dnsext =0A> =0A=0A> Part of Mark A's argument is that the semantics= for QDCOUNT =3D 0 should=0A> be considered well defined because no standar= d query processing is=0A> involved if there is no question to process.=0A= =0AReally? Exactly what part of any RFC defines what should be returned on= =0Aa QUERY where QDCOUNT =3D=3D 0? Unless you found something I haven't see= n,=0Ait's not only not well-defined, it's not defined at all. =0A=0A> Furth= ermore, he noted that an empty question section is (trivially)=0A> parsable= , and cites three plausible scenarios where such a query might=0A> be usefu= l.=0A=0AHe defines circumstances where he can learn things from the server = by=0Adeliberately sending invalid data, thus eliciting an error message. So= =0Awe've already defined that he's deliberately sending contextually bogus= =0Adata. The question is, if everything in the EDNS section is correct,=0Aw= hat would the response be to QDCOUNT=3D0? Unless you can convince me=0Ather= e is a valid non-error response to this, I see nothing wrong with=0Areturni= ng a response based on the first error I find and discontinuing=0Aparsing a= t that point. In my opinion, a query with no query is a format=0Aerror. Any= further errors beyond that point are irrelevant.=0A=0AMy suggestion Mark, = is to put some kind of question in the packet, the=0Asize difference is fra= nkly insignificant.=0A=0A=0AMichael Sheldon=0ADev-DNS Services=0AGoDaddy.co= m=0A From marka@isc.org Tue Nov 15 16:50: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 E6CC911E8088 for ; Tue, 15 Nov 2011 16:50:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.442 X-Spam-Level: X-Spam-Status: No, score=-2.442 tagged_above=-999 required=5 tests=[AWL=0.157, 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 tUwzPp+MGS7e for ; Tue, 15 Nov 2011 16:50:03 -0800 (PST) Received: from mx.pao1.isc.org (mx.pao1.isc.org [IPv6:2001:4f8:0:2::2b]) by ietfa.amsl.com (Postfix) with ESMTP id 7109111E8082 for ; Tue, 15 Nov 2011 16:50:03 -0800 (PST) Received: from bikeshed.isc.org (bikeshed.isc.org [IPv6:2001:4f8:3:d::19]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "bikeshed.isc.org", Issuer "ISC CA" (verified OK)) by mx.pao1.isc.org (Postfix) with ESMTPS id 25970C9450; Wed, 16 Nov 2011 00:49:50 +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 7A247216C6A; Wed, 16 Nov 2011 00:49:49 +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 D4CC6173AE05; Wed, 16 Nov 2011 11:49:45 +1100 (EST) To: "Michael Sheldon" From: Mark Andrews References: <20111115153055.205a61dff9fc1684c258b274662bb912.4a8b265d31.wbe@email00.secureserver.net> In-reply-to: Your message of "Tue, 15 Nov 2011 15:30:55 PDT." <20111115153055.205a61dff9fc1684c258b274662bb912.4a8b265d31.wbe@email00.secureserver.net> Date: Wed, 16 Nov 2011 11:49:45 +1100 Message-Id: <20111116004945.D4CC6173AE05@drugs.dv.isc.org> Cc: dnsext Subject: Re: [dnsext] BADVER/FORMERR X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Nov 2011 00:50:09 -0000 In message <20111115153055.205a61dff9fc1684c258b274662bb912.4a8b265d31.wbe@emai l00.secureserver.net>, "Michael Sheldon" writes: > > > Part of Mark A's argument is that the semantics for QDCOUNT = 0 should > > be considered well defined because no standard query processing is > > involved if there is no question to process. > > Really? Exactly what part of any RFC defines what should be returned on > a QUERY where QDCOUNT == 0? Unless you found something I haven't seen, > it's not only not well-defined, it's not defined at all. Actually if you follow the algorithm you end up with NOERROR. Most of the steps become no-ops. Set or clear RA. There is no QNAME so you can't find a zone. There is no QNAME so you can't recurse and add records. There is no additional data to add. You return the response which is empty/NOERROR. > > Furthermore, he noted that an empty question section is (trivially) > > parsable, and cites three plausible scenarios where such a query might > > be useful. > > He defines circumstances where he can learn things from the server by > deliberately sending invalid data, thus eliciting an error message. So > we've already defined that he's deliberately sending contextually bogus > data. The question is, if everything in the EDNS section is correct, > what would the response be to QDCOUNT=0? Unless you can convince me > there is a valid non-error response to this, I see nothing wrong with > returning a response based on the first error I find and discontinuing > parsing at that point. In my opinion, a query with no query is a format > error. Any further errors beyond that point are irrelevant. QCOUNT > 1 is hard because there is one rcode and more that one possible response. QCOUNT = 0 gets rid of all name based acl processing. QCOUNT = 0 is independent of the zones being served. QCOUNT = 0 in plain DNS gives you a test to see if the server is alive, whether it will recurse for you or not (RA), and whether it will in general answer queries for you. Note QCOUNT > 1 is a valid in a response to a IQUERY. > My suggestion Mark, is to put some kind of question in the packet, the > size difference is frankly insignificant. > Michael Sheldon > Dev-DNS Services > GoDaddy.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 Ed.Lewis@neustar.biz Wed Nov 16 05:53:44 2011 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DDD1421F9691 for ; Wed, 16 Nov 2011 05:53:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.454 X-Spam-Level: X-Spam-Status: No, score=-106.454 tagged_above=-999 required=5 tests=[AWL=0.145, 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 TNL3i1Wgl5AY for ; Wed, 16 Nov 2011 05:53:44 -0800 (PST) Received: from stora.ogud.com (stora.ogud.com [66.92.146.20]) by ietfa.amsl.com (Postfix) with ESMTP id 1CE1D21F968A for ; Wed, 16 Nov 2011 05:53:44 -0800 (PST) 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 pAGDrdDR055337; Wed, 16 Nov 2011 08:53:41 -0500 (EST) (envelope-from Ed.Lewis@neustar.biz) Received: from [10.31.204.66] by Work-Laptop-2.local (PGP Universal service); Wed, 16 Nov 2011 08:53:42 -0500 X-PGP-Universal: processed; by Work-Laptop-2.local on Wed, 16 Nov 2011 08:53:42 -0500 Mime-Version: 1.0 Message-Id: In-Reply-To: <20111116004945.D4CC6173AE05@drugs.dv.isc.org> References: <20111115153055.205a61dff9fc1684c258b274662bb912.4a8b265d31.wbe@email00.se cureserver.net> <20111116004945.D4CC6173AE05@drugs.dv.isc.org> Date: Wed, 16 Nov 2011 08:53:37 -0500 To: dnsext 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] Tao and Re: BADVER/FORMERR X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Nov 2011 13:53:45 -0000 At 11:49 +1100 11/16/11, Mark Andrews wrote: >..."Michael Sheldon" writes: >> ...what part of any RFC defines what should be returned on >> a QUERY where QDCOUNT == 0? ... it's not defined at all. > >Actually if you follow the algorithm you end up with NOERROR. Most of >the steps become no-ops. I can see what Mark is saying but I don't think it is the only possible answer. One problem with this thread is that it is taking the RFCs too literally. From FYI17 (The Tao) what's more important than the written word is running code. With the goal of the IETF documents to document what it means to be interoperable, the place to start when looking at gaps in the documents is "what does running code do" and then come to a consensus. I.e., because you can interpret the RFC to mean something when it says nothing is a flimsy place to start an argument. Part of my motivation to post here is that I've spent a lot of time over the past year wading through paper trails trying to find details of the protocol, details relating to things like the KX record and other vestigial components. Comparing what the text comes up with to popular implementations, I found that the running code does not always meet the specification. The problem here isn't the code being non-conformant, it's the specifications falling behind. (If it were the other way around, we'd see operational hang ups.) From this, I wouldn't take the specifications to be that literal. I'd suggest going back to "what do we think the right response to an empty Question section should be" and then see if the installed code base is acceptable as is, and then document any decisions. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- 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 johani@autonomica.se Wed Nov 16 10:39: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 9408621F93F2 for ; Wed, 16 Nov 2011 10:39:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.699 X-Spam-Level: X-Spam-Status: No, score=-1.699 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_65=0.6, 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 8x1oycK+PTgI for ; Wed, 16 Nov 2011 10:39:56 -0800 (PST) Received: from defiant.autonomica.se (unknown [IPv6:2a01:3f0:1:3::105]) by ietfa.amsl.com (Postfix) with ESMTP id F303921F9519 for ; Wed, 16 Nov 2011 10:39:51 -0800 (PST) Received: from [198.32.17.196] (c-15f5e255.51-2-64736c14.cust.bredbandsbolaget.se [85.226.245.21]) (Authenticated sender: johani) by defiant.autonomica.se (Postfix) with ESMTPSA id 868D67CBBA; Wed, 16 Nov 2011 19:39:50 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: =?iso-8859-1?Q?Johan_Ihr=E9n?= In-Reply-To: <20111116004945.D4CC6173AE05@drugs.dv.isc.org> Date: Wed, 16 Nov 2011 19:39:50 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20111115153055.205a61dff9fc1684c258b274662bb912.4a8b265d31.wbe@email00.secureserver.net> <20111116004945.D4CC6173AE05@drugs.dv.isc.org> To: dnsext X-Mailer: Apple Mail (2.1084) Subject: Re: [dnsext] BADVER/FORMERR X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Nov 2011 18:39:56 -0000 On Nov 16, 2011, at 01:49 , Mark Andrews wrote: > QCOUNT > 1 is hard because there is one rcode and more that one = possible > response. >=20 > QCOUNT =3D 0 gets rid of all name based acl processing. > QCOUNT =3D 0 is independent of the zones being served. > QCOUNT =3D 0 in plain DNS gives you a test to see if the server is > alive, whether it will recurse for you or not (RA), and whether it > will in general answer queries for you. >=20 > Note QCOUNT > 1 is a valid in a response to a IQUERY. While not immediately relevant to the current discussion I make the = observation that once upon a time many, many moons ago there was = discussions about a possible alternate design for DNSSEC called "slabs". = The idea with slabs was that we could do away with the DO bit and the = subtyping of the RRSIG by making two changes: 1. Combine RR + RRSIG(RR) into a new record which was a "slab" (a single = RR that contained the unsigned RRset + the signature over the RRset). = I.e. an A + RRSIG(A) would be an A-SIG, etc. 2. Instead of having resolvers signal DNSSEC interest via the DO bit = they would query for both the A and the A-SIG in the same query, i.e. = with a QDCOUNT=3D2.=20 There were various pros and cons with this and in the end this is not = what became DNSSEC as we know it today.=20 And my point with lifting this old and mouldy stone is that I think it = would be a mistake to go down the route it sounds to me that Ray is = aiming for ("disallow anything but QDCOUNT=3D1 in if OPCODE=3DQUERY = because that's most efficient").=20 RFC1035 doesn't say QDCOUNT=3D1 (then we wouldn't have that as a counter = at all) and just because we here and now, today, may see a point to such = a restriction does not mean that such a thing wouldn't come back and = haunt us in the future when we come up with some new and clever usage = that depends on the ability to have more than one query in the QUERY. Ray: apologies in advance if I misinterpreted your position. If I did, = my point still remains, though. Johan From drc@virtualized.org Wed Nov 16 11:13: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 EE1EB1F0C62 for ; Wed, 16 Nov 2011 11:13:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RX7l7m9TDH2z for ; Wed, 16 Nov 2011 11:13:41 -0800 (PST) Received: from trantor.virtualized.org (trantor.virtualized.org [199.48.134.42]) by ietfa.amsl.com (Postfix) with ESMTP id 312581F0C54 for ; Wed, 16 Nov 2011 11:13:41 -0800 (PST) Received: from [192.168.2.147] (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 5E6F21705A; Wed, 16 Nov 2011 19:13:40 +0000 (UTC) Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=us-ascii From: David Conrad In-Reply-To: Date: Wed, 16 Nov 2011 11:13:39 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <6A35CF88-EE33-47D8-8C95-93F307EB6DF9@virtualized.org> References: <20111115153055.205a61dff9fc1684c258b274662bb912.4a8b265d31.wbe@email00.se cureserver.net> <20111116004945.D4CC6173AE05@drugs.dv.isc.org> To: Edward Lewis X-Mailer: Apple Mail (2.1251.1) Cc: dnsext Subject: Re: [dnsext] Tao and Re: BADVER/FORMERR X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Nov 2011 19:13:42 -0000 On Nov 16, 2011, at 5:53 AM, Edward Lewis wrote: > I'd suggest going back to "what do we think the right response to an = empty Question section should be" and then see if the installed code = base is acceptable as is, and then document any decisions. +1 (Ed and I agreeing on something?? What is this world coming to?) I get a bit of heartburn when folks try to extrapolate (interpolate) = RFCs, particularly the older ones, as they're really not suited for = that. I believe a much better approach in these cases is to try to = figure out: a) what is the desired behavior b) what breaks in the deployed base if that behavior is implemented. and then, as Ed says, document decisions made in an 'updates' RFC.=20 Regards, -drc From rwfranks@gmail.com Wed Nov 16 17:40: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 7A61D11E8099 for ; Wed, 16 Nov 2011 17:40:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.977 X-Spam-Level: X-Spam-Status: No, score=-102.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SqmztqKgfQCg for ; Wed, 16 Nov 2011 17:40:06 -0800 (PST) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id 6A0E411E8081 for ; Wed, 16 Nov 2011 17:40:06 -0800 (PST) Received: by wyf28 with SMTP id 28so1491204wyf.31 for ; Wed, 16 Nov 2011 17:40:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type; bh=CiFI8rjtTbicNuoLL4v0CnVXaB3p5CfAg6kEzTIEzmU=; b=dqAMqXVIl1k9TB8hCNqcGFG0BUpKgQbVN0MWwfdlrO0VS2nr3dKicyoMFvB4/fkeRu Fh7kRYhgzq1vFtsy6L3mvslLF8uIscyvhUfy2/daY/yiGVROujWfpJTz/ThgbGUN2ONQ 48eT57uxrOW/amqlILO7Bllt93cUf+42v2tIE= Received: by 10.229.69.130 with SMTP id z2mr5031177qci.16.1321494005147; Wed, 16 Nov 2011 17:40:05 -0800 (PST) MIME-Version: 1.0 Sender: rwfranks@gmail.com Received: by 10.229.212.79 with HTTP; Wed, 16 Nov 2011 17:39:44 -0800 (PST) In-Reply-To: References: <20111116004945.D4CC6173AE05@drugs.dv.isc.org> From: Dick Franks Date: Thu, 17 Nov 2011 01:39:44 +0000 X-Google-Sender-Auth: H9BdU0IbvbOsNcK87Ska3C3mV4k Message-ID: To: Edward Lewis Content-Type: text/plain; charset=UTF-8 Cc: dnsext Subject: Re: [dnsext] Tao and Re: BADVER/FORMERR X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Nov 2011 01:40:07 -0000 On 16 November 2011 13:53, Edward Lewis wrote: > I.e., because you can interpret the RFC to mean something when it says > nothing is a flimsy place to start an argument. RFC1035 does not say nothing. It says that the question section is a list of QDCOUNT elements. QDCOUNT is an unsigned 16 bit integer. From which we deduce that the question section can possibly be empty. > I'd suggest going back to "what do we think the right response to an empty > Question section should be" ... Mark Andrews has done exactly that and presented a plausible argument for NOERROR. I agree with him. We think the right response to an empty Question section should be NOERROR. > ... and then see if the installed code base is > acceptable as is, and then document any decisions. Code maintainers are free to review the arguments and decide for themselves what to do. --Dick From Ray.Bellis@nominet.org.uk Wed Nov 16 21: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 4A59511E8115 for ; Wed, 16 Nov 2011 21:22:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.938 X-Spam-Level: X-Spam-Status: No, score=-8.938 tagged_above=-999 required=5 tests=[AWL=0.761, BAYES_00=-2.599, J_CHICKENPOX_65=0.6, MIME_8BIT_HEADER=0.3, 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 ezmV8M4OocK5 for ; Wed, 16 Nov 2011 21:22:37 -0800 (PST) Received: from mx4.nominet.org.uk (mail.nominet.org.uk [213.248.199.24]) by ietfa.amsl.com (Postfix) with ESMTP id 1C06B11E810A for ; Wed, 16 Nov 2011 21:22:35 -0800 (PST) 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: Content-ID:Content-Transfer-Encoding:MIME-Version; b=AxwzRYYfp6BZahAjYigWLW1q16oMcLga9sAcmfmRxaBU5PWIskDlZlSf 5TBYrxnQY4ucyei1EMbwHJRUQqM2u//Pm0AGaogtRJ839ADLQ1zlwMy4T qzPATk+Tl19Qj2g; 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=1321507357; x=1353043357; 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]=20BADVER/FORMERR|Date:=20Thu, =2017=20Nov=202011=2005:22:33=20+0000|Message-ID:=20|To:=20 =3D?iso-8859-1?Q?Johan_Ihr=3DE9n?=3D=20|CC:=20dnsext=20|MIME-Version:=201.0 |Content-Transfer-Encoding:=20quoted-printable |Content-ID:=20<4a132d79-98ad-4571-bb73-154e708bf9c4> |In-Reply-To:=20|References:=20<20111115153055.205a61dff9fc168 4c258b274662bb912.4a8b265d31.wbe@email00.secureserver.net >=0D=0A=20<20111116004945.D4CC6173AE05@drugs.dv.isc.org> =0D=0A=20; bh=M3R5S2vjrQYzw/7366gijPV2eDpGwD0zjlrwneti7g0=; b=iAAhUzXxOYEgXUWgXFodEQecGsNS6IzMT1N3oMpDvep1KnaR6BictdPF kSQ9h80iHKawn1RXyq8zmIEte+3VZidwx53CYKGlyy28TcXvvFZH453Zq dbNhUyMuWtTit8k; X-IronPort-AV: E=Sophos;i="4.69,524,1315177200"; d="scan'208";a="29599124" Received: from wds-exc2.okna.nominet.org.uk ([213.248.197.145]) by mx4.nominet.org.uk with ESMTP; 17 Nov 2011 05:22:34 +0000 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; Thu, 17 Nov 2011 05:22:33 +0000 From: Ray Bellis To: =?iso-8859-1?Q?Johan_Ihr=E9n?= Thread-Topic: [dnsext] BADVER/FORMERR Thread-Index: AQHMo+Y95mAz8aYz4U6U8KCek//FTpWuq7xYgAEqtgCAALOSgA== Date: Thu, 17 Nov 2011 05:22:33 +0000 Message-ID: References: <20111115153055.205a61dff9fc1684c258b274662bb912.4a8b265d31.wbe@email00.secureserver.net> <20111116004945.D4CC6173AE05@drugs.dv.isc.org> In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="iso-8859-1" Content-ID: <4a132d79-98ad-4571-bb73-154e708bf9c4> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: dnsext Subject: Re: [dnsext] BADVER/FORMERR X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Nov 2011 05:22:38 -0000 On 17 Nov 2011, at 02:39, Johan Ihr=E9n wrote: > And my point with lifting this old and mouldy stone is that I think it wo= uld be a mistake to go down the route it sounds to me that Ray is aiming fo= r ("disallow anything but QDCOUNT=3D1 in if OPCODE=3DQUERY because that's m= ost efficient").=20 >=20 > RFC1035 doesn't say QDCOUNT=3D1 (then we wouldn't have that as a counter = at all) and just because we here and now, today, may see a point to such a = restriction does not mean that such a thing wouldn't come back and haunt us= in the future when we come up with some new and clever usage that depends = on the ability to have more than one query in the QUERY. >=20 > Ray: apologies in advance if I misinterpreted your position. If I did, my= point still remains, though. My intent is not to restrict (future) use of QDCOUNT > 1 [*] I just believe that it's very reasonable for a _current_ implementation to = do: if (opcode =3D=3D QUERY && qdcount !=3D 1) return FORMERR very early in query processing. [*] That said, I did do some work earlier this year looking into the poss= ible semantics of if not multiple QNAMES, at least multiple QTYPEs in a que= ry using an EDNS option. I wrote a draft, but then decided the problem was= too hard. Ray From rdroms.ietf@gmail.com Sat Nov 19 17:45: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 0C7371F0C3C for ; Sat, 19 Nov 2011 17:45:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LH2vu+V-h--W for ; Sat, 19 Nov 2011 17:45:38 -0800 (PST) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 6701D1F0C34 for ; Sat, 19 Nov 2011 17:45:38 -0800 (PST) Received: by vbbfc26 with SMTP id fc26so1624532vbb.31 for ; Sat, 19 Nov 2011 17:45:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=jBr5u7ljPxmsOrwr9dYkjs8axgdIlw/zI6gu9h+3aWA=; b=TNodD9+S85yxaTABtURnd2psDaPXIcW1GQR3C52okmqGNJfXG1hWZ2R436Vc9DXgdU dTRKL1q2hO3XtSoQM1PUy7RD4xlBFKN/oEq1vxLr1aiLysm6qZ1lIFUr6grD7ogZvDaR n1BDZ1ZSUE/td0JxfY1DJ8lkCDMOAR1hbN9C0= Received: by 10.52.65.14 with SMTP id t14mr9733504vds.47.1321753533141; Sat, 19 Nov 2011 17:45:33 -0800 (PST) Received: from [192.168.1.128] (c-24-147-184-22.hsd1.ma.comcast.net. [24.147.184.22]) by mx.google.com with ESMTPS id hn2sm7791116vdb.14.2011.11.19.17.45.31 (version=SSLv3 cipher=OTHER); Sat, 19 Nov 2011 17:45:32 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=us-ascii From: Ralph Droms In-Reply-To: <0EB23916-DEDA-4899-8ECE-E89F4DEBBF80@gmail.com> Date: Sat, 19 Nov 2011 20:36:36 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <9096F3C9-8E6A-4D59-8A81-9647E119EB9C@gmail.com> References: <20111114145016.8235.28459.idtracker@ietfa.amsl.com> <0EB23916-DEDA-4899-8ECE-E89F4DEBBF80@gmail.com> To: Scott Rose X-Mailer: Apple Mail (2.1251.1) Cc: DNSEXT Working Group Subject: Re: [dnsext] I-D Action: draft-ietf-dnsext-rfc2672bis-dname-25.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, 20 Nov 2011 01:45:39 -0000 Thanks, Scott. I'll ask the Discuss holders to review the revision and = respond. - Ralph On Nov 14, 2011, at 8:57 AM 11/14/11, Scott Rose wrote: > This revised version was to address comments made during the AD = review. Mostly some wording changes, but there is also a new appendix = section with major changes from RFC 2672 and this document. >=20 > Scott >=20 > Begin forwarded message: >=20 >> From: internet-drafts@ietf.org >> Date: November 14, 2011 9:50:16 AM EST >> To: i-d-announce@ietf.org >> Cc: dnsext@ietf.org >> Subject: [dnsext] I-D Action: = draft-ietf-dnsext-rfc2672bis-dname-25.txt >>=20 >> A New Internet-Draft is available from the on-line Internet-Drafts = directories. This draft is a work item of the DNS Extensions Working = Group of the IETF. >>=20 >> Title : DNAME Redirection in the DNS >> Author(s) : Scott Rose >> Wouter Wijngaards >> Filename : draft-ietf-dnsext-rfc2672bis-dname-25.txt >> Pages : 22 >> Date : 2011-11-14 >>=20 >> The DNAME record provides redirection for a sub-tree of the domain >> name tree in the DNS system. That is, all names that end with a >> particular suffix are redirected to another part of the DNS. This is >> a revision to the original specification in RFC 2672 (which this >> document obsoletes) as well as updating RFC 3363 and RFC 4294 to >> align with this revision. >>=20 >>=20 >>=20 >> A URL for this Internet-Draft is: >> = http://www.ietf.org/internet-drafts/draft-ietf-dnsext-rfc2672bis-dname-25.= txt >>=20 >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ >>=20 >> This Internet-Draft can be retrieved at: >> = ftp://ftp.ietf.org/internet-drafts/draft-ietf-dnsext-rfc2672bis-dname-25.t= xt >> _______________________________________________ >> dnsext mailing list >> dnsext@ietf.org >> https://www.ietf.org/mailman/listinfo/dnsext >=20 > _______________________________________________ > dnsext mailing list > dnsext@ietf.org > https://www.ietf.org/mailman/listinfo/dnsext From marka@isc.org Mon Nov 21 13:13: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 B7DAE21F8ADC; Mon, 21 Nov 2011 13:13:45 -0800 (PST) X-Quarantine-ID: X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER SECTION, Duplicate header field: "Cc" X-Spam-Flag: NO X-Spam-Score: -2.303 X-Spam-Level: X-Spam-Status: No, score=-2.303 tagged_above=-999 required=5 tests=[AWL=-0.004, 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 U1o6Z8TpOiqR; Mon, 21 Nov 2011 13:13:45 -0800 (PST) Received: from mx.ams1.isc.org (mx.ams1.isc.org [IPv6:2001:500:60::65]) by ietfa.amsl.com (Postfix) with ESMTP id 344E221F8AD9; Mon, 21 Nov 2011 13:13:45 -0800 (PST) Received: from bikeshed.isc.org (bikeshed.isc.org [IPv6:2001:4f8:3:d::19]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "bikeshed.isc.org", Issuer "ISC CA" (verified OK)) by mx.ams1.isc.org (Postfix) with ESMTPS id 296015F98B6; Mon, 21 Nov 2011 21:13:18 +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 8F479216C6B; Mon, 21 Nov 2011 21:13:16 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (Postfix) with ESMTP id 6692917DB0E8; Tue, 22 Nov 2011 08:13:12 +1100 (EST) To: =?utf-8?Q?Ond=C5=99ej_Sur=C3=BD?= From: Mark Andrews References: <45EA694E-096C-41A1-B60E-BF7B3832FE2A@vpnc.org> <4EC70173.9090106@sv.cmu.edu> <247CAE36-68FB-4048-B07C-9B4C0903434D@vpnc.org> <92AA2445-000C-44CF-8CA5-9796528EA946@checkpoint.com> <0536F82C-346C-4ABE-81E6-3B008219DBD9@kirei.se> <773BAA00-22B9-43A6-BB36-8E3CB6166E38@nic.cz> <4B541E04-4A37-4402-AD01-EA95F69C8FB1@vpnc.org> <6CA2C172-4BE7-479C-B305-E454B15EA9FA@nic.cz> In-reply-to: Your message of "Mon, 21 Nov 2011 19:32:26 BST." <6CA2C172-4BE7-479C-B305-E454B15EA9FA@nic.cz> Date: Tue, 22 Nov 2011 08:13:12 +1100 Message-Id: <20111121211312.6692917DB0E8@drugs.dv.isc.org> Cc: dnsext@ietf.org, Paul Hoffman , IETF DANE WG list Subject: Re: [dnsext] [dane] Aiming towards some specific wording X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: dnsext@ietf.org List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Nov 2011 21:13:45 -0000 The only difference between "insecure" and "indeterminate" is that there was a TA configured somewhere above the name and there is a insecure delegation between that TA and data. We don't actually prove that something is insecure. We prove that there is not a secure path to the data. If you don't have a TA you do not have a secure path to the data. If you have a TA but a insecure delegation you do not have a secure path to the data. In both case the data could be signed or unsigned. "insecure" and "indeterminate" zones are logically the same. Dane should just treat them as !secure. Dnsext should fix the DNSSEC RFC's to get rid of one or other of them as having two terms for the same thing is pointless. Reply-to set to dnsext@ietf.org 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 Mon Nov 21 13:29:00 2011 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8711511E80FD for ; Mon, 21 Nov 2011 13:29:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.468 X-Spam-Level: X-Spam-Status: No, score=-106.468 tagged_above=-999 required=5 tests=[AWL=0.130, 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 OMvPjxYpC7DB for ; Mon, 21 Nov 2011 13:28:59 -0800 (PST) Received: from stora.ogud.com (stora.ogud.com [66.92.146.20]) by ietfa.amsl.com (Postfix) with ESMTP id 6593311E80FC for ; Mon, 21 Nov 2011 13:28:59 -0800 (PST) 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 pALLSt2k002459; Mon, 21 Nov 2011 16:28:56 -0500 (EST) (envelope-from Ed.Lewis@neustar.biz) Received: from [10.31.200.137] by work-laptop-2 (PGP Universal service); Mon, 21 Nov 2011 16:28:57 -0500 X-PGP-Universal: processed; by work-laptop-2 on Mon, 21 Nov 2011 16:28:57 -0500 Mime-Version: 1.0 Message-Id: In-Reply-To: <20111121211312.6692917DB0E8@drugs.dv.isc.org> References: <45EA694E-096C-41A1-B60E-BF7B3832FE2A@vpnc.org> <4EC70173.9090106@sv.cmu.edu> <247CAE36-68FB-4048-B07C-9B4C0903434D@vpnc.org> <92AA2445-000C-44CF-8CA5-9796528EA946@checkpoint.com> <0536F82C-346C-4ABE-81E6-3B008219DBD9@kirei.se> <773BAA00-22B9-43A6-BB36-8E3CB6166E38@nic.cz> <4B541E04-4A37-4402-AD01-EA95F69C8FB1@vpnc.org> <6CA2C172-4BE7-479C-B305-E454B15EA9FA@nic.cz> <20111121211312.6692917DB0E8@drugs.dv.isc.org> Date: Mon, 21 Nov 2011 16:28:52 -0500 To: From: Edward Lewis Content-Type: multipart/alternative; boundary="============_-890211559==_ma============" X-Scanned-By: MIMEDefang 2.72 on 10.20.30.4 Cc: ed.lewis@neustar.biz, dnsext@ietf.org, Paul Hoffman Subject: Re: [dnsext] [dane] Aiming towards some specific wording X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Nov 2011 21:29:00 -0000 --============_-890211559==_ma============ Content-Type: text/plain; charset="us-ascii" ; format="flowed" Answering only to DNSEXT... At 8:13 +1100 11/22/11, Mark Andrews wrote: >"insecure" and "indeterminate" zones are logically the same. Dane >should just treat them as !secure. No, they are not the same. Insecure means I get records indicating there's no possible trust chain that can be constructed from the data to anything I have. Indeterminate means when I try to get records for part of the chain I "time-out". ("No servers could be reached.") There's a significant semantic difference between the two. Apart from the fact that you won't succeed in constructing a chain, "insecure" means it is definitively impossible and "indeterminate" means "not with the data at hand, at this time." The former would be data that is not protected, the latter could be declared a service failure. Here's the definition in RFC 4035 I'm pointing to: 4.3. Determining Security Status of Data ... Insecure: An RRset for which the resolver knows that it has no chain of signed DNSKEY and DS RRs from any trusted starting point to the RRset. This can occur when the target RRset lies in an unsigned zone or in a descendent of an unsigned zone. In this case, the RRset may or may not be signed, but the resolver will not be able to verify the signature. ... Indeterminate: An RRset for which the resolver is not able to determine whether the RRset should be signed, as the resolver is not able to obtain the necessary DNSSEC RRs. This can occur when the security-aware resolver is not able to contact security-aware name servers for the relevant zones. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- 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" --============_-890211559==_ma============ Content-Type: text/html; charset="us-ascii" Re: [dnsext] [dane] Aiming towards some specific wording
Answering only to DNSEXT...

At 8:13 +1100 11/22/11, Mark Andrews wrote:
>"insecure" and "indeterminate" zones are logically the same.  Dane
>should just treat them as !secure.

No, they are not the same.

Insecure means I get records indicating there's no possible trust chain that can be constructed from the data to anything I have.

Indeterminate means when I try to get records for part of the chain I "time-out".  ("No servers could be reached.")

There's a significant semantic difference between the two.  Apart from the fact that you won't succeed in constructing a chain, "insecure" means it is definitively impossible and "indeterminate" means "not with the data at hand, at this time."  The former would be data that is not protected, the latter could be declared a service failure.

Here's the definition in RFC 4035 I'm pointing to:

4.3.  Determining Security Status of Data
...
   Insecure: An RRset for which the resolver knows that it has no chain
      of signed DNSKEY and DS RRs from any trusted starting point to the
      RRset.  This can occur when the target RRset lies in an unsigned
      zone or in a descendent of an unsigned zone.  In this case, the
      RRset may or may not be signed, but the resolver will not be able
      to verify the signature.
...
   Indeterminate: An RRset for which the resolver is not able to
      determine whether the RRset should be signed, as the resolver is
      not able to obtain the necessary DNSSEC RRs.  This can occur when
      the security-aware resolver is not able to contact security-aware
      name servers for the relevant zones.
--
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
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"
--============_-890211559==_ma============-- From marka@isc.org Mon Nov 21 15:21: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 5B79011E814C for ; Mon, 21 Nov 2011 15:21:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.453 X-Spam-Level: X-Spam-Status: No, score=-2.453 tagged_above=-999 required=5 tests=[AWL=0.146, 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 hMFvqe7bF+D9 for ; Mon, 21 Nov 2011 15:21:26 -0800 (PST) Received: from mx.ams1.isc.org (mx.ams1.isc.org [IPv6:2001:500:60::65]) by ietfa.amsl.com (Postfix) with ESMTP id 9DB3F11E8146 for ; Mon, 21 Nov 2011 15:21:26 -0800 (PST) Received: from bikeshed.isc.org (bikeshed.isc.org [IPv6:2001:4f8:3:d::19]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "bikeshed.isc.org", Issuer "ISC CA" (verified OK)) by mx.ams1.isc.org (Postfix) with ESMTPS id 8FF7A5F98AF; Mon, 21 Nov 2011 23:21: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 33638216C6A; Mon, 21 Nov 2011 23:20:59 +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 B6D5D17DD132; Tue, 22 Nov 2011 10:20:55 +1100 (EST) To: Edward Lewis From: Mark Andrews References: <45EA694E-096C-41A1-B60E-BF7B3832FE2A@vpnc.org> <4EC70173.9090106@sv.cmu.edu> <247CAE36-68FB-4048-B07C-9B4C0903434D@vpnc.org> <92AA2445-000C-44CF-8CA5-9796528EA946@checkpoint.com> <0536F82C-346C-4ABE-81E6-3B008219DBD9@kirei.se> <773BAA00-22B9-43A6-BB36-8E3CB6166E38@nic.cz> <4B541E04-4A37-4402-AD01-EA95F69C8FB1@vpnc.org> <6CA2C172-4BE7-479C-B305-E454B15EA9FA@nic.cz> <20111121211312.6692917DB0E8@drugs.dv.isc.org> In-reply-to: Your message of "Mon, 21 Nov 2011 16:28:52 CDT." Date: Tue, 22 Nov 2011 10:20:55 +1100 Message-Id: <20111121232055.B6D5D17DD132@drugs.dv.isc.org> Cc: dnsext@ietf.org, Paul Hoffman Subject: Re: [dnsext] [dane] Aiming towards some specific wording X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Nov 2011 23:21:27 -0000 In message , Edward Lewis writes: > At 8:13 +1100 11/22/11, Mark Andrews wrote: > >"insecure" and "indeterminate" zones are logically the same. Dane > >should just treat them as !secure. > > No, they are not the same. > > Insecure means I get records indicating there's no possible trust > chain that can be constructed from the data to anything I have. > > Indeterminate means when I try to get records for part of the chain I > "time-out". ("No servers could be reached.") > > There's a significant semantic difference between the two. Apart > from the fact that you won't succeed in constructing a chain, > "insecure" means it is definitively impossible and "indeterminate" > means "not with the data at hand, at this time." The former would be > data that is not protected, the latter could be declared a service > failure. > > Here's the definition in RFC 4035 I'm pointing to: > > 4.3. Determining Security Status of Data > ... > Insecure: An RRset for which the resolver knows that it has no chain > of signed DNSKEY and DS RRs from any trusted starting point to the > RRset. This can occur when the target RRset lies in an unsigned > zone or in a descendent of an unsigned zone. In this case, the > RRset may or may not be signed, but the resolver will not be able > to verify the signature. > ... > Indeterminate: An RRset for which the resolver is not able to > determine whether the RRset should be signed, as the resolver is > not able to obtain the necessary DNSSEC RRs. This can occur when > the security-aware resolver is not able to contact security-aware > name servers for the relevant zones. And the difference between that and bogus is? It got data and no signature so it is bogus. If got data and bad signatures it is bogus. It didn't get a response then it has no data. There are are only 3 states the data can be in. Secure, insecure and bogus. -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From paul.hoffman@vpnc.org Mon Nov 21 15:36: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 1939911E814F for ; Mon, 21 Nov 2011 15:36:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.398 X-Spam-Level: X-Spam-Status: No, score=-102.398 tagged_above=-999 required=5 tests=[AWL=0.201, 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 y7Qw+PD4SJju for ; Mon, 21 Nov 2011 15:36:31 -0800 (PST) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 99B9C11E814E for ; Mon, 21 Nov 2011 15:36:31 -0800 (PST) Received: from sn87.proper.com (sn87.proper.com [75.101.18.87]) (authenticated bits=0) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id pALNaUeE033651 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Mon, 21 Nov 2011 16:36:31 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1251.1) From: Paul Hoffman In-Reply-To: <20111121232055.B6D5D17DD132@drugs.dv.isc.org> Date: Mon, 21 Nov 2011 15:36:29 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: <45EA694E-096C-41A1-B60E-BF7B3832FE2A@vpnc.org> <4EC70173.9090106@sv.cmu.edu> <247CAE36-68FB-4048-B07C-9B4C0903434D@vpnc.org> <92AA2445-000C-44CF-8CA5-9796528EA946@checkpoint.com> <0536F82C-346C-4ABE-81E6-3B008219DBD9@kirei.se> <773BAA00-22B9-43A6-BB36-8E3CB6166E38@nic.cz> <4B541E04-4A37-4402-AD01-EA95F69C8FB1@vpnc.org> <6CA2C172-4BE7-479C-B305-E454B15EA9FA@nic.cz> <20111121211312.6692917DB0E8@drugs.dv.isc.org> <20111121232055.B6D5D17DD132@drugs.dv.isc.org> To: DNSEXT Working Group X-Mailer: Apple Mail (2.1251.1) Subject: Re: [dnsext] [dane] Aiming towards some specific wording X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Nov 2011 23:36:32 -0000 If this WG intends to update RFC 403[3-5] with different definitions of = the states, it would be good if someone started an Internet Draft *real = soon* so the DANE WG can refer to it. Otherwise, maybe it is better to = not run this course. Statements of "I don't like it" without action of = an actual draft makes it hard for the rest of the IETF to move forwards. --Paul Hoffman= From suruti94@gmail.com Mon Nov 21 16:59: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 234391F0C5B for ; Mon, 21 Nov 2011 16:59:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HpTa9ywsgjPV for ; Mon, 21 Nov 2011 16:59:23 -0800 (PST) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by ietfa.amsl.com (Postfix) with ESMTP id 985231F0C55 for ; Mon, 21 Nov 2011 16:59:16 -0800 (PST) Received: by yenm7 with SMTP id m7so3257841yen.31 for ; Mon, 21 Nov 2011 16:59:15 -0800 (PST) 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=jn1Pn/2vC1iwtKHNf/iasIGb+bkHbA2inKF4RNHu+QQ=; b=QG3ZE82r/SFBVN5WWXbALIEnWrCQ9Y5bNNIVOzvpX+M9DgET5TP6rS3HVVAebyLOJe yFWJYoa/vf5PsDOTCIQO+DkJ/5+yLxOuHaIy7bXVpb0QsOwMxQ4aVoneSHpuqlLRkKT3 yu2ASFq+HKjF7k5Z7IyrmZrta26MYdnUnTutY= MIME-Version: 1.0 Received: by 10.182.2.136 with SMTP id 8mr3541243obu.71.1321923554986; Mon, 21 Nov 2011 16:59:14 -0800 (PST) Received: by 10.182.159.98 with HTTP; Mon, 21 Nov 2011 16:59:14 -0800 (PST) In-Reply-To: <20111121232055.B6D5D17DD132@drugs.dv.isc.org> References: <45EA694E-096C-41A1-B60E-BF7B3832FE2A@vpnc.org> <4EC70173.9090106@sv.cmu.edu> <247CAE36-68FB-4048-B07C-9B4C0903434D@vpnc.org> <92AA2445-000C-44CF-8CA5-9796528EA946@checkpoint.com> <0536F82C-346C-4ABE-81E6-3B008219DBD9@kirei.se> <773BAA00-22B9-43A6-BB36-8E3CB6166E38@nic.cz> <4B541E04-4A37-4402-AD01-EA95F69C8FB1@vpnc.org> <6CA2C172-4BE7-479C-B305-E454B15EA9FA@nic.cz> <20111121211312.6692917DB0E8@drugs.dv.isc.org> <20111121232055.B6D5D17DD132@drugs.dv.isc.org> Date: Mon, 21 Nov 2011 16:59:14 -0800 Message-ID: From: Mohan Parthasarathy To: Mark Andrews Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Edward Lewis , dnsext@ietf.org, Paul Hoffman Subject: Re: [dnsext] [dane] Aiming towards some specific wording X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Nov 2011 00:59:27 -0000 On Mon, Nov 21, 2011 at 3:20 PM, Mark Andrews wrote: > > In message , Edward Lewis writes: >> At 8:13 +1100 11/22/11, Mark Andrews wrote: >> >"insecure" and "indeterminate" zones are logically the same. =A0Dane >> >should just treat them as !secure. >> >> No, they are not the same. >> >> Insecure means I get records indicating there's no possible trust >> chain that can be constructed from the data to anything I have. >> >> Indeterminate means when I try to get records for part of the chain I >> "time-out". =A0("No servers could be reached.") >> >> There's a significant semantic difference between the two. =A0Apart >> from the fact that you won't succeed in constructing a chain, >> "insecure" means it is definitively impossible and "indeterminate" >> means "not with the data at hand, at this time." =A0The former would be >> data that is not protected, the latter could be declared a service >> failure. >> >> Here's the definition in RFC 4035 I'm pointing to: >> >> 4.3. =A0Determining Security Status of Data >> ... >> =A0 =A0 Insecure: An RRset for which the resolver knows that it has no c= hain >> =A0 =A0 =A0 =A0of signed DNSKEY and DS RRs from any trusted starting poi= nt to the >> =A0 =A0 =A0 =A0RRset. =A0This can occur when the target RRset lies in an= unsigned >> =A0 =A0 =A0 =A0zone or in a descendent of an unsigned zone. =A0In this c= ase, the >> =A0 =A0 =A0 =A0RRset may or may not be signed, but the resolver will not= be able >> =A0 =A0 =A0 =A0to verify the signature. >> ... >> =A0 =A0 Indeterminate: An RRset for which the resolver is not able to >> =A0 =A0 =A0 =A0determine whether the RRset should be signed, as the reso= lver is >> =A0 =A0 =A0 =A0not able to obtain the necessary DNSSEC RRs. =A0This can = occur when >> =A0 =A0 =A0 =A0the security-aware resolver is not able to contact securi= ty-aware >> =A0 =A0 =A0 =A0name servers for the relevant zones. > > And the difference between that and bogus is? =A0 It got data and no > signature so it is bogus. =A0If got data and bad signatures it is > bogus. =A0It didn't get a response then it has no data. > Bogus is defined like this: Bogus: An RRset for which the resolver believes that it ought to be able to establish a chain of trust but for which it is unable to do so, either due to signatures that for some reason fail to validate or due to missing data that the relevant DNSSEC RRs indicate should be present. This case may indicate an attack but may also indicate a configuration error or some form of data corruption. So, the resolver knows a priori that there *is* a chain of trust but it can't establish that for the reasons that you mentioned above. . It is different from Insecure/Indeterminate where the resolver does not know beforehand. Within Indeterminate/Insecure, you still need something to say that "I can't reach the servers or I am behind a crappy CPE device" Vs. "I received an NSEC". I have been having problems understanding what this really means and this is just my interpretation.. -regards mohan > > There are are only 3 states the data can be in. =A0Secure, insecure and b= ogus. > > -- > 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 matt@mattmccutchen.net Mon Nov 21 20:11:00 2011 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A8DF21F886A; Mon, 21 Nov 2011 20:11:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8a3-zA-9yM2k; Mon, 21 Nov 2011 20:10:55 -0800 (PST) Received: from homiemail-a3.g.dreamhost.com (caiajhbdcbef.dreamhost.com [208.97.132.145]) by ietfa.amsl.com (Postfix) with ESMTP id 4845A21F86D0; Mon, 21 Nov 2011 20:10:55 -0800 (PST) Received: from homiemail-a3.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a3.g.dreamhost.com (Postfix) with ESMTP id 31A0A28408C; Mon, 21 Nov 2011 20:10:46 -0800 (PST) DomainKey-Signature: a=rsa-sha1; c=nofws; d=mattmccutchen.net; h=message-id :subject:from:to:cc:in-reply-to:references:content-type:date :mime-version:content-transfer-encoding; q=dns; s= mattmccutchen.net; b=Mux7HzYkwPCXbebarPq4KixxBiP/W/fFpdmGCS5wVp0 ZeO3O+NvGYxFXxpUqm04S3XY1Yutc1pP4vUt64+i5wGZ0DvoeY/EVwnR8ccLQd9i 8B/7fhRVY0CNLpUT+pdrgZ7AziLOmbQiCltjjR3XZGCX/9pB2a4Jfx8OT77t7wYU = DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=mattmccutchen.net; h= message-id:subject:from:to:cc:in-reply-to:references :content-type:date:mime-version:content-transfer-encoding; s= mattmccutchen.net; bh=dhFD+q1cfo7K4aL3T1SiNzPFrzM=; b=LAiyhUf73s siziapGe3baYrTcnpOS0+aKIwBt2MWKDWsl0lzal8Z91yymFIAauGRYzLDeKbrjO govRrn8SBKbda9EXnchCEMxpNhGSN6VTzpjTEMxgy7AR1NSRIabd6WCTvgtKl4mg UTIhdm9yYv2O5kBHsZ5cuhvBfLZB2jSE0= Received: from [IPv6:::1] (ps7180.dreamhost.com [75.119.218.76]) (using SSLv3 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: matt@mattmccutchen.net) by homiemail-a3.g.dreamhost.com (Postfix) with ESMTPSA id F111C284081; Mon, 21 Nov 2011 20:10:45 -0800 (PST) Message-ID: <1321935016.1657.19.camel@mattlaptop2.local> From: Matt McCutchen To: dane@ietf.org, dnsext@ietf.org In-Reply-To: References: <45EA694E-096C-41A1-B60E-BF7B3832FE2A@vpnc.org> <4EC70173.9090106@sv.cmu.edu> <247CAE36-68FB-4048-B07C-9B4C0903434D@vpnc.org> <92AA2445-000C-44CF-8CA5-9796528EA946@checkpoint.com> <0536F82C-346C-4ABE-81E6-3B008219DBD9@kirei.se> <773BAA00-22B9-43A6-BB36-8E3CB6166E38@nic.cz> <4B541E04-4A37-4402-AD01-EA95F69C8FB1@vpnc.org> <6CA2C172-4BE7-479C-B305-E454B15EA9FA@nic.cz> <20111121211312.6692917DB0E8@drugs.dv.isc.org> Content-Type: text/plain; charset="UTF-8" Date: Mon, 21 Nov 2011 20:10:16 -0800 Mime-Version: 1.0 X-Mailer: Evolution 3.2.3 Content-Transfer-Encoding: 7bit Cc: Edward Lewis , Paul Hoffman Subject: Re: [dnsext] [dane] Aiming towards some specific wording X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Nov 2011 04:11:00 -0000 On Mon, 2011-11-21 at 16:28 -0500, Edward Lewis wrote: > Answering only to DNSEXT... > > > At 8:13 +1100 11/22/11, Mark Andrews wrote: > >"insecure" and "indeterminate" zones are logically the same. Dane > >should just treat them as !secure. > > No, they are not the same. > > Insecure means I get records indicating there's no possible trust > chain that can be constructed from the data to anything I have. > > Indeterminate means when I try to get records for part of the chain I > "time-out". ("No servers could be reached.") > > There's a significant semantic difference between the two. Apart from > the fact that you won't succeed in constructing a chain, "insecure" > means it is definitively impossible and "indeterminate" means "not > with the data at hand, at this time." The former would be data that > is not protected, the latter could be declared a service failure. > > Here's the definition in RFC 4035 I'm pointing to: > > 4.3. Determining Security Status of Data > ... > Indeterminate: An RRset for which the resolver is not able to > determine whether the RRset should be signed, as the resolver is > not able to obtain the necessary DNSSEC RRs. This can occur > when > the security-aware resolver is not able to contact > security-aware > name servers for the relevant zones. That's great, RFC 4035 has a totally different definition of "indeterminate" than RFC 4033. RFC 4033 "indeterminate" is equivalent to "insecure" for DANE's purpose and likely other purposes as well. RFC 4035 "indeterminate" is not a separate group of cases; those cases are better described as "SERVFAIL", or possibly "bogus" if the resolver successfully retrieves the target RRset (but not the DNSSEC RRs). Ultimately, DANE needs three cases: 1. Secure: Process the RRset. 2. Insecure or RFC 4033 indeterminate: Fall back to pre-DANE behavior, or (maybe -- under discussion) process the restrictive part of the assertion without the additive part. 3. Bogus or query failed (RCODE other than NOERROR or NXDOMAIN, no response from DNS servers, etc.): Fail closed. -- Matt From Ed.Lewis@neustar.biz Tue Nov 22 05:55: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 B63B121F8D9A for ; Tue, 22 Nov 2011 05:55:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.481 X-Spam-Level: X-Spam-Status: No, score=-106.481 tagged_above=-999 required=5 tests=[AWL=0.118, 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 E0NaWBoYJciq for ; Tue, 22 Nov 2011 05:55:53 -0800 (PST) Received: from stora.ogud.com (stora.ogud.com [66.92.146.20]) by ietfa.amsl.com (Postfix) with ESMTP id 1002A21F8D80 for ; Tue, 22 Nov 2011 05:55:52 -0800 (PST) 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 pAMDtijq008814; Tue, 22 Nov 2011 08:55:45 -0500 (EST) (envelope-from Ed.Lewis@neustar.biz) Received: from [10.31.200.137] by work-laptop-2 (PGP Universal service); Tue, 22 Nov 2011 08:55:51 -0500 X-PGP-Universal: processed; by work-laptop-2 on Tue, 22 Nov 2011 08:55:51 -0500 Mime-Version: 1.0 Message-Id: In-Reply-To: <20111121232055.B6D5D17DD132@drugs.dv.isc.org> References: <45EA694E-096C-41A1-B60E-BF7B3832FE2A@vpnc.org> <4EC70173.9090106@sv.cmu.edu> <247CAE36-68FB-4048-B07C-9B4C0903434D@vpnc.org> <92AA2445-000C-44CF-8CA5-9796528EA946@checkpoint.com> <0536F82C-346C-4ABE-81E6-3B008219DBD9@kirei.se> <773BAA00-22B9-43A6-BB36-8E3CB6166E38@nic.cz> <4B541E04-4A37-4402-AD01-EA95F69C8FB1@vpnc.org> <6CA2C172-4BE7-479C-B305-E454B15EA9FA@nic.cz> <20111121211312.6692917DB0E8@drugs.dv.isc.org> <20111121232055.B6D5D17DD132@drugs.dv.isc.org> Date: Tue, 22 Nov 2011 08:55:14 -0500 To: Mark Andrews 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, Paul Hoffman Subject: Re: [dnsext] [dane] Aiming towards some specific wording X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Nov 2011 13:55:53 -0000 Added Matt McCutchen because his post was on DANE and I'm not on that list. At 10:20 +1100 11/22/11, Mark Andrews wrote: >There are are only 3 states the data can be in. Secure, insecure and bogus. You left out "I don't know yet." But this doesn't matter, as a follow up post points out, 4033 and 4035 define indeterminate differently. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- 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 Ed.Lewis@neustar.biz Tue Nov 22 05:55: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 33CB621F8D9D for ; Tue, 22 Nov 2011 05:55:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.49 X-Spam-Level: X-Spam-Status: No, score=-106.49 tagged_above=-999 required=5 tests=[AWL=0.108, 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 csIAacS-V-ci for ; Tue, 22 Nov 2011 05:55:54 -0800 (PST) Received: from stora.ogud.com (stora.ogud.com [66.92.146.20]) by ietfa.amsl.com (Postfix) with ESMTP id 26E3521F8D80 for ; Tue, 22 Nov 2011 05:55:54 -0800 (PST) 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 pAMDtijs008814; Tue, 22 Nov 2011 08:55:52 -0500 (EST) (envelope-from Ed.Lewis@neustar.biz) Received: from [10.31.200.137] by work-laptop-2 (PGP Universal service); Tue, 22 Nov 2011 08:55:53 -0500 X-PGP-Universal: processed; by work-laptop-2 on Tue, 22 Nov 2011 08:55:53 -0500 Mime-Version: 1.0 Message-Id: In-Reply-To: <1321935016.1657.19.camel@mattlaptop2.local> References: <45EA694E-096C-41A1-B60E-BF7B3832FE2A@vpnc.org> <4EC70173.9090106@sv.cmu.edu> <247CAE36-68FB-4048-B07C-9B4C0903434D@vpnc.org> <92AA2445-000C-44CF-8CA5-9796528EA946@checkpoint.com> <0536F82C-346C-4ABE-81E6-3B008219DBD9@kirei.se> <773BAA00-22B9-43A6-BB36-8E3CB6166E38@nic.cz> <4B541E04-4A37-4402-AD01-EA95F69C8FB1@vpnc.org> <6CA2C172-4BE7-479C-B305-E454B15EA9FA@nic.cz> <20111121211312.6692917DB0E8@drugs.dv.isc.org> <1321935016.1657.19.camel@mattlaptop2.local> Date: Tue, 22 Nov 2011 08:55:36 -0500 To: Matt McCutchen From: Edward Lewis Content-Type: multipart/alternative; boundary="============_-890152344==_ma============" X-Scanned-By: MIMEDefang 2.72 on 10.20.30.4 Cc: Edward Lewis , dnsext@ietf.org, Paul Hoffman Subject: Re: [dnsext] [dane] Aiming towards some specific wording X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Nov 2011 13:55:55 -0000 --============_-890152344==_ma============ Content-Type: text/plain; charset="us-ascii" ; format="flowed" (Took DANE off because I'm not on the list.) At 20:10 -0800 11/21/11, Matt McCutchen wrote: >That's great, RFC 4035 has a totally different definition of >"indeterminate" than RFC 4033. You're right. When I answered I went to 4035 because it is the "protocol mod" and not 4034 because it was "records". I usually ignore 4033 because it's "intro" and has no requirements language in it. That's just to explain why I quoted 4035 (because these kind of terminology things run rampant in RFCs) and why I didn't quote 4033. Not that 4033 is any less wrong than 4035. I just ordinarily look at 4034/4035 more. Here's what '33 says: # Indeterminate: There is no trust anchor that would indicate that a # specific portion of the tree is secure. This is the default # operation mode. Certainly different from 4035 and what I would assume was the right way to define indeterminate. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- 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" --============_-890152344==_ma============ Content-Type: text/html; charset="us-ascii" Re: [dnsext] [dane] Aiming towards some specific wording
(Took DANE off because I'm not on the list.)

At 20:10 -0800 11/21/11, Matt McCutchen wrote:

>That's great, RFC 4035 has a totally different definition of
>"indeterminate" than RFC 4033.

You're right.  When I answered I went to 4035 because it is the "protocol mod" and not 4034 because it was "records".  I usually ignore 4033 because it's "intro" and has no requirements language in it.  That's just to explain why I quoted 4035 (because these kind of terminology things run rampant in RFCs) and why I didn't quote 4033.

Not that 4033 is any less wrong than 4035.  I just ordinarily look at 4034/4035 more.

Here's what '33 says:

#   Indeterminate: There is no trust anchor that would indicate that a
#   specific portion of the tree is secure.  This is the default
#   operation mode.

Certainly different from 4035 and what I would assume was the right way to define indeterminate.
--
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
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"
--============_-890152344==_ma============--