Slashdot: Providers Ignoring DNS TTL?

Sat Apr 23 03:55:23 UTC 2005

On Wed, 20 Apr 2005, Patrick W. Gilmore wrote:

> 
> On Apr 20, 2005, at 3:29 PM, Dean Anderson wrote:
> 
> >> Or don't.  No one here cares if you do.  Reality trumps lab tests.
> >
> > "Reality" for the last ten years has been that no one did either PPLB
> > or TCP DNS. That reality is changing. It'll probably start to change
> > faster, sooner. Then, users will start to notice the problems.
> 
> People have been using TCP applications on anycast for at least a  
> decade, as I mentioned before.  Since DNS responses tend to be very  
> short lived TCP session, it seems to me that if it works for other  
> applications (e.g. HTTP), it should work for DNS.

I don't know of any HTTP servers that do anycast.  But their failure to 
take account of PPLB doesn't change anything. IF they are anycasting under 
false assumptions, they'll have problems, too.

Perhaps you should read RFC 1546, which prescribes how to do TCP anycast.
Then note that TCP anycast requires OS support which is not implemented in
any unix-like system (or any system) that I know of. So, instead of
following this prescription, the (DNS) anycast promoters have relied on an
assumption of unique and slowly changing paths to eliminate the
possibility that "two successive TCP segments sent to the
   anycast peer might be delivered to completely different hosts." But
PPLB makes that "paths change slowly" assumption false, because it can use
different paths on sequential packets.

>From RFC 1546 (page 5)

How UDP and TCP Use Anycasting

   It is important to remember that anycasting is a stateless service.
   An internetwork has no obligation to deliver two successive packets
   sent to the same anycast address to the same host.

   Because UDP is stateless and anycasting is a stateless service, UDP
   can treat anycast addresses like regular IP addresses.  A UDP
   datagram sent to an anycast address is just like a unicast UDP
   datagram from the perspective of UDP and its application.  A UDP
   datagram from an anycast address is like a datagram from a unicast
   address.  Furthermore, a datagram from an anycast address to an
   anycast address can be treated by UDP as just like a unicast datagram
   (although the application semantics of such a datagram are a bit
   unclear).

   TCP's use of anycasting is less straightforward because TCP is
   stateful.  It is hard to envision how one would maintain TCP state
   with an anycast peer when two successive TCP segments sent to the
   anycast peer might be delivered to completely different hosts.

   The solution to this problem is to only permit anycast addresses as
   the remote address of a TCP SYN segment (without the ACK bit set).  A
   TCP can then initiate a connection to an anycast address.  When the
   SYN-ACK is sent back by the host that received the anycast segment,
   the initiating TCP should replace the anycast address of its peer,
   with the address of the host returning the SYN-ACK.  (The initiating
   TCP can recognize the connection for which the SYN-ACK is destined by
   treating the anycast address as a wildcard address, which matches any
   incoming SYN-ACK segment with the correct destination port and
   address and source port, provided the SYN-ACK's full address,
   including source address, does not match another connection and the
   sequence numbers in the SYN-ACK are correct.)  This approach ensures
   that a TCP, after receiving the SYN-ACK is always communicating with
   only one host.

-- 
Av8 Internet   Prepared to pay a premium for better service?
www.av8.net         faster, more reliable, better service
617 344 9000   