On 7 Feb 2019, at 21:06, Mark Andrews <[email protected]> wrote: > On 8 Feb 2019, at 12:53 pm, Joe Abley <[email protected]> wrote: > >> Ohta-san, >> >> On 7 Feb 2019, at 18:28, Masataka Ohta <[email protected]> >> wrote: >> >>> Petr Spacek wrote: >>> >>>> 5. At least one NS RR must be present at the top of the zone. >>> >>> At least two. >> >> With respect, I think the protocol requirement is at least one, not at least >> two. >> >> I think best current practice is to avoid single-points of failure with the >> set of servers used to provide authoritative answers, and I agree that in >> many cases this is codified in user interfaces and registry policy as >> requiring two NS RRs. However, there is no shortage of such multiple RRs >> that refer to a single subnet or even a single instance of a nameserver >> process (so "at least two" is sometimes insufficient), and its perfectly >> possible to use anycast or both A and AAAA RRs attached to a single >> nameserver name that provide useful much more useful diversity than those >> degenerate two-NS implementations (so "just one" could in some circumstances >> be adequate). > > A single anycast server DOES NOT and never can provide diversity from the > client’s perspective. > Additionally multiple servers in the same /24 (IPv4) or same /48 (IPv6) > should be treated as a > single server for diversity testing as these are accepted longest accepted > prefixes.
That depends on what you mean by "server" and how things are provisioned. It's not 1981 and there are many valid approaches for the removal of the outer feline layers. I'll suggest that while recommendations and guidance about formulating a risk analysis are valuable outputs for this working group, absolute and broad statements are bet viewed with suspicion. No individual, no matter how well-informed and well-intentioned, can possibly know with certainty the complete situation of every relying party. I think it's best for this working group to stick to what it's good at. Joe _______________________________________________ DNSOP mailing list [email protected] https://www.ietf.org/mailman/listinfo/dnsop
