Subject: [RRG] transport relying on DNS

From: Brian Dickson <[email-masked]>
Date: Thu, 21 Feb 2008 20:14:56 -0500

William Herrin wrote:
>
>>  DNS lookups will *block* most applications, until the DNS resolution
>>  succeeds or fails.
>>
>>  And that has perception in user-space, but no impact to the underlying
>>  protocols.
>>
>>  However, delays *within* the transport regime, are an entirely different
>>  can of worms.
>>
>>  Unless the transport itself is modified to handle this, I think it's
>>  best to see if we can avoid this.
>>  I think it is a non-negligible issue.
>>     
>
> If I correctly understand your criticism, it's that an ongoing
> transport mustn't pause for an expired DNS TTL. I agree and this is
> addressed in the TRRP document's section on ITRs.
>   
Actually, while that is one concern, it isn't the primary or general 
concern.

The issue is, normally, DNS is used by an application, before initiating 
a connection.
And, not all connections that applications establish, involve DNS at all.

But, it is the application that knows DNS is being used.

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.)

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.

However, that means host stack changes. Not necessarily a non-starter, 
but something that would
need to be itemized in discussions of map-and-encap solutions that rely 
on DNS (such as TRRP).

Brian

--
to unsubscribe send a message to [email-masked] 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

---

From: "William Herrin" <[email-masked]>
Date: Thu, 21 Feb 2008 22:38:40 -0500

>  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.

>  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 [email-masked] [email-masked]
3005 Crane Dr. Web: <http://bill.herrin.us/>
Falls Church, VA 22042-3004