BIND 9.9 cannot resolve PTR record but +trace can
Anand Buddhdev
anandb at ripe.net
Wed Apr 11 13:37:08 UTC 2018
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 at 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 at 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 at 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 at 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 at lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users
>
More information about the bind-users
mailing list