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
> 20180423170000 20180410160000 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
> 20180424120000 20180411110000 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
> XCoaB3UTyU3joSKvvABFA5mLQRY6sDmLgtFJkAGt1WYnls36j0wNQYZO DM0=
> ;; Received 439 bytes from 199.253.183.183#53(b.in-addr-servers.arpa) in
> 118 ms
> 
> 131.161.213.in-addr.arpa. 172800 IN     NS      dns2.est.com.tr.
> 131.161.213.in-addr.arpa. 172800 IN     NS      dns.est.com.tr.
> 131.161.213.in-addr.arpa. 3600  IN      NSEC   
> 132.161.213.in-addr.arpa. NS RRSIG NSEC
> 131.161.213.in-addr.arpa. 3600  IN      RRSIG   NSEC 8 5 3600
> 20180511100134 20180411090134 21904 213.in-addr.arpa.
> gysZjKXx3Dt45lrmZVYkEchRNeYOGkg5Ow5ODCKza3bXLIpk5teLdajq
> Z6ZPFlCvdxcNPNrKilsZJM+D+kuMb19WVCqCyU5b6s6geYtjXkkwUQhR
> FjDi1x4PEk/n2Ryrh9mDT7dsdqrXTWj3ScFJ+mBMpIYA38L1BpR1Jpqi 7v8=
> ;; Received 325 bytes from 202.12.31.53#53(ns4.apnic.net) in 712 ms
> 
> 25.131.161.213.in-addr.arpa. 600 IN     PTR     mail2.asseco-see.com.tr.
> 131.161.213.in-addr.arpa. 600   IN      NS      dns4.est.com.tr.
> 131.161.213.in-addr.arpa. 600   IN      NS      dns3.est.com.tr.
> ;; Received 167 bytes from 213.74.122.20#53(dns2.est.com.tr) in 78 ms
> 
> Also google can return PTR record.
> 
> [root@centos-512mb-ams2-01 ~]# dig @8.8.8.8 -x 213.161.131.25
> 
> ; <<>> DiG 9.9.4-RedHat-9.9.4-51.el7_4.2 <<>> @8.8.8.8 -x 213.161.131.25
> ; (1 server found)
> ;; global options: +cmd
> ;; Got answer:
> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 23088
> ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
> 
> ;; OPT PSEUDOSECTION:
> ; EDNS: version: 0, flags:; udp: 512
> ;; QUESTION SECTION:
> ;25.131.161.213.in-addr.arpa.   IN      PTR
> 
> ;; ANSWER SECTION:
> 25.131.161.213.in-addr.arpa. 599 IN     PTR     mail2.asseco-see.com.tr.
> 
> ;; Query time: 171 msec
> ;; SERVER: 8.8.8.8#53(8.8.8.8)
> ;; WHEN: Wed Apr 11 16:16:12 +03 2018
> ;; MSG SIZE  rcvd: 93
> 
> In addition, I set up an unbound dns server and it gives me PTR record.
> Just BIND cannot resolve this record. I have read that statement in
> older mails in maillist:
> 
> Namservers cannot refer to CNAMEs.
> 
>   Named does *not* follow CNAMEs when looking up addresses
>   of namesevers.
> 
> I checked that situation and saw that dns.est.com.tr is a CNAME of
> dns3.est.com.tr. I think this is the source of problem. But while google
> and unbound could resolve PTR record, why BIND couldn't? Ypu can see my
> named.conf below. Is there any configuration parameter that I missed?
> 
> [root@localhost ~]# cat /var/named/chroot/etc/named.conf
> //
> // named.conf
> //
> // Provided by Red Hat bind package to configure the ISC BIND named(8) DNS
> // server as a caching only nameserver (as a localhost DNS resolver only).
> //
> // See /usr/share/doc/bind*/sample/ for example named configuration files.
> //
> // See the BIND Administrator's Reference Manual (ARM) for details about
> the
> // configuration located in /usr/share/doc/bind-{version}/Bv9ARM.html
> 
> options {
>         listen-on port 53 { any; };
>         listen-on-v6 port 53 { none; };
>         directory       "/var/named";
>         dump-file       "/var/named/data/cache_dump.db";
>         statistics-file "/var/named/data/named_stats.txt";
>         memstatistics-file "/var/named/data/named_mem_stats.txt";
>         allow-query     { localhost; 192.168.42.0/24; };
> 
>         /*
>          - If you are building an AUTHORITATIVE DNS server, do NOT
> enable recursion.
>          - If you are building a RECURSIVE (caching) DNS server, you
> need to enable
>            recursion.
>          - If your recursive DNS server has a public IP address, you
> MUST enable access
>            control to limit queries to your legitimate users. Failing to
> do so will
>            cause your server to become part of large scale DNS
> amplification
>            attacks. Implementing BCP38 within your network would greatly
>            reduce such attack surface
>         */
>         recursion yes;
> 
>         dnssec-enable yes;
>         dnssec-validation yes;
> 
>         /* Path to ISC DLV key */
>         bindkeys-file "/etc/named.iscdlv.key";
> 
>         managed-keys-directory "/var/named/dynamic";
> 
>         pid-file "/run/named/named.pid";
>         session-keyfile "/run/named/session.key";
> };
> 
> logging {
>         channel default_debug {
>                 file "data/named.run";
>                 severity dynamic;
>         };
> };
> 
> zone "." IN {
>         type hint;
>         file "named.ca";
> };
> 
> include "/etc/named.rfc1912.zones";
> include "/etc/named.root.key";
> 
> 
> 
> 
> _______________________________________________
> 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

Reply via email to