William Herrin wrote:
Actually, while that is one concern, it isn't the primary or general concern.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.
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 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