Slashdot: Providers Ignoring DNS TTL?

Mon May 2 01:09:50 UTC 2005

On Sun, 1 May 2005, Edward B. Dreger wrote:

> You object to SMTP+AUTH because it isn't standard:
> 
> http://www.merit.edu/mail/archives/nanog/199-11/msg00263.html
> http://www.merit.edu/mail/archives/nanog/199-11/msg00289.html

Neither of these links actually work.  But it is "Draft Standard". That is
different from saying it is "Standard".  It is not "Standard", and is
still not "Standard", some 7 years after it went to Draft.  All of my
criticisms (made presumably in 1999), were correct. In 2005, SMTP AUTH is
basically dead. There hasn't been a new mail client supporting SMTP AUTH 
in many years.  What would be the point?

> You complain that SMTP+AUTH "doesn't scale"... yet viewing open relay
> logfiles for abusers scales?!  Someone needs to put down the crackpipe.

Actually, it does scale, and very nicely. Its almost trivially easy to
automatically spot and block abusers. Blocking scanning prevents open
relays from being found. And if they aren't found by open-relay
blacklists, they aren't abused and there are no problems whatsoever.  
This requires almost no attention at all--Just ordinary daily and weekly
usage reports, and automated detection and blocking of scans. This is
helped along by blocking the blacklists nameservers, so even if they get a
message in, it won't get delivered back to them, preventing them from 
discovering and abusing the relay.

By contrast, its much, *much* harder to manage thousands of user accounts
and passwords. This requires much customer service attention, and that's
expensive.  And when you offer backup SMTP service to a corporation for a
relative pittance, you don't want to have to take on the headache of
keeping all of their usernames and passwords. Many providers run open
relays. They don't advertise this fact, due to, well, abusers like Matthew
Sullivan. *You* need to put down the crackpipe.

> Yet you cite RFC1546 as the One True Anycast.  Is RFC1546 a standard?
> What does its first paragraph say, again?

RFC 1546 is Category: Informational 

However, its "informational" category doesn't mean one can mislead people
into believing that "Vixie-cast" complies with RFC 1546.  Calling it "TCP
Anycast" and then referring to RFC 1546, misleads people. And criticism is 
well-deserved.

If someone wants to create their own version of Anycast, let them.  But
they shouldn't mislead people that their version is the same as RFC 1546's
version---when in fact they aren't the same.  And "Vixie-cast" isn't
*anything* like RFC 1546 TCP Anycast.  And the fact that they have misled
people is probably operational news. Especially since the DNS root server
operators also assumed the Vixie was serving as their liason to the IETF,
and that the IETF had "blessed" Vixie-cast.

Its one thing to setup some random servers with some hairbrained scheme.
Its quite another to installed some untested, non-standard, and unapproved
configuration on critical network infrastructure like the DNS root
nameservers.

> DA> You really haven't been paying attention: There's no chance of that at
> DA> all:  It isn't possible to build "vixie-cast" clusters that work around
> DA> PPLB. There are no topologies which include diverse paths that avoid
> DA> problems.
> 
> http://www.merit.edu/mail/archives/nanog/msg07220.html
> 
> Read what I said.  Did I say "vixie-cast" clusters?  Did I specify a
> particular topology, or suggest choosing topologies that work?  

You said:

  "As for anycast, there's a fair chance people building anycast clusters
  will work around PPLB.  Maybe they'll build topologies to avoid
  problems.  Maybe they'll have behind-the-scenes unicast intelligence to
  deal with TCP session transfer."

That would be "Vixie-cast" clusters. As I already said, UDP anycast has 
no problem. And I noted that RFC 1546 TCP Anycast has no problem with 
PPLB on diverse paths. That leaves only "vixie-cast" clusters.

And you also indicated that there might exist a topology involving PPLB on
diverse paths that might work.  But there isn't one. There isn't any
"behind-the-scenes unicast intelligence to deal with TCP session transfer"  
other than that described by RFC 1546, which involves changes to the TCP
stack on each machine, including the client machine.

Someone needs to put out their pipe and actually read most of the thread.

> Even when the thread is is plain sight for all to reference, you fail to
> cite correctly.  Someone needs to put down the crackpipe.

I cited it correctly.

> You claim PPLB over widely diverging paths will become increasingly
> common.  If that actually happened, guess what would happen to unicast
> TCP?  

Nothing much. At worst, a performance problem for older TCP stacks. In 
stacks that can handle insertions, nothing at all.

> Guess what would happen to many UDP-based protocols over unicast?

Nothing whatsoever would happen. A protocol implementation that doesn't
behave correctly with out-of-order packets might have a problem. But this
is an implementation problem. There is no obligation for an internetwork
to deliver packets in order, either.

		--Dean

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