On 12 Jun 2025, at 04:23, Brian Dickson <[email protected]> wrote:
> On Jun 11, 2025, at 5:14 AM, Joe Abley <[email protected]> > wrote: > >> I don't think the recommendations in the document will do any harm, and >> some people think they are useful, so I think it is fine to publish this >> advice. (Above repeated, just as a reminder) > I think a balanced reading of the advice, which might depend on favorable > interpretation of semantics and definitions, can be actionable and an > improvement. I don't really know what this means here, but I'll note that we ought to aim for documents that are unequivocally clear, not those that are useful only if read under a full moon. > The (IMHO) reasonable expectation regarding these specific record types is > that they SHOULD be consistent across an anycast set. This is the DNS, and the DNS is specified to be loosely coherent. So, in fact, the expectation that responses are consistent across a set of authoritative servers is definitively unreasonable. Implementation of a DNS service with anycast does not change this. This is an important contract between publishers and consumers of data using the DNS protocol. Acknowledging and accommodating this contract is part and parcel of using the DNS as a control plane. If you ignore the contract, you are inviting sadness. If you try to paper over the fact you ignored it you're just making the sadness less predictable and harder to troubleshoot. If the contract makes your control plane weak, perhaps don't use the DNS as a control plane. In this case the duct tape is only being applied in places that are feeling the consequence of forgetting the contract; the consequences of ignoring the contract are largely self-inflicted and not shared with other innocent bystanders. This is why I think this proposal overall does no great harm and I think it's ok to publish. This is not the same as being in favour of duct tape. Joe _______________________________________________ DNSOP mailing list -- [email protected] To unsubscribe send an email to [email protected]
