RFC2317-style delegation, nothing beyond CNAME

[Mark Andrews]

> Hey all,
> 
> I'm trying to figure out what has recently gone wrong with my reverse
> DNS. I've been at the receiving end of RFC2317-style delegation for a
> number of years now, and up until recently everything has worked
> flawlessly.
> 
> The problem seems to be in that the majority of the time, I'm only
> getting the CNAME response, and that's it. Other times I get a "has no
> PTR record" response. These results seem to be consistent from around
> the globe.
> 
> Example:
> 
> $ host 66.11.175.130
> 130.175.11.66.in-addr.arpa is an alias for 130.128/30.175.11.66.in-
> addr.arpa.
> 
> (and it stops there)
> 
> Note that it does seem to work eventually and sporadically, and this
> is what I expect:
> 
> $ host 66.11.175.130
> 130.175.11.66.in-addr.arpa is an alias for 130.128/30.175.11.66.in-
> addr.arpa.
> 130.128/30.175.11.66.in-addr.arpa domain name pointer
> paradise.ecks.ca.
> 
> Here's what dig says (with some parts omitted for brevity):
> 
> $ dig -x 66.11.175.130 @ns1.igs.net +trace
> (skipped.. usual header, root servers, arin, etc)
> 
> 175.11.66.in-addr.arpa. 86400   IN      NS      dci.doncaster.on.ca.
> 175.11.66.in-addr.arpa. 86400   IN      NS      ns.istop.com.
> ;; Received 103 bytes from 192.26.92.32#53(henna.ARIN.NET) in 62 ms
> 
> 130.175.11.66.in-addr.arpa. 86400 IN    CNAME
> 130.128/30.175.11.66.in-addr.arpa.
> ;; Received 91 bytes from 209.195.118.109#53(ns.istop.com) in 50 ms
> 
> .. and stops there. I don't even see queries against my DNS server
> (based on its logs).

	You won't. "dig +trace" does not follow CNAMES.

	You need to make a "dig +trace 130.128/30.175.11.66.in-addr.arpa ptr"
	query.
 
	Note one of your parent servers is not returning a referral to you
	and is instead saying that there is not PTR record, the other is not
	responding.

	You need to complain to your ISP and ask why there is no referral
	being returned.

	Mark

% dig 130.128/30.175.11.66.in-addr.arpa ptr @209.195.118.109 +norec

; <<>> DiG 9.3.4-P1 <<>> 130.128/30.175.11.66.in-addr.arpa ptr @209.195.118.109 +norec
; (1 server found)
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 18361
;; flags: qr; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;130.128/30.175.11.66.in-addr.arpa. IN  PTR

;; Query time: 242 msec
;; SERVER: 209.195.118.109#53(209.195.118.109)
;; WHEN: Mon Jun 16 11:26:10 2008
;; MSG SIZE  rcvd: 51

% 

> I can proceed manually, though:
> 
> $ host -t NS 128/30.175.11.66.in-addr.arpa.
> 128/30.175.11.66.in-addr.arpa name server ns.oddity.ca.
> 
> $ host -t PTR 130.128/30.175.11.66.in-addr.arpa ns.oddity.ca
> (skip)
> 130.128/30.175.11.66.in-addr.arpa domain name pointer
> paradise.ecks.ca.
> 
> The relevant part of named.conf is pretty basic:
> 
> zone "128/30.175.11.66.in-addr.arpa" {
>         type master;
>         file "/etc/namedb/db.66.11.175.128-30";
> }
> 
> and the zone itself:
> 
> $TTL 2h
> @       IN      SOA     ns.oddity.ca. dnsadm.oddity.ca. (
>                         2008061502 2h 1h 2w 1h
> )
>         IN      NS      ns.oddity.ca.
> 
> 128     IN      PTR     quandary.oddity.ca.
> 129     IN      PTR     grumpy.nanuq.ca.
> 130     IN      PTR     paradise.ecks.ca.
> 131     IN      PTR     paradise.ecks.ca.
> 
> Any ideas why it seems to fail where it does? At first I suspected it
> was in part due to the update to BIND 9.3.5 (from 9.3.4-P1) as part of
> FreeBSD 6.3-STABLE, but the last time reverse seemed to have worked
> was just prior to that update. A temporary downgrade didn't seem to
> provide any relief.
> 
> BTW, if anyone familiar with this (former) ISP is suggesting I switch
> as of yesterday, I'm certainly considering it now.
> 
> Thanks
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: Mark_Andrews at isc.org