Subject: [DNSOP] New draft, seeking comments: draft-sah-resolver-information

From: Paul Hoffman <[email-masked]>
Date: Tue, 30 Apr 2019 21:09:47 +0000

[[ GAAAAH. The abstract of the draft says it should be discussed on the ADD list. That's wrong, it belongs here. ]]

[[ GAAAAH2. I didn't include the draft info.
        Title           : DNS Resolver Information Self-publication
        Authors         : Puneet Sood
                          Roy Arends
                          Paul Hoffman
	Filename        : draft-sah-resolver-information-00.txt
	Pages           : 9
	Date            : 2019-04-30  ]]

Greetings again. Puneet, Roy and I have just published a -00 with an idea for how to get information about a recursive resolver from the resolver, if it wants to give that information. This is an outgrowth of my earlier work in the DOH WG on draft-ietf-doh-resolver-associated-doh. The discussion on that latter draft in Prague had a couple of people saying "this should be more general than just DoH" and "what about DoT", which sparked the idea for draft-sah-resolver-information.

Note as you read this document that we have *not* started filling in the kind of information that a resolver might return; we haven't even specified the DoH stuff. We wanted to be sure that DNSOP folks thought that the direction here might be viable; if so, I'll write an associated draft for a resolver's associated DoH and DoT servers, and some of you might start writing drafts for other ideas.

Also note that this is explicitly only for resolvers; we might later do a second protocol for authoritative servers who want to give information about themselves (such as if they do DoT, if that moves forward in DPRIVE). The reason for the split is that a resolver that doesn't know the protocol here might pass the query on to the authoritative servers for the root or .arpa, and the response to the stub would then be ambiguous.

We look forward to your bashing and/or support.

--Paul Hoffman

---

From: Paul Vixie <[email-masked]>
Date: Tue, 30 Apr 2019 14:16:33 -0700

can dns be like tcp, put into maintainance mode, no new features?

---

From: Erik Kline <[email-masked]>
Date: Tue, 30 Apr 2019 14:17:06 -0700

Can I ask why you went with resolver-info.arpa instead of
<rev-ip>.{in-addr,ip6}.arpa of the resolver IP to which the query is being
issued?  I think the temp-field2.<stuff> trick still works, and maybe we
could get DNSSEC validation (IDK about dnssec validation in the rev-ip
.arpa space).

On Tue, 30 Apr 2019 at 14:10, Paul Hoffman <[email-masked]> wrote:

> [[ GAAAAH. The abstract of the draft says it should be discussed on the
> ADD list. That's wrong, it belongs here. ]]
>
> Greetings again. Puneet, Roy and I have just published a -00 with an idea
> for how to get information about a recursive resolver from the resolver, if
> it wants to give that information. This is an outgrowth of my earlier work
> in the DOH WG on draft-ietf-doh-resolver-associated-doh. The discussion on
> that latter draft in Prague had a couple of people saying "this should be
> more general than just DoH" and "what about DoT", which sparked the idea
> for draft-sah-resolver-information.
>
> Note as you read this document that we have *not* started filling in the
> kind of information that a resolver might return; we haven't even specified
> the DoH stuff. We wanted to be sure that DNSOP folks thought that the
> direction here might be viable; if so, I'll write an associated draft for a
> resolver's associated DoH and DoT servers, and some of you might start
> writing drafts for other ideas.
>
> Also note that this is explicitly only for resolvers; we might later do a
> second protocol for authoritative servers who want to give information
> about themselves (such as if they do DoT, if that moves forward in DPRIVE).
> The reason for the split is that a resolver that doesn't know the protocol
> here might pass the query on to the authoritative servers for the root or
> .arpa, and the response to the stub would then be ambiguous.
>
> _______________________________________________
> DNSOP mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dnsop
>

---

From: "Ralf Weber" <[email-masked]>
Date: Tue, 30 Apr 2019 14:26:27 -0700

Moin!

> can dns be like tcp, put into maintainance mode, no new features?
That was the hope I believe when dnsext was closed, but then dnsop 
extended it’s charter and here we are. While I’m not disagreeing 
with what you propose I believe that ship has sailed.

And I’ll read the document and comment on it later…

So long
-Ralf
—--
Ralf Weber

---

From: Brian Dickson <[email-masked]>
Date: Tue, 30 Apr 2019 16:44:00 -0700

> We look forward to your bashing and/or support.

TL;DR: RFC-1918 potentially messes a lot of things up, including the
ability to bypass any forwarders to talk directly to the resolver being
used.

So, there are some semantic issues that lead to potential problems on
naming/addressing (literally) the intended target.

The roots of the problem below are that:

   - A DNS server can't distinguish between a stub client and a client
   which is a forwarder.
   - A DNS client can't distinguish between a server which is a resolver,
   and a server which is a forwarder.
   - A DNS forwarder can tell nothing about its own downstream or upstream
   - There is no inherent limit on the depth of a forwarding tree
   - Add on selective forwarding, and multiple server addresses on any
   fork, and you end up with arbitrary sized directed graphs (not even
   guaranteed to be acyclic!).

Specifically, regarding the problems that intermediate forwarders can
present:

   - Presume a true "stub" client in the draft
   - Presume that client from the draft, is pointed at what it believes is
   a "resolver"
   - Now consider the possibility that the client's immediate target
   (resolver) is actually what we call a "forwarder", which
      - responds to RD=1 queries
      - possibly implements a cache
      - generally forwards to one or more other "resolvers":
         - each of which is itself indistinguishable as being a "true
         resolver" or another "forwarder"
      - Now, add more complexity from RFC-1918:
      - Each "forwarder" or "resolver" can be numbered from RFC-1918 space
      - Each "forwarder" or "resolver" may be integrated onto a
      "middle-box", which can include:
         - Providing DHCP service to clients
         - Providing DNS service to clients
         - Being a DHCP client of another entity/network
         - Forwarding its DNS queries to an upstream DNS "forwarder" or
         "resolver"
         - May have conflicting outside/inside RFC-1918 addressing schemes
      - There may specifically be an address collision between the DNS host
      IP it serves in DHCP (itself) and some DNS host it uses upstream (direct,
      or upstream^N)

In such a potentially ambiguous and potentially conflicting set of boxes,
there are several problems that can arise:

   - Without a public IP address, global public DNS can't be used (no RFC
   1918 allowed)
   - Without a public IP address, any possible name is at best of limited
   use, and reliant on the use of the correct DNS resolver to achieve name->IP
   mapping
   - Without a public IP address, the private IP address of the intended
   DNS resolver might not even be directly reachable:
      - I.e. if the actual resolver (not forwarder) has an IP address,
      which is in a conflicting RFC-1918 ranges from the perspective of the
      client.
      - E.g.:
         - The client has received a DHCP address of 192.168.0.254/24,
         - The gateway of 192.168.0.1, which is a "middle-box".
         - The middle-box is a DHCP client itself, receiving its own
         address of 192.168.0.127/25
         - The middle-box has its own gateway of 192.168.0.1.
         - Both instances of 192.168.0.1 are DNS servers, with the
         "closest" one to the client being a forwarder, and the
"further" one being
         a full resolver.
         - The full resolver cannot be reached.

(Also, as a result of these challenges, there may even be some overlap with
the "homenet" folks, not that I at all want to open that can of worms.
However, any solutions might be applicable in both areas, so it might be
worth keeping that use case in mind as well.)

It might be possible for any DNS server to establish some unique name (e.g.
a UUID or GUID label).

A UUID/GUID still presents a challenge for having the ability to use the
name, and probably any number of hacks might be needed for being able to
establish a connection to the DNS server via the name.

Restricting the draft's applicability only to publicly-addressed DNS
servers may not be sufficiently useful to warrant pursuit, unfortunately.

Ironically, the only type of DNS server guaranteed to have a public IP
address, is the authority server for a globally unique domain name.

Even if it were possible to stuff the stateful bits of DoT into EDNS
things, e.g. added to DNS over UDP, the problem is EDNS is only hop-by-hop,
not forwarded.

I've kind of run out of wacky ideas on how one might pass Do* through
forwarders, to talk to a resolver if there's any RFC-1918 conflict.

Maybe it is sufficient to discover the conflict/reachability issue, and
have an appropriate error/response with enough information for the user to
get the problem fixed?

I.e. if there is at least one forwarder, possibly doing NAT, but no
RFC-1918 conflict, the resolver should be reachable, and the only issue is
one of naming and discovery of the resolver's IP address (and NOT any of
the forwarders involved).

Maybe that could be added to one of the sections of the draft and worked on?

Brian

---

From: "John Levine" <[email-masked]>
Date: 30 Apr 2019 21:06:45 -0400

In article <[email-masked]> you write:
>-=-=-=-=-=-

in-addr.arpa and ip6.arpa are signed as are the zones delegated to the
RIRs.  I think that all of the RIRs provide a way to add DS records to
delegatd zones.  So in principle DNSSEC in the rDNS should work fine.

There is the practical issue of how much badly written software would
barf with records other than PTR in the rDNS.  I've had an MX for a
while in my rDNS zone and it seems to work OK.

Regards,
[email-masked].