[lug] DNS Reverse Lookups
Nate Duehr
nate at natetech.com
Wed Feb 7 03:22:24 MST 2001
On Tue, Feb 06, 2001 at 10:42:55PM -0700, Timothy C. Klein wrote:
> Hello,
>
> Well, I read up a bit on DNS today. Got DNS working on my machines as I
> want, with the exception of reverse lookups. I have 2 ips,
> 208.203.138.147 208.203.138.148 with a netmask of 255.255.255.192
> which gives a network address of 208.203.138.128 and bcast of
> 208.203.138.192. I think I am being bitten by the fact that I don't have
> a whole class 'C' network. I started to read the rfc2317
> ftp://ftp.isi.edu/in-notes/rfc2317.txt to find a work around, but it is
> a bit hard to get a hold of.
>
> Anyone else have a named config that deals with this issue? Mind sharing.
> Can't quite figure the black magic out
Do this at the ISP level for a living, so here's the scoop...
First off, your ISP will HAVE to delegate anything smaller than the old
Class-C block down to you. This is because reverse lookups look like this...
Say my IP is 216.233.182.158... the name of this machine is
"wireless.natetech.com".
(By the way, I found it easier to have my DSL provider/ISP do the
reverses in their servers than to delegate such a small network... that
might be easier... just e-mail them the right stuff and most DNS admins
will gladly add a few records rather than do a delegation. GRIN)
There's a zone file on some upstream provider's DNS server for the
in-addr.arpa zone with your dotted-quad IP address backwards. (It reads
from right -- most generic -- to left -- most specific.)
So my full reverse DNS entry for that IP looks like this in the zone
file for the 182.233.216.in-addr.arpa zone:
158.182.233.216.in-addr.arpa. IN PTR wireless.natetech.com.
The problem with smaller than Class-C delegations becomes when I want
to delegate just that record to your nameserver. If I add an NS for that
record like this (common DNS mistake and a bad one...):
158.182.233.216.in-addr.arpa. IN NS nameserver.natetech.com
Now the next DNS server to come along asking me for your record is going
to cache the SOA record from YOUR server as authoritative for the ENTIRE
182.233.216.in-addr.arpa. zone! Oops. Now everyone using that server
tries to ask YOUR nameserver for other records in that Class-C worth of
IP addresses and gets a NEGATIVE response from your nameserver. ("I
don't know anything about that IP!")
And since NEGATIVE records also get cached, now it'll take a while for
us to clean it all up.
So what I really have to do to delegate it to you (I'll use non-standard
zone names that don't quite match the RFC to try to make it clearer):
(Also, let's say you have IP's 158, 159, and 160 just for this
example... yes I know that's not possible...)
In the ISP's zone file for the 182.233.216.in-addr.arpa zone:
158.182.233.216.in-addr.arpa. IN CNAME 158.delegated.182.233.in-addr.arpa.
159.182.233.216.in-addr.arpa. IN CNAME 159.delegated.182.233.in-addr.arpa.
160.182.233.216.in-addr.arpa. IN CNAME 160.delegated.182.233.in-addr.arpa.
CNAME's are ALIASES to another name... now I have to create a zone
called "delegated.182.233.in-addr.arpa" on my nameserver with the
following records:
delegated.182.233.in-addr.arpa. NS yournameserver.company.com.
158.delegated.182.233.in-addr.arpa. IN NS yournameserver.company.com.
159.delegated.182.233.in-addr.arpa. IN NS yournameserver.company.com.
160.delegated.182.233,in-addr.arpa. IN NS yournameserver.company.com.
That keeps it all working properly. It's pretty kludgy, but works.
However many resolvers cannot handle more than one level of CNAME
delegation, so once it's delegated to you from whomever delegated it
from the Class-C block, you may have problems continuing that delegation
on down to say another nameserver.
Also, for the two minute tutorial on checking all this stuff... start at
the root servers... (and use dig -- nslookup drives me batty.)
(The -x option does the reversing and the .in-addr.arpa junk for you!
Nice!)
dig @a.root-servers.net -x 216.233.182.158
; <<>> DiG 8.3 <<>> @a.root-servers.net -x
; (1 server found)
;; res options: init recurs defnam dnsrch
;; got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 6
;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 2, ADDITIONAL: 2
;; QUERY SECTION:
;; 159.182.233.216.in-addr.arpa, type = ANY, class = IN
;; AUTHORITY SECTION:
233.216.IN-ADDR.ARPA. 6D IN NS BOHDRAN.RHYTHMS.NET.
233.216.IN-ADDR.ARPA. 6D IN NS BONGO.RHYTHMS.NET.
;; ADDITIONAL SECTION:
BOHDRAN.RHYTHMS.NET. 2D IN A 207.251.144.1
BONGO.RHYTHMS.NET. 2D IN A 207.251.144.2
;; Total query time: 66 msec
;; FROM: dns-master.inflow.net to SERVER: a.root-servers.net 198.41.0.4
;; WHEN: Wed Feb 7 02:41:44 2001
;; MSG SIZE sent: 46 rcvd: 151
Ok, so we see the 182.233.216.in-addr.arpa. zone is delegated to
bohdran.rhythms.net and bongo.rhythms.net. (We also see that they're
stupid and have both nameservers on the same physical network, but let's
not talk about their recent seven day nameserver outage!)
dig @bohdran.rhythms.net -x 216.233.182.158
; <<>> DIG 8.3 <<>> @bohdran.rhythms.net -x
; (1 server found)
;; res options: init recurs defnam dnsrch
;; got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 6
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 2
;; QUERY SECTION:
;; 158.182.233.216.in-addr.arpa, type = ANY, class = IN
;; ANSWER SECTION:
158.182.233.216.in-addr.arpa. 1D IN PTR wireless.natetech.com.
;; AUTHORITY SECTION:
182.233.216.IN-ADDR.ARPA. 1D IN NS bohdran.rhythms.net.
182.233.216.IN-ADDR.ARPA. 1D IN NS bongo.rhythms.net.
;; ADDITIONAL SECTION:
bohdran.rhythms.net. 2H IN A 207.251.144.1
bongo.rhythms.net. 2H IN A 207.251.144.2
;; Total query time: 23 msec
;; FROM: dns-master.inflow.net to SERVER: bohdran.rhythms.net
207.251.144.1
;; WHEN: Wed Feb 7 03:00:41 2001
;; MSG SIZE sent: 46 rcvd: 190
And there's the answer in the intuitively titled "Answer Section". :)
That's the quickie tutorial on reverse lookups and reverse DNS
delegation, there's more, but that's all I should put in this e-mail
or the rest of the BLUG'ers are going to beat me with a cluestick.
The RFC recommends using "/" characters in the delegated reverse zone
names (but does have a note at the bottom about maybe using "-"
instead), and as you can guess, "/" plays havoc with shell scripts
trying to automate any of this. (Or quickly written "shellPerl" as I
like to call it that doesn't use proper checking of the filename...)
I don't do that. I hate it. I use "-" in mine, and our scripts are a
lot happier that manage installing and adding zone files, etc.
If you need any other help, e-mail me off the list.
Here's what I did with my IP's I wanted reverse DNS for... I e-mailed
the DNS admins at my provider with pre-made PTR records so all they had
to do was open the zone file in vi and cut n' paste from the e-mail
message...
158.182.233.216.in-addr.arpa. IN PTR wireless.natetech.com.
Remember to use the trailing dot on the records...
--
Nate Duehr <nate at natetech.com>
GPG Key fingerprint = DCAF 2B9D CC9B 96FA 7A6D AAF4 2D61 77C5 7ECE C1D2
Public Key available upon request, or at wwwkeys.pgp.net and others.
More information about the LUG
mailing list