Subject: Bogus nic.fr behavior

From: "D. J. Bernstein" <[email-masked]>
Date: 6 Feb 2001 00:09:12 -0000

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?

---Dan

---

From: Måns Nilsson <[email-masked]>
Date: Tue, 6 Feb 2001 14:00:33 +0100

> 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.

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.

-- 
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?

---

From: [email-masked]
Date: Wed, 07 Feb 2001 00:07:38 +1100

Dan,
	      I don't always agree with you but I will on this one.

	Mark

--
Mark Andrews, Nominum Inc.
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

---

From: [email-masked]
Date: Wed, 07 Feb 2001 00:58:24 +1100

> about standards compliance.

	Actually only UDP is manditory.

> 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

---

From: Mats Dufberg <[email-masked]>
Date: Tue, 6 Feb 2001 15:56:39 +0100 (CET)

> 	delegated to should be a sub-set of those in the zone as that

Well, we should expect more:

* All NS records in the zone must point at authoritative servers.

* If glue is needed in the delegation, that record must be present in the
zone. And all addresses of that glue must point at authoritative servers.

* The SOA record must have a working email address.

* All non-glue NS records must point at names having an A record in its
authoritative zone.

* All servers must have identical SOA and NS RR set.

Mats

-----------------------------------------------------------------
Mats Dufberg                                    [email-masked]
NIC-SE                                           +46-8-545 857 06
Box 5774                                    fax: +46-8-545 857 29
SE-114 87 Stockholm                         http://www.nic-se.se/

---

From: Robert Elz <[email-masked]>
Date: Tue, 06 Feb 2001 21:58:29 +0700

Date:        Wed, 07 Feb 2001 00:58:24 +1100
    From:        [email-masked]
    Message-ID:  <[email-masked]>

  |  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.

That's nonsense - the parent data is just glue, and should always
be identical to that in the zone itself.

To get "smooth transfer" the new servers should be set up, and then
the old servers made secondary for that (so they start giving out the
new data).   Then the parent should be updated.

That depends upon the DNS property of there being old data for a while
after a change (the parent has old data until it s updated) but never
does the data held by the parent not reflect the data in the autjoritative
zone file, at some particular point in time.

Allowing configurations where the new servers list the old servers just
begs for the new servers to do that, without the old servers ever having
any idea it is happening - which is a genuine recipe for making a
gigantic mess.

kre

---

From: Robert Elz <[email-masked]>
Date: Tue, 06 Feb 2001 20:16:40 +0700

Date:        6 Feb 2001 00:09:12 -0000
    From:        "D. J. Bernstein" <[email-masked]>
    Message-ID:  <[email-masked]>

  | Servers (as opposed to caches) should not have root information unless
  | they are root servers.

From where did this startling variation on accepted practice arrive?

All servers, when queried, should either return an answer (doing the
recursive thing if they want to, and that was requested in the query)
or should return a referral to a better server to ask.   When no other
information is available, the root servers are the better server to
ask.   This has been a part of DNS operations since day 1.

It doesn't matter whether you think the server in question should ever
have been sent the query or not.

  | Caches will never ask for the information;

You mean a cache which is operating and configured properly won't.

  | and there's a cost to copying the information and worrying about keeping it
  | up to date. These are not new observations.

There is, and no, they're not.   Fortunately most rational servers do
the trivial amount of work of finding the root servers and maintaining
that info.   Considering what was supposed to be asked of servers in the
previous little debate (mostly on the ipng list) this amount of work is
in the positively trivial and absolutely easy category.

  | Unfortunately, the .fr administrators won't delegate to servers that
  | don't have the current root NS records and corresponding A records.

Sounds like an entirely reasonable policy to me, and perhaps one I should
consider adopting in AU as well.  In general anything the DNS registrars can
do to help educate people as to what is sanely & properly configured, and
what is bogus (ie: to force them to learn, rather than just provide
information and hope) has to be a long term benefit for the net.

  | This is not an isolated example. They also insist on TCP service even if
  | you don't have any big records,

That's probably technically slightly too much (TCP support is just
a SHOULD I think), but in practice it is a good thing to check - your
average DNS administrator is never going to be able to work out when
they need TCP and when they don't (and a server implementation is very
unlikely to do so reliably either) - simply telling people to make sure
their servers support TCP and then verifying that is probably no bad thing.

Aside from anything else, I have seen cases where UDP DNS servers are
doing PMTU discovery, and then sending pre-fragmented responses, and then
brain-dead firewalls along the path are dropping the non-initial fragments.
Sometimes the only wat to get an answer from such a server is to use TCP
(then you just get smaller segments instead of fragments).

  | and 1.0.0.127.in-addr.arpa PTR records,

Hosts Requirements says that supporting address to name translation
is a MUST for servers.   Since 0.0.127.in-addr.arpa isn't delegated
anywhere, the only way a server can support a name to address translation
of 127.0.0.1 (which is a well known addres) is by being configured with
that particular PTR record.

  | and various other server behaviors that are not relevant to DNS service.

The DNS service is more than just the protocols as strictly defined.
We now have quite a few years of operational experience as to what works,
and what does not = and what is needed to be configured and what is not.

  | 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?

Part of the process of ensuring that the overall DNS (which affects all
of is) is healthy is to diagnose the problems early, and try and get them
fixed.   One of the best ways to achieve that is to simply refuse to
delegate to servers that don't function correctly.

kre

---

From: "Eric A. Hall" <[email-masked]>
Date: Tue, 06 Feb 2001 09:52:51 -0800

> a SHOULD I think), but in practice it is a good thing to check

TCP is required for MX lists which are truncated.

RFC 1123, section 6.1.3.2:

  A mailer must not use a truncated MX response, since this could
  lead to mail loops.

TCP is not required if you can restrict the number and size of MX entries
for a domain name beforehand. Otherwise nobody will be able to send mail
to the affected domain names, which will invalidate the zone.

-- 
Eric A. Hall                                        http://www.ehsco.com/
Internet Core Protocols          http://www.oreilly.com/catalog/coreprot/

---

From: [email-masked]
Date: Wed, 07 Feb 2001 09:54:35 +1100

> any idea it is happening - which is a genuine recipe for making a
	Robert you are reading more into the statement than was there.

	We know that disjoint set of nameservers in the parent and
	child cause problems.

	Now lets say you have the old and new servers that are disjoint
	sets.  There are two ways to do this.

	We are going from old to new.  All child servers are serving
	the same zone contents.

	Subset.

	Parent old  Child old
		new servers commissioned
	Parent old  Child old + new
		inform parent
	Parent new  Child old + new
	Parent new  Child new
		ttls expired, old servers de-commissioned

	Or

	Forced match.

	Parent old  Child old
		new servers commissioned
	Parent old  Child old + new
		inform parent
	Parent old + new   Child old + new
	Parent old + new   Child new
		inform parent
	Parent new   Child new
		ttls expired, old servers de-commissioned

	I am not saying

	Parent old  Child old
		new servers commissioned
	Parent old  Child new	*** broken zone ***
		inform parent
	Parent new  Child new
		ttls expired, old servers de-commissioned

	Mark

---

From: [email-masked]
Date: Wed, 07 Feb 2001 12:28:17 +1100

> % > TCP and UDP are mandatory, regardless of query size. Some of us care
> % > about standards compliance.
> % 
> % 	Actually only UDP is manditory.
> % 
> % > -- 
> % > 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: [email-masked]
> 
> 
> 	One finds that UDP is insufficent when dealing with 
> 	some of the newer, standards track RR types. Prudent
> 	SOP would ensure that TCP is mandatory ..for operations..
> 	even though the specifications lag.
> 
> --bill

	It may be prudent, should be warned about, but should not
	stop a delegation proceeding.

	Mark

---

From: Bill Manning <[email-masked]>
Date: Tue, 6 Feb 2001 16:59:17 -0800 (PST)

% > 	One finds that UDP is insufficent when dealing with 
% > 	some of the newer, standards track RR types. Prudent
% > 	SOP would ensure that TCP is mandatory ..for operations..
% > 	even though the specifications lag.
% > 
% > --bill
% 
% 	It may be prudent, should be warned about, but should not
% 	stop a delegation proceeding.
% 
% 	Mark
% --
% Mark Andrews, Nominum Inc.

	So..  I should encourage you to support TCP, warn you that
	I'm going to use standards track RR's that have known UDP
	problems and instead of making it a mandatory component of
	the delegation process, I should let the delegation proceed
	and then I'll spend -weeks- debugging the problems that 
	will occur.  No thank you.  Nip that problem in the bud
	before it eats my spare time.  
	
For a real life example...

Feb  7 01:51:11 flag named[16246]: refresh_callback: zone cairn.net/IN: truncated UDP answer, initiating TCP zone xfer 38.245.76.15#53

	Now what happens if I turn off TCP on flag?  No zone, I'm lame,
	and I claim its not my fault since TCP was not made mandatory
	at the time of delegation.  Granted, this is a research project
	but if, say Microsoft did not mandate its slaves supported TCP
	and it started using RRs that exhibit the same bahaviour as the
	cairn.net domain, then its slaves would all go "deaf" and it
	might want to seek some remedy.

	Operationally, I'm with FR nic on this. TCP is a mandatory
	precondition before I'll delegate.

--bill

---

From: Nathan Jones <[email-masked]>
Date: Wed, 7 Feb 2001 14:11:16 +1100

On Wed, Feb 07, 2001 at 09:54:35AM +1100, [email-masked] wrote:
> kre wrote:

>		ttls expired, old servers de-commissioned

How does the parent know that the child will remove the old NS records
from the RRset after delegation? As Robert alluded to in his final
paragraph, the new servers might just leave old servers listed, even
through the old servers are no longer serving the zone.

Forcing the -new- servers to have the -new- records seems natural to
me. Sure there will be a brief period where the parent's RRset does
not match the new child's RRset, but the same situation exists in your
subset example.

>		ttls expired, old servers de-commissioned

Forced match doesn't mean you have to delegate twice; you simply
delegate to new servers with new records, rather than both new and old
records. Like your final example, actually, but I don't see that it

>		ttls expired, old servers de-commissioned

When you say "parent old  child new" are you referring to the old
servers or the new servers? There are two variations:

1. Parent has old NS RRset. Old server has old NS RRset. New server
   has new NS RRset. Then the zone is redelegated from old to new.
   How is this broken? The NS RRset held by the parent always matches
   the RRset held by the child those NS records point to.

2. Parent has old NS RRset. Both old and new servers have new NS
   RRset. (Say, if the old servers are set up to secondary the new
   servers.) Then the zone is redelegated from old to new.
   Sure, there is a brief period where the parent's RRset doesn't
   match the old servers' RRset, but at least queries will be answered
   with new data.

--
nathanj

---

From: Robert Elz <[email-masked]>
Date: Wed, 07 Feb 2001 12:06:35 +0700

Date:        Wed, 07 Feb 2001 09:54:35 +1100
    From:        [email-masked]
    Message-ID:  <[email-masked]>

  | 	Robert you are reading more into the statement than was there.

No, I know exactly what you were saying.

  | 	I am not saying

But you should be, because with one addition, this is the right
way to do it...

  | 	Parent old  Child old
  | 		new servers commissioned
  | 	Parent old  Child new	*** broken zone ***
  | 		inform parent
  | 	Parent new  Child new
  | 		ttls expired, old servers de-commissioned

If this becomes

	Parent old  Child old
		new servers commissioned
	Parent old  Child old & new (both) carrying only the new NS RRset
		inform parent
	Parent new  Child new
		ttls expired, old servers de-commissioned

then you have a perfect delegation change - while the parent still
has the old data, queries will keep going to the old servers, but
they will answer with data from the new zone file (including the new
NS record set).   That the parent is (for a whort while) still giving
out the old NS records is just yet another example of the DNS having
a time lag before old data shifts to become new data (it causes no
operational problems if planned for).

Of course, this can't always be accomplished, sometimes the old servers
are decommissioned before anyone (even the operators of the old servers
sometimes...) gets to know about it...   But that's not a problem that
can be solved by changing the order or content of NS updates.

With your scheme, everything that this scheme requires still needs to be
done, the new and old servers still need to be synchronised (for you,
with both of them having the combined NS record set) - except that for
my scheme, once the parent is updated, and time allowed for TTLs to
expire, the old servers simply become irrelevant to everyone, no more
updates need be made anyway.

In any case, you can guarantee that for all delegations I do, I *always*
copy the NS record set (and glue) from the authoritative servers, I use
the info that people send me only to find those servers in the first
place.   If they include 17 servers in their NS RRset, then all 17 of
them go in the parent zone, regardless of how many they told me about
on the form (which I think only has space for 3 or 4 anyway).

From the point of view of validating that the servers being delegated to
contain data that makes sense, this is the only way, as you're not
relying on the operators of the servers making additional changes after
the delegation change at the parent (and then doing it correctly, making
sure the SOA.serial gets updated, etc).

kre

---

From: Robert Elz <[email-masked]>
Date: Wed, 07 Feb 2001 12:13:47 +0700

Date:        Tue, 6 Feb 2001 15:56:39 +0100 (CET)
    From:        Mats Dufberg <[email-masked]>
    Message-ID:  <[email-masked]>

  | Well, we should expect more:

  | * The SOA record must have a working email address.

Do you have any reliable method of testing that, without actually sending
it some e-mail and hoping someone replies, and then associating the reply
with the delegation request that caused it?

I used to like to use SMTP VRFY for this, and tried to get the drums wg
to keep it as a requirement, but too many mailer implementors didn't want
to bother doing a sane implementation (some noise about privacy, but as
you can always use "RCPT To" to test an e-mail address by seeing if mail to
it bounces, that's nonsense - the issue really comes down to whether he
SMTP client is able to figure out what is a valid address, or whether that
gets deferred to later in the e-mail processing).

So, now VRFY can't be relied upon any more - is there some other way
that anyone has found to actually automate this reasonably?

I implement all of your other tests ... plus I make sure that the nameservers
have distinct IP addresses (I'd also like to verify that the distinct addresses
actually reach different servers, rather than just two addresses allocated
to the same server, but again, this one isn't easy to verify).

kre

---

From: Randy Bush <[email-masked]>
Date: Tue, 06 Feb 2001 21:32:02 -0800

> 	precondition before I'll delegate.

sounds prudent to me.  but how to automate testing?

randy

---

From: Mats Dufberg <[email-masked]>
Date: Wed, 7 Feb 2001 10:03:35 +0100 (CET)

> with the delegation request that caused it?

No, but at least you can at least easily spot "", "localhost" and
"administrator@localhost"  as bad alternatives.

Mats

---

From: "D. J. Bernstein" <[email-masked]>
Date: 6 Feb 2001 20:29:56 -0000

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.

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.

> 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.

> 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?

---Dan

---

From: Bill Manning <[email-masked]>
Date: Tue, 6 Feb 2001 06:44:35 -0800 (PST)

--bill

---

From: "Marco d'Itri" <[email-masked]>
Date: Tue, 6 Feb 2001 17:35:05 +0100

>or should return a referral to a better server to ask.   When no other
People are supposed to send queries to an authoritative server only for
the zones it's authoritative for.
Can you explain why the server should return a referral for other
queries? This is broken behaviour anyway, and not replying may dissuade
people using it as their own recursive name server (which it is not).

-- 
ciao,
Marco

---

From: "D. J. Bernstein" <[email-masked]>
Date: 6 Feb 2001 20:46:02 -0000

My DNS cache handles 127.0.0.1 automatically. My DNS server, by default,
does not.

Robert Elz writes:
> Since 0.0.127.in-addr.arpa isn't delegated anywhere, the only way a
> server can support a name to address translation of 127.0.0.1 (which
> is a well known addres) is by being configured with that particular
> PTR record.

So you claim that the delegation of .com to j.gtld-servers.net is broken
because j.gtld-servers.net doesn't know about 127.0.0.1? You've already
sent a letter to the .com server administrators demanding that they fix
this horrible misconfiguration?

> is a MUST for servers.

You mean the part that says ``a host MUST provide a DNS interface to
facilitate translation between host addresses and host names''? Please
explain how j.gtld-servers.net is violating this requirement.

> We now have quite a few years of operational experience as to what works,

Yeah. That delegation of .com to the .com servers obviously doesn't
work. I bow down to your superior knowledge, Lord of All Things DNS.
Let's put you in charge of the root servers so that you can break .com.

> new data).   Then the parent should be updated.

Unfortunately, your procedure triggers a serious BIND bug, as explained
in http://cr.yp.to/djbdns/bugtraq/20000112082807-15140-qmail@cr-yp-to.

To avoid the bug, you have to make sure that there's always an overlap
between the NS names listed in the parent and the NS names that caches
might have (old names from the parent, old names from the child, new
names from the child).

This problem goes away if NS names are unchanging names in the server's
bailiwick: e.g., tmcs.net has servers a.ns.tmcs.net, b.ns.tmcs.net, etc.
But this doesn't work with the .com one-name-one-address policy when
someone switches ISPs.

> the parent data is just glue, and should always

The unfortunate reality is that some parents have limitations like ``at
most two NS records.'' But this is a side issue; obviously the same
parents don't complain about these limitations in their delegations.

---Dan

---

From: Robert Elz <[email-masked]>
Date: Wed, 07 Feb 2001 18:12:30 +0700

Date:        Wed, 7 Feb 2001 10:03:35 +0100 (CET)
    From:        Mats Dufberg <[email-masked]>
    Message-ID:  <[email-masked]>

  | No, but at least you can at least easily spot "", "localhost" and
  | "administrator@localhost"  as bad alternatives.

yes, and the ones where people stick "@" characters into the
DNS formatted string (producing "user@host"@domain type e-mail addresses...)

The two problems I'd particularly like to avoid are the valid looking
e-mail address that simply forwards to what appears to be a black hole
(some ISPs collecting huge collections of mail no-one ever reads, or
at least, never responds to).

And worse, the very valid looking "user.registered.dom.ain" where
"registered.dom.ain" has an MX record that points to the ISP's e-mail
server, and everything looks well configured.

Until you try and send mail to [email-masked] and get back
a bounce message "Relaying for that host denied"...

kre

---

From: Mats Dufberg <[email-masked]>
Date: Wed, 7 Feb 2001 12:59:50 +0100 (CET)

> a bounce message "Relaying for that host denied"...

It is very to validate an address of the reasons that you give above. You
can take either of two approaches; you can skip testing, or you can test
as much as is manageable. Making sure that it is a possible mail domain
(either an A or MX) is quick. Making sure that there is an SMTP server
takes longer time.

Mats

---

From: Måns Nilsson <[email-masked]>
Date: Wed, 7 Feb 2001 13:06:54 +0100

> record types would someday require packets larger than 512 bytes.

I stand corrected.

> 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.
 
> 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.
 
> have learned to do with BIND. Do you want to penalize software that does

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.

does your DRESSING ROOM have enough ASPARAGUS?

---

From: James Raftery <[email-masked]>
Date: Wed, 7 Feb 2001 12:45:01 +0000

On Wed, Feb 07, 2001 at 01:06:54PM +0100, Måns Nilsson wrote:
> between the master and slave?

Why do you need to? TCP is required for AXFR, but AXFR isn't required.
If I choose not to use AXFR to replicate my zone data then I don't need
TCP and you don't need to know which server is master or slave for your
tests.

FWIW, the .IE delegation checker doesn't look for TCP service.

Regards,

james
-- 
James Raftery (JBR54)
  "It's somewhere in the Red Hat district"  --  A network engineer's
   freudian slip when talking about Amsterdam's nightlife at RIPE 38.

---

From: Francois romieu <[email-masked]>
Date: Wed, 7 Feb 2001 13:56:19 +0000

> record types would someday require packets larger than 512 bytes.

RFC1035:
[...]
4.2. Transport

The DNS assumes that messages will be transmitted as datagrams or in a
byte stream carried by a virtual circuit.  While virtual circuits can be
used for any DNS activity, datagrams are preferred for queries due to
their lower overhead and better performance.  Zone refresh activities
must use virtual circuits because of the need for reliable transfer.

The Internet supports name server access using TCP [RFC-793] on server
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
port 53 (decimal) as well as datagram access using UDP [RFC-768] on UDP
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
port 53 (decimal).

My english is poor but if you cut TCP, you don't support TCP "as well"
as UDP. 

[...]
> uses (say) rsync for replication, doesn't need outgoing zone transfers.

Point taken.

> I recommend against TCP service on DNS servers that don't need it. TCP

Even if it's not the point of the discussion, I wouldn't advise rsync then.

[...]
> cost to keeping that information up to date.

cat > /etc/cron.monthly/root-servers <<EOF
#!/bin/sh

dig @a.root-servers.net . ns > /var/named/root.db
ci -m"Mise à jour du `date  +%Y-%m-%d`" -l /var/named/root.db
EOF

+ crontab entry.

I'd be surprised to find any security-conscious admin who can't handle that.

-- 
Ueimor
AFNIC / NIC-France

---

From: Robert Elz <[email-masked]>
Date: Wed, 07 Feb 2001 19:50:00 +0700

Date:        Wed, 7 Feb 2001 12:59:50 +0100 (CET)
    From:        Mats Dufberg <[email-masked]>
    Message-ID:  <[email-masked]>

  | It is very to validate an address of the reasons that you give above.

I am guessing that "difficult" got omitted there.  It wouldn't be if
mailers supported VRFY as 821 required though.   But that's not a dnsop
issue.

  | You can take either of two approaches; you can skip testing,

Yes, that's basically what I do at the minute, which is why I asked
whether anyone had a way to handle this.

  | or you can test as much as is manageable.

Yes, could do, but the problems I mostly see wouldn't be caught by
the simple tests often, so I'm not sure there is a lot of benefit to
them (I don't think I have ever seen anyone here attempting to use
"localhost" in there - though I have seen "" (.) which seems to be
an idea from somewhere on how to avoid spam, and of course the
consequences of $ORIGIN being appended to a FQDN).

kre

---

From: Måns Nilsson <[email-masked]>
Date: Wed, 7 Feb 2001 14:51:27 +0100

> TCP and you don't need to know which server is master or slave for your

You are way above the cluon level of the general MCP who is "Internet
Expert" at the web hotels we deal with. And therein lies the core of
the problem. Do we operate the net as if it was still only operated
by skilled people who know what a RFC is and even has read one, or do
we accept that we might have to use a little less elegant solution in
order to increase yield? Most of us wearing the Protocol hat would go for 
perfectionism. But some who do actual work might opt for function..
 
> FWIW, the .IE delegation checker doesn't look for TCP service.

Neither do we. 

my NOSE is NUMB!

---

From: Mats Dufberg <[email-masked]>
Date: Wed, 7 Feb 2001 15:35:56 +0100 (CET)

> consequences of $ORIGIN being appended to a FQDN).

localhost is not uncommon. The most common error is probably
"[email-masked]", which cannot be caught by anything else but a complete
test.

Mats

---

From: Matti Saarinen <[email-masked]>
Date: 08 Feb 2001 13:29:07 +0200

> * All servers must have identical SOA and NS RR set.

        If the DNS servers of some 2nd level domain are all running on
        Windows 2000 (which unfortunately will happen) and the zone
        has been integrated with Active Directory (which will happen,
        too) the servers will not have identical SOA RRs.

        The differences I have noticed are:
 
        - the MNAME contains the name of the server which answered to
          the query
        
        - in most cases the servers will return different serial
          numbers

-- 
- Matti -

---

From: James Raftery <[email-masked]>
Date: Thu, 8 Feb 2001 12:32:31 +0000

On Wed, Feb 07, 2001 at 02:51:27PM +0100, Måns Nilsson wrote:
> Do we operate the net as if it was still only operated

But when we run checks for user or software stupidity that
look outside of what is /required/ and into the area of what we 
consider to be /desired/ we tread a very thin line. Highlighting common
mistakes is good. Assuming that a common mistake for BIND is a common
mistake for all implementations is not good.

In this case, the AFNIC check script considers it prudent for a BIND
server to have an accurate view of the root servers. Fine. That's their
choice. But they are blindly applying that check to every request. They
shouldn't punish those who use software which isn't BIND, especially
when that alternative software is acting correctly.

Regards,

james