Re: [Add] [EXTERNAL] Re: Zone ownership in DNS server discovery

[Tommy Jensen <[e-mail]>]

Hey Joe,

I don't think "a resolver that cannot perform all resolution itself" is equivalent to "it has no per-name behavior at all". Stub resolvers such as the one in my product will have a set of resolvers for the general case as well as rules per domain indicating different servers should be used. Examples include names that can only be routed internally ("*.<my-employer>.com") and querying different servers to enable lower cost content loading ("*.<foo-streaming-service>.com", "*.<my-carrier-billing>.com"). I don't think this not-fully-recursive behavior disqualifies client from being stubs.

So to reiterate, I think discovering a DNS server is designated for a set of names is DNS resolver information, and we're chartered to "Define a mechanism that allows communication of DNS resolver information to clients for use in selection decisions". I don't think the definition of "clients" need be as rigid as you claim. I do think the use case discussion is more urgent however so I'll shut up about this for now.

To Vittorio's comments: I think your concern is more related to the policy of implementations, which is not in scope. My point is simply an encrypted DNS server may have name ownership or designation as a property and since clients do use name-based routing logic today already, would find it useful to discover this information. Unlike policy-specific information (ex: "server filters content"), this infromation can be securely defined using existing mechanisms (PKI).

Thanks,
Tommy

================================================

The latest in Windows Internet Protocols:

  Native gRPC support: https://aka.ms/grpcblogpost

  DNS over HTTPS: https://aka.ms/dohblogpost

________________________________
From: Joe Abley <[e-mail]>
Sent: Friday, September 11, 2020 3:33 AM
To: Tommy Jensen <[e-mail]>
Cc: Jim Reid <[e-mail]>; ADD Mailing list <[e-mail]>
Subject: [EXTERNAL] Re: [Add] Zone ownership in DNS server discovery

Hi Tommy,

On Sep 10, 2020, at 18:32, Tommy Jensen <Jensen.Thomas=[e-mail]> wrote:

Changing subject line to avoid the noise on Martin's single use case. This is a separate topic.

>From the WG charter:

> Define a mechanism that allows communication of DNS resolver
> information to clients for use in selection decisions. This could be
> part of the mechanism used for discovery, above

If I know "doh.example.com" is authoritative for "foo.example.com", I may prefer to take *.foo.example.com queries directly to it instead of using an intermediary recursive.

In the taxonomy described in RFC 8499, "clients" in the ADD charter refers to "stub resolver" -- "a resolver that cannot perform all resolution itself". The phrase "resolver information" in the charter refers to information about "recursive resolvers" -- resolvers that operate in "recursive mode".

What you are describing above is a hybrid entity that behaves like a stub resolver in some cases but like a recursive resolver in others. The opportunistic choice of transport between this new entity and a particular authoritative server is by definition not communication between stub resolver and recursive resolver (as defined in RFC 8499) or between client and resolver (as described in the ADD charter).

This might be an interesting discussion to start in DNSOP, perhaps as part of a larger discussion about capabilities negotiation between authoritative servers and their clients, but I think it's out of scope for ADD.


Joe