Nice document. In section 2.5 Routing, this is written: Distributing Authoritative Name Servers via Shared Unicast Addresses... organizations implementing these practices should always provide at least one authoritative server which is not a participant in any shared unicast mesh. Could it be that by having the NS a,b in one mesh and c,d in another was a mistake? -----Original Message----- From: NANOG <nanog-bounces+jean=ddostest.me@nanog.org> On Behalf Of Masataka Ohta Sent: October 7, 2021 11:27 AM To: Bjørn Mork <bjorn@mork.no> Cc: nanog@nanog.org Subject: Re: DNS pulling BGP routes? Bjørn Mork wrote:
This is quite common to tie an underlying service announcement to BGP announcements in an Anycast or similar environment.
Yes, that is a commonly seen mistake with anycast. You don't know what you're talking about.
I do but you don't.
https://datatracker.ietf.org/doc/html/rfc4786#section-4.4.1
Not a mistake. BCP.
My comment on the rfc is that it is simply wrong. See also: https://datatracker.ietf.org/doc/html/rfc3258 While it would be possible to have some process withdraw the route for a specific server instance when it is not available, there is considerable operational complexity involved in ensuring that this occurs reliably. Given the existing DNS failover methods, the marginal improvement in performance will not be sufficient to justify the additional complexity for most uses. which was our consensus at that time in DNSOP. I have no idea why it was forgotten. Masataka Ohta