[ale] OT: DNS Reverse still driving me nuts.

[Joe Steele]

If you were to type the following command:

     nslookup -type=ptr 233.192/233.181.81.63.in-addr.arpa

The result from your setup would be:

     233.192/233.181.81.63.in-addr.arpa     name = rdlg.net

Although this might not be the result you are looking for, it could be the 
correct behavior as long as your ISP sets things up properly.

If all you wanted was for this to work properly on your local nameserver, 
you would change the zone name from:

     "192/233.181.81.63.in-addr.arpa" 
to:
     "181.81.63.in-addr.arpa"

However, since it seems that you are wanting this to work properly over 
the entire internet, there's a couple things that need to be done:

First, your ISP (mountainmax.net) is allocated the IP range 63.81.180.0 - 
63.81.183.255 from UUNET, and UUNET maintains authority over the 
81.63.IN-ADDR.ARPA domain.  Your ISP needs to have UUNET delegate 
authority to them for the zones 180.81.63.IN-ADDR.ARPA, 
181.81.63.IN-ADDR.ARPA, 182.81.63.IN-ADDR.ARPA, and 
183.81.63.IN-ADDR.ARPA.  You can see that this is not happening by looking 
at the entire zone file for 81.63.in-addr.arpa:

     dig @AUTH00.NS.UU.NET 81.63.in-addr.arpa axfr

Second, you and your ISP need to decide how best to implement the PTR 
lookup.  You have a few options, a couple of which are:

1)  If it's just one PTR record, then the simplest thing is to have your 
ISP add the PTR record for you in their zone file;  or

2)  If your ISP is willing to delegate authority to you, then you and they 
could follow the procedures outlined in RFC 2317,  "Classless IN-ADDR.ARPA 
delegation" (http://www.rfc-editor.org/rfc/rfc2317.txt).  This method is 
more complicated and would be more appropriate when you have a subnet of 
IP addresses and you want to have direct control of the in-addr.arpa 
look-ups for the subnet, but it can work for single addresses as well.

I am assuming, based on your setup, that you and your ISP are attempting 
to implement option 2, and that there is only one IP address involved.  
Once UUNET has delegated authority to them for 181.81.63.in-addr.arpa, you 
should attempt to query your ISP's authoritative server for the zone.  
This will confirm for you how they have set things up.  

I was able to query your ISP directly for the "180" zone ("dig 
@NS1.EWTECHNOLOGY.COM 180.81.63.in-addr.arpa axfr"), but either they 
presently don't have the "181" zone set up, or else it is on a different 
server.

If your ISP is trying to follow the RFC, then for a single address they 
would have something like this in their 181.81.63.in-addr.arpa zone file:

     233/32    NS     ns1.rdlg.net.
     233       CNAME  233.233/32.181.81.63.in-addr.arpa.

The RFC also recommends that your ISP act as a secondary domain server for 
the 233/32.181.81.63.in-addr.arpa zone for which ns1.rdlg.net is primary, 
otherwise some resolvers could get confused by having to look up a CNAME 
on a different server.

In turn, you would create the zone 233/32.181.81.63.in-addr.arpa, and in 
it you would have the pointer:

     233       PTR    rdlg.net.

If you compare all this with the setup you've been working with, you see 
that the only difference is that you were using "192/233" where I have 
used "233/32".  This is immaterial as it is just text and could be 
anything such as "foobar", as long as you and the ISP are doing the same 
thing.  (The notation I used follows the RFC.)

The RFC doesn't specifically address the delegation of a single address, 
but it seems to me that the procedure above could be greatly simplified in 
such cases.  Your ISP's zone file would contain:

     233       NS     ns1.rdlg.net.

and you would create the zone 233.181.81.63.in-addr.arpa containing:

     @         PTR    rdlg.net.

In this case there is no special need for the ISP to act as a 
secondary server for your zone because the complicated use
of CNAMES (confusing to some resolvers) is absent.

--Joe

--
To unsubscribe: mail majordomo at ale.org with "unsubscribe ale" in message body.