Let me leave some personal opnion/comments on this AUTHINFO idea,
although I don't know the background here.
There are multiple kinds of "capabilities" of an authoritative server.
Some of them are properties of the zone, some are properties of the DNS
server implementation, some are properties of the operational policy.
For examples: DNS algorithm, EDNS version, network MTU, respectively.
While it seems reasonable to disclose some properties of the zone by an
extra zone RR (although it would probably require extra query!), the
properties of DNS server will often vary since implementation diversity
is a general recommendation.
I don't know the foreseeable use-cases for this or similar kinds of
properties signalization. The listed examples are already signalized
another way (EDNS buf size), or useless (DNSSEC presence and DNSKEY
algorithm).
By the way, the operators tend to hide properties of their server
implementations, rather than disclose it. See version.server. CH TXT ...
BR,
Libor
PS: i'm very sorry for the previous e-mails. My client got somehow mad
and sent the e-mail while I was typing it!
Dne 12.09.20 v 03:40 Paul Vixie napsal(a):
On Fri, Sep 11, 2020 at 09:04:02PM -0400, Paul Wouters wrote:
On Sep 11, 2020, at 20:48, Paul Vixie <p...@redbarn.org> 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.
An RR type can be signed and distributed differently and allow for
preloading of (distributed) caches which enhanced the decentralization of
recursive DNS servers.
an authority server's capabilities are with respect to a zone. for example,
dnssec availability, dnssec details like algs, maximum message sizes,
truncation policy, willingness to do persistent TCP (or QUIC) sessions.
our community seems hell bent on gradually evolving the system toward the
needs that micro-leasing would address, without actually understanding that
or getting there. _it's never about the server_.
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
