Thus spake "wayne" <wayne(_at_)schlitt(_dot_)net>
In <7230(_dot_)1127829972(_at_)munnari(_dot_)OZ(_dot_)AU> Robert Elz
<kre(_at_)munnari(_dot_)OZ(_dot_)AU> 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 mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf