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@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
_______________________________________________
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
_______________________________________________
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
