Reverse DNS Dig returning PTR results only with trace option

Kevin Darcy 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
> monetreeysystems. 

Nope.

$ dig -x 63.254.134.228 soa @ns1.moneytreesystems.com

; <<>> DiG 9.3.5-P2 <<>> -x 63.254.134.228 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:
;228.134.254.63.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: 63.254.134.213#53(63.254.134.213)
;; 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 225.134.254.63.in-addr.arpa through 239.134.254.63.in-addr.arpa 
as separate /32 zones.

                                                                         
            - Kevin

> But haven't tried again each separate zone on
> moneytreesystems.
> 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
>>>> problem.
>>>> 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 192.42.93.32#53(y.arin.net) in 173 ms
>>>
>>> 228.134.254.63.in-addr.arpa. 7200 IN NS ns1.cyzap.net.
>>> 228.134.254.63.in-addr.arpa. 7200 IN NS ns2.cyzap.net.
>>> ;; Received 90 bytes from 209.253.113.19#53(NS3.MCLEODUSA.NET) in 159 ms
>>>
>>> 228.134.254.63.in-addr.arpa. 3600 IN NS ns2.moneytreesystems.com.
>>> 228.134.254.63.in-addr.arpa. 3600 IN NS ns1.moneytreesystems.com.
>>> ;; BAD (HORIZONTAL) REFERRAL
>>> ;; Received 160 bytes from 64.253.181.53#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
>>> 228.134.254.63.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).
>>>
>>> Regards,
>>>
>>> Chris
>>>
>>> _______________________________________________
>>> bind-users mailing list
>>> bind-users at lists.isc.org
>>> https://lists.isc.org/mailman/listinfo/bind-users
>>>
>>>
>>>       
>> _______________________________________________
>> bind-users mailing list
>> bind-users at lists.isc.org
>> https://lists.isc.org/mailman/listinfo/bind-users
>>     
>
>
>
>   




More information about the bind-users mailing list