On Tue, Jan 5, 2021 at 2:29 PM Eric Orth <ericorth= 40google....@dmarc.ietf.org> wrote:
> Besides future-proofing for potential changes, I think the current rule > keeps us more flexible for handling obscure cornercases. If there's any > reasonable chance that some obscure usecase in the future might make it > difficult for an authoritative to ensure only one alias is in place, it > seems to me better for the only-one-alias rule to stay a SHOULD-level rule > and keep the prescribed behavior for clients to reasonably handle it if > broken. > > I wouldn't want to change to completely enforcing only-one-alias unless > the authoritative implementers are confident that they will always be able > to absolutely ensure that they are compliant. > Speaking only for one authoritative implementer (GoDaddy), I am confident that we will always be able to absolutely ensure we are compliant. We have the exact same authority enforcement for CNAME, one per owner name. Given that this is new, greenfield stuff, I'd actually prefer a MUST rather than a SHOULD. Any updates to accommodate new use cases SHOULD be new RFCs that Update this RFC, that's the general way of progressing DNS standards, IMHO. As far as corner cases go, the only situation where two different RDATA values could arise that I can think of, would be where the loosely coherent nature of DNS comes into play (different authority servers with different versions of the zone while the zone is in flux, or possibly a zone served by authority servers operated by different parties.) However, a resolver would either have one of those values in its cache (and thus not query for a potentially different record), or not, in which case only one authority should be queried at a time. Thus the ability to obtain multiple (different) RDATA values, if enforced on the authority server, is non-existent. If it isn't possible for more than one RDATA to be returned (atomically, in a single query/response), I'd almost prefer removing the handling of "pick one", and replace it with treating a response with multiple RDATA values as a FORMERR (and try another authority, etc.) Brian
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
