Re: Reverse DNS Dig returning PTR results only with trace option
Raj Adhikari wrote: Thanks Chris for the reply. Actually, let me put my question the other way. How can one delegate the classless subnet to other DNS? Actually, one of our ISP could not delegate classless subnet to our server ns1.cyzap.net. I am trying to help them in delegating the classless subnet to us. So this scenario is simulating our ISP and us. I was just testing with one of our other subnets checking if delegation will work. Unfortunately, we both are using windows DNS. Windows just have RFC 2317 way on configuring the delegation on it KB article using CNAME, which I think has lots of problems. But I am following this BIND way for delegation. I think, in windows the DNS configuration is more or less similar to BIND. On 10.11.09 17:23, Kevin Darcy wrote: There is no BIND way versus Windows way. For a range smaller than /24 you either need to host all the records in the /24 zone, delegate each entry individually (as /32 zones), or use CNAMEs. This is determined by the protocol, regardless of whether you're using Microsoft DNS, BIND or any other implementation. Note that each domain that is delegated SHOULD have proper SOA and NS records, otherwise strange things (like the one you have envcountered) may happen. If you delegate by adding NS records for each PTR, you create different domains for them. The same applies to forward domains (I've seen examples of single record delegations and related problems) It's much easier and safer to do CNAME delegations. -- Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/ Warning: I wish NOT to receive e-mail advertising to this address. Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu. My mind is like a steel trap - rusty and illegal in 37 states. ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Reverse DNS Dig returning PTR results only with trace option
In message 4afa0555.6070...@cyzap.com, Raj Adhikari writes:
Kevin Wrote: {QUOTE} There is no BIND way versus Windows way. For a
range smaller than /24 you either need to host all the records in the
/24 zone, delegate each entry individually (as /32 zones), or use
CNAMEs. This is determined by the protocol, regardless of whether you're
using Microsoft DNS, BIND or any other implementation.
Note that many thousands (tens of thouands? hundreds of thousands?) or
organizations use RFC 2317 for their reverse DNS without issues. So, on
what do you base your assessment of this approach as having lots of
problems? The folks who published RFC 2317 actually know what they're
talking about. People complaining on forums about having botched their
RFC 2317 configs, probably *don't*.
{QUOTE}
Ok, moving to RFC 2317, I may not have configured them correctly. If RFC
2317 will work for me then that would be great. This time I took the
subnet 64.253.134.176/28. This block needs to be delegated from
ns1.cyzap.net to ns1.moneytreesystems.com
I followed this for the configuration and naming convention from
http://support.microsoft.com/kb/174419.
I configured at ns1.cyzap.net as:
; Database file 134.254.63.in-addr.arpa.dns for 134.254.63.in-addr.arpa
zone.
; Zone version:
;
@ IN SOA ns1.cyzap.net. .. (
...
;
; Zone NS records
;
@ NSns1.cyzap.net.
@ NSns2.cyzap.net.
; Delegated sub-zone: 176-28.134.254.63.in-addr.arpa.
;
176-28 NSns1.moneytreesystems.com.
ns1.moneytreesystems.com. A63.254.134.213
ns1.moneytreesystems.com. A63.254.134.214
; End delegation
177 CNAME177.176-28.134.254.63.in-addr.arpa.
And at ns1.moneytreesystems.com, the configuration is as:
;
; Database file 176-28.134.254.63.in-addr.arpa.dns for
176-28.134.254.63.in-addr.arpa zone.
; Zone version: xx
;
@ IN SOA ns1.moneytreesystems.com.
hostmaster.moneytreesystems.com. (
.
.
;
; Zone NS records
;
@ NSns1.moneytreesystems.com.
ns1.moneytreesystems.com. A63.254.134.213
;
; Zone records
;
177 PTRtestnew177.cyzap.net.
My dig output for this are:
$ dig @ns1.cyzap.net -x 63.254.134.177
; DiG 9.4.2 @ns1.cyzap.net -x 63.254.134.177
; (1 server found)
;; global options: printcmd
;; Got answer:
;; -HEADER- opcode: QUERY, status: NOERROR, id: 50666
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 0
;; QUESTION SECTION:
;177.134.254.63.in-addr.arpa. IN PTR
;; ANSWER SECTION:
177.134.254.63.in-addr.arpa. 3600 INCNAME
177.176-28.134.254.63.in-addr.arpa.
177.176-28.134.254.63.in-addr.arpa. 60 IN PTR testnew177.cyzap.net.
;; Query time: 3 msec
;; SERVER: 172.30.111.3#53(172.30.111.3)
;; WHEN: Tue Nov 10 18:06:59 2009
;; MSG SIZE rcvd: 104
$ dig @ns2.cyzap.net -x 63.254.134.177
; DiG 9.4.2 @ns2.cyzap.net -x 63.254.134.177
; (1 server found)
;; global options: printcmd
;; Got answer:
;; -HEADER- opcode: QUERY, status: NOERROR, id: 58836
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 0
;; QUESTION SECTION:
;177.134.254.63.in-addr.arpa. IN PTR
;; ANSWER SECTION:
177.134.254.63.in-addr.arpa. 3600 INCNAME
177.176-28.134.254.63.in-addr.arpa.
177.176-28.134.254.63.in-addr.arpa. 55 IN PTR testnew177.cyzap.net.
;; Query time: 0 msec
;; SERVER: 172.30.111.53#53(172.30.111.53)
;; WHEN: Tue Nov 10 18:20:13 2009
;; MSG SIZE rcvd: 104
==
$ dig -x 63.254.134.177
; DiG 9.4.2 -x 63.254.134.177
;; global options: printcmd
;; Got answer:
;; -HEADER- opcode: QUERY, status: NOERROR, id: 60512
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0
;; QUESTION SECTION:
;177.134.254.63.in-addr.arpa. IN PTR
;; ANSWER SECTION:
177.134.254.63.in-addr.arpa. 2985 INCNAME
177.176-28.134.254.63.in-addr.arpa.
;; Query time: 0 msec
;; SERVER: 172.30.111.254#53(172.30.111.254)
;; WHEN: Tue Nov 10 18:07:18 2009
;; MSG SIZE rcvd: 70
===
$ dig -x 63.254.134.177 +trace
; DiG 9.4.2 -x 63.254.134.177 +trace
;; global options: printcmd
. 54948 IN NS j.root-servers.net.
. 54948 IN NS c.root-servers.net.
. 54948 IN NS k.root-servers.net.
. 54948 IN NS b.root-servers.net.
. 54948
Re: Reverse DNS Dig returning PTR results only with trace option
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 INNS ns1.cyzap.net. 228.134.254.63.in-addr.arpa. 7200 INNS 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 INNS ns2.moneytreesystems.com. 228.134.254.63.in-addr.arpa. 3600 INNS 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
Re: Reverse DNS Dig returning PTR results only with trace option
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
Re: Reverse DNS Dig returning PTR results only with trace option
Thanks Chris for the reply. Actually, let me put my question the other way. How can one delegate the classless subnet to other DNS? Actually, one of our ISP could not delegate classless subnet to our server ns1.cyzap.net. I am trying to help them in delegating the classless subnet to us. So this scenario is simulating our ISP and us. I was just testing with one of our other subnets checking if delegation will work. Unfortunately, we both are using windows DNS. Windows just have RFC 2317 way on configuring the delegation on it KB article using CNAME, which I think has lots of problems. But I am following this BIND way for delegation. I think, in windows the DNS configuration is more or less similar to BIND. In this scenario, lets say ns1.cyzap.net is my ISP and ns1.monetreesystems.com is us. ns1.cyzap.net owns 63.254.134.0/24 and ns1.moneytreesystems.com take a subnet 134.224/28 from them. So isn't there a way for ns1.cyzap.net to delegate the subnet to ns1.moneytreesystems.com? Do ns1.cyzap.net again have to talk to their upper ISP to delegate directly to us? What if upper ISP also need to ask their upper tier ISP. It seems I am lacking some basic concept here about the owner of the subnet. If a true owner delegates the subnet to its client ISP, can't this ISP again delegate the classless subnet agin to its client ISP? Thank you, Rajendra Adhikari 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 INNS ns1.cyzap.net. 228.134.254.63.in-addr.arpa. 7200 INNS 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 INNS ns2.moneytreesystems.com. 228.134.254.63.in-addr.arpa. 3600 INNS 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
Re: Reverse DNS Dig returning PTR results only with trace option
In message 4af9a220.9070...@cyzap.com, Raj Adhikari writes: Hi Guys, I have a 63.254.134.224/28 delegated from ns1.cyzap.net to ns1.moneytreesystems.com. The dig with trace only shows the PTR record. Surprisingly, it starts acting normal after I do the dig on ns1.cyzap.net. See the dig output below. Here is the output: Simple dig to 63.254.234.228. $ dig -x 63.254.134.228 ; DiG 9.3.4 -x 63.254.134.228 ;; global options: printcmd ;; Got answer: ;; -HEADER- opcode: QUERY, status: SERVFAIL, id: 23703 ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0 ;; QUESTION SECTION: ;228.134.254.63.in-addr.arpa. IN PTR ;; Query time: 9 msec ;; SERVER: 127.0.0.1#53(127.0.0.1) ;; WHEN: Tue Nov 10 11:09:36 2009 ;; MSG SIZE rcvd: 45 - Now do dig +trace $ dig -x 63.254.134.228 +trace ; DiG 9.3.4 -x 63.254.134.228 +trace ;; global options: printcmd . 346584 IN NS C.ROOT-SERVERS.NET. . 346584 IN NS D.ROOT-SERVERS.NET. . 346584 IN NS E.ROOT-SERVERS.NET. . 346584 IN NS F.ROOT-SERVERS.NET. . 346584 IN NS G.ROOT-SERVERS.NET. . 346584 IN NS H.ROOT-SERVERS.NET. . 346584 IN NS I.ROOT-SERVERS.NET. . 346584 IN NS J.ROOT-SERVERS.NET. . 346584 IN NS K.ROOT-SERVERS.NET. . 346584 IN NS L.ROOT-SERVERS.NET. . 346584 IN NS M.ROOT-SERVERS.NET. . 346584 IN NS A.ROOT-SERVERS.NET. . 346584 IN NS B.ROOT-SERVERS.NET. ;; Received 500 bytes from 127.0.0.1#53(127.0.0.1) in 20 ms 63.in-addr.arpa.86400 IN NS X.ARIN.NET. 63.in-addr.arpa.86400 IN NS BASIL.ARIN.NET. 63.in-addr.arpa.86400 IN NS DILL.ARIN.NET. 63.in-addr.arpa.86400 IN NS HENNA.ARIN.NET. 63.in-addr.arpa.86400 IN NS INDIGO.ARIN.NET. 63.in-addr.arpa.86400 IN NS Y.ARIN.NET. 63.in-addr.arpa.86400 IN NS Z.ARIN.NET. ;; Received 181 bytes from 192.33.4.12#53(C.ROOT-SERVERS.NET) in 90 ms 254.63.in-addr.arpa.86400 IN NS NS3.MCLEODUSA.NET. 254.63.in-addr.arpa.86400 IN NS NS2.MCLEODUSA.NET. 254.63.in-addr.arpa.86400 IN NS NS1.MCLEODUSA.NET. ;; Received 112 bytes from 192.55.83.32#53(BASIL.ARIN.NET) in 173 ms 228.134.254.63.in-addr.arpa. 7200 INNS ns2.cyzap.net. 228.134.254.63.in-addr.arpa. 7200 INNS ns1.cyzap.net. ;; Received 90 bytes from 209.253.113.19#53(NS3.MCLEODUSA.NET) in 26 ms 228.134.254.63.in-addr.arpa is delegated to ns1.cyzap.net and ns2.cyzap.net. 228.134.254.63.in-addr.arpa. 3600 INNS ns2.moneytreesystems.com. 228.134.254.63.in-addr.arpa. 3600 INNS ns1.moneytreesystems.com. ;; Received 160 bytes from 64.253.181.53#53(ns2.cyzap.net) in 1 ms ns1.cyzap.net and ns2.cyzap.net then claim they don't serve 228.134.254.63.in-addr.arpa but that it is served by ns1.moneytreesystems.com and ns2.moneytreesystems.com. This is a broken delegation and it needs to be fixed. Named detects this breakage, but this version of dig doesn't as it doesn't do checks to ensure that the new referral improves the situation. Mark 228.134.254.63.in-addr.arpa. 3600 INPTR test228.moneytreesystems.com. ;; Received 87 bytes from 63.254.134.214#53(ns2.moneytreesystems.com) in 3 ms - --- Now, I will do a dig on sn1.cyzap.net which has delegated this IP from ns1.cyzap.net to ns1.moneytreesystems.com $ dig @ns1.cyzap.net -x 63.254.134.228 ; DiG 9.3.4 @ns1.cyzap.net -x 63.254.134.228 ; (1 server found) ;; global options: printcmd ;; Got answer: ;; -HEADER- opcode: QUERY, status: NOERROR, id: 60256 ;; flags: qr aa; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0 ;; QUESTION SECTION: ;228.134.254.63.in-addr.arpa. IN PTR ;; ANSWER SECTION: 228.134.254.63.in-addr.arpa. 3600 INPTR test228.moneytreesystems.com. ;; Query time: 3 msec ;; SERVER: 63.254.134.3#53(63.254.134.3) ;; WHEN: Tue Nov 10 11:11:55 2009 ;; MSG SIZE rcvd: 87 - Now, I will do a simple dig again. $ dig -x 63.254.134.228 ; DiG 9.3.4 -x 63.254.134.228 ;; global options: printcmd ;; Got answer: ;; -HEADER- opcode: QUERY, status: NOERROR, id: 21096 ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 2 ;; QUESTION SECTION: ;228.134.254.63.in-addr.arpa. IN
Re: Reverse DNS Dig returning PTR results only with trace option
Raj Adhikari wrote: Thanks Chris for the reply. Actually, let me put my question the other way. How can one delegate the classless subnet to other DNS? Actually, one of our ISP could not delegate classless subnet to our server ns1.cyzap.net. I am trying to help them in delegating the classless subnet to us. So this scenario is simulating our ISP and us. I was just testing with one of our other subnets checking if delegation will work. Unfortunately, we both are using windows DNS. Windows just have RFC 2317 way on configuring the delegation on it KB article using CNAME, which I think has lots of problems. But I am following this BIND way for delegation. I think, in windows the DNS configuration is more or less similar to BIND. There is no BIND way versus Windows way. For a range smaller than /24 you either need to host all the records in the /24 zone, delegate each entry individually (as /32 zones), or use CNAMEs. This is determined by the protocol, regardless of whether you're using Microsoft DNS, BIND or any other implementation. Note that many thousands (tens of thouands? hundreds of thousands?) or organizations use RFC 2317 for their reverse DNS without issues. So, on what do you base your assessment of this approach as having lots of problems? The folks who published RFC 2317 actually know what they're talking about. People complaining on forums about having botched their RFC 2317 configs, probably *don't*. In this scenario, lets say ns1.cyzap.net is my ISP and ns1.monetreesystems.com is us. ns1.cyzap.net owns 63.254.134.0/24 and ns1.moneytreesystems.com take a subnet 134.224/28 from them. So isn't there a way for ns1.cyzap.net to delegate the subnet to ns1.moneytreesystems.com? The /24 is delegated to ns1.cyzap.net. Zone delegation is on octet boundaries. So the next available boundary for delegation would be /32, i.e. delegating each of the 16 usable addresses (or perhaps just the 14 usable addresses) individually. Do ns1.cyzap.net again have to talk to their upper ISP to delegate directly to us? No, that doesn't help. What would the /16 nameservers delegate? They've already delegated 134.254.63.in-addr.arpa, there's nothing more you can expect of them. - 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 INNS ns1.cyzap.net. 228.134.254.63.in-addr.arpa. 7200 INNS 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 INNS ns2.moneytreesystems.com. 228.134.254.63.in-addr.arpa. 3600 INNS 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
Re: Reverse DNS Dig returning PTR results only with trace option
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
Re: Reverse DNS Dig returning PTR results only with trace option
In message 4af9dfba.6040...@cyzap.com, Raj Adhikari writes: Thanks Chris for the reply. Actually, let me put my question the other way. How can one delegate the classless subnet to other DNS? Actually, one of our ISP could not delegate classless subnet to our server ns1.cyzap.net. I am trying to help them in delegating the classless subnet to us. So this scenario is simulating our ISP and us. I was just testing with one of our other subnets checking if delegation will work. Unfortunately, we both are using windows DNS. Windows just have RFC 2317 way on configuring the delegation on it KB article using CNAME, which I think has lots of problems. But I am following this BIND way for delegation. I think, in windows the DNS configuration is more or less similar to BIND. In this scenario, lets say ns1.cyzap.net is my ISP and ns1.monetreesystems.com is us. ns1.cyzap.net owns 63.254.134.0/24 and ns1.moneytreesystems.com take a subnet 134.224/28 from them. So isn't there a way for ns1.cyzap.net to delegate the subnet to ns1.moneytreesystems.com? Do ns1.cyzap.net again have to talk to their upper ISP to delegate directly to us? What if upper ISP also need to ask their upper tier ISP. It seems I am lacking some basic concept here about the owner of the subnet. If a true owner delegates the subnet to its client ISP, can't this ISP again delegate the classless subnet agin to its client ISP? Thank you, Rajendra Adhikari You tell your ISP where the delegation needs to point. If your ISP controls the exclosing name in the DNS namespace they update it there or they pass on your request to where they got their address space from. Repeat until the delegation is added to the parent zone. -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Reverse DNS Dig returning PTR results only with trace option
Kevin Wrote: {QUOTE} There is no BIND way versus Windows way. For a
range smaller than /24 you either need to host all the records in the
/24 zone, delegate each entry individually (as /32 zones), or use
CNAMEs. This is determined by the protocol, regardless of whether you're
using Microsoft DNS, BIND or any other implementation.
Note that many thousands (tens of thouands? hundreds of thousands?) or
organizations use RFC 2317 for their reverse DNS without issues. So, on
what do you base your assessment of this approach as having lots of
problems? The folks who published RFC 2317 actually know what they're
talking about. People complaining on forums about having botched their
RFC 2317 configs, probably *don't*.
{QUOTE}
Ok, moving to RFC 2317, I may not have configured them correctly. If RFC
2317 will work for me then that would be great. This time I took the
subnet 64.253.134.176/28. This block needs to be delegated from
ns1.cyzap.net to ns1.moneytreesystems.com
I followed this for the configuration and naming convention from
http://support.microsoft.com/kb/174419.
I configured at ns1.cyzap.net as:
; Database file 134.254.63.in-addr.arpa.dns for 134.254.63.in-addr.arpa
zone.
; Zone version:
;
@ IN SOA ns1.cyzap.net. .. (
...
;
; Zone NS records
;
@ NSns1.cyzap.net.
@ NSns2.cyzap.net.
; Delegated sub-zone: 176-28.134.254.63.in-addr.arpa.
;
176-28 NSns1.moneytreesystems.com.
ns1.moneytreesystems.com. A63.254.134.213
ns1.moneytreesystems.com. A63.254.134.214
; End delegation
177 CNAME177.176-28.134.254.63.in-addr.arpa.
And at ns1.moneytreesystems.com, the configuration is as:
;
; Database file 176-28.134.254.63.in-addr.arpa.dns for
176-28.134.254.63.in-addr.arpa zone.
; Zone version: xx
;
@ IN SOA ns1.moneytreesystems.com.
hostmaster.moneytreesystems.com. (
.
.
;
; Zone NS records
;
@ NSns1.moneytreesystems.com.
ns1.moneytreesystems.com. A63.254.134.213
;
; Zone records
;
177 PTRtestnew177.cyzap.net.
My dig output for this are:
$ dig @ns1.cyzap.net -x 63.254.134.177
; DiG 9.4.2 @ns1.cyzap.net -x 63.254.134.177
; (1 server found)
;; global options: printcmd
;; Got answer:
;; -HEADER- opcode: QUERY, status: NOERROR, id: 50666
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 0
;; QUESTION SECTION:
;177.134.254.63.in-addr.arpa. IN PTR
;; ANSWER SECTION:
177.134.254.63.in-addr.arpa. 3600 INCNAME
177.176-28.134.254.63.in-addr.arpa.
177.176-28.134.254.63.in-addr.arpa. 60 IN PTR testnew177.cyzap.net.
;; Query time: 3 msec
;; SERVER: 172.30.111.3#53(172.30.111.3)
;; WHEN: Tue Nov 10 18:06:59 2009
;; MSG SIZE rcvd: 104
$ dig @ns2.cyzap.net -x 63.254.134.177
; DiG 9.4.2 @ns2.cyzap.net -x 63.254.134.177
; (1 server found)
;; global options: printcmd
;; Got answer:
;; -HEADER- opcode: QUERY, status: NOERROR, id: 58836
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 0
;; QUESTION SECTION:
;177.134.254.63.in-addr.arpa. IN PTR
;; ANSWER SECTION:
177.134.254.63.in-addr.arpa. 3600 INCNAME
177.176-28.134.254.63.in-addr.arpa.
177.176-28.134.254.63.in-addr.arpa. 55 IN PTR testnew177.cyzap.net.
;; Query time: 0 msec
;; SERVER: 172.30.111.53#53(172.30.111.53)
;; WHEN: Tue Nov 10 18:20:13 2009
;; MSG SIZE rcvd: 104
==
$ dig -x 63.254.134.177
; DiG 9.4.2 -x 63.254.134.177
;; global options: printcmd
;; Got answer:
;; -HEADER- opcode: QUERY, status: NOERROR, id: 60512
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0
;; QUESTION SECTION:
;177.134.254.63.in-addr.arpa. IN PTR
;; ANSWER SECTION:
177.134.254.63.in-addr.arpa. 2985 INCNAME
177.176-28.134.254.63.in-addr.arpa.
;; Query time: 0 msec
;; SERVER: 172.30.111.254#53(172.30.111.254)
;; WHEN: Tue Nov 10 18:07:18 2009
;; MSG SIZE rcvd: 70
===
$ dig -x 63.254.134.177 +trace
; DiG 9.4.2 -x 63.254.134.177 +trace
;; global options: printcmd
. 54948 IN NS j.root-servers.net.
. 54948 IN NS c.root-servers.net.
. 54948 IN NS k.root-servers.net.
. 54948 IN NS b.root-servers.net.
. 54948 IN NS l.root-servers.net.
. 54948 IN NS h.root-servers.net.
. 54948 IN NS f.root-servers.net.
. 54948 IN
