Re: [DNSOP] Authoritative servers announcing capabilities

[Peter van Dijk <[e-mail]>]

Hello Paul, Puneet,

On Fri, 2020-09-11 at 20:37 +0000, Paul Hoffman wrote:
> Greetings. Puneet and I have an new draft, <https://tools.ietf.org/html/draft-pp-dnsop-authinfo>;, that we would like DNSOP to consider. From the abstract:
>   This document defines a new DNS RRtype, AUTHINFO, that is used by
>   authoritative servers to publish information about themselves.  This
>   information can be useful because a recursive resolver can determine
>   an authoritative server's capabilities, such as whether an
>   authoritative server supports the EDNS(0) client subnet extension.
> 
> The responses will be signed if the zone for which the server is authoritative is signed, meaning that validating resolvers can get authenticated information about the server if that would influence how they treat responses from the server.

Thank you for writing this down.

I'm not sure I'm a fan yet (ECS does not need this, and the DoT-usecase that builds upon this in DPRIVE is troublesome at least until the disconnect described below is resolved), but for now I have some comments that should improve the document.

In general, this document appears to suffer from a disconnect between 'information published by an auth about itself' and 'information published in a zone'. Elsewhere in the thread this appears to be leading to 'perhaps it should be EDNS instead', but I feel that that is a premature conclusion. Deciding on that would make more sense once this disconnect is resolved.

'Thus, the AUTHINFO Rdata returned from different authoritative servers for the same zone might differ.' (section 2) and 'The values in the AUTHINFO response will be protected by DNSSEC signature if the zone in which the record resides is signed.' (section 6) appear to be fundamentally incompatible claims (unless all auths for a domain are live-signing).

Similarly, 'Because the record with this information can be signed with DNSSEC, it can be used to help a recursive resolver know whether to expect particular EDNS(0) [RFC6891] options in responses.' in section 1 appears to conflate EDNS protocol abilities with zone contents.

'For example, if an authoritative server is authoritative for example.com, the query could be example.com/IN/AUTHINFO, or the QNAME could be any other name for which the server is authoritative.' (section 2): 'could be any other name' feels underspecified. What other names would make sense? Please be specific. (Non-exhaustive suggestions, each with their own problems: the NS name. A special name [_authinfo.arpa].) My personal preference would be that a singular choice is made here. Anything more than that would amount to more probing code in resolvers, and resolvers do not have time for that.

Expanding section '4.1 Example' to be explicit about the zone, its NSes, and the related AUTHINFO queries and responses would presumably resolve these ambiguities/incompatibilities.

Other comments:

'If the QNAME in the request is for a zone for which the authoritative server is not authoritative, the response MUST be an NXDOMAIN response.' (section 2) is wrong - NXDOMAIN is an authoritative answer, so it cannot be the answer given if the server is not authoritative. REFUSED is the usual response, but I am unsure this has been codified in any document.

The document does not specify when the AUTHINFO query is issued. Is this before any other conversation with the server, or can it be done opportunistically so that the information eventually appears in the cache? (The related dprive document hints at answers for this but does not provide enough rope either.)

Kind regards,
-- 
Peter van Dijk
PowerDNS.COM BV - https://www.powerdns.com/