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. On Tue, Jan 5, 2021 at 5:26 PM Ben Schwartz <bemasc= 40google....@dmarc.ietf.org> wrote: > On Tue, Jan 5, 2021 at 5:12 PM Paul Vixie <p...@redbarn.org> wrote: > >> a small matter. >> >> Ben Schwartz wrote on 2021-01-05 09:42: >> > >> > >> > On Wed, Dec 30, 2020 at 4:39 AM libor.peltan <libor.pel...@nic.cz >> > <mailto:libor.pel...@nic.cz>> wrote: >> > >> > Hi Ben, all, >> > i'd like to ask for some clarification of expected Authoritative >> > server behaviour around Alias SVCB records: >> > >> > 1) when there are multiple Alias SVCB records for an owner name, >> > >> > As Section 2.4.2 says "SVCB RRSets SHOULD only have a single resource >> > record in AliasMode". So this "should" not happen. >> >> can you specify that if it does happen, the client behaviour should be >> the same as if there are no matching records? otherwise clients will >> have degrees of freedom, which i think would not end well. >> > > The current draft says "If multiple are present, clients or recursive > resolvers SHOULD pick one at random.". I like that this leaves us the > possibility of relaxing the single-Alias-RR rule in the future, if we find > a use case for it. Do you think this is not a suitable recommendation? > _______________________________________________ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop >
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
