2072 lines
83 KiB
Plaintext
2072 lines
83 KiB
Plaintext
Path: senator-bedfellow.mit.edu!bloom-beacon.mit.edu!news.kodak.com!news-nysernet-16.sprintlink.net!news-in-east1.sprintlink.net!news.sprintlink.net!newshub.northeast.verio.net!news.idt.net!newsin.iconnet.net!IConNet!not-for-mail
|
|
From: cdp2582@hertz.njit.edu (Chris Peckham)
|
|
Newsgroups: comp.protocols.tcp-ip.domains,comp.answers,news.answers,comp.protocols.dns.bind
|
|
Subject: comp.protocols.tcp-ip.domains Frequently Asked Questions (FAQ) (Part 2 of 2)
|
|
Supersedes: <cptd-faq-2-911181667@njit.edu>
|
|
Followup-To: comp.protocols.tcp-ip.domains
|
|
Organization: NJIT.EDU - New Jersey Institute of Technology, Newark, NJ, USA
|
|
Lines: 2050
|
|
Sender: cdp@chipmunk.iconnet.net
|
|
Approved: news-answers-request@MIT.EDU
|
|
Distribution: world
|
|
Expires: Wednesday, 20 Jan 99 11:47:26 EDT
|
|
Message-ID: <cptd-faq-2-913826846@njit.edu>
|
|
References: <cptd-faq-1-913826846@njit.edu>
|
|
Reply-To: domain-faq@pfmc.net (comp.protocols.tcp-ip.domains FAQ comments)
|
|
Keywords: BIND,DOMAIN,DNS
|
|
X-Posting-Frequency: posted during the first week of each month
|
|
Date: Wed, 16 Dec 1998 16:47:32 GMT
|
|
NNTP-Posting-Host: chipmunk.iconnet.net
|
|
NNTP-Posting-Date: Wed, 16 Dec 1998 11:47:32 EDT
|
|
Xref: senator-bedfellow.mit.edu comp.protocols.tcp-ip.domains:22180 comp.answers:34269 news.answers:146737 comp.protocols.dns.bind:6040
|
|
|
|
Posted-By: auto-faq 3.3 beta (Perl 5.004)
|
|
Archive-name: internet/tcp-ip/domains-faq/part2
|
|
|
|
(Continued from Part 1, where you'll find the introduction and
|
|
table of contents.)
|
|
|
|
|
|
===============================================================================
|
|
|
|
Section 5. CONFIGURATION
|
|
|
|
Q5.1 Upgrading from 4.9.x to 8.x
|
|
Q5.2 Changing a Secondary server to a Primary server ?
|
|
Q5.3 Moving a Primary server to another server
|
|
Q5.4 How do I subnet a Class B Address ?
|
|
Q5.5 Subnetted domain name service
|
|
Q5.6 Recommended format/style of DNS files
|
|
Q5.7 DNS on a system not connected to the Internet
|
|
Q5.8 Multiple Domain configuration
|
|
Q5.9 wildcard MX records
|
|
Q5.10 How do you identify a wildcard MX record ?
|
|
Q5.11 Why are fully qualified domain names recommended ?
|
|
Q5.12 Distributing load using named
|
|
Q5.13 Round robin IS NOT load balancing
|
|
Q5.14 Order of returned records
|
|
Q5.15 resolv.conf
|
|
Q5.16 How do I delegate authority for sub-domains ?
|
|
Q5.17 DNS instead of NIS on a Sun OS 4.1.x system
|
|
Q5.18 Patches to add functionality to BIND
|
|
Q5.19 How to serve multiple domains from one server
|
|
Q5.20 hostname and domain name the same
|
|
Q5.21 Restricting zone transfers
|
|
Q5.22 DNS in firewalled and private networks
|
|
Q5.23 Different DNS answers for same RR
|
|
|
|
-----------------------------------------------------------------------------
|
|
|
|
Question 5.1. Upgrading from 4.9.x to 8.x
|
|
|
|
Date: Wed Jul 9 22:00:07 EDT 1997
|
|
|
|
Q: Help ! How do I use the Completely new configuration syntax in BIND 8
|
|
? I've attempted to upgrade bind from 4.9.5 to 8.1, but unfortunately it
|
|
didn't seem to like the same config/zone files.. is this normal or should
|
|
8.1 be able to read the same files as 4.9.5 did?
|
|
|
|
A: If you then look in doc/html/config.html, you will find directions on
|
|
how to convert a 4.9.x .boot file to 8.x .conf file, as well as directions
|
|
on how to utilize all of the new features of the 8.x .conf file format.
|
|
|
|
-----------------------------------------------------------------------------
|
|
|
|
Question 5.2. Changing a Secondary server to a Primary server ?
|
|
|
|
Date: Fri Jul 5 23:54:35 EDT 1996
|
|
|
|
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.
|
|
|
|
-----------------------------------------------------------------------------
|
|
|
|
Question 5.3. Moving a Primary server to another server
|
|
|
|
Date: Fri Jul 5 23:54:35 EDT 1996
|
|
|
|
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.
|
|
|
|
If you are moving to a different ISP which will change your IP's, the
|
|
recommend setting for the SOA that would minimize problems for your name
|
|
servers using the old settings can be done as follows:
|
|
|
|
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 with 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.
|
|
|
|
Also see the answer to the "How can I change the IP address of our server
|
|
?" in the INTRODUCTION section.
|
|
|
|
-----------------------------------------------------------------------------
|
|
|
|
Question 5.4. How do I subnet a Class B Address ?
|
|
|
|
Date: Mon Jun 15 23:21:39 EDT 1998
|
|
|
|
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). RFC
|
|
1219 discusses the issue of subnetting very well and leaves the network
|
|
administrator with a large amount of flexibility for future growth.
|
|
|
|
(The following section was contributed by Berislav Todorovic.)
|
|
|
|
A user or an ISP, having a whole /16 sized IP block (former "Class B")
|
|
network assigned/allocated, has the responsibility of maintaining the
|
|
reverse domain for the whole network. That policy is currently applied by
|
|
all regional Internet registries (RIPE NCC, ARIN, APNIC). In other words,
|
|
if you're assigned a whole "B class" (say, 10.91/16), you're in charge for
|
|
the whole 91.10.IN-ADDR.ARPA zone. This zone may be organized using two
|
|
methods, according to the network topology being in use.
|
|
|
|
The first, "brute force" method is to place all PTR records directly into
|
|
a single zone file. Example:
|
|
|
|
$origin 91.10.in-addr.arpa
|
|
@ IN SOA (usual stuff)
|
|
IN NS ns1.mydomain.com.
|
|
IN NS ns2.mydomain.com.
|
|
|
|
1.1 IN PTR one-1.mydomain.com. ; ---> 10.91.1.1
|
|
2.1 IN PTR one-2.mydomain.com. ; ---> 10.91.1.2
|
|
...
|
|
254.1 IN PTR one-254.mydomain.com. ; ---> 10.91.1.254
|
|
1.2 IN PTR two-1.mydomain.com. ; ---> 10.91.2.1
|
|
|
|
While this approach may look simple in the networks with a central
|
|
management authority (say, campus networks), maintaining such a zone file
|
|
becomes more and more difficult in the more complex environment. Thus,
|
|
this becomes a bad method. Furthermore, if you're an ISP, it is more
|
|
likely that a /16 network will be subnetted and its subnets be assigned to
|
|
your customers.
|
|
|
|
Therefore, another "smarter" approach is to delegate portions of the
|
|
reverse domain 91.10.IN-ADDR.ARPA to the end users of the subnets of
|
|
10.91/16. There would only be NS records in the zone file, while PTR
|
|
record insertion would be the responsibility of the end users. For
|
|
example, if you assign:
|
|
|
|
* 10.91.0.0/22 (10.91.0.0 - 10.91.3.255) to Customer-A.COM
|
|
* 10.91.4.0/23 (10.91.4.0 - 10.91.5.255) to Customer-B.COM
|
|
* 10.91.7.0/24 (10.91.7.0 - 10.91.7.255) to Customer-C.COM
|
|
|
|
then each customer will maintain zone files for the reverse domains of
|
|
their own networks (say, Customer C will maintain the zone
|
|
7.91.10.IN-ADDR.ARPA, customer B their 2 zones, Customer A their own 4
|
|
zones). In this constellation, the zone file for reverse domain
|
|
91.10.IN-ADDR.ARPA will look like this:
|
|
|
|
$origin 91.10.in-addr.arpa
|
|
@ IN SOA (usual stuff)
|
|
IN NS ns1.mydomain.com.
|
|
IN NS ns2.mydomain.com.
|
|
|
|
; --- Customer-A.COM
|
|
|
|
|
|
0 IN NS ns.customer-A.com.
|
|
IN NS ns1.mydomain.com.
|
|
1 IN NS ns.customer-A.com.
|
|
IN NS ns1.mydomain.com.
|
|
2 IN NS ns.customer-A.com.
|
|
IN NS ns1.mydomain.com.
|
|
3 IN NS ns.customer-A.com.
|
|
IN NS ns1.mydomain.com.
|
|
|
|
; --- Customer-B.COM
|
|
|
|
4 IN NS ns.customer-B.com.
|
|
IN NS ns1.mydomain.com.
|
|
5 IN NS ns.customer-B.com.
|
|
IN NS ns1.mydomain.com.
|
|
|
|
; --- Customer-C.COM
|
|
|
|
7 IN NS ns.customer-C.com.
|
|
IN NS ns1.mydomain.com.
|
|
|
|
The zone file of the Customer C reverse domain would look like this:
|
|
|
|
$origin 7.91.10.in-addr.arpa
|
|
@ IN SOA (usual stuff)
|
|
IN NS ns.customer-C.com.
|
|
IN NS ns1.mydomain.com.
|
|
|
|
1 IN PTR one.customer-C.com.
|
|
2 IN PTR two.customer-C.com.
|
|
3 IN PTR three.customer-C.com.
|
|
...
|
|
|
|
-----------------------------------------------------------------------------
|
|
|
|
Question 5.5. Subnetted domain name service
|
|
|
|
Date: Thu Jul 16 10:50:41 EDT 1998
|
|
|
|
If you are looking for some examples of handling subnetted class C
|
|
networks as separate DNS domains, see RFC 2317 for more information.
|
|
|
|
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.
|
|
|
|
There is additional documentation and a perl script that may be used for
|
|
this purpose available for anonymous ftp from:
|
|
|
|
ftp.is.co.za : /networking/ip/dns/gencidrzone/gencidrzone
|
|
|
|
-----------------------------------------------------------------------------
|
|
|
|
Question 5.6. Recommended format/style of DNS files
|
|
|
|
Date: Sun Nov 27 23:32:41 EST 1994
|
|
|
|
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 internally; 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
|
|
sync. 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.
|
|
|
|
-----------------------------------------------------------------------------
|
|
|
|
Question 5.7. DNS on a system not connected to the Internet
|
|
|
|
Date: Sun Nov 27 23:32:41 EST 1994
|
|
|
|
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)
|
|
|
|
If you connect intermittently and want DNS to work when you are connected,
|
|
and "fail" when you are not, 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.
|
|
|
|
-----------------------------------------------------------------------------
|
|
|
|
Question 5.8. Multiple Domain configuration
|
|
|
|
Date: Fri Dec 2 15:40:49 EST 1994
|
|
|
|
If you want to have multiple domain names pointing to the same
|
|
destination, such as:
|
|
|
|
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
|
|
|
|
You may do this by using CNAMEs:
|
|
|
|
ftp.bowser.com. IN CNAME ftp.biff.com.
|
|
|
|
You can also do the same thing with multiple A records.
|
|
|
|
-----------------------------------------------------------------------------
|
|
|
|
Question 5.9. wildcard MX records
|
|
|
|
Date: Sun Nov 27 23:32:41 EST 1994
|
|
|
|
Does BIND not understand wildcard MX records such as the following?
|
|
|
|
*.foo.com MX 0 mail.foo.com.
|
|
|
|
No. It just doesn't work.
|
|
|
|
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.
|
|
|
|
-----------------------------------------------------------------------------
|
|
|
|
Question 5.10. How do you identify a wildcard MX record ?
|
|
|
|
Date: Thu Dec 1 11:10:39 EST 1994
|
|
|
|
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.
|
|
|
|
-----------------------------------------------------------------------------
|
|
|
|
Question 5.11. Why are fully qualified domain names recommended ?
|
|
|
|
Date: Sun Nov 27 23:32:41 EST 1994
|
|
|
|
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?
|
|
|
|
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.
|
|
|
|
-----------------------------------------------------------------------------
|
|
|
|
Question 5.12. Distributing load using named
|
|
|
|
Date: Thu Jul 16 10:42:05 EDT 1998
|
|
|
|
When you attempt to distribute the load on a system using named, the first
|
|
response be cached, and then later queries use the cached value (This
|
|
would be for requests that come through the same server). Therefore, 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.
|
|
|
|
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
|
|
|
|
Please note that this is not a recommended practice and will not work with
|
|
modern BIND unless you have the entry "multiple-cnames yes" in your
|
|
named.conf file.
|
|
|
|
-----------------------------------------------------------------------------
|
|
|
|
Question 5.13. Round robin IS NOT load balancing
|
|
|
|
Date: Mon Mar 9 22:10:51 EST 1998
|
|
|
|
Round robin != load balancing. It's a very crude attempt at load
|
|
balancing, and a method that is possible without breaking DNS protocols.
|
|
If a host is down that is included in a round robin list, then
|
|
connections to that particular host will fail. In addition, true load
|
|
balancing should take into consideration the actual LOAD on the system.
|
|
|
|
Information on one such technique, implemented by Roland J. Schemers III
|
|
at Stanford, may be found at
|
|
http://www-leland.stanford.edu/~schemers/docs/lbnamed/lbnamed.html.
|
|
|
|
Additional information may be found in RFC 1794. MultiNet for OpenVMS
|
|
also includes this feature.
|
|
|
|
-----------------------------------------------------------------------------
|
|
|
|
Question 5.14. Order of returned records
|
|
|
|
Date: Tue Apr 8 20:21:02 EDT 1997
|
|
|
|
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. The directive may also be used in the
|
|
named.boot as well.
|
|
|
|
-----------------------------------------------------------------------------
|
|
|
|
Question 5.15. resolv.conf
|
|
|
|
Date: Fri Feb 10 15:46:17 EST 1995
|
|
|
|
The question was asked one time, "Why should I use 'real' IP addresses in
|
|
/etc/resolv.conf and not 0.0.0.0 or 127.0.0.1" ?
|
|
|
|
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.
|
|
|
|
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).
|
|
|
|
-----------------------------------------------------------------------------
|
|
|
|
Question 5.16. How do I delegate authority for sub-domains ?
|
|
|
|
Date: Mon Nov 10 22:57:54 EST 1997
|
|
|
|
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 your new servers
|
|
(NOTE that the new servers DO NOT have to be in the new 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.
|
|
|
|
To delegate authority for PTR records, the same concepts apply.
|
|
|
|
stub 10.168.192.in-addr.arpa <subdomain server addr> db.192.168.10
|
|
|
|
may be added to your primary server's named.boot in recent versions of
|
|
bind. In other versions (and recent ones :-) ), the following lines may
|
|
be added to the db.192.168.10 zone file to perform the same function:
|
|
|
|
xxx IN NS <server1>
|
|
xxx IN NS <server2>
|
|
xxx IN NS <server3> ; if needed
|
|
...
|
|
xxx IN NS <serverN> ; if needed
|
|
|
|
-----------------------------------------------------------------------------
|
|
|
|
Question 5.17. DNS instead of NIS on a Sun OS 4.1.x system
|
|
|
|
Date: Sat Dec 7 01:14:17 EST 1996
|
|
|
|
Comments relating to running bind 4.9.x on a Sun OS 4.1.x system and the
|
|
effect on sendmail, ftp, telnet and other TCP/IP services bypassing NIS
|
|
and directly using named is documented quite well in the
|
|
comp.sys.sun.admin FAQ in questions one and two. You can get them from:
|
|
|
|
* ftp.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.
|
|
|
|
-----------------------------------------------------------------------------
|
|
|
|
Question 5.18. Patches to add functionality to BIND
|
|
|
|
Date: Wed Jan 14 11:57:20 EST 1998
|
|
|
|
There are others, but these are listed here:
|
|
|
|
* When using the round robin DNS and assigning 3 IPs to a host (for
|
|
example), a process to guarantee that all 3 IPs are reachable may be
|
|
found at
|
|
http://www-leland.stanford.edu/~schemers/docs/lbnamed/lbnamed.html
|
|
|
|
* Patches for 4.9.3-REL that will support the IPv6 AAAA record format may
|
|
be found at ftp.inria.fr : /network/ipv6/
|
|
|
|
This is built into more recent versions of BIND (after 4.9.5?)
|
|
|
|
* A patch for 4.9.3-REL that will allow you to turn off forwarding of
|
|
information from my server may be found at ftp.vix.com :
|
|
/pub/bind/release/4.9.3/contrib/noforward.tar.gz
|
|
|
|
Also look at
|
|
|
|
ftp.is.co.za : /networking/ip/dns/bind/contrib/noforward.tar.gz
|
|
|
|
* How do I tell a server to listen to a particular interface to listen and
|
|
respond to DNS queries on ?
|
|
|
|
Mark Andrews has a patch that will tell a 4.9.4 server to listen to a
|
|
particular interface and respond to DNS queries. It may be found at an
|
|
unofficial location: http://www.ultra.net/~jzp/andrews.patch.txt
|
|
|
|
This is built into BIND 8.1.1.
|
|
|
|
* A patch to implement "selective forwarding" from Todd Aven at
|
|
http://www.dns.net/dnsrd/servers.html.
|
|
|
|
-----------------------------------------------------------------------------
|
|
|
|
Question 5.19. How to serve multiple domains from one server
|
|
|
|
Date: Tue Nov 5 23:44:02 EST 1996
|
|
|
|
Most name server implementations allow information about multiple domains
|
|
to be kept on one server, and questions about those domains to be
|
|
answered by that one server. For instance, there are many large servers
|
|
on the Internet that each serve information about more than 1000
|
|
different domains.
|
|
|
|
To be completely accurate, a server contains information about zones,
|
|
which are parts of domains that are kept as a single unit. [Ed note: for
|
|
a definition of zones and domains, see Section 2: The Name Service in the
|
|
"Name Server Operations Guide" included with the BIND 4.9.5 distribution.]
|
|
|
|
In the configuration of the name server, the additional zones need to be
|
|
specified. An important consideration is whether a particular server is
|
|
primary or secondary for any specific zone--a secondary server maintains
|
|
only a copy of the zone, periodically refreshing its copy from another,
|
|
specified, server. In BIND, to set up a server as a secondary server for
|
|
the x.y.z zone, to the configuration file /etc/named.boot add the line
|
|
|
|
secondary x.y.z 10.0.0.1 db.x.y.z
|
|
|
|
where 10.0.0.1 is the IP address of the server that the zone will be
|
|
copied from, and db.x.y.z is a local filename that will contain the copy
|
|
of the zone.
|
|
|
|
If this is a question related to how to set up multiple IP numbers on one
|
|
system, which you do not need to do to act as a domain server for
|
|
multiple domains, see
|
|
|
|
http://www.thesphere.com/%7Edlp/TwoServers/.
|
|
|
|
-----------------------------------------------------------------------------
|
|
|
|
Question 5.20. hostname and domain name the same
|
|
|
|
Date: Wed Jul 9 21:47:36 EDT 1997
|
|
|
|
Q: I have a subdomain sub.foobar.com. I would like to name a host
|
|
sub.foobar.com. It should also be the mail relay for all hosts in
|
|
sub.foobar.com. How do I do this ?
|
|
|
|
A: You would add an A record for sub.foobar.com, and multiple MX records
|
|
pointing to this host (sub.foobar.com). For example:
|
|
|
|
sub.foobar.com. IN A 1.2.3.4 ; address of host
|
|
;
|
|
foo.sub.foobar.com. IN MX 10 sub.foobar.com.
|
|
bar.sub.foobar.com. IN MX 10 sub.foobar.com.
|
|
|
|
The host, sub.foobar.com, may also need to be to configured to understand
|
|
that mail addressed to user@sub.foobar.com and possibly other sub.foobar.com
|
|
hosts should be treated as local.
|
|
|
|
-----------------------------------------------------------------------------
|
|
|
|
Question 5.21. Restricting zone transfers
|
|
|
|
Date: Wed Jan 14 12:16:35 EST 1998
|
|
|
|
Q: How do I restrict my zone transfers to my secondaries or other trusted
|
|
hosts?
|
|
|
|
A: Use the 'xfrnets' directive within the named.boot file or the
|
|
'secure_zone' TXT RR within a zone file. The BOG has more information on
|
|
both of these options.
|
|
|
|
As an example within an 4.9.x named.boot file:
|
|
|
|
xfernets 10.1.2.0&255.255.255.0 44.66.10.0&255.255.255.0
|
|
|
|
|
|
Only Nameservers on these networks will be able to do zone transfers from
|
|
the server with this configuration.
|
|
|
|
Please note that 'secure_zone' restricts all access to the containing
|
|
zone, as well as restricting zone transfers :-) .
|
|
|
|
BIND 8.x supports restricting zone transfers on a per-zone basis in the
|
|
named.conf file, whereas BIND 4.9.x only supports xfrnets as a global
|
|
option.
|
|
|
|
-----------------------------------------------------------------------------
|
|
|
|
Question 5.22. DNS in firewalled and private networks
|
|
|
|
Date: Mon Sep 14 22:15:16 EDT 1998
|
|
|
|
(The following section was contributed by Berislav Todorovic)
|
|
|
|
When talking about private networks, we distinguish between two cases:
|
|
|
|
* Networks consisting of firewall-separated private and public subnetworks
|
|
|
|
* Same domain name used in private and public part of the network
|
|
* Different domain names used in the public and private subnetwork
|
|
|
|
* Closed networks, not connected the Internet at all
|
|
|
|
* The first case of the "Same domain name", we're talking about DNS
|
|
configuration, usually referred to as "split DNS". In this case, two
|
|
different DNS servers (or two separate DNS processes on the same
|
|
multi-homed machine) have to be configured. One of them ("private DNS")
|
|
will serve the internal network and will contain data about all hosts in
|
|
the private part of the network. The other one ("public DNS") will serve
|
|
Internet users and will contain only the most necessary RR's for
|
|
Internet users (like MX records for email exchange, A and CNAME records
|
|
for public Web servers, records for other publicly accessible hosts
|
|
etc.). Both of them will be configured as primary for the same corporate
|
|
domain (e.g. DOMAIN.COM). The public DNS will be delegated with the
|
|
appropriate NIC as authoritative for domain DOMAIN.COM.
|
|
|
|
Private DNS - resolves names from DOMAIN.COM for hosts inside the
|
|
private network. If asked for a name outside DOMAIN.COM, they should
|
|
forward the request to the public DNS (forwarders line should be used in
|
|
the boot file). They should NEVER contact a root DNS on the Internet.
|
|
The boot file for the private DNS should, therefore, be:
|
|
|
|
primary domain.com ZONE.domain.com
|
|
primary 1.10.in-addr.arpa REV.10.1
|
|
forwarders 172.16.12.10
|
|
slave
|
|
Public DNS - resolves names from DOMAIN.COM for hosts on the public part
|
|
of the network. If asked for a name outside DOMAIN.COM they should
|
|
contact root DNS servers or (optionally) forward the request to a
|
|
forwarder on the ISP network. Boot file for the public DNS should be of
|
|
the form:
|
|
|
|
primary domain.com ZONE.domain.com
|
|
primary 12.16.172.in-addr.arpa REV.172.16.12
|
|
... (other domains)
|
|
Zone files for domain DOMAIN.COM on the public and private DNS should
|
|
be:
|
|
|
|
; --- Public DNS - zone file for DOMAIN.COM
|
|
|
|
domain.com. IN SOA ns.domain.com. hostmaster.domain.com. ( ... )
|
|
IN NS ns.domain.com.
|
|
IN NS ns.provider.net.
|
|
IN MX 10 mail.provider.net.
|
|
|
|
ns IN A 172.16.12.10
|
|
www IN A 172.16.12.12
|
|
ftp IN A 172.16.12.13
|
|
...
|
|
|
|
; --- Private DNS - zone file for DOMAIN.COM
|
|
|
|
domain.com. IN SOA ns1.domain.com. hostmaster.domain.com. ( ... )
|
|
IN NS ns1.domain.com.
|
|
IN NS ns2.domain.com.
|
|
wks1-1 IN A 10.1.1.1
|
|
wks1-2 IN A 10.1.1.2
|
|
...
|
|
|
|
The second case of the "Same domain name", is simpler than the previous
|
|
case: in the internal network, a separate domain name might be used.
|
|
Recommended domain name syntax is "name.local" (e.g. DOMAIN.LOCAL).
|
|
Sample configuration:
|
|
|
|
; --- Private DNS - named.boot
|
|
|
|
primary domain.local ZONE.domain.local
|
|
...
|
|
forwarders 172.16.12.10
|
|
slave
|
|
|
|
; --- Public DNS - named.boot
|
|
|
|
primary domain.com ZONE.domain.com
|
|
...
|
|
IMPLEMENTATION NOTES
|
|
|
|
Location of the DNS service in both cases is irrelevant. Usually, they
|
|
are located on two different physical servers, each of them connected to
|
|
the appropriate part of the network (private, public). Certain savings
|
|
may be done if public DNS service is hosted on the ISP network - in that
|
|
case, the user will need only one (private) DNS server.
|
|
|
|
Finally, both public and private DNS, in some cases, may be placed on
|
|
the servers in the private network, behind the firewall. With a Cisco
|
|
PIX, a statical public/private IP address mapping in this case would be
|
|
needed. Two servers for the same domain could be even placed on the
|
|
same physical server, with two different DNS processes running on
|
|
different IP interfaces. Note that BIND 8 is needed in the latter case.
|
|
|
|
* If the network is not connected to the Internet at all, only private DNS
|
|
servers are needed. However, due to the lack of Internet connectivity,
|
|
internal servers will fail to contact the root DNS servers every time a
|
|
user types, by mistake, an address outside the corporate domain
|
|
DOMAIN.COM. Some older servers won't even work if they can't reach root
|
|
servers. To overcome this, it is most proper to create a so-called "fake
|
|
root zone" on one or more DNS servers in the corporation. That would
|
|
make all DNS servers within the corporation think there is only one or
|
|
two DNS servers in the world, all located on the corporation network.
|
|
Only domain names used within the corporation (DOMAIN.COM, appropriate
|
|
inverse domains etc.) should be entered in the fake root zone file. Note
|
|
that no cache line in the boot file of the "root" DNS makes sense.
|
|
Sample configuration:
|
|
|
|
; --- named.boot
|
|
|
|
primary domain.com ZONE.domain.com
|
|
primary 1.10.in-addr.arpa REV.10.1
|
|
priamry . ZONE.root
|
|
... (other data; NOTE - do *NOT* place any "cache" line here !!!)
|
|
|
|
; --- ZONE.root - fake root zone file, containing only corporation domains
|
|
|
|
. IN NS ns.domain.com. hostmaster.domain.com. ( ... )
|
|
IN NS ns.domain.com.
|
|
IN NS ns2.domain.com.
|
|
|
|
domain.com. IN NS ns.domain.com.
|
|
ns.domain.com. IN A 10.1.1.1
|
|
domain.com. IN NS ns2.domain.com.
|
|
ns2.domain.com. IN A 10.1.1.2
|
|
|
|
1.10.in-addr.arpa. IN NS ns.domain.com.
|
|
IN NS ns2.domain.com.
|
|
|
|
Other zone files follow standard configuration.
|
|
|
|
-----------------------------------------------------------------------------
|
|
|
|
Question 5.23. Different DNS answers for same RR
|
|
|
|
Date: Mon Sep 14 22:15:16 EDT 1998
|
|
|
|
(The following section was contributed by Berislav Todorovic)
|
|
|
|
Many times there is a need for a DNS server to send different answers for
|
|
same RR's, depending on the IP address of the request sender. For example,
|
|
many coprporations wish to make their customers to use the "geographically
|
|
closest" Web server when accessing corporate Web pages. A corporation may
|
|
impose the following policy: if someone asked for the IP address of
|
|
WWW.DOMAIN.COM, they may want to:
|
|
|
|
* Answer that the IP address is 172.16.2.3, if the request came from one
|
|
of the following IP networks: 172.1/16, 172.2/16 or 172.10/16.
|
|
* Answer that the IP address is 172.16.1.1, if the request came from the
|
|
IP address 172.16/16 or 172.17.128/18.
|
|
* By default, for all other requests send the answer that the IP address
|
|
is 172.16.2.3.
|
|
|
|
The example above will need a DNS to send different A RR's, depending on
|
|
the source of queries. A similar approach may be imposed for MX's, CNAME's
|
|
etc. The question which arise here is: IS IT POSSIBLE?
|
|
|
|
[Ed note: There are commercial products such as Cisco's Distributed
|
|
Director that also will address this issue]
|
|
|
|
The simple answer to the question is: NOT DIRECTLY. This is true if
|
|
standard DNS software (e.g. BIND) is used on the DNS servers. However,
|
|
there are two workarounds which may solve this problem:
|
|
|
|
* Using two DNS servers on different UDP ports + UDP redirector
|
|
* Using two DNS servers on different IP addresses + NAT on the router
|
|
|
|
Solution 1: (tested on a Linux system and should work on other Unix boxes
|
|
as well). Software needed is:
|
|
|
|
* BIND 8
|
|
* udprelay - a package which redirects traffic to other UDP port
|
|
(sunsite.unc.edu: /pub/Linux/system/network/misc/udprelay-0.2.tar.Z ).
|
|
|
|
Build and install udprelay and bring up two DNS servers on different UDP
|
|
ports, using different configuration files (i.e., bring one on 5300 and
|
|
the other one on 5400):
|
|
|
|
// --- named.conf.5300
|
|
options {
|
|
directory "/var/named"
|
|
listen-on port 5300 { any; };
|
|
... (other options)
|
|
};
|
|
|
|
zone "domain.com" {
|
|
type master;
|
|
file "domain.com.5300";
|
|
};
|
|
|
|
// --- named.conf.5400
|
|
|
|
options {
|
|
directory "/var/named"
|
|
listen-on port 5400 { any; };
|
|
... (other options)
|
|
};
|
|
|
|
zone "domain.com" {
|
|
type master;
|
|
file "domain.com.5400";
|
|
};
|
|
|
|
|
|
; domain.com.5300
|
|
... (SOA and other stuff)
|
|
|
|
www IN A 172.16.2.3
|
|
|
|
; --- domain.com.5400
|
|
... (SOA and other stuff)
|
|
|
|
www IN A 172.16.1.1
|
|
|
|
As can be seen, there will be two separate zone files for DOMAIN.COM,
|
|
depending on which UDP port the server listens to. Each zone file can
|
|
contain different records. Now, when configure udprelay to forward UDP
|
|
traffic from port 53 to 5300 or 5400, depending on the remote IP address:
|
|
|
|
relay 172.1.0.0 mask 255.255.0.0 * 53 172.16.1.1 5300 53
|
|
relay 172.2.0.0 mask 255.255.0.0 * 53 172.16.1.1 5300 53
|
|
relay 172.10.0.0 mask 255.255.0.0 * 53 172.16.1.1 5300 53
|
|
relay 172.16.0.0 mask 255.255.0.0 * 53 172.16.1.1 5400 53
|
|
relay 172.17.0.0 mask 255.255.0.0 * 53 172.16.1.1 5400 53
|
|
relay * * 53 172.16.1.1 5400 53
|
|
After starting udprelay, all traffic coming to port 53 will be redirected
|
|
to 5300 or 5400, depending on the source IP address.
|
|
|
|
NOTE - This solution deals with the UDP part of DNS only. Zone xfers will
|
|
be able to be done from one DNS server only, since this solution doesn't
|
|
deal the TCP part of DNS. This is, thus, a partial solution but it works!
|
|
|
|
Solution 2: Bring up two DNS servers on your network, using "private" IP
|
|
addresses (RFC 1918), say ns1.domain.com (10.1.1.1) and ns2.domain.com
|
|
(10.1.1.2). Both servers will have the same public address - 172.16.1.1,
|
|
which will be used to access the servers. Configure them to be both
|
|
primary for domain DOMAIN.COM. Let one of them (say, ns1) be the
|
|
"default" DNS, which will be used in most of the cases. Establish NAT on
|
|
the router, so it translates the public IP address 172.16.1.1 to 10.1.1.1
|
|
and delegate your "default" DNS with the appropriate NIC, using its public
|
|
address 172.16.1.1. Once you're assured everything works, setup your
|
|
router to translate the public IP address 172.16.1.1 to either 10.1.1.1 or
|
|
10.1.1.2, depending on the requestor IP address. After that, depending on
|
|
the source IP address, the router will return one translation or the
|
|
latter, thus forwarding the remote side to the appropriate DNS server.
|
|
|
|
===============================================================================
|
|
|
|
Section 6. PROBLEMS
|
|
|
|
Q6.1 No address for root server
|
|
Q6.2 Error - No Root Nameservers for Class XX
|
|
Q6.3 Bind 4.9.x and MX querying?
|
|
Q6.4 Do I need to define an A record for localhost ?
|
|
Q6.5 MX records, CNAMES and A records for MX targets
|
|
Q6.6 Can an NS record point to a CNAME ?
|
|
Q6.7 Nameserver forgets own A record
|
|
Q6.8 General problems (core dumps !)
|
|
Q6.9 malloc and DECstations
|
|
Q6.10 Can't resolve names without a "."
|
|
Q6.11 Why does swapping kill BIND ?
|
|
Q6.12 Resource limits warning in system
|
|
Q6.13 ERROR:ns_forw: query...learnt
|
|
Q6.14 ERROR:zone has trailing dot
|
|
Q6.15 ERROR:Zone declared more then once
|
|
Q6.16 ERROR:response from unexpected source
|
|
Q6.17 ERROR:record too short from [zone name]
|
|
Q6.18 ERROR:sysquery: findns error (3)
|
|
Q6.19 ERROR:Err/TO getting serial# for XXX
|
|
Q6.20 ERROR:zonename IN NS points to a CNAME
|
|
Q6.21 ERROR:Masters for secondary zone [XX] unreachable
|
|
Q6.22 ERROR:secondary zone [XX] expired
|
|
Q6.23 ERROR:bad response to SOA query from [address]
|
|
Q6.24 ERROR:premature EOF, fetching [zone]
|
|
Q6.25 ERROR:Zone [XX] SOA serial# rcvd from [Y] is < ours
|
|
Q6.26 ERROR:connect(IP/address) for zone [XX] failed
|
|
Q6.27 ERROR:sysquery: no addrs found for NS
|
|
Q6.28 ERROR:zone [name] rejected due to errors
|
|
|
|
-----------------------------------------------------------------------------
|
|
|
|
Question 6.1. No address for root server
|
|
|
|
Date: Wed Jan 14 12:15:54 EST 1998
|
|
|
|
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.
|
|
|
|
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'.
|
|
|
|
Q: We are getting logging information in the form:
|
|
|
|
Apr 8 08:05:22 gute named[107]: sysquery: no addrs found for root NS
|
|
(A.ROOT-SERVERS.NET)
|
|
Apr 8 08:05:22 gute named[107]: sysquery: no addrs found for root NS
|
|
(B.ROOT-SERVERS.NET)
|
|
Apr 8 08:05:22 gute named[107]: sysquery: no addrs found for root NS
|
|
(C.ROOT-SERVERS.NET)
|
|
...
|
|
|
|
We are running bind 4.9.5PL1 Our system IS NOT behind a firewall. Any ideas ?
|
|
|
|
This was discussed on the mailing list in November of 1996. The short
|
|
answer was to ignore it as it was not a problem. That being said, you
|
|
should upgrade to a newer version at this time if you are running a
|
|
non-current version :-)
|
|
|
|
-----------------------------------------------------------------------------
|
|
|
|
Question 6.2. Error - No Root Nameservers for Class XX
|
|
|
|
Date: Sun Nov 27 23:32:41 EST 1994
|
|
|
|
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?
|
|
|
|
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.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.
|
|
|
|
-----------------------------------------------------------------------------
|
|
|
|
Question 6.3. Bind 4.9.x and MX querying?
|
|
|
|
Date: Sun Nov 27 23:32:41 EST 1994
|
|
|
|
If you 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. This
|
|
happens because 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.
|
|
|
|
-----------------------------------------------------------------------------
|
|
|
|
Question 6.4. Do I need to define an A record for localhost ?
|
|
|
|
Date: Sat Sep 9 00:36:01 EDT 1995
|
|
|
|
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.
|
|
|
|
-----------------------------------------------------------------------------
|
|
|
|
Question 6.5. MX records, CNAMES and A records for MX targets
|
|
|
|
Date: Sun Nov 27 23:32:41 EST 1994
|
|
|
|
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. How does this apply to mail
|
|
spokes. RFC 974 has a similar warning, but where is it specifically
|
|
prohibited to us an alias in an MX record ?
|
|
|
|
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.
|
|
|
|
-----------------------------------------------------------------------------
|
|
|
|
Question 6.6. Can an NS record point to a CNAME ?
|
|
|
|
Date: Wed Mar 1 11:14:10 EST 1995
|
|
|
|
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
|
|
|
|
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.
|
|
|
|
-----------------------------------------------------------------------------
|
|
|
|
Question 6.7. Nameserver forgets own A record
|
|
|
|
Date: Fri Dec 2 16:17:31 EST 1994
|
|
|
|
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.
|
|
|
|
-----------------------------------------------------------------------------
|
|
|
|
Question 6.8. General problems (core dumps !)
|
|
|
|
Date: Sun Dec 4 22:21:22 EST 1994
|
|
|
|
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.
|
|
|
|
-----------------------------------------------------------------------------
|
|
|
|
Question 6.9. malloc and DECstations
|
|
|
|
Date: Mon Jan 2 14:19:22 EST 1995
|
|
|
|
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.cs.wisc.edu : /pub/misc/malloc.tar.gz
|
|
|
|
-----------------------------------------------------------------------------
|
|
|
|
Question 6.10. Can't resolve names without a "."
|
|
|
|
(Answer written by Mark Andrews) You are not using a RFC 1535 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.
|
|
|
|
RFC 1535 aware resolvers try qualified address first.
|
|
|
|
internic.net.
|
|
internic.net.langley.af.mil
|
|
internic.net.af.mil
|
|
internic.net.mil
|
|
|
|
RFC 1535 documents the problems associated with the old search
|
|
algorithim, including security issues, and how to alleviate some of the
|
|
problems.
|
|
|
|
-----------------------------------------------------------------------------
|
|
|
|
Question 6.11. Why does swapping kill BIND ?
|
|
|
|
Date: Thu Jul 4 23:20:20 EDT 1996
|
|
|
|
The question was:
|
|
|
|
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 ?
|
|
|
|
And the answer is:
|
|
|
|
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.)
|
|
|
|
-----------------------------------------------------------------------------
|
|
|
|
Question 6.12. Resource limits warning in system
|
|
|
|
Date: Sun Feb 15 22:04:43 EST 1998
|
|
|
|
When bind-8.1.1 is started the following informational message appears in
|
|
the syslog...
|
|
|
|
Feb 13 14:19:35 ns1named[1986]:
|
|
"cannot set resource limits on this system"
|
|
|
|
What does this mean ?
|
|
|
|
A: It means that BIND doesn't know how to implement the "coresize",
|
|
"datasize", "stacksize", or "files" process limits on your OS.
|
|
|
|
If you're not using these options, you may ignore the message.
|
|
|
|
-----------------------------------------------------------------------------
|
|
|
|
Question 6.13. ERROR:ns_forw: query...learnt
|
|
|
|
Date: Sun Feb 15 23:08:06 EST 1998
|
|
|
|
The following message appears in syslog:
|
|
|
|
Jan 22 21:59:55 server1 named[21386]: ns_forw: query(testval) contains
|
|
our address (dns1.foobar.org:1.2.3.4) learnt (A=:NS=)
|
|
|
|
what does it mean ?
|
|
|
|
A: This means that when it was looking up the NS records for the domain
|
|
containing "testval" (i.e. the root domain), it found an NS record
|
|
pointing to dns1.foobar.org, and the A record for this is 1.2.3.4.
|
|
This is server1's own IP address, but it's not authoritative for the
|
|
root domain. The (A-:NS=) part of the message means that it didn't
|
|
learn these NS records from any other machine.
|
|
|
|
You may have listed dns1.foobar.org in your root server cache
|
|
file, even though it's not configured as a root server.
|
|
|
|
|
|
\question 09jul:linuxq ERROR:recvfrom: Connection refused
|
|
|
|
Date: Wed Jul 9 21:57:40 EDT 1997
|
|
|
|
DNS on my linux system is reporting the error
|
|
|
|
\verbatim
|
|
Mar 26 12:11:20 idg named[45]: recvfrom: Connection refused
|
|
|
|
When I start or restart the named program I get no errors. What could be
|
|
causing this ?
|
|
|
|
A: Are you running the BETA9 version of bind 4.9.3 ? It is a bug that
|
|
does no harm and the error reporting was corrected in later releases. You
|
|
should upgrade to a newer version of bind.
|
|
|
|
-----------------------------------------------------------------------------
|
|
|
|
Question 6.14. ERROR:zone has trailing dot
|
|
|
|
Date: Wed Jul 9 22:11:51 EDT 1997
|
|
|
|
If syslog reports "zone has trailing dot", the zone information contains a
|
|
trailing dot in the named.boot file where it does not belong.
|
|
|
|
|
|
example:
|
|
secondary domain.com. xxx.xxx.xxx.xxx S-domain.com
|
|
^
|
|
-----------------------------------------------------------------------------
|
|
|
|
Question 6.15. ERROR:Zone declared more then once
|
|
|
|
Date: Wed Jul 9 22:12:45 EDT 1997
|
|
|
|
If syslog reports "Zone declared more then once",
|
|
|
|
A zone is specified multiple times in the named.boot file
|
|
|
|
example:
|
|
secondary domain.com 198.247.225.251 S-domain.com
|
|
secondary zone.com 198.247.225.251 S-zone.com
|
|
primary domain.com P-domain.com
|
|
|
|
domain.com is declared twice, once as primary, and once as secondary
|
|
|
|
-----------------------------------------------------------------------------
|
|
|
|
Question 6.16. ERROR:response from unexpected source
|
|
|
|
Date: Wed Jul 9 22:12:45 EDT 1997
|
|
|
|
If syslog reports "response from unexpected source", BIND (pre 4.9.3) has
|
|
a bug if implimented on a multi homed server. This error indicates that
|
|
the response to a query came from an address other then the one sent to.
|
|
So, if ace gets a response from an unexpected source, ace will ignore the
|
|
response.
|
|
|
|
-----------------------------------------------------------------------------
|
|
|
|
Question 6.17. ERROR:record too short from [zone name]
|
|
|
|
Date: Mon Jun 15 21:34:49 EDT 1998
|
|
|
|
If syslog report "record too short from [zone name]", The secondary server
|
|
is trying to pull a zone from the primary server. For some reason, the
|
|
primary sent an incomplete zone. This usually is a problem at the primary
|
|
server.
|
|
|
|
To troubleshoot, try this:
|
|
|
|
dig [zonename] axfr @[primary IP address]
|
|
|
|
Often, this is caused by a line broken in the middle.
|
|
|
|
When the primary server's "named.boot" file contains "xfrnets" entries
|
|
for other servers and the secondary is not listed, this error can occur.
|
|
Creating an "xfrnets" entry for the secondary will solve the error.
|
|
|
|
-----------------------------------------------------------------------------
|
|
|
|
Question 6.18. ERROR:sysquery: findns error (3)
|
|
|
|
Date: Wed Jul 9 22:17:09 EDT 1997
|
|
|
|
If syslog reports "sysquery: findns error (3)" or
|
|
"qserial_query(zonename): sysquery FAILED", there is no ns record for the
|
|
zone. or the NS record is not defined correctly.
|
|
|
|
-----------------------------------------------------------------------------
|
|
|
|
Question 6.19. ERROR:Err/TO getting serial# for XXX
|
|
|
|
Date: Wed Jul 9 22:18:41 EDT 1997
|
|
|
|
If syslog reports "Err/TO getting serial# for XXX", there could be a
|
|
number of possible errors:
|
|
|
|
- An incorrect IP address in named.boot,
|
|
- A network reachibility problem,
|
|
- 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.
|
|
|
|
-----------------------------------------------------------------------------
|
|
|
|
Question 6.20. ERROR:zonename IN NS points to a CNAME
|
|
|
|
Date: Wed Jul 9 22:20:29 EDT 1997
|
|
|
|
If syslog reports "zonename IN NS points to a CNAME" or "zonename IN MX
|
|
points to a CNAME", named is 'reminding' you that due to various RFCs, an
|
|
NS or MX record cannot point to a CNAME.
|
|
|
|
EXAMPLE 1
|
|
---------
|
|
domain.com IN SOA (...stuff...)
|
|
IN NS ns.domain.com.
|
|
ns IN CNAME machine.domain.com.
|
|
machine IN A 1.2.3.4
|
|
|
|
The IN NS record points to ns, which is a CNAME for machine. This
|
|
is what results in the above error
|
|
|
|
EXAMPLE 2
|
|
---------
|
|
domain.com IN SOA (...stuff...)
|
|
IN MX mail.domain.com.
|
|
mail IN CNAME machine.domain.com.
|
|
machine IN A 1.2.3.4
|
|
|
|
This would cause the MX variety of the error.
|
|
|
|
The fix is point MX and NS records to a machine that is defined explicitly
|
|
by an IN A record.
|
|
|
|
-----------------------------------------------------------------------------
|
|
|
|
Question 6.21. ERROR:Masters for secondary zone [XX] unreachable
|
|
|
|
Date: Wed Jul 9 22:24:27 EDT 1997
|
|
|
|
If syslog reports "Masters for secondary zone [XX] unreachable", the
|
|
initial attempts to load a zone failed, and the name server is still
|
|
trying. If this occurs multiple times, a problem exists, likely on the
|
|
primary server. This is a fairly generic error, and could indicate a vast
|
|
number of problems. It might be that named is not running on the primary
|
|
server, or they do not have the correct zone file. If this keeps up long
|
|
enough a zone might expire.
|
|
|
|
-----------------------------------------------------------------------------
|
|
|
|
Question 6.22. ERROR:secondary zone [XX] expired
|
|
|
|
Date: Wed Jul 9 22:25:53 EDT 1997
|
|
|
|
If syslog reports "secondary zone [XX] expired", there has been a
|
|
expiration of a secondary zone on this server.
|
|
|
|
An expired zone is one in which a transfer hasn't successfully been
|
|
completed in the amount of time specified before a zone expires.
|
|
|
|
This problem could be anything which prevents a zone transfer: The primary
|
|
server is down, named isn't running on the primary, named.boot has the
|
|
wrong IP address, etc.
|
|
|
|
-----------------------------------------------------------------------------
|
|
|
|
Question 6.23. ERROR:bad response to SOA query from [address]
|
|
|
|
Date: Wed Jan 14 12:15:11 EST 1998
|
|
|
|
If syslog reports "bad response to SOA query from [address], zone [name]",
|
|
a syntax error may exist in the SOA record of the zone your server is
|
|
attempting to pull.
|
|
|
|
It may also indicate that the primary server is lame, possibly due to a
|
|
syntax error somewhere in the zone file.
|
|
|
|
-----------------------------------------------------------------------------
|
|
|
|
Question 6.24. ERROR:premature EOF, fetching [zone]
|
|
|
|
Date: Wed Jul 9 22:28:26 EDT 1997
|
|
|
|
If syslog reports "premature EOF, fetching [zone]", a syntax error exists
|
|
on the zone at the primary location, likely towards the End of File (EOF)
|
|
location.
|
|
|
|
-----------------------------------------------------------------------------
|
|
|
|
Question 6.25. ERROR:Zone [XX] SOA serial# rcvd from [Y] is < ours
|
|
|
|
Date: Wed Jul 9 22:30:03 EDT 1997
|
|
|
|
If syslog reports "Zone [name] SOA serial# rcvd from [address] is < ours",
|
|
the zone transfer failed because the primary machine has a lower serial
|
|
number in the SOA record than the one on file on this server.
|
|
|
|
-----------------------------------------------------------------------------
|
|
|
|
Question 6.26. ERROR:connect(IP/address) for zone [XX] failed
|
|
|
|
Date: Wed Jan 14 12:21:40 EST 1998
|
|
|
|
If syslog reports "connect(address) for zone [name] failed: No route to
|
|
host" or "connect(address) for zone [name] failed: Connection timed out",
|
|
it could be that there is no route to the specified host or a slow primary
|
|
system. Try a traceroute to the address specified to isolate the problem.
|
|
The problem may be a mistyped IP address in named.boot.
|
|
|
|
A very slow primary machine or a connection may have been initialized,
|
|
then connectivity lost for some reason, etc. Try networking
|
|
troubleshooting tools like ping and traceroute, then try connecting to
|
|
port 53 using nslookup or dig.
|
|
|
|
If syslog reports "connect(address) for zone [name] failed: Connection
|
|
refused", the destination address is not allowing the connection. Either
|
|
the destination is not running DNS (port 53), or possibly filtering the
|
|
connection from you. It is also possible that the named.boot is pointing
|
|
to the wrong address.
|
|
|
|
-----------------------------------------------------------------------------
|
|
|
|
Question 6.27. ERROR:sysquery: no addrs found for NS
|
|
|
|
Date: Wed Jul 9 22:37:01 EDT 1997
|
|
|
|
If syslog reports "sysquery: no addrs found for NS" , the IN NS record may
|
|
be pointing to a host with no IN A record.
|
|
|
|
-----------------------------------------------------------------------------
|
|
|
|
Question 6.28. ERROR:zone [name] rejected due to errors
|
|
|
|
Date: Wed Jul 9 22:37:51 EDT 1997
|
|
|
|
If syslog reports "primary zone [name] rejected due to errors", there will
|
|
likely be another more descriptive error along with this, like "zonefile:
|
|
line 17: database format error". That zone file should be investigated
|
|
for errors.
|
|
|
|
===============================================================================
|
|
|
|
Section 7. ACKNOWLEDGEMENTS
|
|
|
|
Q7.1 How is this FAQ generated ?
|
|
Q7.2 What formats are available ?
|
|
Q7.3 Contributors
|
|
|
|
-----------------------------------------------------------------------------
|
|
|
|
Question 7.1. How is this FAQ generated ?
|
|
|
|
Date: Mon Jun 15 21:45:53 EDT 1998
|
|
|
|
This FAQ is maintained in BFNN (Bizzarre Format with No Name). This
|
|
allows me to create ASCII, HTML, and GNU info (postscript coming soon)
|
|
from one source file.
|
|
|
|
The perl script "bfnnconv.pl" that is available with the linux FAQ is used
|
|
to generate the various output files from the BFNN source. This script is
|
|
available at
|
|
|
|
txs-11.mit.edu : /pub/linux/docs/linux-faq/linux-faq.source.tar.gz
|
|
|
|
-----------------------------------------------------------------------------
|
|
|
|
Question 7.2. What formats are available ?
|
|
|
|
Date: Fri Dec 6 16:51:31 EST 1996
|
|
|
|
You may obtain one of the following formats for this document:
|
|
|
|
* ASCII: http://www.intac.com/~cdp/cptd-faq/cptd-faq.ascii
|
|
* BFNN: http://www.intac.com/~cdp/cptd-faq/cptd-faq.bfnn
|
|
* GNU info: http://www.intac.com/~cdp/cptd-faq/cptd-faq.info
|
|
* HTML: http://www.intac.com/~cdp/cptd-faq/index.html
|
|
|
|
-----------------------------------------------------------------------------
|
|
|
|
Question 7.3. Contributors
|
|
|
|
Date: Thu Jul 16 10:45:57 EDT 1998
|
|
|
|
Many people have helped put this list together. Listed in e-mail address
|
|
alphabetical order, the following people have contributed to this FAQ:
|
|
|
|
* <BERI@etf.bg.ac.yu> (Berislav Todorovic)
|
|
* <Benoit.Grange@inria.fr> (Benoit.Grange)
|
|
* <D.T.Shield@csc.liv.ac.uk> (Dave Shield)
|
|
* <Karl.Auer@anu.edu.au> (Karl Auer)
|
|
* <Todd.Aven@BankersTrust.Com>
|
|
* <adam@comptech.demon.co.uk> (Adam Goodfellow)
|
|
* <andras@is.co.za> (Andras Salamon)
|
|
* <barmar@bbnplanet.com> (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])
|
|
* <dj@netscape.com> (David Jagoda)
|
|
* <djk@cyber.com.au> (David Keegel)
|
|
* <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)
|
|
* <jpass@telxon.com> (Jim Pass)
|
|
* <jhawk@panix.com> (John Hawkinson)
|
|
* <jmalcolm@uunet.uu.net> (Joseph Malcolm)
|
|
* <jprovo@augustus.ultra.net> (Joe Provo)
|
|
* <jrs@foliage.com> (J. Richard Sladkey)
|
|
* <jsd@gamespot.com> (Jon Drukman)
|
|
* <jwells@pacificcoast.net> (John Wells)
|
|
* <kop@meme.com> (Karl O. Pinc)
|
|
* <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)
|
|
* <mfuhr@dimensional.com> (Michael Fuhr)
|
|
* <mike@westie.gi.net> (Michael Hawk)
|
|
* <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)
|
|
* <raj@ceeri.ernet.in> (Raj Singh)
|
|
* <rocky@panix.com> (R. Bernstein)
|
|
* <rv@seins.Informatik.Uni-Dortmund.DE> (Ruediger Volk)
|
|
* <sedwards@sedwards.com> (Steve Edwards)
|
|
* <shields@tembel.org> (Michael Shields)
|
|
* <spsprunk@pop.srv.paranet.com> (Stephen Sprunk)
|
|
* <tanner@george.arc.nasa.gov> (Rob Tanner)
|
|
* <vixie@vix.com> (Paul A Vixie)
|
|
* <wag@swl.msd.ray.com> (William Gianopoulos)
|
|
* <whg@inel.gov> (Bill Gray)
|
|
* <wolf@pasteur.fr> (Christophe Wolfhugel)
|
|
|
|
Thank you !
|
|
|