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

[Brian Dickson <[e-mail]>]

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

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