Reverse DNS Dig returning PTR results only with trace option

2009-11-10 Thread Raj Adhikari
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. 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

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  PTR

;; ANSWER SECTION:
228.134.254.63.in-addr.arpa. 3599 INPTR
test228.moneytreesystems.com.

;; AUTHORITY SECTION:
228.134.254.63.in-addr.arpa. 7057 INNS  ns1.cyzap.net.
228.134.254.63.in-addr.arpa. 7057 INNS  ns2.cyzap.net.

;; ADDITIONAL SECTION:
ns1.cyzap.net.  12523   IN  A   63.254.134.3
ns2.cyzap.net.  1723IN  A   64.253.181.53

;; Query time: 7 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Tue Nov 10 11:11:56 2009
;; MSG SIZE  rcvd: 164

-
Now I can do a dig for an 

Re: Reverse DNS Dig returning PTR results only with trace option

2009-11-10 Thread Raj Adhikari
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

2009-11-10 Thread Raj Adhikari
   IN  NS  m.root-servers.net.
.   54948   IN  NS  e.root-servers.net.
.   54948   IN  NS  d.root-servers.net.
.   54948   IN  NS  a.root-servers.net.
.   54948   IN  NS  g.root-servers.net.
.   54948   IN  NS  i.root-servers.net.
;; Received 449 bytes from 172.30.111.254#53(172.30.111.254) in 1 ms

63.in-addr.arpa.86400   IN  NS  X.ARIN.NET.
63.in-addr.arpa.86400   IN  NS  Y.ARIN.NET.
63.in-addr.arpa.86400   IN  NS  INDIGO.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  Z.ARIN.NET.
63.in-addr.arpa.86400   IN  NS  BASIL.ARIN.NET.
;; Received 181 bytes from 192.36.148.17#53(i.root-servers.net) in 60 ms

254.63.in-addr.arpa.86400   IN  NS  NS2.MCLEODUSA.NET.
254.63.in-addr.arpa.86400   IN  NS  NS1.MCLEODUSA.NET.
254.63.in-addr.arpa.86400   IN  NS  NS3.MCLEODUSA.NET.
;; Received 112 bytes from 192.26.92.32#53(HENNA.ARIN.NET) in 41 ms

177.134.254.63.in-addr.arpa. 7200 INNS  ns2.cyzap.net.
177.134.254.63.in-addr.arpa. 7200 INNS  ns1.cyzap.net.
;; Received 90 bytes from 209.253.113.19#53(NS3.MCLEODUSA.NET) in 17 ms

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. 16 IN PTR   testnew177.cyzap.net.
;; Received 104 bytes from 172.30.111.3#53(ns1.cyzap.net) in 0 ms

===
Why did the simple dig (without trace or specifying ns1.cyzap.net)  not
return the PTR record?
Also, if I do  dig @ns1.cyzap.net -x 63.254.134.177 and then dig -x
63.254.134.177 +trace , it will not give the PTR record if it traces to
ns2.cyzap.net. If I do,  dig @ns2.cyzap.net -x 63.254.134.177 and then
dig -x 63.254.134.177 +trace, it will not give PTR record if it traces
to ns1.cyzap.net. That is why sometimes I am getting PTR from trace
option and sometimes not. Something is broken here.


Thank you,
Raj


Kevin Darcy wrote:
 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