Newsgroups: comp.protocols.tcp-ip.domains,comp.answers,news.answers
Path: news1.ucsd.edu!ihnp4.ucsd.edu!swrinde!cs.utexas.edu!uwm.edu!rutgers!njitgw.njit.edu!hertz.njit.edu!cdp2582
From: cdp2582@hertz.njit.edu (Chris Peckham)
Subject: comp.protocols.tcp-ip.domains Frequently Asked Questions (FAQ) (Part 1 of 2)
Message-ID: <cptd-faq-1-836627408@njit.edu>
Followup-To: comp.protocols.tcp-ip.domains
Originator: cdp2582@hertz.njit.edu
Keywords: BIND,DOMAIN,DNS
Sender: news@njit.edu
Supersedes: <cptd-faq-1-836538047@njit.edu>
Nntp-Posting-Host: hertz.njit.edu
X-Posting-Frequency: posted during the first week of each month
Reply-To: domain-faq@njit.edu (comp.protocols.tcp-ip.domains FAQ comments)
Organization: NJIT.EDU - New Jersey Institute of Technology, Newark, NJ, USA
Date: Sat, 6 Jul 1996 04:30:33 GMT
Approved: news-answers-request@MIT.EDU
Expires: Sat 10 Aug 96 00:30:08 EDT
Lines: 1495
Xref: news1.ucsd.edu comp.protocols.tcp-ip.domains:8488 comp.answers:15596 news.answers:62287
Posted-By: auto-faq 3.1.1.2
Archive-name: internet/tcp-ip/domains-faq/part1
Revision: 1.10 1996/07/06 04:24:11
NOTE: PLEASE EXCUSE THE DOUBLE POSTING THIS MONTH - THERE WAS A SMALL
ERROR IN THE VERSION (section 1.3) INFO THAT I WANTED TO CORRECT
BEFORE THE MONTH WAS OUT -
Section 0 now contains an "UPDATES / Changes since last FAQ"
sub-section.
-----
This FAQ is edited and maintained by Chris Peckham, <cdp@pfmc.net>.
The latest version may always be found for anonymous ftp from
ftp://rtfm.mit.edu/pub/usenet/news.answers/internet/tcp-ip/domains-faq
If you can contribute any answers for items in the TODO section, please do
so by sending e-mail to domain-faq@pfmc.net ! If you know of any items that
are not included and you feel that they should be, send the relevant
information to domain-faq@pfmc.net.
------------------------------
Date: Sat Jul 6 00:28:25 EDT 1996
Subject: Table of Contents
Table of Contents
=================
Part 1
------
0. TO DO / UPDATES
1. INTRODUCTION / MISCELLANEOUS
1.1 What is this newsgroup ?
1.2 More information
1.3 What is BIND and where is the latest version of BIND ?
1.4 How can I find the route between systems ?
1.5 Finding the hostname if you have the tcp-ip address
1.6 How to register a domain name
1.7 Change IP of primary name server
1.8 Change of Domain name
1.9 How memory and CPU does DNS use ?
1.10 Other things to consider when planning your servers
1.11 Proper way to get NS and reverse IP records into DNS
1.12 How to get my address assigned from the NIC ?
1.13 Is there a block of private IP addresses I can use?
1.14 Cache failed lookups
1.15 What does an NS record really do ?
1.16 DNS ports
1.17 Obtaining the latest cache file
1.18 Selecting a nameserver (internal to BIND)
1.19 InterNIC and domain names
2. UTILITIES
2.1 Utilities to administer DNS zone files
2.2 DIG - Domain Internet Groper
2.3 DNS packet analyzer
2.4 host
2.5 Programming with DNS
2.6 A source of information relating to DNS
3. DEFINITIONS
3.1 TCP/IP Host Naming Conventions
3.2 Slaves and servers with forwarders
3.3 When is a server authoritative?
3.4 Underscore in host-/domain names
3.5 Lame delegation
3.6 What does opt-class field do?
3.7 Top level domains
3.8 Classes of networks
3.9 What is CIDR ?
3.10 What is the rule for glue ?
Part 2
------
4. CONFIGURATION
4.1 Changing a Secondary server to a Primary and moving Primary
4.2 How do I subnet a Class B Address ?
4.3 Subnetted domain name service
4.4 Recommended format/style of DNS files
4.5 DNS on a system not connected to the Internet
4.6 Multiple Domain configuration
4.7 wildcard MX records
4.8 How to identify a wildcard MX record
4.9 Why are fully qualified domain names recommended ?
4.10 Distributing load using named
4.11 Order of returned records
4.12 resolv.conf
4.13 Delegating authority
4.14 DNS instead of NIS on a Sun OS 4.1.x system
4.15 Patches to add functionality to BIND
5. PROBLEMS
5.1 No address for root server
5.2 Error - No Root Nameservers for Class XX
5.3 Bind 4.9.x and MX querying?
5.4 Some root nameservers don't know localhost
5.5 MX records and CNAMES and separate A records for MX targets
5.6 NS is a CNAME
5.7 Nameserver forgets own A record
5.8 General problems (core dumps !)
5.9 malloc and DECstations
5.10 Can't resolve names without a "."
5.11 Err/TO errors being reported
5.12 Why does swapping kill BIND ?
6. ACKNOWLEDGEMENTS
------------------------------
Date: Fri Jul 5 23:43:36 EDT 1996
Subject: Q0 - TO DO / UPDATES
TO DO
* How to do an initial installation
* Explain the difference between BIND (an implementation) and DNS (spec)
* Expand the slave/forward section of Q 3.2
* mention mail-to-news gateways for newsgroup, mailing lists, anonymous
ftp, etc in what is newsgroup section
* How to serve multiple domains from one server
* Internic fees and Internic www pages
UPDATES / Changes since last FAQ
0 TO DO / UPDATES (NEW UPDATES section)
1.3 What is BIND and where is the latest version of BIND ? (4.9.4)
3.7 Top level domains (added info on Internic alternatives)
4.1 Changing a Secondary server to a Primary and moving Primary (TTL)
4.3 Subnetted domain name service (draft changed from -00 to -01)
5.12 Why does swapping kill BIND (NEW)
-------------------------------
Date: Thu Dec 1 11:08:28 EST 1994
Subject: Q1.1 - What is this newsgroup ?
comp.protocols.tcp-ip.domains is the usenet newsgroup for discussion
on issues relating to the Domain Name System (DNS).
This newsgroup is not for issues directly relating to IP routing and
addressing. Issues of that nature should be directed towards
comp.protocols.tcp-ip.
-------------------------------
Date: Sun May 5 22:38:12 EDT 1996
Subject: Q1.2 - More information
You can find more information concerning DNS in the following places:
* The BOG (BIND Operations Guide) - in the BIND distribution
* The FAQ included with bind4.9.3 doc/misc/FAQ
* DNS and BIND by Albitz and Liu (an O'Reilly & Associates Nutshell
handbook)
* A number of RFCs (920, 974, 1032, 1034, 1101, 1123, 1178, 1183, 1348,
1535, 1536, 1537, 1591, 1706, 1712, 1713, 1912, 1918)
* The DNS Resource Directory (DNSRD)
http://www.dns.net/dnsrd
* If you are having troubles relating to sendmail and DNS, you may wish to
refer to the USEnet newsgroup comp.mail.sendmail and/or the FAQ for that
newsgroup
ftp://rtfm.mit.edu/pub/usenet/news.answers/mail/sendmail-faq
* Information concerning some frequently asked questions relating to
the Internet (i.e., what is the InterNIC, what is an RFC, what is the
IETF, etc) may be found for anonymous ftp from
ftp://ds.internic.net/fyi/fyi4.txt
A version may also be obtained with the URL
gopher://ds.internic.net/00/fyi/fyi4.txt
* A "Fast Guide to DNS" may be found at
http://www.netpart.com/free/dns.html
-------------------------------
Date: Fri Jul 5 23:47:27 EDT 1996
Subject: Q1.3 - What is BIND and where is the latest version of BIND ?
Q: What is BIND ?
A: From the BOG Introduction -
The Berkeley Internet Name Domain (BIND) implements
an Internet name server for the BSD operating system.
The BIND consists of a server (or ``daemon'') and a
resolver library. A name server is a network service
that enables clients to name resources or objects and
share this information with other objects in the network.
This in effect is a distributed data base system for
objects in a computer network. BIND is fully integrated
into BSD (4.3 and later releases) network programs for
use in storing and retrieving host names and address.
The system administrator can configure the system to use
BIND as a replacement to the older host table lookup of
information in the network hosts file /etc/hosts. The
default configuration for BSD uses BIND.
Q: Where is the latest version of BIND located ?
A: You can reference this URL:
http://www.vixie.com/isc/bind.html
At this time, BIND version of 4.9.4 may be found for anonymous ftp
from
ftp://ftp.vix.com/pub/bind/release/4.9.4/bind-4.9.4-REL.tar.gz
What's in 4.9.4 that wasn't in 4.9.3-P1:
1. IPv6 AAAA RRs can be resolved, loaded, dumped, transferred, and
cached
2. The CERT bulletin regarding bad host names has been dealt with
3. Numerous bug fixes that were going to go into 4.9.3-P2 anyway
Other sites that officially mirror the BIND distribution are
ftp://bind.fit.qut.edu.au/pub/bind
ftp://ftp.funet.fi/pub/unix/tcpip/dns/bind
ftp://ftp.univ-lyon1.fr/pub/mirrors/unix/bind
ftp://ftp.oleane.net/pub/mirrors/unix/bind
ftp://ftp.ucr.ac.cr/pub/Unix/dns/bind
ftp://ftp.luth.se/pub/unix/dns/bind/beta
You will need GNU zip, Larry Wall's patch program (if there are any
patch files), and a C compiler to get BIND running from the above
mentioned source.
GNU zip is available for anonymous ftp from
ftp://prep.ai.mit.edu/pub/gnu/gzip-1.2.4.tar
patch is available for anonymous ftp from
ftp://prep.ai.mit.edu/pub/gnu/patch-2.1.tar.gz
A version for Windows NT is available for anonymous ftp from
ftp://ftp.vix.com/pub/bind/release/4.9.3/contrib/{winntbin.zip,
winntsrc.zip}
Version 4.9.4 of the freeware NT port are availale
ntdns494relbin.zip
ntdns494relbin-nongui.zip
ntbind494rel.zip
Send email to access@drcoffsite.com for information on getting onto
the site.
------------------------------
Date: Mon Jan 2 13:27:27 EST 1995
Subject: Q1.4 - How can I find the route between systems
Q: How can I find the path taken by packets between two systems/domains ?
A: Get the source of the 'traceroute' command, compile it and install
it on your system.
One version of this program with additional functionality may be found
for anonymous ftp from
ftp://ftp.nikhef.nl/pub/network/traceroute.tar.Z
This package is mirrored at
ftp://ftp.njit.edu/pub/dns/nikhef/traceroute.tar.Z
Another version may be found for anonymous ftp from
ftp://ftp.psc.edu/pub/net_tools/traceroute.tar
------------------------------
Date: Thu Dec 1 09:55:24 EST 1994
Subject: Q1.5 - Finding the hostname if you have the tcp-ip address
Q: Can someone tell me how can I find the name of the domain if I know the
tcp-ip address of the domain? Is there some kind of service for this?
A: For an address a.b.c.d you can always do:
% nslookup
> set q=ptr
> d.c.b.a.in-addr.arpa.
Most newer version of nslookup (since 4.8.3) will recognize an address,
so you can just say:
% nslookup a.b.c.d
DiG will work like this also:
$ dig -x a.b.c.d
Host from the contrib/host from the bind distribution may also be used.
-------------------------------
Date: Sun Jun 2 11:20:48 EDT 1996
Subject: Q1.6 - How to register a domain name
Q: I would like to register a domain. How do I do this ? Can a name be
reserved, or must we already have an IP address and be hooked up to the
Internet before obtaining a domain name?
A: You can talk to your Internet Service Provider (ISP). They can submit
the registration for you. If you are not going to be directly
connected, they should be able to offer MX records for your domain
for mail delivery (so that mail sent to the new domain will be sent
to your "standard" account). In the case where the registration is
done by the organization itself, it still makes the whole process
much easier if the ISP is approached for secondary servers _before_
the InterNIC is approached for registration.
For information about making the registration yourself, look to the
InterNIC !
ftp://internic.net/templates/
gopher://rs.internic.net/
http://rs.internic.net/reg/reg-forms.html
http://www.ripe.net
You will need at least two domain name servers when you register your
domain. Many ISP's are willing to provide primary and/or secondary name
service for their customers.
Many times, registration of a domain name can be initiated by sending
e-mail to the zone contact. You can obtain the contact in the
SOA record for the country, or in a whois server:
$ nslookup -type=SOA fr.
origin = ns1.nic.fr
mail addr = nic.nic.fr
...
The mail address to contact in this case is 'nic@nic.fr' (you must
substitute an '@' for the first dot in the mail addr field).
An alternate method to obtain the e-mail address of the national NIC
is the 'whois' server at InterNIC.
You may be requested to make your request to another email address or
using a certain information template/application.
-------------------------------
Date: Sun May 5 22:46:28 EDT 1996
Subject: 1.7 - Change IP of primary name server
Q: We are going to change IP of primary name server. (with the same
machine but attach to another network). Our server serves as a
primary server for many domains. How can we do this as smoothly
as possible ?
A: (From Mark Andrews)
Before the move.
1. Ensure you are running a modern nameserver. BIND 4.9.3-REL +
Patch1 is a good choice.
2. Inform all your secondaries that you are going to change.
Have them install both the current and new addresses in
their named.boot's.
3. Drop the ttl of the A's associated with the nameserver to
something small (5 min is usually good).
4. Drop the refesh and retry times of the zone containing the
forward records for the server.
5. Configure the new reverse zone before the move and make sure
it is operational.
* On the day of the move add the new A record(s) for the server.
Don't forget to have these added to parent domains. You will
look like you are multihomed with one interface dead.
* Move the machine after gracefully terminating any other services
it is offering.
* Fixup the A's, ttl, refresh and retry counters. (If you are running
an all server EDIT out all references to the old addresses in the
cache files).
* Inform all the secondaries the move is complete.
* Inform the parents of all zones you are primary of the new NS/A
pairs for the relevent zones.
* Inform all the administators of zones you are secondaring that
the machine has moved.
* For good measure update the serial no for all zones you are
primary for. This will flush out old A's.
-------------------------------
Date: Sun Nov 27 23:32:41 EST 1994
Subject: Q1.8 - Change of Domain name
Q: We are preparing for a change of our domain name:
abc.foobar.com -> foobar.net
What are the tricks and caveats we should be aware of ?
A: The forward zones are easy and there are a number of ways to do it.
One way is the following:
Have a single db file for the 2 domains, and have a single machine
be the primary server for both abc.foobar.com and foobar.net.
To resolve the host foo in both domains, use a single zone file which
merely uses this for the host:
foo IN A 1.2.3.4
Use a "@" wherever the domain would be used ie for the SOA:
@ IN SOA (...
Then use this pair of lines in your named.boot:
primary abc.foobar.com db.foobar
primary foobar.net db.foobar
The reverse zones should either contain PTRs to both names,
or to whichever name you believe to be canonical currently.
-------------------------------
Date: Fri Apr 28 13:52:20 EDT 1995
Subject: Q1.9 - How memory and CPU does DNS use ?
Q: How much memory and CPU does DNS use ?
A: It can use quite a bit ! The main thing that BIND needs is memory.
It uses very little CPU or network bandwidth. The main
considerations to keep in mind when planning are:
1) How many zones do you have and how large are they ?
2) How many clients do you expect to serve and how active are they ?
As an example, here is a snapshot of memory usage from CSIRO Division
of Mathematics and Statistics, Australia
Named takes several days to stabalize its memory usage.
Our main server stabalises at ~10Mb. It takes about 3 days to
reach this size from 6 M at startup. This is under Sun OS 4.1.3U1.
As another example, here is the configuration of ns.uu.net (from late
1994):
ns.uu.net only does nameservice. It is running a version of BIND
4.9.3 on a Sun Classic with 96 MB of RAM, 220 MB of swap (remember
that Sun OS will reserve swap for each fork, even if it is not needed)
running Sun OS 4.1.3_U1.
Joseph Malcolm, of Alternet, states that named generally hovers at
5-10% of the CPU, except after a reload, when it eats it all. He
also states that if you are interested in the network connectivity
around the system (ns.uu.net is located off of Falls-Church4), a
PostScript map is available for anonymous ftp from
ftp://ftp.uu.net/uunet-info/alternet.map.ps
-------------------------------
Date: Mon Jan 2 14:24:51 EST 1995
Subject: Q1.10 - Other things to consider when planning your servers
When making the plans to set up your servers, you may want to also
consider the following issues:
A) Server O/S limitations/capacities (which tend to be widely
divergent from vendor to vendor)
B) Client resolver behavior (even more widely divergent)
C) Expected query response time
D) Redundancy
E) Desired speed of change propagation
F) Network bandwidth availability
G) Number of zones/subdomain-levels desired
H) Richness of data stored (redundant MX records? HINFO records?)
I) Ease of administration desired
J) Network topology (impacts reverse-zone volume)
Assuming a best-possible case for the factors above, particularly (A), (B),
(C), (F), (G) & (H), it would be possible to run a 1000-node domain
using a single lowly 25 or 40 MHz 386 PC with a fairly modest amount of RAM
by today's standards, e.g. 4 or 8 Meg. However, this configuration would
be slow, unreliable, and would provide no functionality beyond your basic
address-to-name and name-to-address mappings.
Beyond that baseline case, depending on what factors listed above,
you may want look at other strategies, such splitting up the DNS
traffic among several machines strategically located, possibly larger ones,
and/or subdividing your domain itself. There are many options, tradeoffs,
and DNS architectural paradigms from which to choose.
------------------------------
Date: Mon Jan 2 13:03:53 EST 1995
Subject: Q1.11 - Proper way to get NS and reverse IP records into DNS
Q: Reverse domain registration is separate from forward domain registration.
How do I get it updated ?
A: Blocks of network addresses have been delegated by the InterNIC. Check
if your network a.b.c.0 is in such a block by using nslookup:
nslookup -type=soa c.b.a.in-addr.arpa.
nslookup -type=soa b.a.in-addr.arpa.
nslookup -type=soa a.in-addr.arpa.
One of the above should give you the information you are looking for
(the others will return with an error something like `*** No start of
authority (SOA) records available for ...')
This will give you the email address of the person to whom you should
address your change request.
If none of these works, your network probably has not been delegated
by the InterNIC and you need to contact them directly.
CIDR has meant that the registration is delegated, but registration
of in-addr.arpa has always been separate from forward zones - and
for good reason - in that the forward and reverse zones may have
different policies, contents etc, may be served by a different set
of nameservers, and exist at different times (usually only at point
of creation). There isn't a one-to-one mapping between the two, so
merging the registration would probably cause more problems than
people forgetting/not-knowing that they had to register in-addr.arpa
zones separately. For example, there are organizations that have
hundreds of networks and two or more domains, with a sprinkling of
machines from each network in each of the domains.
-------------------------------
Date: Mon Jan 2 13:08:38 EST 1995
Subject: Q1.12 - How to get my address assigned from the NIC ?
Q: Can anyone tell me how can I get the address from NIC? How many subnets
will NIC give to me?
A: You should probably ask your Internet provider to give you an address.
These days, addresses are being distributed through the providers,
so that they can assign adjacent blocks of addresses to sites that
go through the same provider, to permit more efficient routing on
the backbones.
Unless you have thousands of hosts, you probably won't be able to get a
class B these days. Instead, you can get a series of class C networks.
Large requests will be queried, so be ready to provide a network plan if
you ask for more than 16 class C networks.
If you can't do this through your Internet provider, you can look for a
subnet registration form on rs.internic.net. See the answer in this FAQ
to the question "How to register a domain name" for a URL to these
forms.
-------------------------------
Date: Sun May 5 23:02:49 EDT 1996
Subject: Q1.13 -Is there a block of private IP addresses I can use?
Q: Is there a block of private IP addresses I can use?
A: Yes there is. Please refer to RFC 1918:
1918 Address Allocation for Private Internets. Y. Rekhter, B.
Moskowitz, D. Karrenberg, G. de Groot, & E. Lear. February 1996.
(Format: TXT=22270 bytes)
RFC 1918 documents the allocation of the following addresses for use
by ``private internets'':
10.0.0.0 - 10.255.255.255
172.16.0.0 - 172.31.255.255
192.168.0.0 - 192.168.255.255
-------------------------------
Date: Mon Jan 2 13:55:50 EST 1995
Subject: Q1.14 - Cache failed lookups
Q: Does BIND cache negative answers (failed DNS lookups) ?
A: Yes, BIND 4.9.3 will cache negative answers.
-------------------------------
Date: Fri Feb 10 15:35:07 EST 1995
Subject: Q1.15 - What does an NS record really do ?
Q: What does a NS record really do ?
A: The NS records in your zone data file pointing to the zone's name
servers (as opposed to the servers of delegated subdomains) don't do
much. They're essentially unused, though they are returned in the
authority section of reply packets from your name servers.
-------------------------------
Date: Fri Feb 10 15:40:10 EST 1995
Subject: Q1.16 - DNS ports
Q: Does anyone out there have any information/experience on exactly which
TCP/UDP ports DNS uses to send and receive queries ?
A: Use the following chart:
Prot Src Dst Use
udp 53 53 Queries between servers (eg, recursive queries)
Replies to above
tcp 53 53 Queries with long replies between servers, zone
transfers Replies to above
udp >1023 53 Client queries (sendmail, nslookup, etc ...)
udp 53 >1023 Replies to above
tcp >1023 53 Client queries with long replies
tcp 53 >1023 Replies to above
Note: >1023 is for non-priv ports on Un*x clients. On other client
types, the limit may be more or less.
Another point to keep in mind when designing filters for DNS is that a
DNS server uses port 53 both as the source and destination for it's
queries. So, a client queries an initial server from an unreserved
port number to UDP port 53. If the server needs to query another
server to get the required info, it sends a UDP query to that server
with both source and destination ports set to 53. The response is then
sent with the same src=53 dest=53 to the first server which then
responds to the original client from port 53 to the original source
port number.
The point of all this is that putting in filters to only allow UDP
between a high port and port 53 will not work correctly, you must also
allow the port 53 to port 53 UDP to get through.
Also, ALL versions of BIND use TCP for queries in some cases. The
original query is tried using UDP. If the response is longer than
the allocated buffer, the resolver will retry the query using a TCP
connection. If you block access to TCP port 53 as suggested above,
you may find that some things don't work.
Newer version of BIND allow you to configure a list of IP addresses
from which to allow zone transfers. This mechanism can be used to
prevent people from outside downloading your entire namespace.
-------------------------------
Date: Fri Apr 28 14:19:10 EDT 1995
Subject: Q1.17 - Obtaining the latest cache file
Q: What is the cache file and where can I obtain the latest version ?
A: From the "Name Server Operations Guide"
6.3. Cache Initialization
6.3.1. root.cache
The name server needs to know the servers that
are the authoritative name servers for the root
domain of the network. To do this we have to prime
the name server's cache with the addresses of these
higher authorities. The location of this file is
specified in the boot file. ...
A copy of the comments in the file available from the InterNIC follow:
; This file holds the information on root name servers needed to
; initialize cache of Internet domain name servers
; (e.g. reference this file in the "cache . <file>"
; configuration file of BIND domain name servers).
;
; This file is made available by InterNIC registration services
; under anonymous FTP as
; file /domain/named.root
; on server FTP.RS.INTERNIC.NET
; -OR- under Gopher at RS.INTERNIC.NET
; under menu InterNIC Registration Services (NSI)
; submenu InterNIC Registration Archives
; file named.root
;
; last update: Oct 5, 1994
; related version of root zone: 1994100500
;
If you have a version of dig running, you may obtain the information with
the command
dig @ns.internic.net . ns
-------------------------------
Date: Sun May 5 23:31:51 EDT 1996
Subject: Q1.18 - Selecting a nameserver (internal to BIND)
Q: If a host in the US is in a domain for which the defined primary and
secondary name servers are in Europe, how does one go about setting up
name services to eliminate the need for US hosts to query the European
name servers to get the address? Is it as simple as defining a secondary
name server for the zone in the US? Are resolvers smart enough to
determine which name server is "closer"?
A: (Answer from Mark Andrews) The basic answer is YES. Firstly resolvers,
usually, use a fixed set of servers to answer queries.
Modern servers however maintain RTT (round trip time) estimates for
servers for a zone and use this information to order the forward list
and to set the retry timers. If you have a servers in the US and ones
in Europe the sorting algorithm is able to detect the differences in
raw trasmission times, all other things being equal. By modern server
I mean BIND 4.9.3-REL.
-------------------------------
Date: Sun Jun 2 11:23:49 EDT 1996
Subject: Q1.19 - InterNIC and domain names
Q: What is the present InterNIC policy on what to do if someone wants to
use a domain name that is already in use ?
A: Please reference the current policy at
ftp://rs.internic.net/policy/internic/internic-domain-4.txt
http://rs.internic.net/domain-info/internic-domain-4.html
The following information was submitted by Carl Oppedahl
<oppedahl@patents.com>:
If the jealous party happens to have a trademark registration, it
is quite likely that the domain name owner will lose the domain
name, even if they aren't infringing the trademark. This presents
a substantial risk of loss of a domain name on only 30 days'
notice. Anyone who is the manager of an Internet-connected site
should be aware of this risk and should plan for it.
See "How do I protect myself from loss of my domain name?" at
http://www.patents.com/weblaw.sht#domloss .
For an example of an ISP's battle to keep its domain name, see
http://www.patents.com/nsi.sht .
A compendium of information on the subject may be found at
http://www.law.georgetown.edu/lc/internic/domain1.html .
-------------------------------
Date: Mon Jan 2 13:13:49 EST 1995
Subject: Q2.1 - Utilities to administer DNS zone files
Q: I am wondering if there are utilities available to ease the
administration of the zone files in the DNS.
A: There are a few. Two common ones are h2n and makezones. Both are perl
scripts. h2n is used to convert host tables into zone data files. It
is available for anonymous ftp from
ftp://ftp.uu.net/published/oreilly/nutshell/dnsbind/dns.tar.Z.
makezones works from a single file that looks like a forward zone file,
with some additional syntax for special cases. It is included in the
current BIND distribution. The newest version is always available for
anonymous ftp from
ftp://ftp.cus.cam.ac.uk/pub/software/programs/DNS/makezones
This package is mirrored at
ftp://ftp.njit.edu/pub/dns/cus.cam.ac/makezones
More information may be found using the DNS Resource Directory
http://www.dns.net/dnsrd
-------------------------------
Date: Thu Dec 1 11:09:11 EST 1994
Subject: Q2.2 - DIG - Domain Internet Groper
Q: Where can I find the latest version of DIG ?
A: The latest and greatest, official, accept-no-substitutes version of DiG
is the one that comes with BIND. Get the latest kit.
-------------------------------
Date: Mon May 15 12:57:42 EDT 1995
Subject: Q2.3 -DNS packet analyser
Q: I'm looking for a Ethernet packet analyser of public domain or standard
(like tcpdump, snoop, packetman) that is able to determine DNS data
field protocol
A: There is a free ethernet analyser called Ethload available for PC's
running DOS. The latest filename is ETHLD104.ZIP. It understands lots
of protocols including TCP/UDP. It'll look inside there and display
DNS/BOOTP/ICMP packets etc. (Ed. note: something nice for someone to
add to tcpdump ;^) ). Depending on the ethernet controller it's given
it'll perform slightly differently. It handles NDIS/Novell/Packet
drivers. It works best with Novell's promiscuous mode drivers.
A A SimTel mirror site should have the program available for anonymous
ftp. As an example,
-------------------------------
Date: Sun Dec 4 21:15:38 EST 1994
Subject: Q2.4 - host
A section from the host man page:
host looks for information about Internet hosts and domain
names. It gets this information from a set of intercon-
nected servers that are spread across the world. The infor-
mation is stored in the form of "resource records" belonging
to hierarchically organized "zones".
By default, the program simply converts between host names
and Internet addresses. However, with the -t, -a and -v
options, it can be used to find all of the information about
domain names that is maintained by the domain nameserver
system. The information printed consists of various fields
of the associated resource records that were retrieved.
The arguments can be either host names (domain names) or
numeric Internet addresses.
'host' is compatible with both BIND 4.9 and BIND 4.8
'host' may be found in contrib/host in the BIND distribution. The latest
version always available for anonymous ftp from
ftp://ftp.nikhef.nl/pub/network/host.tar.Z
It may also be found for anonymous ftp from
ftp://ftp.uu.net/networking/ip/dns/host.tar.Z
-------------------------------
Date: Fri Feb 10 15:25:11 EST 1995
Subject: Q2.5 - Programming with DNS
Q: How can I use DNS information in my program?
A: It depends on precisely what you want to do:
a) Consider whether you need to write a program at all. It may well
be easier to write a shell program (e.g. using awk or perl) to parse
the output of dig, host or nslookup.
b) If all you need is names and addresses, there will probably be
system routines 'gethostbyname' and 'gethostbyaddr' to provide this
information.
c) If you need more details, then there are system routines (res_query
and res_search) to assist with making and sending DNS queries.
However, these do not include a routine to parse the resulting answer
(although routines to assist in this task are provided). There is a
separate library available that will take a DNS response and unpick
it into its constituent parts, returning a C structure that can be
used by the program. The source for this library is available for
anonymous ftp from
ftp://hpux.csc.liv.ac.uk/hpux/Networking/Admin/resparse-*
-------------------------------
Date: Wed May 3 12:46:50 EDT 1995
Subject: Q2.6 - A source of information relating to DNS
Q: Where can I find utilities and tools to help me manage my zone files ?
A: There are several tools available. Please refer to the "tools" section
of the DNS resources directory:
http://www.dns.net/dnsrd/tools.html
-------------------------------
Date: Fri May 12 14:33:40 EDT 1995
Subject: Q3.1 - TCP/IP Host Naming Conventions
Q: Is a guide available relating to naming systems ?
A: One guide/resource is RFC 1178, "Choosing a Name for Your Computer",
which is available via anonymous FTP from
ftp://ftp.internic.netrfc/rfc1178.txt
RFCs (Request For Comments) are specifications and guidelines for how
many aspects of TCP/IP and the Internet (should) work. Most RFCs are
fairly technical documents, and some have semantics that are hotly
contested in the newsgroups. But a few, like RFC 1178, are actually
good to read for someone who's just starting along a TCP/IP path.
-------------------------------
Date: Thu Dec 1 10:32:43 EST 1994
Subject: Q3.2 - What are slaves and forwarders ?
Q: What are slaves and forwarders ?
A: "forwarders" is a list of NS records that are _prepended_ to a list
of NS records to query if the data is not available locally. This
allows a rich cache of records to be built up at a centralized
location. This is good for sites that have sporadic or very slow
connections to the Internet. (demand dial-up, for example) It's
also just a good idea for very large distributed sites to increase
the chance that you don't have to go off to the Internet to get an
IP address. (sometimes for addresses across the street!)
"slave" modifies this to say to replace the list of NS records
with the forwarders entry, instead of prepending to it. This is
for firewalled environments, where the nameserver can't directly
get out to the Internet at all.
"slave" is meaningless (and invalid, in late-model BINDs) without
"forwarders". "forwarders" is an entry in named.boot, and therefore
applies only to the nameserver (not to resolvers).
-------------------------------
Date: Mon Jan 2 13:15:13 EST 1995
Subject: Q3.3 - When is a server authoritative?
Q: What criteria does a server use to determine if it is authoritative
for a domain?
A: In the case of BIND:
1) The server contains current data in files for the zone in
question (Data must be current for secondaries, as defined
in the SOA)
2) The server is told that it is authoritative for the zone, by
a 'primary' or 'secondary' keyword in /etc/named.boot.
3) The server does an error-free load of the zone.
Q: I have set up a DNS where there is an SOA record for
the domain, but the server still does not consider itself
authoritative. (I used nslookup and set server=the correct machine.)
It seems to me that something is not matching up somewhere. I suspect
that this is because the service provider has not given us control
over the IP numbers in our own domain, and so while the machine listed
has an A record for an address, there is no corresponding PTR record.
A: That's possible too, but is unrelated to the first question.
You need to be delegated a zone before outside people will start
talking to your server. However, a server can still be authoritative
for a zone even though it hasn't been delegated authority (it's just
that only the people who use that as their server will see the data).
A server may consider itself non-authoritative even though it's a
primary if there is a syntax error in the zone (see point 3 above).
Q: I always believe that it was the NS record that defined authoritative
servers.
A: Nope, delegation is a separate issue from authoritativeness.
You can still be authoritative, but not delegated. (you can also be
delegated, but not authoritative -- that's a "lame delegation")
Q: We have had problems in the past from servers that were
authoritative (primary or secondary) but no NS, so other thought they
were not. Some resolvers get very confused when they get non-
authoritative data from the primary server.
A: Yes, that's a lame delegation. That's not caused by what you said,
but rather by a server which is _not_ authoritative for a zone, yet
someone else (the parent) is saying that a server is authoritative
(via the NS records).
The set of NS records in the parent zone must be a subset of the
authoritative servers to avoid lame delegations.
-------------------------------
Date: Sun May 5 23:38:37 EDT 1996
Subject: Q3.4 - underscore in host-/domainnames
Q: I had a quick look on whether underscores are allowed in host- or
domainnames.
RFC 1033 allows them.
RFC 1035 doesn't.
RFC 1123 doesn't.
dnswalk complains about them.
Which RFC is the final authority these days?
A: Actually RFC 1035 deals with names of machines or names of
mail domains. i.e "_" is not permitted in a hostname or on the
RHS of the "@" in local@domain.
Underscore is permitted where ever the domain is NOT one of
these types of addresses.
In general the DNS mostly contains hostnames and mail domainnames.
This will change as new resource record types for authenticating DNS
queries start to appear.
The latest version of 'host' checks for illegal characters in A/MX
record names and the NS/MX target names.
After saying all of that, remember that RFC 1123 is a Required Internet
Standard (per RFC 1720), and RFC 1033 isn't. Even 1035 isn't a required
standard. Therefore, RFC 1123 wins, no contest.
There has been a recent update on this subject which may be found in
ftp://ftp.internic.net/internet-drafts/draft-andrews-dns-hostnames-02.txt.
-------------------------------
Date: Fri Dec 2 15:03:56 EST 1994
Subject: Q3.5 - Lame delegation
Q: What is lame delegation ?
A: Two things are required for a lame delegation:
1) A nameserver X is delegated as authoritative for a zone.
2) Nameserver X is not performing nameservice for that zone.
Try to think of a lame delegation as a long-term condition, brought
about by a misconfiguration somewhere. Bryan Beecher's 1992 LISA
paper on lame delegations is good to read on this. The problem
really lies in misconfigured nameservers, not "lameness" brought
about by transient outages. The latter is common on the Internet
and hard to avoid, while the former is correctable.
In order to be performing nameservice for a zone, it must have
(presumed correct) data for that zone, and it must be answering
authoritatively to resolver queries for that zone. (The AA bit is
set in the flags section)
The "classic" lame delegation case is when nameserver X is delegated
as authoritative for domain Y, yet when you ask Y about X, it
returns non-authoritative data.
Here's an example that shows what happens most often (using dig,
dnswalk, and doc to find).
Let's say the domain bogus.com gets registered at the NIC and they
have listed 2 primary name servers, both from their *upstream*
provider:
bogus.com IN NS ns.bogus.com
bogus.com IN NS upstream.com
bogus.com IN NS upstream1.com
So the root servers have this info. But when the admins at
bogus.com actually set up their zone files they put something like:
bogus.com IN NS upstream.com
bogus.com IN NS upstream1.com
So your name server may have the nameserver info cached (which it
may have gotten from the root). The root says "go ask ns.bogus.com"
since they are authoritative
This is usually from stuff being registered at the NIC (either
nic.ddn.mil or rs.internic.net), and then updated later, but the
folks who make the updates later never let the folks at the NIC know
about it.
Q: How can I see if the server is "lame" ?
A: Go to the authoritative servers one level up, and ask them who
they think is authoritative, and then go ask each one of those
delegees if they think that they themselves are authoritative. If any
responds "no", then you know who the lame delegation is, and who is
delegating lamely to them. You can then send off a message to the
administrators of the level above.
The 'lamers' script from Byran Beecher really takes care of all this
for you. It parses the lame delegation notices from BIND's syslog
and summarizes them for you. It may be found in the contrib section
of the latest BIND distribution. The latest version is available
for anonymous ftp from
ftp://terminator.cc.umich.edu/dns/lame-delegations/
If you want to actively check for lame delegations, you can use 'doc'
and 'dnswalk'. You can check things manually with 'dig'.
-------------------------------
Date: Thu Dec 1 11:10:39 EST 1994
Subject: Q3.6 - What does opt-class field do?
Q: Just something I was wondering about: What does the opt-class
field in an name database do (the one that always says IN)?
What would happen if I put something else there instead?
A: This field is the address class. From the BOG -
...is the address class; currently, only one class
is supported: IN for internet addresses and other
internet information. Limited support is included for
the HS class, which is for MIT/Athena ``Hesiod''
information.
-------------------------------
Date: Fri Jul 5 23:49:55 EDT 1996
Subject: Q3.7 - Top level domains
A section from RFC 1591:
2. The Top Level Structure of the Domain Names
In the Domain Name System (DNS) naming of computers there is a
hierarchy of names. The root of system is unnamed. There are a set
of what are called "top-level domain names" (TLDs). These are the
generic TLDs (EDU, COM, NET, ORG, GOV, MIL, and INT), and the two
letter country codes from ISO-3166. It is extremely unlikely that
any other TLDs will be created.
[ Ed note: the ISO-3166 country codes may be found for anonymous ftp from:
ftp://ftp.isi.edu/in-notes/iana/assignments/country-codes
ftp://ftp.ripe.net/iso3166-codes
]
[ Ed note: Since the Internic started charging for registration services,
(and for other reasons) there are a number of groups that want to offer
an alternative to registering a domain under a "standard" TLD. More
information on some of these options may be found at:
http://www.alternic.net/
http://www.eu.org/
http://www.ml.org/mljoin.html
Additional note:
From: Michael Dillon <michael@memra.com>
Date: Wed, 3 Jul 96 17:21 PDT
IANA (Internet Assigned Numbers Authority) is currently responsible for
delegating the top level domains used in URL's, i.e. .COM, .ORG,
etc. Currently under consideration is a plan that would see new
international Top Level Domains created and new commercial registries (not
the Internic) to manage those domains. Most of the discussion is happening
on a mailing list at newdom@iiia.org which you can subscribe to by sending
subscribe
to newdom-request@iiia.org or you can review the discussions to date at
http://www.iiia.org/lists/newdom/ especially the recent discussions. Over
the past 9 months we have come up with one main proposal that appears as
if it will be the core of an RFC. This is available at
ftp://ietf.cnri.reston.va.us/internet-drafts/
draft-postel-iana-itld-admin-01.txt
There are a couple of other proposals also being discussed on the list.
Jon Postel will shortly be posting a revised draft of his proposal in
light of discussions that took place at the Montreal IETF meeting. Also,
there is information from the dissenting camp available at
http://www.alternic.nic
For most of you, that domain name will be unreachable and you will need to
use http://www.alternic.net to reach it.
The plan is to have this system in place by year end and be registering
new domains by early 1997. You may soon see URL's like
http://www.industrial.plastics or http://www.spock.klingon appearing in a
magazine near you. If you want to have any input into this proceeding, now
is the time to speak up.
Please forward this to any colleagues who may wish to have input into
these decisions.
Michael Dillon ISP & Internet Consulting
Memra Software Inc. Fax: +1-604-546-3049
http://www.memra.com E-mail: michael@memra.com
]
Under each TLD may be created a hierarchy of names. Generally, under
the generic TLDs the structure is very flat. That is, many
organizations are registered directly under the TLD, and any further
structure is up to the individual organizations.
In the country TLDs, there is a wide variation in the structure, in
some countries the structure is very flat, in others there is
substantial structural organization. In some country domains the
second levels are generic categories (such as, AC, CO, GO, and RE),
in others they are based on political geography, and in still others,
organization names are listed directly under the country code. The
organization for the US country domain is described in RFC 1480.
Each of the generic TLDs was created for a general category of
organizations. The country code domains (for example, FR, NL, KR,
US) are each organized by an administrator for that country. These
administrators may further delegate the management of portions of the
naming tree. These administrators are performing a public service on
behalf of the Internet community. Descriptions of the generic
domains and the US country domain follow.
Of these generic domains, five are international in nature, and two
are restricted to use by entities in the United States.
World Wide Generic Domains:
COM - This domain is intended for commercial entities, that is
companies. This domain has grown very large and there is
concern about the administrative load and system performance if
the current growth pattern is continued. Consideration is
being taken to subdivide the COM domain and only allow future
commercial registrations in the subdomains.
EDU - This domain was originally intended for all educational
institutions. Many Universities, colleges, schools,
educational service organizations, and educational consortia
have registered here. More recently a decision has been taken
to limit further registrations to 4 year colleges and
universities. Schools and 2-year colleges will be registered
in the country domains (see US Domain, especially K12 and CC,
below).
NET - This domain is intended to hold only the computers of network
providers, that is the NIC and NOC computers, the
administrative computers, and the network node computers. The
customers of the network provider would have domain names of
their own (not in the NET TLD).
ORG - This domain is intended as the miscellaneous TLD for
organizations that didn't fit anywhere else. Some non-
government organizations may fit here.
INT - This domain is for organizations established by international
treaties, or international databases.
United States Only Generic Domains:
GOV - This domain was originally intended for any kind of government
office or agency. More recently a decision was taken to
register only agencies of the US Federal government in this
domain. State and local agencies are registered in the country
domains (see US Domain, below).
MIL - This domain is used by the US military.
Example country code Domain:
US - As an example of a country domain, the US domain provides for
the registration of all kinds of entities in the United States
on the basis of political geography, that is, a hierarchy of
<entity-name>.<locality>.<state-code>.US. For example,
"IBM.Armonk.NY.US". In addition, branches of the US domain are
provided within each state for schools (K12), community
colleges (CC), technical schools (TEC), state government
agencies (STATE), councils of governments (COG),libraries
(LIB), museums (MUS), and several other generic types of
entities (see RFC 1480 for details).
A section from RFC 1480:
2. NAMING STRUCTURE
The US Domain hierarchy is based on political geography. The
basic name space under US is the state name space, then the
"locality" name space, (like a city, or county) then
organization or computer name and so on.
For example:
BERKELEY.CA.US
PORTLAND.WA.US
There is of course no problem with running out of names.
The things that are named are individual computers.
If you register now in one city and then move, the database can
be updated with a new name in your new city, and a pointer can
be set up from your old name to your new name. This type of
pointer is called a CNAME record.
The use of unregistered names is not effective and causes problems
for other users. Inventing your own name and using it without
registering is not a good idea.
In addition to strictly geographically names, some special names
are used, such as FED, STATE, AGENCY, DISTRICT, K12, LIB, CC,
CITY, and COUNTY. Several new name spaces have been created,
DNI, GEN, and TEC, and a minor change under the "locality" name
space was made to the existing CITY and COUNTY subdomains by
abbreviating them to CI and CO. A detailed description
follows.
Below US, Parallel to States:
-----------------------------
"FED" - This branch may be used for agencies of the federal
government. For example: <org-name>.<city>.FED.US
"DNI" - DISTRIBUTED NATIONAL INSTITUTES - The "DNI" branch was
created directly under the top-level US. This branch is to be used
for distributed national institutes; organizations that span state,
regional, and other organizational boundaries; that are national in
scope, and have distributed facilities. For example:
<org-name>.DNI.US.
Name Space Within States:
------------------------
"locality" - cities, counties, parishes, and townships. Subdomains
under the "locality" would be like CI.<city>.<state>.US,
CO.<county>.<state>.US, or businesses. For example:
Petville.Marvista.CA.US.
"CI" - This branch is used for city government agencies and is a
subdomain under the "locality" name (like Los Angeles). For example:
Fire-Dept.CI.Los-Angeles.CA.US.
"CO" - This branch is used for county government agencies and is a
subdomain under the "locality" name (like Los Angeles). For example:
Fire-Dept.CO.San-Diego.CA.US.
"K12" - This branch may be used for public school districts. A
special name "PVT" can be used in the place of a school district name
for private schools. For example: <school-name>.K12.<state>.US and
<school-name>.PVT.K12.<state>.US.
"CC" - COMMUNITY COLLEGES - This branch was established for all state
wide community colleges. For example: <school-name>.CC.<state>.US.
"TEC" - TECHNICAL AND VOCATIONAL SCHOOLS - The branch "TEC" was
established for technical and vocational schools and colleges. For
example: <school-name>.TEC.<state>.US.
"LIB" - LIBRARIES (STATE, REGIONAL, CITY, COUNTY) - This branch may
be used for libraries only. For example: <lib-name>.LIB.<state>.US.
"STATE" - This branch may be used for state government agencies. For
example: <org-name>.STATE.<state>.US.
"GEN" - GENERAL INDEPENDENT ENTITY - This branch is for the things
that don't fit easily into any other structure listed -- things that
might fit in to something like ORG at the top-level. It is best not
to use the same keywords (ORG, EDU, COM, etc.) that are used at the
top-level to avoid confusion. GEN would be used for such things as,
state-wide organizations, clubs, or domain parks. For example:
<org-name>.GEN.<state-code>.US.
The application form for the US domain may be found for anonymous ftp
from:
ftp://internic.net/templates/us-domain-template.txt
The application form for the EDU, COM, NET, ORG, and GOV domains may be
found for anonymous ftp from:
ftp://internic.net/templates/domain-template.txt
-------------------------------
Date: Sun Nov 27 23:32:41 EST 1994
Subject: Q3.8 - Classes of networks
Q: I am just kind of curious to what exactly the differences in classes
of networks are (class A, B, C).
A: An Internet Protocol (IP) address is 32 bit in length, divided into
two or three parts (the network address, the subnet address (if present),
and the host address. The subnet addresses are only present if the
network has been divided into subnetworks. The length of the network,
subnet, and host field are all variable.
There are five different network classes. The leftmost bits indicate
the class of the network.
# bits in # bits in
network host
Class field field Internet Protocol address in binary Ranges
============================================================================
A 7 24 0NNNNNNN.HHHHHHHH.HHHHHHHH.HHHHHHHH 1-127.x.x.x
B 14 16 10NNNNNN.NNNNNNNN.HHHHHHHH.HHHHHHHH 128-191.x.x.x
C 22 8 110NNNNN.NNNNNNNN.NNNNNNNN.HHHHHHHH 192-223.x.x.x
D NOTE 1 1110xxxx.xxxxxxxx.xxxxxxxx.xxxxxxxx 224-239.x.x.x
E NOTE 2 11110xxx.xxxxxxxx.xxxxxxxx.xxxxxxxx 240-247.x.x.x
where N represents part of the network address and H represents part of
the host address. When the subnet address is defined, the needed bits
are assigned from the host address space.
NOTE 1: Reserved for multicast groups - RFC 1112
NOTE 2: Reserved for future use
127.0.0.1 is reserved for local loopback.
Under the current arrangements, many class A IP numbers will not be
assigned whereas class C usage will be at a premium.
-------------------------------
Date: Fri Apr 28 13:31:24 EDT 1995
Subject: Q3.9 - What is CIDR ?
Q: What is CIDR ?
A: CIDR is "Classless Inter-Domain Routing (CIDR). From RFC1517:
...Classless Inter-Domain Routing (CIDR) attempts to deal with
these problems by defining a mechanism to slow the growth of
routing tables and reduce the need to allocate new IP network
numbers.
Much more information may be obtained in RFCs 1467, 1517, 1518, 1520;
with primary reference 1519
-------------------------------
Date: Fri Apr 28 13:31:24 EDT 1995
Subject: Q3.10 - What is the rule for glue ?
Q: What is the rule for glue ?
A: A glue record is an A record for a name that appears on the right-hand
side of a NS record. So, if you have this:
sub.foobar.com. IN NS dns.sub.foobar.com.
dns.sub.foobar.com. IN A 1.2.3.4
then the second record is a glue record (for the NS record above it).
You need glue records when -- and only when -- you are delegating
authority to a nameserver that "lives" in the domain you are delegating
*and* you aren't a secondary server for that domain.
In other words, in the example above, you need to add an A record
for dns.sub.foobar.com since it "lives" in the domain it serves.
This boot strapping information is necessary: How are you supposed
to find out the IP address of the nameserver for domain FOO if the
nameserver for FOO "lives" in FOO?
If you have this NS record:
sub.foobar.com. IN NS dns.xyz123.com.
you do NOT need a glue record, and, in fact, adding one is a very
bad idea. If you add one, and then the folks at xyz123.com change
the address, then you will be passing out incorrect data.
Also, unless you actually have a machine called something.IN-ADDR.ARPA,
you will never have any glue records present in any of your "reverse"
files.
There is also a sort of implicit glue record that can be useful (or
confusing :^) ). If the parent server (abc.foobar.com domain in example
above) is a secondary server for the child, then the A record will be
fetched from the child server when the zone transfer is done. The glue
is still there but it's a little different, it's in the ip address in
the named.boot line instead of explicitly in the data. In this case
you can leave out the explicit glue A record and leave the manually
configured "glue" in just the one place in the named.boot file.
RFC 1537 says it quite nicely:
2. Glue records
Quite often, people put unnecessary glue (A) records in their
zone files. Even worse is that I've even seen *wrong* glue records
for an external host in a primary zone file! Glue records need only
be in a zone file if the server host is within the zone and there
is no A record for that host elsewhere in the zone file.
Old BIND versions ("native" 4.8.3 and older versions) showed the
problem that wrong glue records could enter secondary servers in
a zone transfer.
----------------------------------------------------------------------
Newsgroups: comp.protocols.tcp-ip.domains,comp.answers,news.answers
Path: news1.ucsd.edu!ihnp4.ucsd.edu!swrinde!cs.utexas.edu!uwm.edu!rutgers!njitgw.njit.edu!hertz.njit.edu!cdp2582
From: cdp2582@hertz.njit.edu (Chris Peckham)
Subject: comp.protocols.tcp-ip.domains Frequently Asked Questions (FAQ) (Part 2 of 2)
Message-ID: <cptd-faq-2-836627408@njit.edu>
Followup-To: comp.protocols.tcp-ip.domains
Originator: cdp2582@hertz.njit.edu
Keywords: BIND,DOMAIN,DNS
Sender: news@njit.edu
Supersedes: <cptd-faq-2-836538047@njit.edu>
Nntp-Posting-Host: hertz.njit.edu
X-Posting-Frequency: posted during the first week of each month
Reply-To: domain-faq@njit.edu (comp.protocols.tcp-ip.domains FAQ comments)
Organization: NJIT.EDU - New Jersey Institute of Technology, Newark, NJ, USA
References: <cptd-faq-1-836627408@njit.edu>
Date: Sat, 6 Jul 1996 04:30:38 GMT
Approved: news-answers-request@MIT.EDU
Expires: Sat 10 Aug 96 00:30:08 EDT
Lines: 1315
Xref: news1.ucsd.edu comp.protocols.tcp-ip.domains:8489 comp.answers:15597 news.answers:62288
Posted-By: auto-faq 3.1.1.2
Archive-name: internet/tcp-ip/domains-faq/part2
Revision: 1.9 1996/07/06 04:24:16
This FAQ is edited and maintained by Chris Peckham, <cdp@pfmc.net>.
The latest version may always be found for anonymous ftp from
ftp://rtfm.mit.edu/pub/usenet/news.answers/internet/tcp-ip/domains-faq
If you can contribute any answers for items in the TODO section, please do
so by sending e-mail to domain-faq@pfmc.net ! If you know of any items that
are not included and you feel that they should be, send the relevant
information to domain-faq@pfmc.net.
------------------------------
Date: Thu Jul 4 23:18:51 EDT 1996
Subject: Table of Contents
Table of Contents
=================
Part 1
------
0. TO DO / UPDATES
1. INTRODUCTION / MISCELLANEOUS
1.1 What is this newsgroup ?
1.2 More information
1.3 What is BIND and where is the latest version of BIND ?
1.4 How can I find the route between systems ?
1.5 Finding the hostname if you have the tcp-ip address
1.6 How to register a domain name
1.7 Change IP of primary name server
1.8 Change of Domain name
1.9 How memory and CPU does DNS use ?
1.10 Other things to consider when planning your servers
1.11 Proper way to get NS and reverse IP records into DNS
1.12 How to get my address assigned from the NIC ?
1.13 Is there a block of private IP addresses I can use?
1.14 Cache failed lookups
1.15 What does an NS record really do ?
1.16 DNS ports
1.17 Obtaining the latest cache file
1.18 Selecting a nameserver (internal to BIND)
1.19 InterNIC and domain names
2. UTILITIES
2.1 Utilities to administer DNS zone files
2.2 DIG - Domain Internet Groper
2.3 DNS packet analyzer
2.4 host
2.5 Programming with DNS
2.6 A source of information relating to DNS
3. DEFINITIONS
3.1 TCP/IP Host Naming Conventions
3.2 Slaves and servers with forwarders
3.3 When is a server authoritative?
3.4 Underscore in host-/domain names
3.5 Lame delegation
3.6 What does opt-class field do?
3.7 Top level domains
3.8 Classes of networks
3.9 What is CIDR ?
3.10 What is the rule for glue ?
Part 2
------
4. CONFIGURATION
4.1 Changing a Secondary server to a Primary and moving Primary
4.2 How do I subnet a Class B Address ?
4.3 Subnetted domain name service
4.4 Recommended format/style of DNS files
4.5 DNS on a system not connected to the Internet
4.6 Multiple Domain configuration
4.7 wildcard MX records
4.8 How to identify a wildcard MX record
4.9 Why are fully qualified domain names recommended ?
4.10 Distributing load using named
4.11 Order of returned records
4.12 resolv.conf
4.13 Delegating authority
4.14 DNS instead of NIS on a Sun OS 4.1.x system
4.15 Patches to add functionality to BIND
5. PROBLEMS
5.1 No address for root server
5.2 Error - No Root Nameservers for Class XX
5.3 Bind 4.9.x and MX querying?
5.4 Some root nameservers don't know localhost
5.5 MX records and CNAMES and separate A records for MX targets
5.6 NS is a CNAME
5.7 Nameserver forgets own A record
5.8 General problems (core dumps !)
5.9 malloc and DECstations
5.10 Can't resolve names without a "."
5.11 Err/TO errors being reported
5.12 Why does swapping kill BIND ?
6. ACKNOWLEDGEMENTS
------------------------------
Date: Fri Jul 5 23:54:35 EDT 1996
Subject: Q4.1 - Changing a Secondary server to a Primary and moving Primary
Q: Do I need to do anything special when I change a server from a secondary
to a primary ?
A: For 4.8.3, it's prudent to kill and restart following any changes to
named.boot.
In BIND 4.9.3, you only have to kill and restart named if you change
a primary zone to a secondary or v-v, or if you delete a zone and
remain authoritative for its parent. Every other case should be
taken care of by a HUP. (Ed. note: 4.9.3b9 may still require you to
kill and restart the server due to some bugs in the HUP code).
You will also need to update the server information on the root servers.
You can do this by filing a new domain registration form to inform
InterNIC of the change. They will then update the root server's SOA
records. This process usually takes 10-12 business days after they
receive the request.
Q: How do I move my primary nameserver from one server to another ?
A: The usual solution is to move the primary to ns.newserver.com, and have
ns.oldserver.com be configured as a secondary server until the change
to the root servers takes place after the request has been made to the
InterNIC.
Q: I am currently moving to a diffrent ISP which will change my IP's.
Now I have 26+ domains that I am Primary and Secondary name servers for.
Is there a way to have a change of these domains name servers all at once
on a specific day?
Is there a recommened setting for the SOA that would minimize name servers
using the old settings?
A: Yes. Gradually lower the TTL value in your SOA (that's the last one of
the five numbers) to always be equal to the time left until you change
over. (assuming that none of your resource records have individual
TTL's set, if so, do likewise witht them.) So, the day before, lower
to 43200 seconds (12 hours). Then lower every few hours to be the time
remaining until the change-over. So, an hour before the change, you may
just want to lower it all the way to 60 seconds or so. That way no one
can cache information past the change-over.
After the change, start gradually incrementing the TTL value, because
you'll probably be making changes to work out problems. Once everything
stabilizes, move the TTL up to whatever your normal values are.
To minimize name servers from using the "old settings", you can do the
same thing with the "refresh" interval in the SOA (the second
number of the SOA). That will tell the secondaries to refresh every X
seconds. Lower that value as you approach the changeover date. You
probably don't want to go much below an hour or you'll start the primary
thrashing as all the secondaries perpetually refresh.
-------------------------------
Date: Fri Apr 28 13:34:52 EDT 1995
Subject: Q4.2 - How do I subnet a Class B Address ?
Q: I just received a Class B internet address and I am wondering where to
get an RFC or other information on how to properly to the TCP/IP
sub-netting.
A: That you need to subnet at all is something of a misconception. You
can also think of a class B network as giving you 65,534 individual
hosts, and such a network will work. You can also configure your
class B as 16,384 networks of 2 hosts each. That's obviously not
very practical, but it needs to be made clear that you are not
constrained by the size of an octet (remember that many older
devices would not work in a network configured in this manner).
So, the question is: why do you need to subnet? One reason is that
it is easier to manage a subnetted network, and in fact, you can
delegate the responsibility for address space management to local
administrators on the various subnets. Also, IP based problems will
end up localized rather than affecting your entire network.
If your network is a large backbone with numerous segments
individually branching off the backbone, that too suggests
subnetting.
Subnetting can also be used to improve routing conditions.
You may wish to partition your network to disallow certain protocols
on certain segments of your net. You can, for example, restrict IP or
IPX to certain segments only by adding a router routing high level
protocols, and across the router you may have to subnet.
Finally, as far as how many subnets you need depends on the answer to
the above question. As far as subnet masks are concerned, the mask
can be anything from 255.0.0.0 to 255.255.255.252. You'll probably be
looking at 9 or 10 bits for the subnet (last octet 128 or 192
respectively). RFC1219 discusses the issue of subnetting very well
and leaves the network administrator with a large amount of flexibility
for future growth.
------------------------------
Date: Sat Jul 6 00:01:37 EDT 1996
Subject: Q4.3 -Subnetted domain name service
Q: After doing some reading (DNS and BIND, Albitz&Liu), I don't really
find any examples of handling subnetted class C networks as separate
DNS domains.
A: See the Internet Draft
draft-ietf-cidrd-classless-inaddr-01.txt
for more information. This file is available for anonymous ftp at
ftp://ds.internic.net/internet-drafts
or other IETF mirror sites (ftp.is.ca.za [Africa], nic.nordu.net [Europe],
munnari.oz.au [Pacific Rim], ds.internic.net [US East Coast], or
ftp.isi.edu [US West Coast]).
Details follow- You need to delegate down to the fourth octet, so you
will have one domain per IP address ! Here is how you can subdelegate
a in-addr.arpa address for non-byte aligned subnet masks:
Take as an example the net 192.1.1.x, and example subnet mask
255.255.255.240.
We first define the domain for the class C net,
$origin 1.1.192.in-addr.arpa
@ SOA (usual stuff)
@ ns some.nameserver
ns some.other.nameserver
; delegate a subdomain
one ns one.nameserver
ns some.nameserver
; delegate another
two ns two.nameserver
ns some.nameserver
; CNAME pointers to subdomain one
0 CNAME 0.one
1 CNAME 1.one
; through
15 CNAME 15.one
; CNAME pointers to subdomain two
16 CNAME 16.two
17 CNAME 17.two
31 CNAME 31.two
; CNAME as many as required.
Now, in the delegated nameserver, one.nameserver
$origin one.1.1.192.in-addr.arpa
@ SOA (usual stuff)
NS one.nameserver
NS some.nameserver ; secondary for us
0 PTR onenet.one.domain
1 PTR onehost.one.domain
; through
15 PTR lasthost.one.domain
And similar for the two.1.1.192.in-addr.arpa delegated domain.
------------------------------
Date: Sun Nov 27 23:32:41 EST 1994
Subject: Q4.4 - Recommended format/style of DNS files
Q: Are there any suggestions for how to layout DNS configuration files
(both forward and reverse)?
A: This answer is quoted from an article posted by Paul Vixie:
I've gone back and forth on the question of whether the BOG should
include a section on this topic. I know what I myself prefer, but
I'm wary of ramming my own stylistic preferences down the throat of
every BOG reader. But since you ask :-)...
Create /var/named. If your system is too old to have a /var, either
create one or use /usr/local/adm/named instead. Put your named.boot
in it, and make /etc/named.boot a symlink to it. If your system
doesn't have symlinks, you're S-O-L (but you knew that). In
named.boot, put a "directory" directive that specifies your actual
BIND working directory:
directory /var/named
All relative pathnames used in "primary", "secondary", and "cache"
directives will be evaluated relative to this directory. Create two
subdirectories, /var/named/pri and /var/named/sec. Whenever you add
a "primary" directive to your named.boot, use "pri/WHATEVER" as the
path name. And then put the primary zone file into "pri/WHATEVER".
Likewise when you add "secondary" directives, use "sec/WHATEVER" and
BIND (really named-xfer) will create the files in that
subdirectory.
(Variations: (1) make a midlevel directory "zones" and put "pri" and
"sec" into it; (2) if you tend to pick up a lot of secondaries from
a few hosts, group them together in their own subdirectories --
something like /var/named/zones/uucp if you're a UUCP Project name
server.)
For your forward files, name them after the zone. dec.com becomes
"/var/named/zones/pri/dec.com". For your reverse files, name them
after the network number. 0.1.16.in-addr.arpa becomes
"/var/named/zones/pri/16.1.0".
When creating or maintaining primary zone files, try to use the same
SOA values everywhere, except for the serial number which varies per
zone. Put a $ORIGIN directive at the top of the primary zone file,
not because its needed (it's not since the default origin is the
zone named in the "primary" directive) but because it make it easier
to remember what you're working on when you have a lot of primary
zones. Put some comments up there indicating contact information
for the real owner if you're proxying. Use RCS and put the "Id"
in a ";" comment near the top of the zone file.
The SOA and other top level information should all be listed
together. But don't put IN on every line, it defaults nicely. For
example:
==============
@ IN SOA gw.home.vix.com. postmaster.vix.com. (
1994082501 ; serial
3600 ; refresh (1 hour)
1800 ; retry (30 mins)
604800 ; expire (7 days)
3600 ) ; minimum (1 hour)
NS gw.home.vix.com.
NS ns.uu.net.
NS uucp-gw-1.pa.dec.com.
NS uucp-gw-2.pa.dec.com.
MX 10 gw.home.vix.com.
MX 20 uucp-gw-1.pa.dec.com.
MX 20 uucp-gw-1.pa.dec.com.
==============
I don't necessarily recommend those SOA values. Not every zone is
as volatile as the example shown. I do recommend that serial number
format; it's in date format with a 2-digit per-day revision number.
This format will last us until 2147 A.D. at which point I expect a
better solution will have been found :-). (Note that it would last
until 4294 A.D. except that there are some old BINDs out there that
use a signed quantity for representing serial number interally; I
suppose that as long as none of these are still running after 2047
A.D., that we can use the above serial number format until 4294
A.D., at which point a better solution will HAVE to be found.)
You'll note that I use a tab stop for "IN" even though I never again
specify it. This leaves room for names longer than 7 bytes without
messing up the columns. You might also note that I've put the MX
priority and destination in the same tab stop; this is because both
are part of the RRdata and both are very different from MX which is
an RRtype. Some folks seem to prefer to group "MX" and the priority
together in one tab stop. While this looks neat it's very confusing
to newcomers and for them it violates the law of least
astonishment.
If you have a multi-level zone (one which contains names that have
dots in them), you can use additional $ORIGIN statements but I
recommend against it since there is no "back" operator. That is,
given the above example you can add:
=============
$ORIGIN home
gw A 192.5.5.1
=============
The problem with this is that subsequent RR's had better be
somewhere under the "home.vix.com" name or else the $ORIGIN that
introduces them will have to use a fully qualified name. FQDN
$ORIGIN's aren't bad and I won't be mad if you use them.
Unqualified ones as shown above are real trouble. I usually stay
away from them and just put the whole name in:
=============
gw.home A 192.5.5.1
=============
In your reverse zones, you're usually in some good luck because the
owner name is usually a single short token or sometimes two.
=============
$ORIGIN 5.5.192.in-addr.arpa.
@ IN SOA ...
NS ...
1 PTR gw.home.vix.com.
=========================================
$ORIGIN 1.16.in-addr.arpa.
@ IN SOA ...
NS ...
2.0 PTR gatekeeper.dec.com.
=============
It is usually pretty hard to keep your forward and reverse zones in
synch. You can avoid that whole problem by just using "h2n" (see
the ORA book, DNS and BIND, and its sample toolkit, included in the
BIND distribution or on ftp.uu.net (use the QUOTE SITE EXEC INDEX
command there to find this -- I never can remember where it's at).
"h2n" and many tools like it can just read your old /etc/hosts file
and churn it into DNS zone files. (May I recommend
contrib/decwrl/mkdb.pl from the BIND distribution?) However, if you
(like me) prefer to edit these things by hand, you need to follow
the simple convention of making all of your holes consistent. If
you use 192.5.5.1 and 192.5.5.3 but not (yet) 192.5.5.2, then in
your forward file you will have something like
=============
...
gw.home A 192.5.5.1
;avail A 192.5.5.2
pc.home A 192.5.5.3
=============
and in your reverse file you will have something like
=============
...
1 PTR gw.home.vix.com.
;2 PTR avail
3 PTR pc.home.vix.com.
=============
This convention will allow you to keep your sanity and make fewer
errors. Any kind of automation (h2n, mkdb, or your own
perl/tcl/awk/python tools) will help you maintain a consistent
universe even if it's also a complex one. Editing by hand doesn't
have to be deadly but you MUST take care.
------------------------------
Date: Sun Nov 27 23:32:41 EST 1994
Subject: Q4.5 - DNS on a system not connected to the Internet
Q: How do I use DNS on a system that is not connected to the Internet or
set BIND up with an internal root server ?
A: You need to create your own root domain name server until you connect
to the internet. Your roots need to delegate to mydomain.com and any
in-addr.arpa subdomains you might have, and that's about it. As
soon as you're connected, rip out the fake roots and use the real
ones.
It does not actually have to be another server pretending to be the root.
You can set up the name server so that it is primary for each domain
above you and leave them empty (i.e. you are foo.bar.com - claim to be
primary for bar.com and com)
Q: What if you connect intermittently and want DNS to work when you are
connected, and "fail" when you are not ?
A: You can point the resolver at the name server at the remote site and
if the connection (SLIP/PPP) isn't up, the resolver doesn't have a
route to the remote server and since there's only one name server in
resolv.conf, the resolver quickly backs off the using /etc/hosts.
No problem. You could do the same with multiple name server and a
resolver that did configurable /etc/hosts fallback.
------------------------------
Date: Fri Dec 2 15:40:49 EST 1994
Subject: Q4.6 -Multiple Domain configuration
Q: I have seen sites that seem to have multiple domain names pointing to the
same destination. I would like to implement this and have found no
information explaining how to do it. What I would like to do is:
ftp ftp.biff.com connects user to -> ftp.biff.com
ftp ftp.fred.com connects user to -> ftp.biff.com
ftp ftp.bowser.com connects user to -> ftp.biff.com
A: This is done through CNAME records:
ftp.bowser.com. IN CNAME ftp.biff.com.
You can also do the same thing with multiple A records.
------------------------------
Date: Sun Nov 27 23:32:41 EST 1994
Subject: Q4.7 - wildcard MX records
Q: Does BIND not understand wildcard MX records such as the following?
*.foo.com MX 0 mail.foo.com.
A: Explicit RR's at one level of specificity will, by design, "block" a
wildcard at a lesser level of specificity. I suspect that you have
an RR (an A RR, perhaps?) for "bar.foo.com" which is blocking the
application of your "*.foo.com" wildcard. The initial MX query is
thus failing (NOERROR but an answer count of 0), and the backup
query finds the A RR for "bar.foo.com" and uses it to deliver the
mail directly (which is what you DIDN'T want it to do). Adding an
explicit MX RR for the host is therefore the right way to handle
this situation.
See RFC 1034, Section 4.3.3 ("Wildcards") for more information on
this "blocking" behavior, along with an illustrative example. See
also RFC 974 for an explanation of standard mailer behavior in the
face of an "empty" response to one's MX query.
Basically, what it boils down to is, there is no point in trying to
use a wildcard MX for a host which is otherwise listed in the DNS.
It just doesn't work.
------------------------------
Date: Thu Dec 1 11:10:39 EST 1994
Subject: Q4.8 - How to identify a wildcard MX record
Q: How do you identify a wildcard MX record ?
A: You don't really need to "identify" a wildcard MX RR. The precedence
for u@dom is:
exact match MX
exact match A
wildcard MX
One way to implement this is to query for ("dom",IN,MX) and if the
answer name that comes back is "*." something, you know it's a
wildcard, therefore you know there is no exact match MX, and you
therefore query for ("dom",IN,A) and if you get something, use it.
if you don't, use the previous wildcard response.
RFC 974 explains this pretty well.
------------------------------
Date: Sun Nov 27 23:32:41 EST 1994
Subject: Q4.9 - Why are fully qualified domain names recommended ?
Q: Why are fully qualified domain names recommended ?
A: The documentation for BIND 4.9.2 says that the hostname should be set
to the full domain style name (i.e host.our.domain rather than
host). What advantages are there in this, and are there any adverse
consequences if we don't?
A: Paul Vixie likes to do it :-) He lists a few reasons -
* Sendmail can be configured to just use Dj$w rather than
Dj$w.mumble where "mumble" is something you have to edit in by
hand. Granted, most people use "mumble" elsewhere in their config
files ("tack on local domain", etc) but why should it be a
requirement ?
* The real reason is that not doing it violates a very useful invariant:
gethostbyname(gethostname) == gethostbyaddr(primary_interface_address)
If you take an address and go "backwards" through the PTR's with
it, you'll get a FQDN, and if you push that back through the A
RR's, you get the same address. Or you should. Many multi-homed
hosts violate this uncaringly.
If you take a non-FQDN hostname and push it "forwards" through the
A RR's, you get an address which, if you push it through the
PTR's, comes back as a FQDN which is not the same as the hostname
you started with. Consider the fact that, absent NIS/YP, there is
no "domainname" command analogous to the "hostname" command.
(NIS/YP's doesn't count, of course, since it's
sometimes-but-only-rarely the same as the Internet domain or
subdomain above a given host's name.) The "domain" keyword in
resolv.conf doesn't specify the parent domain of the current host;
it specifies the default domain of queries initiated on the
current host, which can be a very different thing. (As of RFC
1535 and BIND 4.9.2's compliance with it, most people use "search"
in resolv.conf, which overrides "domain", anyway.)
What this means is that there is NO authoritative way to
programmatically discover your host's FQDN unless it is set in the
hostname, or unless every application is willing to grovel the
"netstat -in" tables, find what it hopes is the primary address,
and do a PTR query on it.
FQDN /bin/hostnames are, intuitively or not, the simplest way to go.
------------------------------
Date: Wed Mar 1 11:04:43 EST 1995
Subject: Q4.10 - Distributing load using named
Q: If you attempt to distribute the load on a system using named, won't
the first response be cached, and then later queries use the cached
value? (This would be for requests that come through the same
server.)
A: Yes. So it can be useful to use a lower TTL on records where this is
important. You can use values like 300 or 500 seconds.
If your local caching server has ROUND_ROBIN, it does not matter
what the authoritative servers have -- every response from the cache
is rotated.
But if it doesn't, and the authoritative server site is depending on
this feature (or the old "shuffle-A") to do load balancing, then if
one doesn't use small TTLs, one could conceivably end up with a
really nasty situation, e.g., hundreds of workstations at a branch
campus pounding on the same front end at the authoritative server's
site during class registration.
Not nice.
A: Paul Vixie has an example of the ROUND_ROBIN code in action. Here is
something that he wrote regarding his example:
>I want users to be distributed evenly among those 3 hosts.
Believe it or not :-), BIND offers an ugly way to do this. I offer
for your collective amusement the following snippet from the
ugly.vix.com zone file:
hydra cname hydra1
cname hydra2
cname hydra3
hydra1 a 10.1.0.1
a 10.1.0.2
a 10.1.0.3
hydra2 a 10.2.0.1
a 10.2.0.2
a 10.2.0.3
hydra3 a 10.3.0.1
a 10.3.0.2
a 10.3.0.3
Note that having multiple CNAME RR's at a given name is
meaningless according to the DNS RFCs but BIND doesn't mind (in
fact it doesn't even complain). If you call
gethostbyname("hydra.ugly.vix.com") (try it!) you will get
results like the following. Note that there are two round robin
rotations going on: one at ("hydra",CNAME) and one at each
("hydra1",A) et al. I used a layer of CNAME's above the layer of
A's to keep the response size down. If you don't have nine
addresses you probably don't care and would just use a pile of
CNAME's pointing directly at real host names.
{hydra.ugly.vix.com}
name: hydra2.ugly.vix.com
aliases: hydra.ugly.vix.com
addresses: 10.2.0.2 10.2.0.3 10.2.0.1
{hydra.ugly.vix.com}
name: hydra3.ugly.vix.com
aliases: hydra.ugly.vix.com
addresses: 10.3.0.2 10.3.0.3 10.3.0.1
{hydra.ugly.vix.com}
name: hydra1.ugly.vix.com
aliases: hydra.ugly.vix.com
addresses: 10.1.0.2 10.1.0.3 10.1.0.1
{hydra.ugly.vix.com}
name: hydra2.ugly.vix.com
aliases: hydra.ugly.vix.com
addresses: 10.2.0.3 10.2.0.1 10.2.0.2
{hydra.ugly.vix.com}
name: hydra3.ugly.vix.com
aliases: hydra.ugly.vix.com
addresses: 10.3.0.3 10.3.0.1 10.3.0.2
------------------------------
Date: Sun Dec 4 22:12:32 EST 1994
Subject: Q4.11 - Order of returned records
Q: Is there any way to tell named to return records, specifically
address records, in the order in which they are listed in the
database?
It would appear that named consistently applies a sorting algorithm
to address records which seems to be virtually guaranteed to be
pessimal for our routers, which have many A records.
A: Sorting, is the *resolver's* responsibility. RFC 1123:
6.1.3.4 Multihomed Hosts
When the host name-to-address function encounters a host
with multiple addresses, it SHOULD rank or sort the
addresses using knowledge of the immediately connected
network number(s) and any other applicable performance or
history information.
DISCUSSION:
The different addresses of a multihomed host generally
imply different Internet paths, and some paths may be
preferable to others in performance, reliability, or
administrative restrictions. There is no general way
for the domain system to determine the best path. A
recommended approach is to base this decision on local
configuration information set by the system
administrator.
In BIND 4.9.x's resolver code, the "sortlist" directive in resolv.conf
can be used to configure this.
------------------------------
Date: Fri Feb 10 15:46:17 EST 1995
Subject: Q4.12 - resolv.conf
Q: Why should I use "real" IP addresses in /etc/resolv.conf and not 0.0.0.0
or 127.0.0.1.
A: Paul Vixie writes on the issue of the contents of resolv.conf:
It's historical. Some kernels can't unbind a UDP socket's source
address, and some resolver versions (notably not including BIND
4.9.2 or 4.9.3's) try to do this. The result can be wide area
network traffic with 127.0.0.1 as the source address. Rather than
giving out a long and detailed map of version/vendor combinations of
kernels/BINDs that have/don't this problem, I just tell folks not to
use 127.0.0.1 at all.
0.0.0.0 is just an alias for the first interface address assigned
after a system boot, and if that interface is a up-and-down point to
point link (PPP, SLIP, whatever), there's no guarantee that you'll
be able to reach yourself via 0.0.0.0 during the entire lifetime of
any system instance. On most kernels you can finesse this by adding
static routes to 127.0.0.1 for each of your interface addresses, but
some kernels don't like that trick and rather than give a detailed
map of which ones work and which ones don't, I just globally
recommend against 0.0.0.0.
If you know enough to know that 127.0.0.1 or 0.0.0.0 is safe on your
kernel and resolver, then feel free to use them. If you don't know
for sure that it is safe, don't use them. I never use them (except
on my laptop, whose hostname is "localhost" and whose 0.0.0.0 is
127.0.0.1 since I ifconfig my lo0 before any other interface). The
operational advantage to using a real IP address rather than an
wormhole like 0.0.0.0 or 127.0.0.1, is that you can then "rdist" or
otherwise share identical copies of your resolv.conf on all the
systems on any given subnet, not all of which will be servers.
A: The problem was with older versions of the resolver (4.8.X). If you
listed 127.0.0.1 as the first entry in resolv.conf, and for whatever
reason the local name server wasn't running and the resolver fell
back to the second name server listed, it would send queries to the
name server with the source IP address set to 127.0.0.1 (as it was
set when the resolver was trying to send to 127.0.0.1--you use the
loopback address to send to the loopback address).
------------------------------
Date: Mon Jan 2 13:50:13 EST 1995
Subject: Q4.13 - Delegating authority
Q: How do I delegate authority for domains within my domain ?
A: When you start having a very big domain that can be broken into logical
and separate entities that can look after their own DNS information,
you will probably want to do this. Maintain a central area for the
things that everyone needs to see and delegate the authority for the
other parts of the organization so that they can manage themselves.
Another essential piece of information is that every domain that
exists must have it NS records associated with it. These NS records
denote the name servers that are queried for information about that
zone. For your zone to be recognized by the outside world, the
server responsible for the zone above you must have created a NS
record for your machine in your domain. For example, putting the
computer club onto the network and giving them control over their
own part of the domain space we have the following.
The machine authorative for gu.uwa.edu.au is mackerel and the machine
authorative for ucc.gu.uwa.edu.au is marlin.
in mackerel's data for gu.uwa.edu.au we have the following
@ IN SOA ...
IN A 130.95.100.3
IN MX mackerel.gu.uwa.edu.au.
IN MX uniwa.uwa.edu.au.
marlin IN A 130.95.100.4
ucc IN NS marlin.gu.uwa.edu.au.
IN NS mackerel.gu.uwa.edu.au.
Marlin is also given an IP in our domain as a convenience. If they
blow up their name serving there is less that can go wrong because
people can still see that machine which is a start. You could place
"marlin.ucc" in the first column and leave the machine totally
inside the ucc domain as well.
The second NS line is because mackerel will be acting as secondary name
server for the ucc.gu domain. Do not include this line if you are not
authorative for the information included in the sub-domain.
------------------------------
Date: Wed Mar 1 11:45:00 EST 1995
Subject: Q4.14 - DNS instead of NIS on a Sun OS 4.1.x system
Q: I would appreciate any comments on whether running bind 4.9.x will
enable sendmail, ftp, telnet and other TCP/IP services to bypass
NIS and connect directly to named.
A: How to do this is documented quite well in the comp.sys.sun.admin FAQ in
questions one and two. You can get them from:
ftp://thor.ece.uc.edu/pub/sun-faq/FAQs/sun-faq.general
http://www.cis.ohio-state.edu/hypertext/faq/usenet/comp-sys-sun-faq
as well as from rtfm.mit.edu in the usual place, etc.
------------------------------
Date: Sun May 5 23:10:41 EDT 1996
Subject: Q4.15 - Patches to add functionality to BIND
There are others, but these are listed here:
Q: When using the round robin DNS and assigning 3 IPs to a host (for
example), anybody know of software or processes to guarantee that all 3
IPs are reachable?
A: Look at
http://www-leland.stanford.edu/~schemers/docs/lbnamed/lbnamed.html
for precisely what you need.
Q: Does anyone know where to find patches for BIND 4.9.3-P1 to support
the IPv6 AAAA record format?
A: The patches for 4.9.3-REL are at
ftp://ftp.inria.fr/network/ipv6/
These patches will apply fairly cleanly for 4.9.3-P1.
Q: How do I turn off forwarding of information from my server ?
A: The patch for 4.9.3-REL may be found at
ftp://ftp.vix.com/pub/bind/release/4.9.3/contrib/noforward.tar.gz.
------------------------------
Date: Mon Jan 2 13:49:43 EST 1995
Subject: Q5.1 - No address for root server
Q: I've been getting the following messages lately from bind-4.9.2..
ns_req: no address for root server
We are behind a firewall and have the following for our named.cache file -
; list of servers
. 99999999 IN NS POBOX.FOOBAR.COM.
99999999 IN NS FOOHOST.FOOBAR.COM.
foobar.com. 99999999 IN NS pobox.foobar.com.
A: You can't do that. Your nameserver contacts POBOX.FOOBAR.COM, gets the
correct list of root servers from it, then tries again and fails
because of your firewall.
You will need a 'forwarder' definition, to ensure that all requests
are forwarded to a host which can penetrate the firewall. And
it is unwise to put phony data into 'named.cache'.
------------------------------
Date: Sun Nov 27 23:32:41 EST 1994
Subject: Q5.2 - Error - No Root Nameservers for Class XX
Q: I've received errors before about "No root nameservers for class XX"
but they've been because of network connectivity problems.
I believe that Class 1 is Internet Class data.
And I think I heard someone say that Class 4 is Hesiod??
Does anyone know what the various Class numbers are?
A: From RFC 1700:
DOMAIN NAME SYSTEM PARAMETERS
The Internet Domain Naming System (DOMAIN) includes several
parameters. These are documented in [RFC1034] and [RFC1035]. The
CLASS parameter is listed here. The per CLASS parameters are
defined in separate RFCs as indicated.
Domain System Parameters:
Decimal Name References
-------- ---- ----------
0 Reserved [PM1]
1 Internet (IN) [RFC1034,PM1]
2 Unassigned [PM1]
3 Chaos (CH) [PM1]
4 Hesoid (HS) [PM1]
5-65534 Unassigned [PM1]
65535 Reserved [PM1]
DNS information for RFC 1700 was taken from
ftp://ftp.isi.edu/in-notes/iana/assignments/dns-parameters
Hesiod is class 4, and there are no official root nameservers for class
4, so you can safely declare yourself one if you like. You might want
to put up a packet filter so that no one outside your network is capable
of making Hesiod queries of your machines, if you define yourself to be
a root nameserver for class 4.
------------------------------
Date: Sun Nov 27 23:32:41 EST 1994
Subject: Q5.3 - Bind 4.9.x and MX querying?
Q: If I query a 4.9.x DNS server for MX records, a list of the MX records
as well as a list of the authorative nameservers is returned. Why ?
A: Bind 4.9.2 returns the list of nameserver that are authorative
for a domain in the response packet, along with their IP
addresses in the additional section.
------------------------------
Date: Sat Sep 9 00:36:01 EDT 1995
Subject: Q5.4 - Some root nameservers don't know localhost
Q: Do I need to define an A record for localhost ?
Where is the A record for 127.0.0.1 defined? I see where
the PTR record is defined pointing to localhost, but can't find
where the A record is. And is the A record supposed to be
localhost.MY_DOMAIN or just localhost ?
A: Somewhere deep in the BOG (BIND Operations Guide) that came with
4.9.3 (section 5.4.3), it says that you define this yourself
(if need be) in the same zone files as your "real" IP addresses
for your domain. Quoting the BOG:
... As implied by this PTR
record, there should be a ``localhost.my.dom.ain''
A record (with address 127.0.0.1) in every domain
that contains hosts. ``localhost.'' will lose its
trailing dot when 1.0.0.127.in-addr.arpa is queried
for;...
The sample files in the BIND distribution show you what needs to be
done (see the BOG).
Some HP boxen (especially those running HP OpenView) will also need
"loopback" defined with this IP address. You may set it as a CNAME
record pointing to the "localhost." record.
------------------------------
Date: Sun Nov 27 23:32:41 EST 1994
Subject: Q5.5 - MX records and CNAMES and separate A records for MX targets
Q: The O'Reilly "DNS and Bind" book warns against using non-canonical
names in MX records, however, this warning is given in the context
of mail hubs that MX to each other for backup purposes. I don't see
how this applies to mail spokes. RFC 974 has a similar warning, but
I can not see where it specifically prohibits using an alias in an
MX record.
A: Without the restrictions in the RFC, a MTA must request the A records
for every MX listed to determine if it is in the MX list then reduce
the list. This introduces many more lookups than would other wise be
required. If you are behind a 1200 bps link YOU DON'T WANT TO DO
THIS. The addresses associated with CNAMES are not passed as
additional data so you will force additional traffic to result even
if you are running a caching server locally.
There is also the problem of how does the MTA find all of it's
IP addresses. This is not straight forward. You have to be able
to do this is you allow CNAMEs (or extra A's) as MX targets.
The letter of the law is that an MX record should point to an A record.
There is no "real" reason to use CNAMEs for MX targets or separate
As for nameservers any more. CNAMEs for services other than mail
should be used because there is no specified method for locating the
desired server yet.
People don't care what the names of MX targets are. They're
invisible to the process anyway. If you have mail for "mary"
redirected to "sue" is totally irrelevant. Having CNAMEs as the
targets of MX's just needlessly complicates things, and is more work
for the resolver.
Having separate A's for nameservers like "ns.your.domain" is
pointless too, since again nobody cares what the name of your
nameserver is, since that too is invisible to the process. If you
move your nameserver from "mary.your.domain" to "sue.your.domain"
nobody need care except you and your parent domain administrator
(and the InterNIC). Even less so for mail servers, since only you
are affected.
Q: Given the example -
hello in cname realname
mailx in mx 0 hello
Now, while reading the operating manual of bind it clearly states
that this is *not* valid. These two statements clearly contradict
each other. Is there some later rfc than 974 that overrides what is
said in there with respect to MX and CNAMEs? Anyone have the
reference handy?
A: This isn't what the BOG says at all. See below. You can have a CNAME
that points to some other RR type; in fact, all CNAMEs have to point
to other names (Canonical ones, hence the C in CNAME). What you
can't have is an MX that points to a CNAME. MX RR's that point to
names which have only CNAME RR's will not work in many cases, and
RFC 974 intimates that it's a bad idea:
Note that the algorithm to delete irrelevant RRs breaks if LOCAL has
a alias and the alias is listed in the MX records for REMOTE. (E.g.
REMOTE has an MX of ALIAS, where ALIAS has a CNAME of LOCAL). This
can be avoided if aliases are never used in the data section of MX
RRs.
Here's the relevant BOG snippet:
aliases {ttl} addr-class CNAME Canonical name
ucbmonet IN CNAME monet
The Canonical Name resource record, CNAME, speci-
fies an alias or nickname for the official, or
canonical, host name. This record should be the
only one associated with the alias name. All other
resource records should be associated with the
canonical name, not with the nickname. Any
resource records that include a domain name as
their value (e.g., NS or MX) must list the canoni-
cal name, not the nickname.
------------------------------
Date: Wed Mar 1 11:14:10 EST 1995
Subject: Q5.6 - NS is a CNAME
Q: Can I do this ? Is it legal ?
@ SOA (.........)
NS ns.host.this.domain.
NS second.host.another.domain.
ns CNAME third
third IN A xxx.xxx.xxx.xxx
A: No. Only one RR type is allowed to refer, in its data field, to a
CNAME, and that's CNAME itself. So CNAMEs can refer to CNAMEs but
NSs and MXs cannot.
BIND 4.9.3 (Beta11 and later) explicitly syslogs this case rather than
simply failing as pre-4.9 servers did. Here's a current example:
Dec 7 00:52:18 gw named[17561]: \
"foobar.com IN NS" points to a CNAME (foobar.foobar.com)
Here is the reason why:
Nameservers are not required to include CNAME records in the
Additional Info section returned after a query. It's partly an
implementation decision and partly a part of the spec. The
algorithm described in RFC 1034 (pp24,25; info also in RFC 1035,
section 3.3.11, p 18) says 'Put whatever addresses are available
into the additional section, using glue RRs [if necessary]'.
Since NS records are speced to contain only primary names of
hosts, not CNAMEs, then there's no reason for algorithm to
mention them. If, on the other hand, it's decided to allow CNAMEs
in NS records (and indeed in other records) then there's no
reason that CNAME records might not be included along with A
records. The Additional Info section is intended for any
information that might be useful but which isn't strictly the
answer to the DNS query processed. It's an implementation
decision in as much as some servers used to follow CNAMEs in
NS references.
------------------------------
Date: Fri Dec 2 16:17:31 EST 1994
Subject: Q5.7 - Nameserver forgets own A record
Q: Lately, I've been having trouble with named 4.9.2 and 4.9.3.
Periodically, the nameserver will seem to "forget" its own A record,
although the other information stays intact. One theory I had was
that somehow a site that the nameserver was secondary for was
"corrupting" the A record somehow.
A: This is invariably due to not removing ALL of the cached zones
when you moved to 4.9.X. Remove ALL cached zones and restart
your nameservers.
You get "ignoreds" because the primaries for the relevant zones are
running old versions of BIND which pass out more glue than is
required. named-xfer trims off this extra glue.
------------------------------
Date: Sun Dec 4 22:21:22 EST 1994
Subject: Q5.8 - General problems (core dumps !)
Q: I am running bind 4.9.3b9p1 on a DEC alpha OSF/1 V3.0 and have had it
core dump while in debug mode. The last lines printed to named.run
were [...]
A: Paul Vixie says:
I'm always interested in hearing about cases where BIND dumps core.
However, I need a stack trace. Compile with -g and not -O (unless
you are using gcc and know what you are doing) and then when it
dumps core, get into dbx or gdb using the executable and the core
file and use "bt" to get a stack trace. Send it to me
<paul@vix.com> along with specific circumstances leading to or
surrounding the crash (test data, tail of the debug log, tail of the
syslog... whatever matters) and ideally you should save your core
dump for a day or so in case I have questions you can answer via
gdb/dbx.
------------------------------
Date: Mon Jan 2 14:19:22 EST 1995
Subject: Q5.9 - malloc and DECstations
We have replaced malloc on our DECstations with a malloc that is more
compact in memory usage, and this helped the operation of bind a lot.
The source is now available for anonymous ftp from
ftp://ftp.cs.wisc.edu/pub/misc/malloc.tar.gz
------------------------------
Date: Sun May 5 23:46:32 EDT 1996
Subject: Q5.10 - Can't resolve names without a "."
Q: I am trying to debug a problem. I can not resolve fully qualified
domain names unless I put a . at the end of the name. Any thoughts?
A: (Answer written by Mark Andrews) You are not using a RFC1535 aware
resolver. Depending upon the age of your resolver you could try
adding a search directive to resolv.conf.
e.g.
domain <domain>
search <domain> [<domain2> ...]
If that doesn't work you can configure you server to serve the parent
and grandparent domains as this is the default search list.
"domain langley.af.mil" has an implicit "search langley.af.mil af.mil
mil" in the old resolvers, and you are timing out trying to resolve
the address with one of these domains tacked on.
When resolving internic.net the following will be tried in order.
internic.net.langley.af.mil
internic.net.af.mil
internic.net.mil
internic.net.
RFC1535 aware resolvers try qualified address first.
internic.net.
internic.net.langley.af.mil
internic.net.af.mil
internic.net.mil
RFC1535 documents the problems associated with the old search algorithim,
including security issues, and how to alleviate some of the problems.
------------------------------
Date: Sun May 5 23:46:32 EDT 1996
Subject: Q5.11 - Err/TO errors being reported
Q: I am running the latest verison of named (4.9.3 + P1). Why are we
seeing messages like:
Apr 2 20:41:58 nameserver named[25846]: Err/TO getting serial# for
"foobar.domain1.com"
Apr 2 20:41:59 nameserver named[25846]: Err/TO getting serial# for
"foobar.domain2.com"
A: These generally indicate that there is one of the following problems:
1. A network problem between you and the primary,
2. A bad IP address in named.boot,
3. The primary is Lame for the zone.
An external check to see if you can retrieve the SOA is the best way to
work out which it is.
------------------------------
Date: Thu Jul 4 23:20:20 EDT 1996
Subject: Q5.12 - Why does swapping kill BIND ?
Q: I've been diagnosing a problem with BIND 4.9.x (where x is usually 3BETA9
or 3REL) for several months now. I finally tracked it down to swap space
utilization on the unix boxes.
This happens under (at least) under Linux 1.2.9 & 1.2.13, SunOS 4.1.3U1,
4.1.1, and Solaris 2.5. The symptom is that if these machines get into
swap at all bind quits resolving most, if not all queries. Mind you that
these machines are not "swapping hard", but rather we're talking about a
several hundred K TEMPORARY deficiency. I have noticed while digging
through various archives that there is some referral to "bind thrashing
itself to death". Is this what is happening ?
A: Yes it is. Bind can't tolerate having even a few pages swapped out.
The time required to send responses climbs to several seconds/request,
and the request queue fills and overflows.
It's possible to shrink memory consumption a lot by undefining STATS
and XSTATS, and recompiling. You could nuke DEBUG too, which will
cut the code size down some, but probably not the data size. If that
doesn't do the job then it sounds like you'll need to move DNS onto a
separate box.
BIND tends to touch all of its resident pages all of the time with
normal activity... if you look at the RSS verses the total process
size, you will always see the RSS within, usually, 90% of the total
size of the process. This means that *any* paging of named-owned
pages will stall named. Thus, a machine running a heavily accessed
named process cannot afford to swap *at all*.
(Paul Vixie continues on this subject):
I plan to try to get BIND to exhibit slightly better locality of
reference in some future release. Of course, I can only do this if
the query names also exhibit some kind of hot spots. If someone
queries all your names often, BIND will have to touch all of its VM
pool that often. (Right now, BIND touches everything pretty often
even if you're just hammering on some hot spots -- that's the part
I'd like to fix. Malloc isn't cooperating.)
------------------------------
Date: Thu Jul 4 23:29:40 EDT 1996
Subject: Q6 - Acknowledgements
Listed in e-mail address alphabetical order, the following people have
contributed to this FAQ:
Benoit.Grange@inria.fr (Benoit.Grange)
D.T.Shield@csc.liv.ac.uk (Dave Shield)
Todd.Aven@BankersTrust.Com
adam@comptech.demon.co.uk (Adam Goodfellow)
andras@is.co.za (Andras Salamon)
barmar@nic.near.net (Barry Margolin)
barr@pop.psu.edu (David Barr)
bj@herbison.com (B.J. Herbison)
bje@cbr.fidonet.org (Ben Elliston)
brad@birch.ims.disa.mil (Brad Knowles)
ckd@kei.com (Christopher Davis)
cdp2582@hertz.njit.edu (Chris Peckham)
cricket@hp.com (Cricket Liu)
cudep@csv.warwick.ac.uk (Ian 'Vato' Dickinson [ID17])
dillon@best.com (Matthew Dillon)
dparter@cs.wisc.edu (David Parter)
e07@nikhef.nl (Eric Wassenaar)
fitz@think.com (Tom Fitzgerald)
fwp@CC.MsState.Edu (Frank Peters)
gah@cco.caltech.edu (Glen A. Herrmannsfeldt)
glenn@popco.com (Glenn Fleishman)
harvey@indyvax.iupui.edu (James Harvey)
hubert@cac.washington.edu (Steve Hubert)
ivanl@pacific.net.sg (Ivan Leong)
jmalcolm@uunet.uu.net (Joseph Malcolm)
jhawk@panix.com (John Hawkinson)
kevin@cfc.com (Kevin Darcy)
lamont@abstractsoft.com (Sean T. Lamont)
lavondes@tidtest.total.fr (Michel Lavondes)
mark@ucsalf.ac.uk (Mark Powell)
marka@syd.dms.CSIRO.AU (Mark Andrews)
mathias@unicorn.swi.com.sg (Mathias Koerber)
mjo@iao.ford.com (Mike O'Connor)
nick@flapjack.ieunet.ie (Nick Hilliard)
oppedahl@popserver.panix.com (Carl Oppedahl)
patrick@oes.amdahl.com (Patrick J. Horgan)
paul@software.com (Paul Wren)
pb@fasterix.frmug.fr.net (Pierre Beyssac)
ph10@cus.cam.ac.uk (Philip Hazel)
phil@netpart.com (Phil Trubey)
rv@seins.Informatik.Uni-Dortmund.DE (Ruediger Volk)
shields@tembel.org (Michael Shields)
tanner@george.arc.nasa.gov (Rob Tanner)
vixie@vix.com (Paul A Vixie)
wag@swl.msd.ray.com (William Gianopoulos {84718})
whg@inel.gov (Bill Gray)
wolf@pasteur.fr (Christophe Wolfhugel)
Thank you !