[98902] in RedHat Linux List
Re: How do I take over reverse lookups?
daemon@ATHENA.MIT.EDU (jb)
Wed Nov 11 01:41:31 1998
Date: Wed, 11 Nov 1998 00:38:28 -0600
To: redhat-list@redhat.com
From: jb <jb@reachtheplanet.com>
In-Reply-To: <Pine.LNX.4.04.9811101657390.16743-100000@wally.kinze.com>
Resent-From: redhat-list@redhat.com
Reply-To: redhat-list@redhat.com
04:58 PM 11/10/98 -0600 [Bill Carlson]
<begin quote>
>On Tue, 10 Nov 1998, Matt Kaminer wrote:
>> so my question is how do you assume "authority" for reverse lookups? (I
>> am, btw, the authority for forward lookups..)
>Someone enlighten Matt and myself, from what I had read/heard, you
>delegate authority for reverse lookups of a subnet. Is this true?
>At the class C level, of course.
<end quote>
i'm just going to reiterate what's been said, add an example of a working
configuration and my two cents.
As forward DNS records are authoritative, so are reverse records.
Internic assigns who is authoritative for forward DNS based on IP
address(es) of nameserver machine(s).
ARIN (The American Registry for Internet Numbers) handles assigning IP
addresses and their authoritative sources.
most people use an ISP which are assigned and authoritative for blocks of
IP, generally class C. therefore, the ISP is authoritative for answering
questions about what hostnames go with which IP, or, reverse DNS.
therefore, there are 4 options, in order of preference, as follows:
1. have your isp forward requests for reverse (PTR) records for your
subnet to you so that you may be authoritative for them.
2. have your isp allow you access to change their reverse (PTR) records
for your subnet.
3. have your isp change your reverse records upon request.
4. do nothing and have your reverse not match your forward.
as said, most ISP will tell you that it "can't be done" or "we don't allow
that". that generally equates to a reality of, "uhh... what? i don't know
how." or, "we don't feel like it.".
my isp allows me access to change their reverse (PTR) records on their
machine(s). this is very unlikely to happen; i have access to and can
alter anyone else records. i only had a block of 32. authoritative blocks
are assigned in class-C and larger.
they trusted me and allowed it; it worked fine; i am trustworthy. i'm
surprised they allowed it; i wouldn't have.
for those with subnets of class-C blocks, the best solution is to have your
ISP forward requests for reverse (PTR) records to your name server(s).
that way, you are authoritative for both the forward and reverse (PTR)
records in your subnet.
fortunately, my ISP uses *nix with Bind. the following is an example of
how queries for reverse (PTR) records are forwarded to my nameservers:
1.1.168.192.in-addr.arpa 86400 IN NS
ns.mynameserver.com.
1.1.168.192.in-addr.arpa 86400 IN NS
ns2.mynameserver.com.
that means that any requests for the reverse records for IP 192.168.1.1
will use the nameserver ns.mynameserver.com. should that fail, it will try
ns2*.
note that i chose to continue having my ISP handle reverse DNS and altering
my reverse records there on the ISP machine(s). i have a relatively slow
link and don't need to have additional DNS traffic cluttering up my
networks bandwidth when my ISP and their large pipes can handle it fine.
so, the bottom line?
i think the best bet is to have your isp trust you and allow you access to
the configuration file which contains your subnet. it's not reality,
however... most will not. if they use NT or the likes, well.... <insert
something>.
second-best doable solution is to have your isp forward all reverse queries
to your nameserver.
lastly, if they are insistent on not helping you out and giving you what
you seemingly are paying for, insist that they change them on demand when
you require (within reason).
i hope this helps; feel free to ask questions and read Oreily & Associates,
"DNS and BIND".
Jeff Barrett
Jeff Barrett (jb) <jb@reachtheplanet.com>
irc: /nick jb (jb@jb.reachtheplanet.com)
undernet: #reachtheplanet
icq: 2187213
--
PLEASE read the Red Hat FAQ, Tips, Errata and the MAILING LIST ARCHIVES!
http://www.redhat.com http://archive.redhat.com
To unsubscribe: mail redhat-list-request@redhat.com with
"unsubscribe" as the Subject.
