How to configure bind with less than a block of ip's?
Bob Vance
bobvance at alumni.caltech.edu
Sat Jan 20 17:53:08 UTC 2001
It's helpful to realize that there's really nothing different between a
"forward" zone and a "reverse" zone.
The former *generally* contains A (address records) and latter
*generally* contains PTR records, but, both zones can and do carry other
record types (SOA and NS, obviously, but CNAMEs, etc., also) -- it's
all just DNS data.
The magic is in what the DNS clients do when they request a lookup.
Viz.:
To get an IP address, when presented with a "name", a DNS client does an
"A"-record lookup on the name given, and this causes the nameserver to
look in what we call the "forward zone" for an "A" record, but it's only
because that's what the client asked for. E.g., when a client asks for
"a.b.c.com", the server ultimately looks in his "b.c.com" zone data and
we happen to call this the "forward zone".
But, when trying to look up a *name*, when presented with an IP address,
say "a.b.c.d", (which we call "reverse" lookup)
(e.g., an 'rlogin' server trying to find out the name of the
client machine from which the login is occurring so that he,
the 'rlogin' server, can check that name in the ".rhosts" file
),
the DNS client (which is the 'rlogin' server code in this example :)
requests a lookup for a "PTR" record, "d.c.b.a.in-addr.arpa." .
(Note that the above is generally hidden in library calls, e.g.,
gethostbyname and gethostbyaddr on Unix.
)
All of that should pretty well be known, even by a newbie.
But, two major, non-obvious-to-the-newbie things, I think, that help
clear up the non-octet-reverse delegation are:
1. valid CNAMEs can point to records *outside* the current zone
foo.bar.com. IN A 1.2.3.4
fubar.bar.com. CNAME yyy.yahoo.com.
2. PTRs can have CNAMEs as well !
4.3.2.1.in-addr.arpa. IN PTR foo.bar.com.
5.3.2.1.in-addr.arpa. CNAME fandoo.bar.com.
6.3.2.1.in-addr.arpa. CNAME 6.subxx.3.2.1.in-addr.arpa.
(where fandoo.bar.com. and 6.subxx.3.2.1.in-addr.arpa.
would be PTR records in the bar.com and
subxx.3.2.1.in-addr.arpa zones, respectively.
)
Your ISP is generally authoritative for the class C from which he has
parsimoniously given you a few addresses.
So he can handle the reverse PTRs for you -- if he wants to!!
If you are hosting your DNS, even though your ISP's kindly agreed to be
a secondary for your "forward" domain, he's not gonna want to be
bothered changing or adding PTR records while you can't decide on a good
name for one of your boxes. So you really want to handle the reverse
yourself. However, the ISP doesn't want to delegate to you the *whole*
class C in-addr.arpa domain (since there are other clients therein :).
However, he *can* delegate a *sub-domain* of the class C
in-addr.arpa to you, (since he's authoritative for the parent).
Then he can put CNAMEs in his parent pointing to the PTRs in
the sub-domain he delegated to you!
So, he is still authoritative for 3.2.1.in-addr.arpa, but has delegated
to you, say "hoohah.3.2.1.in-addr.arpa", which is a valid sub-domain of
"3.2.1.in-addr.arpa" .
Then he has
1.3.2.1.in-addr.arpa. CNAME 1.hoohah.3.2.1.in-addr.arpa.
...
6.3.2.1.in-addr.arpa. CNAME 6.hoohah.3.2.1.in-addr.arpa.
(or
1 CNAME 1.hoohah.3.2.1.in-addr.arpa.
...
6 CNAME 6.hoohah.3.2.1.in-addr.arpa.
since the ORIGIN, ".hoohah.3.2.1.in-addr.arpa. " will be appended to
those non-dot-terminated names.
And, probably done with a
$GENERATE 1-6 $ CNAME $.hoohah.3.2.1.in-addr.arpa.
)
You are authoritative for "hoohah.3.2.1.in-addr.arpa" (since the ISP
delegated it to you) and in the zone master file for that domain, you
have:
1.hoohah.3.2.1.in-addr.arpa. IN PTR www.bar.com.
4.hoohah.3.2.1.in-addr.arpa. IN PTR foo.bar.com.
(or
1 IN PTR www.bar.com.
4 IN PTR foo.bar.com.
)
or whatever.
It doesn't really matter that you don't have the other records.
When a DNS client wants to do a reverse lookup on 1.2.3.4, he will
do a PTR request for 4.3.2.1.in-addr.arpa.
It will be found that the ISP is authoritative for 3.2.1.in-addr.arpa
and he will be queried for 4.3.2.1.in-addr.arpa.
But the CNAME will point to 4.hoohah.3.2.1.in-addr.arpa for which
you are authoritative and you'll be queried for it and will return
"foo.bar.com".
Voila!
Of course, the ISP will probably not call the sub-domain "hoohah", but
"0-7" or "sub-0-7" or "subnet-0" or "0/29" or something more meaningful.
I'm sure that the gurus will find and fill holes in the above, but
it should clarify things for you a bit.
-------------------------------------------------
Tks | <mailto:BVance at sbm.com>
BV | <mailto:BobVance at alumni.caltech.edu>
Sr. Technical Consultant, SBM, A Gates/Arrow Co.
Vox 770-623-3430 11455 Lakefield Dr.
Fax 770-623-3429 Duluth, GA 30097-1511
=================================================
-----Original Message-----
From: bind-users-bounce at isc.org [mailto:bind-users-bounce at isc.org]On
Behalf Of Alexandra
Sent: Friday, January 19, 2001 9:50 PM
To: comp-protocols-dns-bind at moderators.isc.org
Subject: How to configure bind with less than a block of ip's?
I'm trying to get a handle on DNS and Bind in order to run my own name
server.
After reading chapter 4 in the cricket book, various tutorials on the
internet, and the ask Mr. DNS forum my mind is somewhat less tortured.
My question concerns PTR records. The example in the DNS and Bind book
is fine and dandy if you happen to have at the very least a class C
network at your disposal.
Me, Joe Littlefish, on the other hand plan on only having a handful of
IP addresses
allocated to me by my yet to be decided upon ISP.
So if I have the IP addresses 192.249.249.17 through 192.249.249.28 I
can't very
well have one file that say's:
249.249.192.in-addr.arpa IN SOA bla bla bla
Do I need to set up one file for every ip number???
Also, how do most ISP's delagate just a portion of a block of ip's to me
since it's not an octet.
Trying to make sense out of RFC2317 I 'm guessing this is what the ISP
does:
the db record would have an A record and PTR record ie
littlefish.com. A 192.249.249.17
192.249.249.17.in-addr* PTR** littlefish.com
*why isn't it 192.249.249.17.in-addr.arpa.??**What's PTR? the same as IN
PTR?
The ISP's in-addr.arpa file would look like this:
249.249.192.in-addr.arpa IN SOA .......
17 CNAME
17.249.249.192.in-addr.A.domain*
I left this in it's original state from RFC 2317 I don't get what
should be appended in place of "A.domain" would it be
17.249.249.192.in-addr.littlefish.com????
It's a bit confusing. There's CNAMES in the rev file and PTR records in
the forward file.
Any help clarifying any of this would be appreciated. My main concern
though is
what I need to do. Is it as simple as me making a rev file for each of
my ip addresses? ie
249.249.192.17.in-addr.arpa through 249.249.192.28.in-addr.arpa . or is
it simpler only involving 1 rev file?
Thanks,
Scott
More information about the bind-users
mailing list