BIND 9.9 cannot resolve PTR record but +trace can
Aras Yorgancı
yorgancia at itu.edu.tr
Wed Apr 11 13:23:18 UTC 2018
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";
More information about the bind-users
mailing list