![[Back to DNSRD]](img/dnsrd.png)
Anyone with DiG installed (which includes anyone running BIND 4.9 or better) can generate a new cache file by typing
% dig @a.root-servers.net. . ns >root.cacheCheck this file by hand before installing it, of course.
It's only hard to recover from a typo if you're running an old BIND. If your secondaries are 4.9 or later, then you should just need two serial number changes to get back in sync:
Also refer to RFC 1982.
With the stock Ultrix 4.3 name server (and possibly other releases), all primary nameservers must be in the /etc/hosts file. Look out for the indicative "address of primary server not in local db:" message in the logs.
Cricket Liu recommends not running a name server at the site that connects via SLIP, but instead pointing the resolver at a single name server on the upstream side of the SLIP link. If the SLIP link isn't up, the resolver doesn't have a route to the server, and since there's only one name server in resolv.conf, the resolver quickly backs off to using /etc/hosts. This assumes a reasonable resolver, of course.
A lame delegation is an instance when a nameserver has been listed as authoritative for a domain, but does not seem to be performing authoritative service for that domain. That is, the nameserver appears to be answering out of its cache instead of out of its data. Note that even a server which is performing secondary service for a domain is still an authoritative server, and should be returning authoritative data.
Section 3.6.2, `Aliases and canonical names':
Domain names in RRs which point at another name should always point at
the primary name and not the alias.
In other words, the names which are on the right hand side of a resource record (RR targets) should not be on the left hand side of a CNAME resource record. Depending on how smart the resolver software is CNAME targets may work fine, but depending on correct behaviour in resolvers all around the world is guaranteed to fail somewhere.
To stop the DNS from doing a lookup when the request is to localhost, run a local caching-only nameserver which is set up to be a primary for "localhost" as well as "127.in-addr.arpa" and include the necessary DNS data in those zones to resolve the respective names/addresses. Then point your /etc/resolv.conf to your local machine. To be extra safe from DNS corruption set the server up as a primary for "255.in-addr.arpa" and "0.in-addr.arpa" also.
Domain names can contain almost any characters. However, host names and mail domain names have restrictions which only allow the use of characters `a-z', `A-Z', `0-9', and `-' (dash or minus sign). The `/' and `_' (divide or slash and underscore) characters are not legal. Note that hostnames include the owners of A and MX records and .in-addr.arpa PTR records, and the data fields of MX and .in-addr.arpa PTR records: in other words, almost all currently used DNS entries! The current releases of the BIND name server software enforce these restrictions. 20-Nov-1997, 10-Apr-1996
Since the DNS database is highly distributed, DNS does not support wildcard searching, and extraction of a complete list of domains is extremely difficult. Note that a domain name may be reserved without appearing in the DNS--there is no effective way to find out which names are reserved except to try to register them. However, to check if a domain name has been registered and appears in the DNS, there are a couple of possible approaches.
example.com is just www.example.com.
The Netcraft list of web servers
is large and searchable, so it could be used to search for domain names
that are associated with an active web server.
Setting up the client side of DNS depends on the operating environment of the client. For a Unix machine, the resolver is configured through a text file, usually /etc/resolv.conf which commonly contains the IP address of the name server or servers which will be used to do the actual work. An adequate resolv.conf file contains just the one line
nameserver x.y.z.wwhere x.y.z.w is the IP address of a suitable name server. Often this will be a server provided by the Internet service provider. It is a bad idea to point resolvers to name servers controlled by organisations with which there is no organisational relationship: the name server could be configured to return bogus information, especially if permission was not sought first for using the server.
For PC type resolvers there is usually a network configuration option which specifies the same information as resolv.conf. Each network stack tends to have its own set of configuration information. However, on MacOS, there are moves towards central network configuration.
For SunOS 4.x, the resolver is by default not set up to use DNS. The standard operating procedure to get SunOS to use DNS is in the comp.sys.sun FAQ, last I looked these were questions 1 and 2. In short,
Solaris 2.x is also not set up to use DNS by default. In the file /etc/nsswitch.conf there is a line
hosts: fileswhich needs to be changed to
hosts: files dnsfor the machine to use DNS.
Every recursive BIND name server (that is, one which is willing to go out and find something if asked something it doesn't know) will remember the measured round trip time (RTT) to each server it sends queries to. If it has a choice of several servers for some domain (like "." for example) it will use the one whose measured RTT is lowest.
Since the measured RTT of all NS RRs starts at zero (0), every one is tried once. Once all have responded, all RTT's will be nonzero, and the "fastest server" will get all queries henceforth, until it slows down for some reason.
To promote dispersion and good recordkeeping, BIND will penalize the RTT by a little bit each time a server is reused, and it will penalize the RTT a _lot_ if it ever has to retransmit a query. For a server to stay "#1", it has to keep on answering quickly and consistently.
Note that this is something BIND does that the DNS Specification does not mention at all. So other servers, those not based on BIND, might behave very differently.
If Microsoft's DNS server is integrated with WINS, it needs to be explicitly configured to interoperate with non-Microsoft name servers. Microsoft represents WINS information in the DNS using a nonstandard resource record type. This can cause a name server to fail when attempting a zone transfer from a Microsoft server. Older BIND servers may actually terminate when receiving such resource records in a zone transfer.
To correct the problem, ensure that the option "Zone Properties -> WINS Lookup -> Settings only affect local server" is set for each such zone on the Microsoft server.
Zone transfers can be done manually by using the ls
command in the nslookup
tool, or with the axfr pseudo-query-type in the
dig tool. If a server is configured to
disallow zone transfers, it may not be possible to easily obtain a copy
of the zone file.
14-Jan-2000
To promote a slave server (secondary) to be the master server (primary) for a zone, you need to
You can do the usual pre-change planning by reducing TTLs for the various records beforehand to speed up propagation and restoring them afterwards. But if your parent zone maintainer won't reduce TTLs of your NS records in their zone, the biggest delay is waiting for the parent to make the changes and to have these propagate, so tweaking TTLs is less effective. 30-May-2006