[dnsext] Incoherency and draft-vandergaast-edns-client-ip-00.txt

[Brian Dickson <[e-mail]>]

Let's presume the idea here is to genuinely make a scalable, interoperable
framework for incoherent queries, with the intent of supporting "special
needs" (e.g. CDN networks and their resolvers).

Clearly, an operator of such an infrastructure could do what they like in a
closed (undocumented or at least non-standardized) fashion.

However, the idea of standardizing this has several benefits - multiple
implementations, inter-operator compatibility, overall improvement of
utility of the results.

As such, here are specific suggestions/ideas:

- Support for multiple selection criteria for incoherency (such as Paul
suggested - language, lat/long, IP, etc.). Generalize the structure, and
break out the specific entries in separate IDs/RFCs.
- Support for order-of-operations on the multiple criteria. Closest X that
supports Y,  may be different from closest Y that supports X.
- Specify the behavior of match/no-match on support for specific criteria on
an ordered set of criteria - e.g. don't care about language, do support IP,
return results that encode and parameterize the component results

And most particularly, there are two approaches that should be distinguished
between, that have drastically different characteristics in what needs to be
stored/accessed, on the recursive resolver.

If the incoherence is introduced at some referral level, it looks like this:

Root-> (ns) -> TLD -> (ns) -> Incoherent-delegator -> (ns based on edns0
option(s)) -> authority server (with coherent-to-this-server results)

This would mean that a relatively small number of nameservers, e.g. operated
by specialized service operators, or by TLD operators, or whoever, would
need to special incoherence handling.
The actual authority data caching would be based on (label,IP).

Contrast that with incoherence only at the authority server level itself:

Root -> (ns) -> TLD -> (ns) -> authority server (with
incoherent-within-this-server results, returned based on query edns0
options).

The authority data would have to be cached, and retrieved/returned, based on
(label,IP,a_bunch_of_other_parameters).

I'd suggest that an open structure, with the intent of handling incoherence
in referrals only, would be the preferred way to go.

Brian