Re: [DNSOP] Authoritative servers announcing capabilities

[Joe Abley <[e-mail]>]

On Sep 12, 2020, at 02:47, Paul Vixie <[e-mail]> wrote:

> On Sat, Sep 12, 2020 at 09:40:11AM +1000, Mark Andrews wrote:
>> and why is it a RR type at all.  An EDNS option or a opcode is better suited
>> for this sort of thing.
> 
> +1.

Plus lots. See below for TL;DR.

Operational reality is that there are often a different set of nameservers authoritative for the zone than are anticipated by whomever is responsible for the zone contents. Examples are mismatches between NS RRSets above and below the zone cut, and people opportunistically serving zones from from their own authoritative servers for their own local reasons (e.g. RFC 8806).

It's not reasonable to assume that all authoritative servers for any particular zone have the same server characteristics. Almost by definition, different servers live in different places with different local conditions in all layers up to and beyond 9, operated by different people with no existing requirement to centralise operational changes with the people responsible for zone data. To address the example given in the draft, it's ok some authoritative servers for a zone support ECS and others do not; some will give ECS-specific answers and some will not. Clients will still get answers. More generally, if the goal is a general mechanism that might be used to describe as-yet-unknown characteristics about a server, it ought to allow individual servers to be described.

It's not reasonable to assume that an individual hostname as exposed in a single NS RR corresponds to a single server. Authoritative servers are routinely provisioned as clusters or anycast clouds, and the details of what individual server might look like can change between successive queries.

It's always possible to imagine a very simple set of authoritative servers for a particular zone which would not run into these kinds of problems. However, such a mechanism would fail in exciting ways for pretty much any zone you can imagine that sees any real traffic. High-traffic zones with twitchy end-users are not usually provisioned in onto static, simple sets of authoritative servers.

If there is to be a general mechanism that describes the characteristic of an individual authoritative server, it ought to be one that embeds information in a specific response in such a way that it will never normally be cached.

Whether there is a convincing use-case for such a mechanism is a separate question. The example given in the draft does not seem very convincing, simply because there is an existing mechanism to achieve the same thing (see RFC 7871 section 7.2.1).


Joe