RE: BIND 9.9 cannot resolve PTR record but +trace can

2018-04-11 Thread Darcy Kevin (FCA)
On a case-by-case basis, one can use stub zones, conditional forwarding, etc. 
but if you're looking for a "break Internet standards" switch, I think you're 
going to be disappointed. Vix has stopped calling BIND a "reference" 
implementation of DNS, but it still tries to set a good example.


- Kevin



-Original Message-
From: bind-users  On Behalf Of Aras Yorganci
Sent: Wednesday, April 11, 2018 9:49 AM
To: Anand Buddhdev 
Cc: bind-users@lists.isc.org
Subject: Re: BIND 9.9 cannot resolve PTR record but +trace can


Alinti Anand Buddhdev 

> The delegation of 131.161.213.in-addr.arpa points to dns.est.com.tr 
> and dns2.est.com.tr. But these two names are aliased to 
> dns3.est.com.tr and dns4.est.com.tr.
>
> However, one cannot use alias names as targets of NS records. This is 
> forbidden by RFC 2181, section 10.3.
>
> The operator of this reverse zone (EST Bilisim) should update the 
> delegation of 131.161.213.in-addr.arpa (in the RIPE Database) and use 
> the proper name servers names in there. If you know someone there, 
> please inform them.
>
> Regards,
> Anand
>
> On 11/04/2018 15:23, Aras Yorgancı wrote:

Thanks for reply. I understand that there is an illegal situation but other dns 
servers can resolve this query while BIND cannot. Maybe I have not much 
knowledge about subject but I wonder is there any way or any configuration to 
resolve this query with my BIND server, bypass this prohibition?

Regards,
Aras

___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users


Re: BIND 9.9 cannot resolve PTR record but +trace can

2018-04-11 Thread Aras Yorgancı


Alinti Anand Buddhdev 


The delegation of 131.161.213.in-addr.arpa points to dns.est.com.tr and
dns2.est.com.tr. But these two names are aliased to dns3.est.com.tr and
dns4.est.com.tr.

However, one cannot use alias names as targets of NS records. This is
forbidden by RFC 2181, section 10.3.

The operator of this reverse zone (EST Bilisim) should update the
delegation of 131.161.213.in-addr.arpa (in the RIPE Database) and use
the proper name servers names in there. If you know someone there,
please inform them.

Regards,
Anand

On 11/04/2018 15:23, Aras Yorgancı wrote:


Thanks for reply. I understand that there is an illegal situation but  
other dns servers can resolve this query while BIND cannot. Maybe I  
have not much knowledge about subject but I wonder is there any way or  
any configuration to resolve this query with my BIND server, bypass  
this prohibition?


Regards,
Aras

___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users


Re: BIND 9.9 cannot resolve PTR record but +trace can

2018-04-11 Thread Tony Finch
Aras Yorgancı  wrote:
>
> Our BIND 9.9 DNS servers cannot resolve PTR record of a mx server. So We
> cannot established e-mail communication.

This is because the delegation NS records point at CNAMEs, which is not
allowed - if a resolver tries to chase CNAMEs in this situation it can get
into a confusing mess. BIND just refuses to use NS records that point at
CNAMEs.

; <<>> DiG 9.13.0-dev <<>> -x 213.161.131.25 @pri.authdns.ripe.net.

;; AUTHORITY SECTION:
131.161.213.in-addr.arpa. 172800 IN NS  dns.est.com.tr.
131.161.213.in-addr.arpa. 172800 IN NS  dns2.est.com.tr.

; <<>> DiG 9.13.0-dev <<>> dns.est.com.tr.

;; ANSWER SECTION:
dns.est.com.tr. 600 IN  CNAME   dns3.est.com.tr.
dns3.est.com.tr.600 IN  A   213.153.232.20

; <<>> DiG 9.13.0-dev <<>> dns2.est.com.tr.

;; ANSWER SECTION:
dns2.est.com.tr.600 IN  CNAME   dns4.est.com.tr.
dns4.est.com.tr.600 IN  A   213.74.122.20

Tony.
-- 
f.anthony.n.finchhttp://dotat.at/
Dogger, Fisher, German Bight: East or northeast 5 to 7, occasionally gale 8 in
Fisher. Moderate or rough. Showers. Moderate or good.___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users


Re: BIND 9.9 cannot resolve PTR record but +trace can

2018-04-11 Thread Anand Buddhdev
The delegation of 131.161.213.in-addr.arpa points to dns.est.com.tr and
dns2.est.com.tr. But these two names are aliased to dns3.est.com.tr and
dns4.est.com.tr.

However, one cannot use alias names as targets of NS records. This is
forbidden by RFC 2181, section 10.3.

The operator of this reverse zone (EST Bilisim) should update the
delegation of 131.161.213.in-addr.arpa (in the RIPE Database) and use
the proper name servers names in there. If you know someone there,
please inform them.

Regards,
Anand

On 11/04/2018 15:23, Aras Yorgancı wrote:
> 
> Hi,
> 
> Our BIND 9.9 DNS servers cannot resolve PTR record of a mx server. So We
> cannot established e-mail communication.
> 
> [root@localhost ~]# dig @127.0.0.1 -x 213.161.131.25
> 
> ; <<>> DiG 9.9.4-RedHat-9.9.4-51.el7_4.2 <<>> @127.0.0.1 -x 213.161.131.25
> ; (1 server found)
> ;; global options: +cmd
> ;; Got answer:
> ;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 7490
> ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1
> 
> ;; OPT PSEUDOSECTION:
> ; EDNS: version: 0, flags:; udp: 4096
> ;; QUESTION SECTION:
> ;25.131.161.213.in-addr.arpa.   IN  PTR
> 
> ;; Query time: 54 msec
> ;; SERVER: 127.0.0.1#53(127.0.0.1)
> ;; WHEN: Wed Apr 11 16:13:21 +03 2018
> ;; MSG SIZE  rcvd: 56
> 
> But when I give +trace to dig commant I can resolve PTR.
> 
> [root@localhost ~]# dig @127.0.0.1 -x 213.161.131.25 +trace
> 
> ; <<>> DiG 9.9.4-RedHat-9.9.4-51.el7_4.2 <<>> @127.0.0.1 -x
> 213.161.131.25 +trace
> ; (1 server found)
> ;; global options: +cmd
> .   517406  IN  NS  a.root-servers.net.
> .   517406  IN  NS  e.root-servers.net.
> .   517406  IN  NS  f.root-servers.net.
> .   517406  IN  NS  j.root-servers.net.
> .   517406  IN  NS  m.root-servers.net.
> .   517406  IN  NS  c.root-servers.net.
> .   517406  IN  NS  k.root-servers.net.
> .   517406  IN  NS  d.root-servers.net.
> .   517406  IN  NS  b.root-servers.net.
> .   517406  IN  NS  l.root-servers.net.
> .   517406  IN  NS  g.root-servers.net.
> .   517406  IN  NS  h.root-servers.net.
> .   517406  IN  NS  i.root-servers.net.
> .   517419  IN  RRSIG   NS 8 0 518400
> 2018042317 2018041016 39570 .
> PVPdWr8uleU6aJ2gD0jgKpuu9mQzJ/wRvBwtCV1/HJll67y5CbT4D6to
> o4LzSn07161UQRP9NrqRtOxec6xk2ovU7tQDngfqUNyJ8yThXl65y+iC
> leoK5wf+2Cr/SgJyvP9kyifL18BaC2KBLFzbv1XS8qJmABlxxoGJ4mAm
> FUXrMm7Kw2XAYRbCtBNnsLmUNngLnryLeavlQ9wrrrvrmKQiI3itlm9B
> nBysG1ERJnyTIHYcfdFo0qifVZiF2Zrdms1HPKrUdSNGm+5yX39WFhtU
> jZcbgTJqhuSiwoZh5GWp2L1ENtbNiXTdprJAiXKDfsPHn6nD76i0RP8e VQU08w==
> ;; Received 525 bytes from 127.0.0.1#53(127.0.0.1) in 50 ms
> 
> in-addr.arpa.   172800  IN  NS  e.in-addr-servers.arpa.
> in-addr.arpa.   172800  IN  NS  f.in-addr-servers.arpa.
> in-addr.arpa.   172800  IN  NS  d.in-addr-servers.arpa.
> in-addr.arpa.   172800  IN  NS  c.in-addr-servers.arpa.
> in-addr.arpa.   172800  IN  NS  b.in-addr-servers.arpa.
> in-addr.arpa.   172800  IN  NS  a.in-addr-servers.arpa.
> in-addr.arpa.   86400   IN  DS  53696 8 2
> 13E5501C56B20394DA921B51412D48B7089C5EB6957A7C58553C4D4D 424F04DF
> in-addr.arpa.   86400   IN  DS  63982 8 2
> AAF4FB5D213EF25AE44679032EBE3514C487D7ABD99D7F5FEC3383D0 30733C73
> in-addr.arpa.   86400   IN  DS  47054 8 2
> 5CAFCCEC201D1933B4C9F6A9C8F51E51F3B39979058AC21B8DF1B1F2 81CBC6F2
> in-addr.arpa.   86400   IN  RRSIG   DS 8 2 86400
> 2018042412 201804 56191 arpa.
> Nd9soXvlQes9+QDoWvXqAkWa4B3HVZ7TE4u6R9O/3dLWd8fNGz2UrW96
> ndT3LFn46lBs+Ne8k5eLCNimsCcYicik5jjSFfqDvFDbCDOuyT5yud+N
> qGkf3nSKvnCnN0RNOUjwy5hTcr3t6JXCeGimrGxI8wGNVJLIzFc7kNCt AK0=
> ;; Received 740 bytes from 198.41.0.4#53(a.root-servers.net) in 281 ms
> 
> 213.in-addr.arpa.   86400   IN  NS  ns3.lacnic.net.
> 213.in-addr.arpa.   86400   IN  NS  ns3.afrinic.net.
> 213.in-addr.arpa.   86400   IN  NS  ns4.apnic.net.
> 213.in-addr.arpa.   86400   IN  NS  pri.authdns.ripe.net.
> 213.in-addr.arpa.   86400   IN  NS  sns-pb.isc.org.
> 213.in-addr.arpa.   86400   IN  NS  tinnie.arin.net.
> 213.in-addr.arpa.   86400   IN  DS  48511 8 2
> 517659CCA01FFE7F16E1034F43BFA5EFCDE8ECEFADA017082F37C262 FA784AB3
> 213.in-addr.arpa.   86400   IN  RRSIG   DS 8 3 86400
> 20180428231459 20180407202433 43878 in-addr.arpa.
> UM4csvWyH7w67fP5kxewzIpZthvNYFLVp111KNYUXNxyhZazRklZZW1x
> pnVftNbOulxdp0ndlvEVVKLB2qpk694lVi6Gfa9VVjpoYKMJlR4959uq
> XCoaB3UTyU3joSKvvABFA5mLQRY6sDmLgtFJkAGt1WYnls36j0wNQYZ