Subject: Re: draft-ietf-nat-protocol-complications-02.txt

From: Vernon Schryver <[email-masked]>
Date: Wed, 26 Apr 2000 20:56:06 -0600 (MDT)

> From: "Steven M. Bellovin" <[email-masked]>

> ...
> There is some data indicating that Keith is right, that there are problems in 
> the DNS.  See, for example, http://www.research.att.com/~edith/Papers/infocom2000.ps

I don't think I understand the connection between that paper about
"Prefetching the Means for Dcoument Transfer: A New Approach for Reducing
Web Latency" and Keith's statement that DNS email errors are usually on
the receiver's side:

] (email errors are usually detected by the sender of a message, since
] that's who gets the bounced message.  but the party who has responsibility 
] for fixing the error is usually not on the sender's end of things)

My perhaps irrelevant, boring, or even wrong claim was that I'm seeing
more sender-side than receiver-side SMTP+DNS problems.

If the relevance of that paper is that people are have fun and
games with DNS to help HTTP, and that causes DNS errors that in
turn cause DNS problems seen by HTTP clients, then that's consistent
with my personal experience and my claim.  I see many crazy
DNS failures in my personal web surfing.  (crazy either because
obviously silly for a very big, presumably competently run  site
or because temporary, which says either roots are hosed or the same
very big, presumably competent site is crazy...have I mentioned
lately how frequently Akamai is not working for me?)

I bet that the types and frequencies of DNS errors varies with the
application, which strikes me as a significant change from how things used
to be.  For example, how many SMTP servers are behind DNS names that do
fancy load balancing?--yes, I think I can name a very few, but isn't the
vast majority of SMTP load balancing and so forth based on turning off
the listen socket (e.g. sendmail), MX records, and non-fancy round-robin
RR serving?  On the extreme, every venture capital fund seems to still be
shoveling money at anyone who wants to try anything you'd care to mention
(and lots more besides) to make HTTP go faster, and many of those schemes
seem to involve DNS creativity.

Vernon Schryver    [email-masked]