[lug] DNS Reverse Lookups
Nate Duehr
nate at natetech.com
Wed Feb 7 03:32:58 MST 2001
On Wed, Feb 07, 2001 at 03:22:24AM -0700, Nate Duehr wrote:
And of course I forgot the last step in the example... on your
nameserver you need a zone file called "delegated.182.233.in-addr.arpa."
with appropriate IN PTR records in it. Argh. Then when the NS records
in the fake zone send the queries on down to your server, you answer for
that "fake" zone, and not for the real 182.233.216.in-addr.arpa. zone.
I also typoed the example. Damn.
To make the "fake" zone look like what I was originally shooting for,
replace all delegated.182.233.in-addr.arpa.'s with
delegated.182.233.216.in-addr.arpa.
Grrr...
Mad at myself now. I may have made it more difficult by goofing the
example.
This is the hardest part of delegation, getting the two server admins to
agree on a naming standard that makes both happy for the "fake" zone.
Either example would have worked, the way I typed it just didn't make
sense though... sigh.
Must be time for sleep.
> 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.
> _______________________________________________
> Web Page: http://lug.boulder.co.us
> Mailing List: http://lists.lug.boulder.co.us/mailman/listinfo/lug
--
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