domain
Click on the red underlined text to get to the source
... timers have been set (far) too low. Especially for top level domain
nameservers this causes unnecessary traffic ...
... host was supposed to (i.e., the information was
in the root servers) run secondary for some domain (or reverse (in-
addr.arpa)) domain, without that host ...
... root servers) run secondary for some domain (or reverse (in-
addr.arpa)) domain, without that host's nameserver manager having
...
... spot this problem.
Practice has shown that most domain registrars accept registrations
of nameservers ...
... removed, can the systems
manager turn to the naming authority of the domain above the
offending domain to get the problem sorted out.
...
...
Sometimes one encounters weird names, which appear to be an external
name extended with a local domain. This is caused by forgetting to
terminate a name with a dot: names in zone files that don't end with
a dot are always expanded with the name of the current zone (the
...
... terminate a name with a dot: names in zone files that don't end with
a dot are always expanded with the name of the current zone (the
domain that the zone file stands for or the last $ORIGIN).
...
...
It is required that there be a least 2 nameservers for a domain. For
obvious reasons the nameservers for top level ...
... obvious reasons the nameservers for top level domains need to be very
well reachable from all over the Internet. This implies that there
...
... point where international and/or intercontinental lines come
together. To keep things manageable, there shouldn't be too many
servers for a domain either.
Important aspects in selecting the location of primary and secondary
...
... case of problems, changes/fixes must be carried out quickly. It
should be considered logical that primary servers for European top
level domains should run on a host in Europe, preferably (if
...
... Europe, preferably (if
possible) in the country itself. For each top level domain there
should be 2 secondary servers in Europe and 2 in the USA, but there
...
... nameserver managers
tend to overlook the fact that a host/domain listed with ANY type of
record in a zone file is NOT covered by an overall wildcard MX record
...
... record in a zone file is NOT covered by an overall wildcard MX record
in that zone; this goes not only for simple domain/host names, but
also for names that cover one or more domains ...
... domain/host names, but
also for names that cover one or more domains. Take the following
example in zone foo.bar:
...
... This makes pqr.foo.bar, def.foo.bar and abd.def.foo.bar valid
domains, but the wildcard MX record covers NONE of them, nor anything
below them. To cover everything by MX records, the required entries
...
...
In particular the zone file of a top level domain should NEVER
contain only an overall wildcard MX record (*.XX). The effect of such
...
... gateway
that the record points to. Top level domain zone files should
explicitly list at least all the officially registered primary
subdomains.
...
... provided they are allowed under a given subdomain (to be determined
by the naming authority for that domain).
Example:
...
... There has been extensive discussion about whether or not to append
the local domain to it. The conclusion was that "localhost." would be
the best solution; reasons given were:
...
... - "localhost" itself is used and expected to work on some systems.
- translating 127.0.0.1 into "localhost.my_domain" can cause some
software to connect to itself using the loopback interface when
...
... it didn't want to.
Note that all domains that contain hosts should have a "localhost" A
record in them.
...
... queries
for A records with domain names like "192.16.184.3" to go out. This
happens when users type in IP addresses and the resolver code does
...
... the root servers looking for top level domains like "3" etc. It is
strongly recommended to install the latest (publicly) available BIND
version ...
... naming authority is that of a clearing house. Anyone registering a
subdomain under a particular (top level) domain becomes naming
authority and therewith the sole responsible for that subdomain.
Requests to enter MX or NS ...
... NS records concerning such a subdomain
therefore always MUST be honored by the registrar of the next higher
domain.
Examples of practices that are not allowed are:
...
... be changed in order to get it registered (think of DEC trying to
register a domain IBM.XX).
There are also cases were one has to probe ...
... person: sending in the application - not every systems manager should
be able to register a domain name for a whole university. The naming
authority can impose certain extra rules as long as they don't
violate or conflict with the rights and interest of the registrars of
...
... violate or conflict with the rights and interest of the registrars of
subdomains; a top level domain registrar may e.g., require that there
be primary subdomain "ac" and "co" only and that subdomains be
registered under those primary subdomains.
...
... naming authority can also interfere in exceptional cases like the
one mentioned in point 4, e.g., by temporarily removing a domain's
entry from the nameserver zone files; this of course should be done
...
... When adding NS records for subdomains, top level domain nameserver
managers should realize that the people setting up ...
... 822std11(-> 2822prop), paragraph 6.2.2) is not possible in
and under that subdomain. When requested to register such a domain,
one should always notify the people of this consequence. As an
example take the name "cs", which is commonly used for Computer
Science ...
... example take the name "cs", which is commonly used for Computer
Science departments: it is also the name of the top level domain for
Czecho-Slovakia, so within the domain cs.foo.bar the user@host ...
... top level domain for
Czecho-Slovakia, so within the domain cs.foo.bar the user@host.cs is
ambiguous in that in can denote both a user on the host ...
... Mockapetris, P., "Domain Names Concepts and Facilities", STD 13, RFC 1034std13, USC/Information Sciences Institute, November 1987. ...
... Mockapetris, P., "Domain Names Implementation and Specification", STD 13, RFC 1035std13, USC/Information Sciences Institute, November 1987. ...
... Partridge, C., "Mail Routing and the Domain System", STD 14, RFC 974(-> 2821prop), CSNET CIC BBN, January 1986. ...