Re: [DNSOP] I-D Action: draft-ietf-dnsop-resolver-information-00.txt

Neil Cook <neil.cook@noware.co.uk> Wed, 30 October 2019 09:15 UTC

Return-Path: <neil.cook@noware.co.uk>
X-Original-To: dnsop@ietfa.amsl.com
Delivered-To: dnsop@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 237F0120113 for <dnsop@ietfa.amsl.com>; Wed, 30 Oct 2019 02:15:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.106
X-Spam-Level:
X-Spam-Status: No, score=-1.106 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RDNS_NONE=0.793, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DOWv8Fex1Uso for <dnsop@ietfa.amsl.com>; Wed, 30 Oct 2019 02:15:22 -0700 (PDT)
Received: from mail.noware.co.uk (unknown [IPv6:2604:a880:0:1010::add:2001]) by ietfa.amsl.com (Postfix) with ESMTP id B00FA120043 for <dnsop@ietf.org>; Wed, 30 Oct 2019 02:15:22 -0700 (PDT)
Received: from [192.168.1.170] (unknown [81.156.224.111]) by mail.noware.co.uk (Postfix) with ESMTPSA id 3F7E71C229A; Wed, 30 Oct 2019 09:05:38 +0000 (UTC)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3594.4.19\))
From: Neil Cook <neil.cook@noware.co.uk>
In-Reply-To: <alpine.LRH.2.21.1910291903230.1249@bofh.nohats.ca>
Date: Wed, 30 Oct 2019 09:15:20 +0000
Cc: Ben Schwartz <bemasc@google.com>, Erik Kline <ek.ietf@gmail.com>, dnsop <dnsop@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <05065EBB-8ACC-4813-A56D-DDBD1260BD0E@noware.co.uk>
References: <156624288737.19884.5252170663574668911@ietfa.amsl.com> <A8482079-FC91-414D-B0EF-E016606E9093@noware.co.uk> <34CACD4F-554A-4736-BD53-36D980B5A5A5@noware.co.uk> <CAMGpriWD_dOADk4=OKFzVZn8KT9RC_A1v3jQDq6oDLuRB3K9yg@mail.gmail.com> <CAHbrMsCng7tG=qNjDv23xzRU+_-_QD-4a_NvKzGDAHmGO4PA5Q@mail.gmail.com> <54A6311E-E688-4357-AC14-8A9ACBC1D6FF@noware.co.uk> <alpine.LRH.2.21.1910291903230.1249@bofh.nohats.ca>
To: Paul Wouters <paul@nohats.ca>
X-Mailer: Apple Mail (2.3594.4.19)
X-VADE-SPAMSTATE: clean
X-VADE-SPAMSCORE: -100
X-VADE-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrgedufedruddtfedgtddvucetufdoteggodetrfdotffvucfrrhhofhhilhgvmecupffgkffnvefqqffmnecuuegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenucfjughrpegtggfuhfgjfffgkfhfvffosehtqhhmtdhhtdejnecuhfhrohhmpefpvghilhcuvehoohhkuceonhgvihhlrdgtohhokhesnhhofigrrhgvrdgtohdruhhkqeenucfkphepkedurdduheeirddvvdegrdduuddunecurfgrrhgrmhepihhnvghtpeekuddrudehiedrvddvgedrudduuddphhgvlhhopegludelvddrudeikedruddrudejtdgnpdhmrghilhhfrhhomheppfgvihhlucevohhokhcuoehnvghilhdrtghoohhksehnohifrghrvgdrtghordhukheqpdhrtghpthhtohepphgruhhlsehnohhhrghtshdrtggrpdhrtghpthhtohepsggvmhgrshgtsehgohhoghhlvgdrtghomhdprhgtphhtthhopegvkhdrihgvthhfsehgmhgrihhlrdgtohhmpdhrtghpthhtohepughnshhophesihgvthhfrdhorhhgnecuvehluhhsthgvrhfuihiivgeptd
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/Y_sEfAmYbEBB5HVNAN_YYPMNkqc>
Subject: Re: [DNSOP] I-D Action: draft-ietf-dnsop-resolver-information-00.txt
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF DNSOP WG mailing list <dnsop.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dnsop>, <mailto:dnsop-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dnsop/>
List-Post: <mailto:dnsop@ietf.org>
List-Help: <mailto:dnsop-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dnsop>, <mailto:dnsop-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 30 Oct 2019 09:15:24 -0000


> On 29 Oct 2019, at 23:04, Paul Wouters <paul@nohats.ca>; wrote:
> 
> On Tue, 29 Oct 2019, Neil Cook wrote:
> 
>>      FWIW, I've previously stated a preference for dropping the use of ".well-known" entirely, and using draft-00's "resolver-info.arpa" name instead of reverse-IP, in order to improve support for
>>      passive forwarders.  I understand this was changed in the hope of offering some kind of security here with DNSSEC, but I think it's unlikely to work in practice, and we're better off keeping
>>      things simple.
>> I completely agree. I’d much rather see something like "resolver-info.arpa" instead of reverse-IP.
> 
> Throwing DNSSEC under the bus for a "simpler" name seems rather
> excessive. I for one would like to see DNSSEC in the reverse
> support when possible. For a future where not everything is
> chained to a single all-powerful LetsEncrypt root CA.
> 

I’m certainly not against DNSSEC per-se. I do question what it’s actually being used for in this situation and if it could actually work the way it is currently specified. I’ve included my original comments on this below:

- For the DNS method, given that a resolver never knows if DNS proxies are being used (in CPEs or elsewhere) or indeed what IP addresses are being used behind those proxies, I would imagine that at a minimum it would need to answer RESINFO queries for *all* RFC1918 addresses. This does then lead to the question, why include the IP address in the query at all? I assume the answer is “DNSSEC”, but see below for some more questions/comments on that.

- There is an acknowledgement "Erik Kline suggested using "<reverse-ip>.{in-addr,ip6}.arpa" as the
  domain name to allow for the possibility of DNSSEC-signed responses.”

I think it’s worth noting that RESINFO queries for private IP addresses will never be able to generate DNSSEC-signed responses. Also given the restriction "Authoritative servers MUST NOT answer queries that are defined in this protocol.” it seems unlikely that many resolvers would be capable of generating DNSSEC-signed responses, especially given that resolvers and authoritative servers tend to be completely separate entities these days.

This also begs the question, why create that restriction at all? Why must Authoritative Servers not answer those queries? The draft also states that "if the resolver can be configured to also be authoritative for some zones, it can use that configuration to actually be authoritative for the addresses on which it responds.” Which seems to contradict the previous MUST NOT - surely this is an implementation detail that should not be mentioned in an IETF draft?

Neil