Thus spake "wayne" <wayne@xxxxxxxxxxx> > In <7230.1127829972@xxxxxxxxxxxxx> Robert Elz <kre@xxxxxxxxxxxxx> writes: > > Anycast does not work (or perhaps more correctly, in some > > circumstances when there is routing instability, will not work) with > > fragmented UDP packets (the size of the packets is irrelevant, only > > whether they are fragmented), when sending those fragments *to* > > an anycast address. > > In order for anycast DNS to fail, either due to the use of TCP or in > cases where the UDP DNS query was fragmented, doesn't the network > routing instability have to be such that retries also fail? A single > failure isn't fatal, after all. The routes would have to be flapping > pretty badly to most of the root servers (anycast or not) for this to > cause any problems, in which case, I think we would be far more > worried about other things. The issue is when a network, usually at neither the client nor server end of the path, uses PPLB such that packets from the same TCP query or fragments of a single large UDP query will consistently arrive at different anycast server instances. The IETF and network operators have long understood that this is a Bad Thing(tm) in general, and is one of a long list of reasons why PPLB is strongly discouraged and sees little use today [1]. > > It is anycast at the root name servers that you seem to be > > complaining about. If the root servers are going fine grained load > > balancing, then it would not only be routing instability that would > > result in a switch of server. I am by no means convinced that even > > that would be any kind of a serious problem for the root servers (or > > those sending legitimate queries to them [...] > > I'm not sure I see any problem at all here, serious or not. Even if a > root server is doing fine grained load balancing, all the packets will > still end up at the destination address, where fragments can be > reassembled and out of order reception can be resolved. Anycast in the face of PPLB has been accepted (by most of us, at least) specifically for the root servers because current queries to the roots do not need to be fragmented and do not use TCP. It appears that Dean is alleging that DNSSEC will cause queries to the roots to be fragmented or to be transmitted over TCP, thus invalidating the exception which allows root server operators to use anycast. While I admit to not having followed the DNSOP list, I've seen no substantiated claims so far that indicate DNSSEC will cause queries to exceed the minimum MTUs for IPv4 and/or for IPv6 [2]. > Right now, it looks like in theory, the use of anycast DNS servers > can't be a significant problem. So far, I have seen no demonstrations > of practical problems. To the best of my understanding, this has been > the state of the debate for years now. If Dean (or someone else) shows that the above problem case will indeed occur in real-world situations, the criticism of DNSSEC and/or anycasting is valid and one of the two needs to be fixed. > This looks like a tempest in a teapot to me. Based on the messages to the IETF list so far, it appears so. For the record, I support a PR action against Dean due to his consistent provocation of flame wars, particularly as they form a long-term pattern of harassment of a particular company or persons. Note that I consider it irrelevant whether his position in this or any past instance turns out to be correct: it's the form, not the content, of his efforts that is the problem. S [1] Many modern routers, particularly ones used in the Internet core, do not even have the ability to enable PPLB, and the places where I've seen it used in the last five years have exclusively been topologies that will always re-merge the balanced traffic further upstream. [2] I have seen misguided operators set MTUs below 200 bytes, but my position is that these people deserve what they get in such cases. We cannot cater to deliberately broken implementations. Stephen Sprunk "Stupid people surround themselves with smart CCIE #3723 people. Smart people surround themselves with K5SSS smart people who disagree with them." --Aaron Sorkin _______________________________________________ Ietf@xxxxxxxx https://www1.ietf.org/mailman/listinfo/ietf