Re: Bogus nic.fr behavior

[Mark.Andrews@nominum.com]

> Subject: Bogus nic.fr behavior Date: Tue, Feb 06, 2001 at 12:09:12AM -0000 Qu
> oting D. J. Bernstein (djb@cr.yp.to):
> > Servers (as opposed to caches) should not have root information unless
> > they are root servers. Caches will never ask for the information; and
> > there's a cost to copying the information and worrying about keeping it
> > up to date. These are not new observations.
> > 
> > Unfortunately, the .fr administrators won't delegate to servers that
> > don't have the current root NS records and corresponding A records.
> > 
> > This is not an isolated example. They also insist on TCP service even if
> > you don't have any big records, and 1.0.0.127.in-addr.arpa PTR records,
> > and various other server behaviors that are not relevant to DNS service.
> >
> > Where does this disease come from? Even if the .fr administrators are
> > confused about how DNS works, why do they care what other servers do?
> 
> TCP and UDP are mandatory, regardless of query size. Some of us care
> about standards compliance.

	Actually only UDP is manditory.

> 
> Real-life experience has shown that being (perhaps) excessively picky
> about the status of servers is one of the few methods we have as ccTLD
> operators, if we want to be proactive about the quality of DNS service
> on the Internet at large. I am personally responsible for implementing
> similar checks for the SE ccTLD. We feel that this adds considerable to
> the end-user experience when operators are *forced* to actually provide
> the service they charge for. A frightening amount of DNS servers appointed
> for second-level domains are in an abysmal state of malconfiguration. Who
> loses? The clueless end user, who has outsourced this, just because
> s/he does not know. They are being treated quite roughly by "web hotel"
> operators striving to maximise profit.
> 
> Ensuring that things work in a compliant fashion is a Good Thing. 
> Also, we do not need any more open relays on the Internet. 
> 
> While your comments about the need for a '.' hint file on a auth server
> (as opposed to a cache server) do contain some relevance 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. Also,
> most people still fail to understand the difference between name serving
> and caching resolver. They will run one single name server (on NT, no
> less!) on their office LAN, and use it for master and resolving. Before
> we can teach them about the difference we must make sure that they can
> resolve names at all, or they will fail to resolve the clue-inducing
> URL's we send them.
> 
> Real World operations do introduce a number of grays in addition to the
> black and white of the Ideal World.

	Yes there are gray areas.  They should cause warnings.  They
	should not stop the delegation process however.

	The only real check should be that the servers for the zone to
	be delegated are serving the zone authoratitively and that
	the NS RRset agrees with the delegation.  The later only applies
	to the first delegation.  With re-delgation the NS RRset to be
	delegated to should be a sub-set of those in the zone as that
	permits smooth transfer.

	Mark

> 
> -- 
> Måns Nilsson			DNS Technichian
> +46 709 174 840			NIC-SE
> +46 8 545 85 707		MN1334-RIPE
> 
> Will the third world war keep "Bosom Buddies" off the air?
--
Mark Andrews, Nominum Inc.
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: Mark.Andrews@nominum.com