I've set up a BIND DNS server on centos 7. I've created the master zone record, it is the following:

$ttl 38400    
loool.ro. IN  SOA ns1.loool.ro. owner.yahoo.com. (    
      1421842090   
      10800
      3600
      604800
      38400 )
loool.ro. IN  NS  loool.ro.
loool.ro. IN  A   86.34.156.51
loool.ro. IN  MX  10 loool.ro.
loool.ro. IN  NS  ns1.loool.ro.
ns1.loool.ro. IN  A   86.34.156.51

The 86.34.156.51 is a public IP address, I can access the server via. The port 53 is opened, checked with free online port checker. The named.service is listening on port 53. The domain name is registered and the ns1 too. But when I check with a dnslookup tool, the ns1.loool.ro answer doesn't come, timeout after 3 sec.

The BIND server config file is the following:

options {
listen-on port 53 {
    any;
    };
#listen-on-v6 port 53 { ::1; };
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-transfer {
    none;
    };
recursion yes;
dnssec-enable yes;
dnssec-validation yes;
dnssec-lookaside auto;
/* 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";
also-notify {
    };
allow-query {
    any;
    };
 };
 logging {
    channel default_debug {
            file "data/named.run";
            severity dynamic;
    };
};
zone "." IN {
    type hint;
    file "named.ca";
 };
 zone "loool.ro" {
    type master;
    file "/var/named/loool.ro.hosts";
 };

If I check with dig from localhost the answer comes and correct, but from an other host doesn't come. If I set the allow-query from any to localhost, the messages.log file logs the denied querys and IP address, so the querys arrive.

On named.service start the messages.log shows the following:

Jan 21 14:31:35 servera named[38627]: using default UDP/IPv4 port range: [1024, 65535]
Jan 21 14:31:35 servera named[38627]: using default UDP/IPv6 port range: [1024, 65535]
Jan 21 14:31:35 servera named[38627]: listening on IPv4 interface lo, 127.0.0.1#53
Jan 21 14:31:35 servera named[38627]: listening on IPv4 interface em1, 10.10.10.100#53
Jan 21 14:31:35 servera named[38627]: listening on IPv4 interface em1, 86.34.156.51#53

With allow-query=localhost shows the following:

Jan 21 14:30:55 servera named[38403]: client 109.99.188.88#54374 (loool.ro): query 'loool.ro/A/IN' denied    
Jan 21 14:31:08 servera named[38403]: client 74.125.17.211#53668 (loool.ro): query 'loool.ro/AAAA/IN' denied    

What is the problem? If the allow-query is any, there isn't any error log on messages.log. This will be a network config issue or the problem is with the linux(port or selinux) and the BIND server(misconfig)? Does BIND drops the queries?

Dig:

loool.ro. 0 IN NS ns1.loool.ro. ;;
Received 71 bytes from 192.162.16.20#53(sec-dns-a.rotld.ro) in 88 ms

loool.ro. 38400 IN A 86.34.156.51
loool.ro. 38400 IN NS ns1.loool.ro.
loool.ro. 38400 IN NS loool.ro.

;; Received 101 bytes from 10.10.10.100#53(ns1.loool.ro) in 1 ms

As Andrew B suggested, I've captured the packets on the localhost(where the dns server is located), here is the result, I hope somebody knows what is the problem or what's wrong here :

$tcpdump -i em1 -vvv -s 0 -l -n port 53     
tcpdump: listening on em1, link-type EN10MB (Ethernet), capture size 65535 bytes    
 82.79.24.76.14761 > 10.10.10.100.domain: [udp sum ok] 3532 [1au] A? loool.ro. ar: . OPT UDPsize=4096 OK (37)
22:50:49.723204 IP (tos 0x0, ttl 64, id 63258, offset 0, flags [none], proto UDP (17), length 115)
    10.10.10.100.domain > 82.79.24.76.14761: [udp sum ok] 3532*- q: A? loool.ro. 1/1/2 loool.ro. [10h40m] A 86.34.156.51 ns: loool.ro. [10h40m] NS ns1.loool.ro. ar: ns1.loool.ro. [10h40m] A 86.34.156.51, . OPT UDPsize=4096 OK (87)
22:50:49.987990 IP (tos 0x0, ttl 64, id 35514, offset 0, flags [DF], proto UDP (17), length 72)
    10.10.10.100.52857 > 193.231.100.130.domain: [udp sum ok] 2042+ PTR? 38.124.41.103.in-addr.arpa. (44)
  • It doesn't look like your bind config loads the zone file for domain.yy to me?.. – Daniel Widrick Jan 21 '15 at 14:11
  • It loads, I just forgeted... – Zsigmond Szilveszter Jan 21 '15 at 14:14

Your nameserver cannot be queried from the internet. The glue is present, but that doesn't help if replies cannot be received by your nameserver.

Here's the tail end of a +trace output similar to lVlint67's, but with the +additional flag set:

loool.ro.               86400   IN      NS      ns1.loool.ro.
ns1.loool.ro.           86400   IN      A       86.34.156.51
dig: couldn't get address for 'ns1.loool.ro': no more

The glue record is there, but something else is wrong. If I try to query that nameserver myself...

$ dig @86.34.156.51 loool.ro

; <<>> DiG 9.8.4-rpz2+rl005.12-P1 <<>> @86.34.156.51 loool.ro
; (1 server found)
;; global options: +cmd
;; connection timed out; no servers could be reached

The nameserver is unreachable, so the domain is dead to the internet. Additionally, you only have a single NS record defined. For proper resiliency, you need at least two nameservers that are located at different physical locations. The registrar's website really shouldn't have let you apply this configuration. :(

I also recommend reading Should we host our own nameservers?.

  • The only 1 nameserver is just temporary, if I could make this nameserver to work, I'm going to make a second dedicated nameserver with separate internet connection. Could you give me an advice where should I start the troubleshooting. Now I removed the A record for loool.ro, remained only the A record for ns1.loool.ro and the namserver responds with the SOA record). Why doesn't answer if the A record is entered? – Zsigmond Szilveszter Jan 21 '15 at 17:01
  • @Zsigmond I can't help you with this unfortunately. Either the packet is never arriving at the nameserver (a security device blocking it maybe?), or the reply is not being routed properly back to the internet. No one on this site can help you troubleshoot that. Packet captures are highly recommended. – Andrew B Jan 21 '15 at 17:02
  • The packets is arriving as I mentioned in the question, the messages.log contains ns queries denied(if the allow-query is empty or localhost). Probably there must being a network issue, as you mentioned, that the reply is not being routed back properly. Thank you for the answer. – Zsigmond Szilveszter Jan 21 '15 at 17:29
  • I've captured the packets and I've appended to the question. Could you check out? – Zsigmond Szilveszter Jan 22 '15 at 20:37
  • Queries and replies for remote IPs are both using the same interface. Assuming that 82.79.24.76 is not an IP address that you own, I'd try to troubleshoot what is going on with packets leaving your network. To simplify things, make sure that the replies are exiting your network through the same device that is performing the DNAT to 10.10.10.100 on the way in. Beyond that, this has shifted scope from a DNS question to a "troubleshoot my network" question so unless you find a smoking gun I'm probably done. Sorry! – Andrew B Jan 23 '15 at 15:31

It looks like you are lacking the appropriate glue records at your registrar.

$ dig +trace loool.ro

; <<>> DiG 9.9.5 <<>> +trace loool.ro
;; global options: +cmd
.                       929     IN      NS      j.root-servers.net.
.                       929     IN      NS      m.root-servers.net.
.                       929     IN      NS      e.root-servers.net.
.                       929     IN      NS      f.root-servers.net.
.                       929     IN      NS      l.root-servers.net.
.                       929     IN      NS      g.root-servers.net.
.                       929     IN      NS      h.root-servers.net.
.                       929     IN      NS      k.root-servers.net.
.                       929     IN      NS      c.root-servers.net.
.                       929     IN      NS      a.root-servers.net.
.                       929     IN      NS      d.root-servers.net.
.                       929     IN      NS      i.root-servers.net.
.                       929     IN      NS      b.root-servers.net.
.                       929     IN      RRSIG   NS 8 0 518400 20150131050000 20150121040000 16665 . X95MjU0E0exFVnq9oEJBi/Dih/wwyDhI0NoJ10bj1jthr6kjVElQgZTH l9XepwZOzSWiTzBXrhiMCaAd4MBIiDpNVHl5r8P0BAiw7GfB2HAQkEcr WPTcJe9Y0JX6ruSbcD93gWbvd4/rHZXpgB13y6hWJNlY0zHuu7Iqv4h9 H8s=
;; Received 397 bytes from 8.8.8.8#53(8.8.8.8) in 1025 ms

ro.                     172800  IN      NS      dns-at.rotld.ro.
ro.                     172800  IN      NS      dns-ro.denic.de.
ro.                     172800  IN      NS      sns-pb.isc.org.
ro.                     172800  IN      NS      primary.rotld.ro.
ro.                     172800  IN      NS      sec-dns-a.rotld.ro.
ro.                     172800  IN      NS      sec-dns-b.rotld.ro.
ro.                     86400   IN      NSEC    rocks. NS RRSIG NSEC
ro.                     86400   IN      RRSIG   NSEC 8 1 86400 20150131050000 20150121040000 16665 . d0xAIZZ3+EiqsKePxYP/ym8OEvp4bywmHIUTSigk6CUie8512rpuvXM2 vAL5RRuXDdCCG/0nP4bfR6cz0dgN9lTLdJz68kd4nRYZcTsz5ZLZkQ1T zmyiKEzzRK7PAVUTTfMG94NrHzIIBwLTYdhOqHPWHN4TQC8NYf2hJlyQ CqI=
;; Received 613 bytes from 193.0.14.129#53(k.root-servers.net) in 1130 ms

loool.ro.               86400   IN      NS      ns1.loool.ro.
dig: couldn't get address for 'ns1.loool.ro': no more
  • If i make this, from a different host(it is in the same network with the server), I got the same result as you but with the following end: loool.ro. 0 IN NS ns1.loool.ro. ;; Received 71 bytes from 192.162.16.20#53(sec-dns-a.rotld.ro) in 88 ms loool.ro. 38400 IN A 86.34.156.51 loool.ro. 38400 IN NS ns1.loool.ro. loool.ro. 38400 IN NS loool.ro. ;; Received 101 bytes from 10.10.10.100#53(ns1.loool.ro) in 1 ms – Zsigmond Szilveszter Jan 21 '15 at 15:11
  • In addition, mxtoolbox can get the glue records – Zsigmond Szilveszter Jan 21 '15 at 15:16
  • The output of this trace is (understandably) misleading at first glance. Rerun it with +additional and you'll see the glue records. The failure being reported is +trace failing to perform that lookup against the local resolver. – Andrew B Jan 21 '15 at 16:17

iptables could be blocking the connection. Simply allow named through the firewall.

iptables -I INPUT 1 -p tcp -m tcp --dport 53 -m state --state NEW,ESTABLISHED -j ACCEPT
iptables -I INPUT 2 -p udp -m udp --dport 53 -m state --state NEW,ESTABLISHED -j ACCEPT

iptables -A OUTPUT -p tcp -m tcp --sport 53:65535 --dport 53 -m state --state NEW,ESTABLISHED -j ACCEPT
iptables -A OUTPUT -p udp -m udp --sport 53:65535 --dport 53 -m state --state NEW,ESTABLISHED -j ACCEPT

Your Answer

By clicking "Post Your Answer", you acknowledge that you have read our updated terms of service, privacy policy and cookie policy, and that your continued use of the website is subject to these policies.

Not the answer you're looking for? Browse other questions tagged or ask your own question.