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

Ben Schwartz <bemasc@google.com> Mon, 28 October 2019 18:55 UTC

Return-Path: <bemasc@google.com>
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 F083212026E for <dnsop@ietfa.amsl.com>; Mon, 28 Oct 2019 11:55:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -17.5
X-Spam-Level:
X-Spam-Status: No, score=-17.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com
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 JadUPJR5zQW1 for <dnsop@ietfa.amsl.com>; Mon, 28 Oct 2019 11:55:29 -0700 (PDT)
Received: from mail-io1-xd2b.google.com (mail-io1-xd2b.google.com [IPv6:2607:f8b0:4864:20::d2b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E1DCA1200E3 for <dnsop@ietf.org>; Mon, 28 Oct 2019 11:55:28 -0700 (PDT)
Received: by mail-io1-xd2b.google.com with SMTP id r144so11911247iod.8 for <dnsop@ietf.org>; Mon, 28 Oct 2019 11:55:28 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=LNVigGipirkj71uQNDDDoNVq0i7Fx6Qo9omBlMTv5vo=; b=NYL729ME7A1i4edYfOiZ0VMJnJU/ehjl9ATtN7w0/mcqyQ2it/KjTgy7mKmv2RH8Qf LNxEehe4TQbgzCnpEUqqihXaXj3kIoryAaUuiylbPwaiS+C/0m4sRdeDtT0qo10TSkI5 yc+lb8GeNL6DkkQZ298FqEc5yHPJ/T2WA4SkX0tLpuJ2dlneThNlzBx5LI4YCUeCc3Tz xjfhVij+/GoU4tyl8UeCBs/bM8C9JogduZJF43u5xd+7u0SUqfb4cJPSkyPg1aN5AIHC Dwkenpee3NieHbokVdtSrxNX5D+XZRgwk5v3jPBESPh3fpZQWIRHeMkeEa053yrkMUeo RDiQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=LNVigGipirkj71uQNDDDoNVq0i7Fx6Qo9omBlMTv5vo=; b=KM91i6NpQDdISf2B7jTymcgnBBbB7lakEU/4bu0KtDd8cRR2P/0t3ExQ9DsXJRljAF hkrIdwDenx/607ySlP9b6dd5I4OL0nAYC5Nlj3cyRIXes8e5uyEzWgqVK+v1IF63runl a8HRc8zWc/FFPZm6ZjZpWloV2f/bw53QJQ90FYpuxhncSgVCWi9fKqENNu5pi5aRmrqn gQJ7OYyprkArmU1uwYQZfQcXR7yy9c9QEj/7TC84VAYm9YuR/UNA8yZxzpDXgTzVCrsv XjSLqqZQz3mQXh0tqHwZKEAp7w9FIADOi7IntWB9+NfHsh4kEM2rNE0DfbV68NoCBRMZ kW8A==
X-Gm-Message-State: APjAAAW4KTEQ3qPiO8tNrnSoDgjhahfAFTNhrACnENoLhHo87x2EmSjq u/sgHcTk/nNkes8dNLrXF+EGr9BzxnphrWlezT7m/A==
X-Google-Smtp-Source: APXvYqx8l2vGWH+0WxFXv9m63Fir3QMxjwEu/KcFlqF3SvmVEgCogyoG61yNNYji6UkKX05zDj8SzXtoKFB4HS5WKYA=
X-Received: by 2002:a6b:1741:: with SMTP id 62mr12948848iox.153.1572288927833; Mon, 28 Oct 2019 11:55:27 -0700 (PDT)
MIME-Version: 1.0
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>
In-Reply-To: <CAMGpriWD_dOADk4=OKFzVZn8KT9RC_A1v3jQDq6oDLuRB3K9yg@mail.gmail.com>
From: Ben Schwartz <bemasc@google.com>
Date: Mon, 28 Oct 2019 14:55:16 -0400
Message-ID: <CAHbrMsCng7tG=qNjDv23xzRU+_-_QD-4a_NvKzGDAHmGO4PA5Q@mail.gmail.com>
To: Erik Kline <ek.ietf@gmail.com>
Cc: Neil Cook <neil.cook@noware.co.uk>, dnsop <dnsop@ietf.org>
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="00000000000010c6b00595fd0b8a"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/7MnKlFNspZWwh_U-Teu6hmnNx2k>
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: Mon, 28 Oct 2019 18:55:37 -0000

On Mon, Oct 28, 2019 at 2:40 PM Erik Kline <ek.ietf@gmail.com> wrote:

> IIRC Ben Schwartz at the mic (Prague? Montreal?) mentioned he was
> interested in seeing something like "traceroute but for DNS", which (a) is
> what your described scenario sounds like to me and (b) is a
> separate objective from this draft.  I think it's just...unrelated.
>

I'm not sure that it's unrelated.  I hazily imagined something like an
"upstream" field in the RESINFO object, which contains the upstream
resolver's RESINFO object (etc.).  In other words, I think that use case
might be well-served by this design.


>   I don't think we have DNS hop-by-hop -type semantics, which would make
> the discovery of intermediate resolvers/forwarders easier.
>
> On Mon, Oct 28, 2019 at 9:03 AM Neil Cook <neil.cook@noware.co.uk> wrote:
>
>> I was quite surprised that there was no reaction to my comments. Are they
>> not worth replying to, or is there just not enough interest in this draft?
>>
>
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.


>
>> Resolver discovery seems like such an important topic given what is
>> happening with DoH and DoT, I can’t believe that folks aren’t interested in
>> progressing this, and I think ensuring that it works for the extremely
>> widely deployed use-case of a DNS proxy/forwarder is very important.
>>
>> Neil
>>
>> > On 11 Oct 2019, at 14:41, Neil Cook <neil.cook@noware.co.uk> wrote:
>> >
>> > I have some comments on this draft.
>> >
>> > I’m particularly concerned about the extremely common use-case where a
>> DNS proxy is used in front of the actual resolver; this is the case for
>> many home routers/CPEs, particularly those provided by ISPs. They tend to
>> give out DNS via DHCP on a private IP address e.g. 192.168.0.x, and then
>> use dnsmasq (or homegrown software) to proxy to the actual resolver of the
>> ISP located in the network on a public IP address.
>> >
>> > TL;DR - there are two mechanisms defined in this draft. The first
>> mechanism "Retrieving Resolver Information by DNS” seems like it would work
>> ok with the above scenario. The second mechanism "Retrieving Resolver
>> Information by Well-Known URI” would require changes to every CPE of the
>> type described above, which IMO makes it unworkable for that scenario. (BTW
>> for CPE insert any kind of DNS proxy/forwarder, which would have the same
>> issue).
>> >
>> > My main concern is that given that there are two mechanisms specified,
>> clients may choose only to implement one of them. The draft doesn’t appear
>> to specify that client authors must implement one or the other, or both. So
>> I’d like to see the draft mandate that if only one of the mechanisms is
>> implemented, it must be the "Retrieving Resolver Information by DNS” method.
>> >
>> > I’d like to see the draft give due consideration to this very common
>> use-case, (both CPEs and the more general case of DNS proxies/forwarders).
>> >
>> > A few additional comments which I think need to be considered:
>> >
>> > - For the Well-Known URI mechanism by resolver IP, clearly private IP
>> addresses can never get valid certificates, so even if CPEs were to
>> implement this mechanism, they can never be authenticated.
>> >
>> > - 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 Cook
>> >
>> >> On 19 Aug 2019, at 20:28, internet-drafts@ietf.org wrote:
>> >>
>> >>
>> >> A New Internet-Draft is available from the on-line Internet-Drafts
>> directories.
>> >> This draft is a work item of the Domain Name System Operations WG of
>> the IETF.
>> >>
>> >>       Title           : DNS Resolver Information Self-publication
>> >>       Authors         : Puneet Sood
>> >>                         Roy Arends
>> >>                         Paul Hoffman
>> >>      Filename        : draft-ietf-dnsop-resolver-information-00.txt
>> >>      Pages           : 9
>> >>      Date            : 2019-08-19
>> >>
>> >> Abstract:
>> >>  This document describes methods for DNS resolvers to self-publish
>> >>  information about themselves, such as whether they perform DNSSEC
>> >>  validation or are available over transports other than what is
>> >>  defined in RFC 1035.  The information is returned as a JSON object.
>> >>  The names in this object are defined in an IANA registry that allows
>> >>  for light-weight registration.  Applications and operating systems
>> >>  can use the methods defined here to get the information from
>> >>  resolvers in order to make choices about how to send future queries
>> >>  to those resolvers.
>> >>
>> >>
>> >> The IETF datatracker status page for this draft is:
>> >>
>> https://datatracker.ietf.org/doc/draft-ietf-dnsop-resolver-information/
>> >>
>> >> There are also htmlized versions available at:
>> >> https://tools.ietf.org/html/draft-ietf-dnsop-resolver-information-00
>> >>
>> https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-resolver-information-00
>> >>
>> >>
>> >> Please note that it may take a couple of minutes from the time of
>> submission
>> >> until the htmlized version and diff are available at tools.ietf.org.
>> >>
>> >> Internet-Drafts are also available by anonymous FTP at:
>> >> ftp://ftp.ietf.org/internet-drafts/
>> >>
>> >
>>
>> _______________________________________________
>> DNSOP mailing list
>> DNSOP@ietf.org
>> https://www.ietf.org/mailman/listinfo/dnsop
>>
> _______________________________________________
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop
>