Re: Bogus nic.fr behavior

[Måns Nilsson <mansaxel@nic-se.se>]

Subject: Re: Bogus nic.fr behavior Date: Tue, Feb 06, 2001 at 08:29:56PM -0000 Quoting D. J. Bernstein (djb@cr.yp.to):
> Nilsson writes:
> > TCP and UDP are mandatory, regardless of query size.
> 
> False. RFC 1123 _recommends_ TCP. Query size was explicitly identified
> as the reason for this recommendation: the authors believed that new DNS
> record types would someday require packets larger than 512 bytes.

I stand corrected.

> Of course, TCP is required for zone transfers, but zone transfers aren't
> required for servers. A pure secondary server, or a primary server that
> uses (say) rsync for replication, doesn't need outgoing zone transfers.
> 
> I recommend against TCP service on DNS servers that don't need it. TCP
> makes the machine unnecessarily vulnerable to denial-of-service attacks:
> opening a bunch of TCP connections will chew up memory and slow down UDP
> service much more effectively than a UDP flood at the same speed would.

All good considerations. But if you automate testing, how do you discren
between the master and slave? The SOA MNAME is not always the answer.
TCP & UDP on all servers *is* a good compromise between the most elegant
solution and the most easy to test.
 
> > it is far more likely that a generally mis-managed server would fail
> > there (and in localhost reverse) than a server that is correctly managed.
> 
> Perhaps that's true for BIND. But my DNS server goes to great effort to
> help new DNS administrators create correct configurations, and it does
> _not_ provide lame root information by default. As I said, there's a
> cost to keeping that information up to date.

Yes. But some 75% of the world *does* run BIND. I find it somewhat interesting
to optimize for the largest audience.
 
> > Also, most people still fail to understand the difference between name
> > serving and caching resolver.
> 
> My software follows the RFC 1035 model and separates these two services.
> The cache and the server run on separate IP addresses, exactly as ISPs
> have learned to do with BIND. Do you want to penalize software that does
> things right?

No, I want maximum joy for maximum people. Your DTRT model fails to deliver. 
Don't get me wrong. You and I know, as does most of the audience here,
that your approach does have a lot of merit. But not doing things just
because they are not The Ultimately Correct Solution is not operationally
feasible. Before we can get people to  appreciate the Good Things we are
talking about here we need to get them on the right track. Denying them
service unless they deliver at least a skeletal set of servers correctly
and via a unified model that fits most needs is operationally a least
horrible way of getting there. Most people doing operations as opposed
to developement seem to concur.

-- 
Måns Nilsson			DNS Technichian
+46 709 174 840			NIC-SE
+46 8 545 85 707		MN1334-RIPE

does your DRESSING ROOM have enough ASPARAGUS?