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

[Ben Schwartz <[e-mail]>]

On Mon, Oct 28, 2019 at 2:40 PM Erik Kline <[e-mail]> 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 <[e-mail]> 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 <[e-mail]> 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, [e-mail] 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
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/dnsop
>>
> _______________________________________________
> DNSOP mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dnsop
>