Subject: [DNSOP] Request for adoption: draft-sah-resolver-information

From: Paul Hoffman <[email-masked]>
Date: Thu, 27 Jun 2019 18:44:09 +0000

Greetings. We have again updated draft-sah-resolver-information based on comments from this mailing list. We think that this is ready for adoption by the WG so that the initial use of the protocol (to be able to determine the URI template of the DoH server preferred by your current resolver) can move forward as well.

--Paul Hoffman

A New Internet-Draft is available from the on-line Internet-Drafts directories.

        Title           : DNS Resolver Information Self-publication
        Authors         : Puneet Sood
                          Roy Arends
                          Paul Hoffman
	Filename        : draft-sah-resolver-information-02.txt
	Pages           : 9
	Date            : 2019-06-27

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-sah-resolver-information/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-sah-resolver-information-02
https://datatracker.ietf.org/doc/html/draft-sah-resolver-information-02

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-sah-resolver-information-02

---

From: 神明達哉 <[email-masked]>
Date: Fri, 28 Jun 2019 13:06:55 -0700

At Thu, 27 Jun 2019 18:44:09 +0000,
Paul Hoffman <[email-masked]> wrote:

> Greetings. We have again updated draft-sah-resolver-information
> based on comments from this mailing list. We think that this is
> ready for adoption by the WG so that the initial use of the protocol
> (to be able to determine the URI template of the DoH server
> preferred by your current resolver) can move forward as well.

I don't have a strong opinion on the adoption, but I'm willing to
review it.  My comments on 02 follow:

- I think the RESINFO RDATA specification (at least its wire format,
  and preferably also the presentation format) should be more clearly
  specified.  At least to me it was not very clear, and I'm afraid
  this can lead to interoperability problems.

- It was not clear to me how the RESINFO is supported or not supported
  by authoritative servers.

  Section 1 states:
   [...]  Authoritative
   servers MUST NOT answer queries that are defined in this protocol.

  But Section 2 states:

   [...] 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.

  This sounds like an "authoritative server" may answer those queries
  (perhaps Section 1 means "real" authoritative servers, and
  authoritative only servers in particular, while Section 2 intends to
  mean "local zone" features often available in recursive server
  implementations.  But that's not really clear from the text.)

  And  Section 6 states:

   [...] or unless the
   <reverse-ip>.{in-addr,ip6}.arpa zone is signed with DNSSEC, the
   response is susceptible to forgery.

  This seems to implicate that RESINFO under a
  <reverse-ip>.{in-addr,ip6}.arpa zone could be signed and answered by
  its authoritative server.

  I think the draft needs to clarify the expected role or limitation
  of authoritative servers regarding the proposed protocol.

- (Somewhat related to the previous point) Section 2 states

   Any query for the RESINFO RRtype that is not in <reverse-ip>.{in-
   addr,ip6}.arpa/IN or a subdomain of <reverse-ip>.{in-addr,ip6}.arpa/
   IN is meaningless and MUST result in a NODATA or NXDOMAIN response.
   Resolvers would not need any special code to meet this requirement;
   [...]

  How can we enforce (with a MUST) the result of NODATA or NXDOMAIN,
  especially if the resolver doesn't do anything special for such a
  case?  If it means the resolver could just try to resolve it with
  authoritative servers and we require authoritative servers return
  NODATA or NXDOMAIN, can we always assume that?  What if the zone's
  administrator configure a zone including the RESINFO?  (And in any
  case, wouldn't it contradict the MUST NOT in Section 1?)

- The last sentence of Section 2 doesn't make sense to me:

   they only need code to handle the RESINFO RRtype that is not in
   <reverse-ip>.{in-addr,ip6}.arpa/IN or a subdomain of <reverse-
   ip>.{in-addr,ip6}.arpa/IN .

  Should it actually be "that is in" instead of "that is not in"?  If
  it's really "not in", I don't know how to interpret this in this
  context...

--
JINMEI, Tatuya

---

From: "Ralf Weber" <[email-masked]>
Date: Sat, 29 Jun 2019 23:22:53 +0200

Moin!

On 27 Jun 2019, at 20:44, Paul Hoffman wrote:

> Greetings. We have again updated draft-sah-resolver-information based 
> on comments from this mailing list. We think that this is ready for 
> adoption by the WG so that the initial use of the protocol (to be able 
> to determine the URI template of the DoH server preferred by your 
> current resolver) can move forward as well.
Couple of questions/remarks that may have been asked/answered (but are 
not discussed in the draft thus I’m asking).

- The draft offers two methods of retrieving the object but says nothing 
about which is mandatory (Me being a lazy DNS geek will certainly not 
put a web server on my DNS server so won’t implement 3). Will it still 
work? Why?
- In section 3 there is the mention of the DOMAINNAMEOFRESOLVER. I have 
no idea how any API/Interface for DNS resolvers offers the ability to 
enter a name. So where does it come from? If there is no such thing 
should we not remove it from the draft.
- The biggest issue IMHO are RFC1918 and IPv6 link local addresses as 
these are mostly used in homes for DNS resolver addresses. This means 
that the CPE - who usually is a DNS Forwarder has to answer (and 
understand) this query and either forward or answer by himself. DNS 
Proxies might not implement RFC3597. Should there be a fallback (TXT)?

So long
-Ralf
—--
Ralf Weber

---

From: Paul Hoffman <[email-masked]>
Date: Sat, 29 Jun 2019 22:55:07 +0000

Thanks for the review!

>   this can lead to interoperability problems.

It is a JSON object. What beyond that description would help?

>   of authoritative servers regarding the proposed protocol.

Good catch! We will make this clearer in the next draft by sahing that, even if the server is also an authoritative server, the responses only pertain to the recursive side.

>   case, wouldn't it contradict the MUST NOT in Section 1?)

Hrm, this is a good point. A recursive resolver might have cached a RESINFO response from some other server that it queried. We will remove the restriction.

>   it's really "not in", I don't know how to interpret this in this

The whole sentence is confusing, and we can remove it. Thus, that whole paragraph can go away.

--Paul Hoffman

---

From: Paul Hoffman <[email-masked]>
Date: Sat, 29 Jun 2019 23:01:06 +0000

On Jun 29, 2019, at 2:22 PM, Ralf Weber <[email-masked]> wrote:
> 
> Couple of questions/remarks that may have been asked/answered (but are not discussed in the draft thus I’m asking).
> 
> - The draft offers two methods of retrieving the object but says nothing about which is mandatory (Me being a lazy DNS geek will certainly not put a web server on my DNS server so won’t implement 3). Will it still work? Why?

Neither is mandatory: both are optional. That is, we cannot force a resolver to give information about itself, nor can we force it to do something abnormal for a resolver (be authoritative for a new type of query or run a web server).

> - In section 3 there is the mention of the DOMAINNAMEOFRESOLVER. I have no idea how any API/Interface for DNS resolvers offers the ability to enter a name. So where does it come from? If there is no such thing should we not remove it from the draft.

The name doesn't need to be in the config of the DNS part of the resolver: it would only appear in the TLS part, just as it does in every web server that supports TLS.

> - The biggest issue IMHO are RFC1918 and IPv6 link local addresses as these are mostly used in homes for DNS resolver addresses. This means that the CPE - who usually is a DNS Forwarder has to answer (and understand) this query and either forward or answer by himself. DNS Proxies might not implement RFC3597. 

If a resolver of any type can't be configured to give the information here, it just won't. 

> Should there be a fallback (TXT)?

I'm not sure how that would help if it can't be configured due to address issues.

--Paul Hoffman

---

From: "Ralf Weber" <[email-masked]>
Date: Sun, 30 Jun 2019 10:08:25 +0200

Moin!

On 30 Jun 2019, at 1:01, Paul Hoffman wrote:
>> - The draft offers two methods of retrieving the object but says 
>> nothing about which is mandatory (Me being a lazy DNS geek will 
>> certainly not put a web server on my DNS server so won’t implement 
>> 3). Will it still work? Why?
>
> Neither is mandatory: both are optional. That is, we cannot force a 
> resolver to give information about itself, nor can we force it to do 
> something abnormal for a resolver (be authoritative for a new type of 
> query or run a web server).
Sure you can not, but as we have seen with RFC8484 deplopyment where 
browser vendors can say, oh if you don’t speak this (our language) we 
will just go around you and talk to someone else. I want to avoid that 
situation in discovery. So we have to give the client of such a protocol 
clear guidance on what to do. IMHO try both ways and only if none work 
go back to your fallback scenario. That is missing in the draft.

> The name doesn't need to be in the config of the DNS part of the 
> resolver: it would only appear in the TLS part, just as it does in 
> every web server that supports TLS.
That does make no sense. Where does a client of discovery get the name 
from? All stub resolvers I know only have the IP configured and not a 
name. Can you explain where the name for such a call would come from?

>> Proxies might not implement RFC3597.
>
Again the problem are the consequences when it doesn’t. Which might 
happen because even though the ISP resolver has configured the RESINFO 
record it simply might not get the query if it is ignored by the proxy 
on the CPE the customer has bought, because of type.

> I'm not sure how that would help if it can't be configured due to 
DNS proxies can forward stuff and you could put wildcard answers on the 
link local/RFC1918 addresses. So you could actually make it work. But 
the likelihood of being able to forward TXT are bigger then the 
likelihood of being able to forward RESINFO, thus my question for 
fallback.

In general I don’t like the idea of traversing the reverse tree for 
that as we can not validate it in a lot of use cases anyway and the 
information we want is rather static and does not necessarily appear in 
the global DNS as it is first line resolver specific.

So long
-Ralf