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

Erik Kline <ek.ietf@gmail.com> Mon, 28 October 2019 18:39 UTC

Return-Path: <ek.ietf@gmail.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 EE5A2120810 for <dnsop@ietfa.amsl.com>; Mon, 28 Oct 2019 11:39:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level:
X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 diF9WIKQnjaL for <dnsop@ietfa.amsl.com>; Mon, 28 Oct 2019 11:39:25 -0700 (PDT)
Received: from mail-ed1-x52c.google.com (mail-ed1-x52c.google.com [IPv6:2a00:1450:4864:20::52c]) (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 0651C120868 for <dnsop@ietf.org>; Mon, 28 Oct 2019 11:39:25 -0700 (PDT)
Received: by mail-ed1-x52c.google.com with SMTP id c4so8740481edl.0 for <dnsop@ietf.org>; Mon, 28 Oct 2019 11:39:24 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=tHpsC3YoBVkwtSziVEXSIxejaqBzRrLmV3BqUoN3QPw=; b=FaM5Xvz9MlrZJwmMWdr9wAyFKWO0ye3nh7DRBygcuZ7myI/YHS1ZC9ZWq6j2JRS/ED bMriPlYIg8tnUHUf7qGdFGm2K4y/iO4+Y2Q0pKlEE6RuMyKbVqutJTMgUhNt06FIIMJm rKznDH3bbI8Y7aIzFwgfLXhV+58RVrV1FxfGzWQSItqVdn+6I/r0GUBB8ftlm/3IhAww gEUaJXAMwyD+asDmBosjeSYPFrr6MunB04laqGVlWUGWqhWaOJZrWSpi7OFNj060qAs4 Q+J7lRbtMsUCaoBgI1yIKI3zeCX+q7v6YFNK6M1fB34jSIitisSC4eIUQ6UL8hd5Dyp7 d3HA==
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=tHpsC3YoBVkwtSziVEXSIxejaqBzRrLmV3BqUoN3QPw=; b=EAll1vF8HF97WBoqTKjhy2vR644hoZbXD06+Vk/77eM2JQyB+Y9oPeU9R2GjuAIM2i DHPmKtAE8po6iwhDSc6Q2dqhLNvTjRLF9L6bpucIfL4cNwfuVrdrz4WhNn3b9lPQDEc9 vouw3VFO/ZnayN8ajXeBX5u7yNlAk7A7YMC+k97qLZSLxFSFewm/4dkosW+dezxKWlme fUiH2iSm+JW8IJ74sFR5kAtBh/vl9/YDq3VCSwQzrlEqVOEgxAOe7BUJyCwnt88GnxVE tiulAvGPgwaBgCthxelOOEZJnNirstrMwQ7WVwxVUche8RefGX7wneo3LWgrWTem7aMc haaQ==
X-Gm-Message-State: APjAAAX+SQhK3ddcevB1F23LqzpxacCe9Ld9h/+elDbNq3LeYZvzQgH1 ZZvKwLOxCpe9G31K7WK6pflrZF7J54AHn04Crdnplg==
X-Google-Smtp-Source: APXvYqz1RS5xUce3JHJm1huUVD5p9W+/xQS5o73rav+Oo1w7jlp3Hs4dkQLAFeVzXqL91XA8SG9qQov2/nB2HIQ4Fpo=
X-Received: by 2002:a50:b558:: with SMTP id z24mr21274221edd.67.1572287963589; Mon, 28 Oct 2019 11:39:23 -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>
In-Reply-To: <34CACD4F-554A-4736-BD53-36D980B5A5A5@noware.co.uk>
From: Erik Kline <ek.ietf@gmail.com>
Date: Mon, 28 Oct 2019 11:39:12 -0700
Message-ID: <CAMGpriWD_dOADk4=OKFzVZn8KT9RC_A1v3jQDq6oDLuRB3K9yg@mail.gmail.com>
To: Neil Cook <neil.cook@noware.co.uk>
Cc: dnsop@ietf.org
Content-Type: multipart/alternative; boundary="0000000000008df0250595fcd139"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/musmSVuXTi1bAA6_YZOyG_4O6vE>
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:39:37 -0000

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
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?
>
> 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
>