Xref: utzoo comp.mail.sendmail:89 comp.dcom.lans:1829
Path: utzoo!utgpu!water!watmath!clyde!att!osu-cis!tut.cis.ohio-state.edu!ukma!rutgers!elbereth.rutgers.edu!aramis.rutgers.edu!athos.rutgers.edu!hedrick
From: hedrick@athos.rutgers.edu (Charles Hedrick)
Newsgroups: comp.mail.sendmail,comp.dcom.lans
Subject: Re: sendmail, the resolver and /etc/hosts
Message-ID: 
Date: 21 Sep 88 18:48:29 GMT
References: <713@ncar.ucar.edu> <1469@valhalla.ee.rochester.edu>  <1473@valhalla.ee.rochester.edu> <285@hal.UUCP> <729@ncar.ucar.edu> <286@hal.UUCP> <733@ncar.ucar.edu>
Organization: Rutgers Univ., New Brunswick, N.J.
Lines: 48

>  Does this mean that the NIC's root servers provide host information for
>registered hosts in domains that do not yet have working name servers?
>That is what would be required for your statement to be correct.

Not quite.  What it means is that you aren't allowed to start using a
domain until that domain has working name servers.  Until that point,
you can only register hosts in .arpa or some other generic domain.
"registered hosts in domains that do not yet have working name
servers" is a contradiction in terms.

What I think happens is that in practice there's a period of time
during which things are in transition, and so bad things happen.
This can happen in two ways:

1) A site asks for authorization from NIC to create a domain, and
immediately starts using domain-format names, without waiting
for NIC's response.  We had that problem with a neighboring site.
We kept getting mail from foo.bar.edu, but the root servers hadn't
heard of bar.edu.  The management of bar said "oh, well, we've
asked NIC to register bar, but things are being held up."  We
fixed this by telling our name servers about bar's name servers.

2) A site asks for authorization to use a domain before they've
got name servers running.  This is perfectly OK, but they shouldn't
start using domain-format names until they've got the servers up.

In both cases, the basic problem is the same: It is not allowed to use
a name foo.bar.edu until bar.edu is both (1) authorized by the NIC and
(2) has working name servers.  Until that happens, mail should be sent
out with return addresses of the form user%foo@bar.arpa, where
bar.arpa is a mail gateway that is in the NIC host table and is
prepared to forward mail to all of your internal sites.  If the domain
has been authorized but does not yet have working name servers,
another approach is to have the NIC delegate the domain to a temporary
set of name servers.  These would have a single MX entry that points
*.bar.edu to your relay machine.  Once you get your real name servers
up you would then tell the NIC to change the delegation to point to
them.

If this problem is common enough to be worth worrying about, NIC 
could do a couple of things to help:
  - change the domain application to have a note at the bottom:
	WARNING: do not start using host names in this domain
	until (1) the NIC has notified you that the root domain
	servers have delegated it to your name servers and (2)
	your name servers are operational.
  - when they get requests to add new hosts to the host table,
	first check that a domain query can find them.