help with Reverse Lookup and PTR's
mathias at koerber.org
Sun Oct 28 06:33:23 UTC 2001
| my head is spinning on all this DNS stuff :)
| As I see it...
| This reverse DNS lookup is a parallel concept
| to the normal DNS system -
yes, it is a special hierarchy parallel to the 'normal' forward
hierarchy. It is part of the DNS system and not parallel to it though.
| The DNS "A" record defines - xxx.xyz.com ---> 192.168.1.1
| and they are stored with the nameserver for the "domain"
| and the nameserver is obtained via lookup for the "domain".
| however -
| for a reverse IP lookup - 18.104.22.168 - (our mail server)
| all you have is an IP address to initially work with -
| It seems like ARPA has a special "domain"
| such as "in-addr.arpa" that is the real placeholder,
| and then the IP address (reversed) is prefixed.
| The records in the local DNS server
| define the "PTR" records - or pointer records.
No, this is not tied to the local DNS server. The records in
the appropriate reverse zone define are PTR records providing
IP to hostname resolution. Which nameservers hold these records
depends on the delegations in the reverse (.in-addr.arpa) tree
as do those for forward zones in the 'normal' tree.
In other words, a reverse domain can be served by nameservers that
are not directly related to the IP addresses of that zone. In fact,
this is often the case, when (see RFC 2182 Section 3.1) the secondary/slave
servers for those reverse zones are also properly distributed.
| However, I'm not sure how they propagate back
| to the ARPA domain ???????
They don't. You have to arrange for the appropriate reverse zone
to be delegated to your servers. The organization providing you with
your IP address block(s) (eg an RIR like ARIN, RIPE or APNIC or your
ISP or potentially your organization's main MIS department or somesuch)
will usually also delegate the reverse zone(s) associated with the IP
address block(s) you got to whatever nameservers you nominate for that
purpose. (Obviously there are policies involved, and these may vary
especially if you are dealing with a parent in an enterprise or an ISP).
This may involve CIDR-delegations (see RFC 2317).
| And what happens with address conflicts,
| or stealing of addresses ?????????
As each IP address has defines has a defined point in the reverse
(in-addr.arpa) tree for its PTR record (modulo some 'tricks' like
those used in RFC2317), all that is required really is that the
proper reverse zone(s) are delegated to those organizations that
hold the respective IP address blocks.
| So - as with Register.com and other "registering" providers,
| You may get "A" records to ref your servers,
| but I don't think there are any corresponding PTR records,
| hence no Reverse Lookup is possible....
No, you will have to get the reverse zone delegated to your servers
from the same place you got your IP addresses from. If you have only one
or two IP addresses (in some cases even if you have more), your ISP may
or may not do that. If they don't provide reverse delegation, you may have
to ask them to publish the proper PTR records in their reverse zone.
| For us - with our 22.214.171.124 - mail server name -
| the nameserver at "itsi2.your-net.com" has the various "A" records,
| but doesn't seem to have any PTR records.
| And our 126.96.36.199 backup nameserver
| has the "A" records, and a handful of PTR records...
| but the "itsi2" nameserver may be interrogated 1st by the net,
| so the Reverse Lookup will again fail -
The IP address block 208.16.x.x seems to belong to Sprint. Sprint does seem
to have delegated 174.16.208.in-addr.arpa to only one of your nameservers:
;; ANSWER SECTION:
174.16.208.in-addr.arpa. 1D IN NS itsi2.your-net.com.
;; ADDITIONAL SECTION:
itsi2.your-net.com. 4H IN A 188.8.131.52
There are a few problems with this delegation:
a) itsi2.your-net.com is not set up as authoritative nameserver
for the reverse zone '174.16.208.in-addr.arpa.' it has been
delegated. (querying it for the zone results in a non-authoritative
reply from its cache. It should be replying authoritatively with
a good copy of the zone)
This needs to be corrected (ie make that nameserver
authoritative for that zone, then put the necessary PTR records into
b) Your 'backup' nameserver 184.108.40.206 *is* properly authoritative for
that zone. In fact, it does not seem to be the 'backup but the primary
(looking at the SOA record). The problem is that it does not appear in
the delegation (see point a), so it will never be queried for the zone
from any outside nameserver (as the delegated nameserver also does not
know about it).
c) The zone is only delegated to a single nameserver. You will always
need two authoritative nameservers for each zone, to provide for
redundancy. And those two nameservers should not share a common
point of failure such as the same LAN, network, location etc. See
RFC 2182 Section 3.1. As your two nameserver seem to be located
on different networks (at least their IP addresses are radically different),
it should be sufficient to properly add ns1.daysup.com to the delegation
and make sure isti2.your-net.com is properly configured as a secondary/slave
nameserver for that zone.
More information about the bind-users