Re: [DNSOP] [Ext] Call for Adoption: draft-sah-resolver-information

[Brian Dickson <[e-mail]>]

+1 to everything Joe wrote below. (There should be an automatic +1 to
things Joe writes.)

I'd like to suggest an approach to the issues of DNS forwarders + NATs of
varying depth/scope, but I think there may be some extra protocol work in
order to address these problems.

Also, I think there would be additional value in that extra work, in the
form of a "DNS traceroute" that would be possible.

Here are two conundrums:

   - Forwarding:
      - The server side of a DNS resolver (or forwarder) cannot determine
      if the client is a vanilla host (or stub or whatever), or a forwarder.
      - The client side of a DNS resolver (or forwarder) cannot determine
      if the server it is talking to is a full resolver or merely a forwarder.
      - Corollary: a forwarder cannot determine whether it is the only
      forwarder in a resolution path
   - EDNS:
      - EDNS is hop-by-hop
      - Thus, EDNS does not facilitate new EDNS records that might allow a
      client to pass stuff to the eventual resolver, or vice versa

There are two things, which combined, would get around this issue:

   - A way to pass an EDNS type to discover the identifier of every server
   (including forwarders) in a resolution chain
      - E.g. a transitive EDNS Type, that would have no entries on the
      query, but would include an ordered list of identities in the response
   - A way to target a DNS query at a specific identified forwarder/resolver
      - E.g. a transitive EDNS Type, indicating that only the
      forwarder/resolver with the specified ID should answer, and otherwise the
      query should be passed "upwards"

Use of these two hypothetical mechanisms would facilitate this RESINFO
draft (and do so within DNS itself).

It's too bad that the original spec for EDNS didn't include a bit in the
Type field for "transitive", the way that BGP attributes did. (Doing that
allows "unknown" types to be passed or dropped based solely on that bit.)

I realize that "transitive" only has any meaning in the forwarder context,
since recursive-authoritative is technically unrelated to
client-(forwarder*)-recursive.

I'm not sure it would be feasible at this point to propose fixing the
exclusively hop-by-hop nature of EDNS. However, I think there will always
be value and need for this, so perhaps doing it sooner would be less
painful.

Thoughts?

Brian

On Mon, Aug 5, 2019 at 5:53 AM Joe Abley <[e-mail]> wrote:

> On 4 Aug 2019, at 21:00, Martin Thomson <[e-mail]> wrote:
>
> > On Sun, Aug 4, 2019, at 00:37, Paul Hoffman wrote:
> >>> I think that I might have said this before, but I don't think that
> asking an HTTP server about a DNS server is the right solution.
> >>
> >> It is not "the" right solution, but it is one of them. That's why there
> >> is also a DNS-based solution in the same document.
> >
> > Let me be slightly more pointed then.  I think that documenting a
> solution that has one protocol speak for another would be a bad idea.  Even
> if there is a better way to do the same thing in a "better" way.
>
> and
>
> >>> The RESINFO RRtype seems OK, but I have less confidence in my ability
> to assess that aspect of this.  The only thing that bothers me is the
> potential for 1.0.0.10.in-addr.arpa and friends to leak and ruin the
> protocol for everyone.
> >>
> >> Please say more here. Who do you think would be publishing at 10.0.0.1?
> >
> > A good proportion of the resolvers I talk to operate from 1918 space,
> how else would they advertise this information?  I don't care if they are
> merely proxies, and nor should it matter if they are.
> >
> > The fact that they are proxies means that my ISP is likely going to be
> the one fielding RESINFO queries for 10.0.0.1 and friends.
>
> together also trigger discomfort for me. DNS and HTTP requests might
> generally follow the same gradient as far as network address translation
> goes (escaping to ever-shallower NAT domains) but it's worth remembering
> that the gateways between the layers are not always just gateways at the IP
> layer; some are ALGs. The addresses that services are reachable at can can
> change between layers, as (in general) do the addresses used for proxy
> requests in the case of ALGs.
>
> I'm concerned about the cases where:
>
> (a) the data enclosed within a RESINFO response includes embedded IP
> addresses that may not match the addresses that correspond to the resolver
> service as viewed from another addressing domain, and
>
> (b) the potential for HTTPS and DNS ALGs to further confuse matters as the
> system generating the RESINFO response for one retrieval protocol might not
> be the same as for the other.
>
> I realise it's tempting to imagine that HTTPS is not subject to explicit
> or implicit handling by ALGs; however, anecdotally at least, SSL-stripping
> (e.g. with jurisdiction-specific trust anchors installed on clients) is on
> the rise and not just in enterprise networks. I've also seen networks where
> traffic is routed by policy in different directions according to
> transport-layer addresses, e.g. for reasons of available capacity or
> latency.
>
> So I echo the concern about having one protocol speaking for another. I
> haven't quite got my head around what I think about RESINFO in general but
> this particular aspect seems like a more general weakness that is worth
> highlighting.
>
>
> Joe
> _______________________________________________
> DNSOP mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dnsop
>