Reverse DNS Dig returning PTR results only with trace option
kcd at chrysler.com
Tue Nov 10 22:20:08 UTC 2009
Raj Adhikari wrote:
> Yes, they both are non-BIND servers, actually using Windows DNS servers.
> I have delegated *each*in-addr*arpa*name* from cyzap to
$ dig -x 220.127.116.11 soa @ns1.moneytreesystems.com
; <<>> DiG 9.3.5-P2 <<>> -x 18.104.22.168 soa @ns1.moneytreesystems.com.
;; global options: printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 910
;; flags: qr aa rd; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0
;; QUESTION SECTION:
;22.214.171.124.in-addr.arpa. IN SOA
;; AUTHORITY SECTION:
134.254.63.in-addr.arpa. 3600 IN SOA
ns1.moneytreesystems.com. hostmaster.moneytreesystems.com. 2009110820
900 600 86400 3600
;; Query time: 37 msec
;; SERVER: 126.96.36.199#53(188.8.131.52)
;; WHEN: Tue Nov 10 17:18:44 2009
;; MSG SIZE rcvd: 116
You've delegated -- or tried to "re-delegate" -- 134.254.63.in-addr.arpa
(the /24 zone) to the moneytreesystems.com nameservers.
To properly implement the approach you have chosen, you'd need to
delegate 184.108.40.206.in-addr.arpa through 220.127.116.11.in-addr.arpa
as separate /32 zones.
> But haven't tried again each separate zone on
> I tried RFC 2317 also. But again sometimes it just stuck at CNAME and
> sometimes no answer when queried for the PTR record. I read several
> problems with this approach.
> Kevin Darcy wrote:
>> It's worse than that. Sometimes RD doesn't even get copied into the
>> response header.
>> I suspect there's a load-balancer in front here, and at least one
>> "bad", non-BIND nameserver behind it, spewing out nasty stuff like
>> "horizontal" delegations...
>> Either that, or some middlebox is munging the queries/responses.
>> To clarify what needs to be done to fully implement this approach to
>> "classless delegation": *each*in-addr*arpa*name* needs to be delegated
>> separately, and *each*one* needs to be defined as a *separate* zone on
>> the moneytreesystems.com nameservers. Put each respective PTR record
>> at the apex of each of those zones.
>> That's a pain, isn't it? Maybe now you understand why most people uses
>> aliases a la RFC 2317. It's often the lesser of two evils.
>> - Kevin
>> Chris Hills wrote:
>>> On 10/11/09 18:25, Raj Adhikari wrote:
>>>> Now I can do a dig for an hour or so. But again I run into same
>>>> It wont return PTR record unless I explicitly do dig on ns1.cyzap.net.
>>>> Also, the last did showing ns1.cyzap.net as Authority NS for this IP.
>>>> But trace showing ns1.moneytreesystems.com as final sender.
>>>> Could someone shed a light on this?
>>> 254.63.in-addr.arpa. 86400 IN NS NS3.MCLEODUSA.NET.
>>> 254.63.in-addr.arpa. 86400 IN NS NS1.MCLEODUSA.NET.
>>> 254.63.in-addr.arpa. 86400 IN NS NS2.MCLEODUSA.NET.
>>> ;; Received 112 bytes from 18.104.22.168#53(y.arin.net) in 173 ms
>>> 22.214.171.124.in-addr.arpa. 7200 IN NS ns1.cyzap.net.
>>> 126.96.36.199.in-addr.arpa. 7200 IN NS ns2.cyzap.net.
>>> ;; Received 90 bytes from 188.8.131.52#53(NS3.MCLEODUSA.NET) in 159 ms
>>> 184.108.40.206.in-addr.arpa. 3600 IN NS ns2.moneytreesystems.com.
>>> 220.127.116.11.in-addr.arpa. 3600 IN NS ns1.moneytreesystems.com.
>>> ;; BAD (HORIZONTAL) REFERRAL
>>> ;; Received 160 bytes from 18.104.22.168#53(ns2.cyzap.net) in 167 ms
>>> You should not chain a delegation in this manner. Either make the
>>> servers ns1.cyzap.net. and ns2.cyzap.net. authoritative for
>>> 22.214.171.124.in-addr.arpa. or have your ISP change the NS records
>>> to point directly to ns1.moneytreesystems.com. and
>>> ns2.moneytreesystems.com. The cyzap servers do not respond with the
>>> authority bit set ("aa" in dig).
>>> bind-users mailing list
>>> bind-users at lists.isc.org
>> bind-users mailing list
>> bind-users at lists.isc.org
More information about the bind-users