[ale] more reverse DNS questions

Michael H. Warfield mhw at WittsEnd.com
Fri Jan 6 17:03:55 EST 2012


On Fri, 2012-01-06 at 15:00 -0600, John Heim wrote: 
> Last week I was asking about using godaddy for DNS. Well, I finally figured 
> out how to get godaddy to let us run our own DNS server. Toward the bottom 
> of the page for setting nameservers is a button called "Host summary". You 
> have to enter the names and IP addresses of your nameservers on that page 
> before you can enter them onto the list of nameservers for your domain. So I 
> did that and now we are up and running.

> Well, except for one thing. you can't do a reverse lookup on the IP address 
> of our virtual machine. There is nothing I can do about that, right?

Probably not.

> This is 
> a vm that is donated to us by a local web services company.

It's doubtful they even control their own reverse DNS.

> Its one thing 
> to tell the world that www.iavit.org goes to 66.170.20.226. That can't mess 
> anything up. But you can't have just anybody doing it the other way around. 
> If that was something anybody could do, the internet could be severaly 
> messed up.

No, that's not quite the situation.  In fact, the reverse DNS is MORE
often thoroughly messed it.  In general, it's a morass.  It's an
entirely separate hierarchy and structure under the .arpa. TLD
(in-addr.arpa. for IPv4 and ip6.arpa. for IPv6).

No, the problem is in its structure and how it's organized and
delegated.  I have a large enough block of addresses that I have my own
delegated nameservers for that namespace that are actually registered
with ARIN.

If you do a lookup on my web server you'll get this forward:

[mhw at canyon ~]$ host www.wittsend.com
www.wittsend.com has address 130.205.32.81

If you do the reverse, you get this:

[mhw at canyon ~]$ host 130.205.32.81
81.32.205.130.in-addr.arpa domain name pointer amethyst.wittsend.com.

(You'll notice they don't match - Amethyst is the canonical name of that
server - they don't have to match).

Now you see what was actually looked up was "81.32.205.130.in-addr.arpa"
looking for a pointer (PTR) record.  But that record has to exist as an
individual resource record in the "32.205.130.in-addr.arpa" zone (drop
the 81. on the left).  So I have a zone file for that entire block of
256 addresses.  Here are a few of the records from that file:

$ORIGIN 32.205.130.in-addr.arpa.
;

;
74              IN PTR slate.wittsend.com.
75              IN PTR ruby.wittsend.com.
76              IN PTR emerald.wittsend.com.
77              IN PTR perl.wittsend.com.
78              IN PTR basalt.wittsend.com.
79              IN PTR granite.wittsend.com.
80              IN PTR mercury.wittsend.com.
81              IN PTR amethyst.wittsend.com.
82              IN PTR mica.wittsend.com.
83              IN PTR dark-tower.wittsend.com.

So, you see, that's all being managed in one spot under one zone shared
for all those addresses.  That would normally be delegated from the zone
above it, 205.130.in-addr.arpa in this case, either by using NS
delegation records in the parent zone or having the parent do zone
transfers and be authoritative for the child, or reside on the same name
server and have the child essentially inherit the parent's delegation.
There are standards and ways of delegation out partial zones that don't
fall on an 8 bit boundary but not all ISPs and block owners support that
(I don't need to :-P).

If you had a cooperative ISP, they could either update the PTR record
for you (most common, if they are willing at all) OR change the PTR
record to one or more NS records pointing at your name server like this:

81 IN NS ns1.wittsend.com.
IN NS ns2.wittsend.com.

Then you would have a zone file containing just the 81 PTR record and
could update it to your hearts content.  BUT!  If you use that same name
server as your caching name server (poor but very common practice) it
won't know to refer the OTHER reverse records back to the parent and you
could create a mess for yourself.  Not a good idea and you probably
couldn't get the ISP to agree to it without a very good reason and proof
you had a good grasp on DNS configurations and gotchas.

> So if I understand the way the internet works, I'm going to have to go to 
> the company that donated the virtual machine and get them to contact their 
> ISP on our behalf. Is that correct?

More or less, correct.  You have to go to the owner of that netblock,
most likely the ISP, and possibly have to chase down who is responsible
for the nameserver that is authoritative for the /24 containing your
address.  Most people will just shrug and go "why bother".

Based on the address you listed in your A records below, I did a quick
check on the SOA for the parent zone like this:

[mhw at canyon ~]$ dig -t SOA 20.170.66.in-addr.arpa

; <<>> DiG 9.7.4-P1-RedHat-9.7.4-2.P1.fc14 <<>> -t SOA 20.170.66.in-addr.arpa
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 37261
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 0

;; QUESTION SECTION:
;20.170.66.in-addr.arpa.		IN	SOA

;; ANSWER SECTION:
20.170.66.in-addr.arpa.	3600	IN	SOA	dns1.supranet.net. hostmaster.supranet.net. 2012010300 1800 900 604800 300

;; AUTHORITY SECTION:
20.170.66.in-addr.arpa.	86380	IN	NS	dns2.supranet.net.
20.170.66.in-addr.arpa.	86380	IN	NS	dns1.supranet.net.

;; Query time: 85 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Fri Jan  6 16:45:03 2012
;; MSG SIZE  rcvd: 137

Now...  What you are REALLY interested in is in the "AUTHORITY SECTION"
where you see two NS records.  Those are the nameservers that have to be
updated for the reverse DNS to be changed.  You would have to contact
Supranet.net.  In the "ANSWER SECTION" also shows dns1.supranet.net. as
the "primary" authoritative name server (but it can also be some slave
off of a hidden master).  You need to get to someone who can update the
master authoritative nameserver for that zone.

Doing a "whois 66.170.20.226" confirms Supranet as controlling that
block and returns some contact information like this E-Mail address:

hostmaster at supranet.net

Which agrees with the pseudo E-Mail address in the SOA (the '@' is
replaced by a '.' in the SOA).

Honestly...  Good luck with that.  That block is a delegated /19.  So,
basically 32 of the /24 zone blocks like I was describing.  Some ISPs
will do it and some of the just couldn't be bothered, especially if it's
an automatically generated zone and this would require manual
intervention (not saying it is, not saying it's not).

In you're particular case, they don't even have a PTR record in place
for you:

[mhw at canyon ~]$ host 66.170.20.226
Host 226.20.170.66.in-addr.arpa. not found: 3(NXDOMAIN)

So they would have to add a record and they may not even have a zone
file for that /24 block to begin with.

> PS: Here is my forward lookup zone file. Can anybody tell me if I've done 
> anything wrong?
> 
> $TTL 86400 ; 24 hours could have been written as 24h or 1d
> $ORIGIN iavit.org.
> @ IN SOA iavit.iavit.org. hostmaster at iavit.org. (
>          2011062601 ; serial
>          3H ; refresh
>          15 ; retry
>          1w ; expire
>          3h ; minimum
>         )
> ;define name servers on domain
>     IN NS ns1
> iavit.org.     IN TXT "v=spf1 mx ~all"
>     IN  MX 10  mailhost
>     IN  A      66.170.20.226
> iavit IN A 66.170.20.226
> lists IN A 66.170.20.226
> ns1 IN A 66.170.20.226
> ns2 IN A 66.170.20.226
> mailhost IN CNAME iavit
> wiki           IN CNAME iavit
> www            IN CNAME iavit
> 

That "minimum" parameter really serves a different purpose than what it
was originally defined for.  In the distant past it was the default or
minimum TTL applied to resource records (RR) but that is now handled by
the $TTL directive, which you have there set to 1 day.  Since every RR
that is contained in a reply has a TTL specified, it wasn't necessary to
also have a minimum TTL in the SOA.  That was redefined years ago to be
the negative TTL.  That comes into play if someone requests a
non-existent record and get an NXDOMAIN (no such domain or FQDN) error
and basically returns no resource records for the query.  The negative
TTL in the SOA tells the cachers how long to remember that there was no
records returned in the response.  3 hours is a rather low value for
that unless you're planning on adding a lot of records as time goes on
which may get queried and NX cached before you have them ready.  I would
set that to a day as well.

Regards,
Mike
-- 
Michael H. Warfield (AI4NB) | (770) 985-6132 |  mhw at WittsEnd.com
   /\/\|=mhw=|\/\/          | (678) 463-0932 |  http://www.wittsend.com/mhw/
   NIC whois: MHW9          | An optimist believes we live in the best of all
 PGP Key: 0x674627FF        | possible worlds.  A pessimist is sure of it!
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 482 bytes
Desc: This is a digitally signed message part
Url : http://mail.ale.org/pipermail/ale/attachments/20120106/11331ce8/attachment.bin 


More information about the Ale mailing list