[RRG] Re: transport relying on DNS

["William Herrin" <bill@herrin.us>]

On Thu, Feb 21, 2008 at 8:14 PM, Brian Dickson <briand@ca.afilias.info> wrote:
>  If you start adding DNS into the transport itself, even remotely (e.g.
>  at an ITR), it changes,
>  however subtly, the expected behavior of the transport, especially on
>  the first packet.
>
>  And, it also presupposes that DNS servers/resolvers for root, TLDs
>  (especially arpa), and
>  reachable destinations, will be available 100% of the time. While
>  generally that is reasonable
>  to expect, it is not universally so. (There have been instances where
>  outages in some parts
>  of the Internet, left large swaths of regions without root servers
>  reachable, which was Very Bad.)

Hi Brian,

You make a fair point. DNS becomes even more critical to the
functioning of the network.

Might it be desirable to permit each AS to secondary the key zones
that would be available at the root and capture the requisite anycast
server address internally?

With TRRP, normal interior routing either has priority or exists as a
fallback until you get out to the first BGP node. This means that
local routing won't die because of an upstream failure. The AS
operator would presumably be in the best position to know whether his
network reliability and distance from the DNS root exceeds the cost of
running a root and risk of falling out of sync.


>  I will suggest, however, that making small changes to common transport
>  protocols (TCP and UDP at least),
>  to make them suitably aware and compatible with the DNS stuff going on,
>  might allay the concerns.

I can see adjusting the stack to ignore the round-trip times for the
initial SYN/SYNACK/ACK packets for congestion control purposes. This
doesn't strike me as a prerequisite but it might be desirable.

GRE's use in TRRP is intended to be a stopgap to facilitate
deployment. Down the line as we talk about the successor protocol to
GRE, it might be desirable to adjust the host stack to handle things
like path MTU discovery when the outer source address has been set to
the same as the inner address.  To my mind that's a discussion for
later, though. I'd rather get it into the field using a tunnelling
protocol that already exists and then, if it proves successful,
contemplate more intrusive enhancements.

What else do you have in mind?

Regards,
Bill Herrin


-- 
William D. Herrin herrin@dirtside.com bill@herrin.us
3005 Crane Dr. Web: <http://bill.herrin.us/>
Falls Church, VA 22042-3004

--
to unsubscribe send a message to rrg-request@psg.com with the
word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/rrg/> & ftp://psg.com/pub/lists/rrg