BIND 9.8.3-P4 doesn't resolve some domains

G

gnoma

Hello,

I have two DNS servers that worked for 3-4 years without any problems, I have updated them to FreeBSD 9.1 few months ago and still everything is OK.

A few days ago I found out that I am no longer able to resolve some domain names that I was able to resolve before. I didn't make any changes on the configuration or so. I updated the named.root file, but still not working.

Domains like speedy.bg, zamunda.net, addons.mozilla.org, planetunreal.com and so on.

I am able to resolve them from my home (another Bulgarian ISP, through their DNS servers), I am able to resolve them through the Google DNS servers, but not from my DNS servers.

Check this out:

Code: 
root@ns:/root # ping addons.mozilla.org

ping: cannot resolve addons.mozilla.org: Host name lookup failure
root@ns:/root #
root@ns:/root #
root@ns:/root # dig addons.mozilla.org +trace

; <<>> DiG 9.8.3-P4 <<>> addons.mozilla.org +trace
;; global options: +cmd
.                       506696  IN      NS      l.root-servers.net.
.                       506696  IN      NS      k.root-servers.net.
.                       506696  IN      NS      c.root-servers.net.
.                       506696  IN      NS      j.root-servers.net.
.                       506696  IN      NS      f.root-servers.net.
.                       506696  IN      NS      b.root-servers.net.
.                       506696  IN      NS      m.root-servers.net.
.                       506696  IN      NS      g.root-servers.net.
.                       506696  IN      NS      i.root-servers.net.
.                       506696  IN      NS      e.root-servers.net.
.                       506696  IN      NS      a.root-servers.net.
.                       506696  IN      NS      d.root-servers.net.
.                       506696  IN      NS      h.root-servers.net.
;; Received 512 bytes from 127.0.0.1#53(127.0.0.1) in 20 ms

org.                    172800  IN      NS      a2.org.afilias-nst.info.
org.                    172800  IN      NS      b0.org.afilias-nst.org.
org.                    172800  IN      NS      a0.org.afilias-nst.info.
org.                    172800  IN      NS      d0.org.afilias-nst.org.
org.                    172800  IN      NS      b2.org.afilias-nst.org.
org.                    172800  IN      NS      c0.org.afilias-nst.info.
;; Received 438 bytes from 198.41.0.4#53(198.41.0.4) in 1027 ms

mozilla.org.            86400   IN      NS      ns1.mozilla.org.
mozilla.org.            86400   IN      NS      ns2.mozilla.org.
mozilla.org.            86400   IN      NS      ns3.mozilla.org.
;; Received 138 bytes from 199.249.112.1#53(199.249.112.1) in 284 ms

addons.mozilla.org.     60      IN      CNAME   addons.dynect.mozilla.net.
;; Received 75 bytes from 63.245.212.5#53(63.245.212.5) in 38 ms

root@ns:/root #

Here at least I got quick response.

But here I got about 2-3 minutes delay before the last line of output:

Code: 
root@ns:/root # dig speedy.bg +trace

; <<>> DiG 9.8.3-P4 <<>> speedy.bg +trace
;; global options: +cmd
.                       506669  IN      NS      d.root-servers.net.
.                       506669  IN      NS      f.root-servers.net.
.                       506669  IN      NS      k.root-servers.net.
.                       506669  IN      NS      a.root-servers.net.
.                       506669  IN      NS      e.root-servers.net.
.                       506669  IN      NS      b.root-servers.net.
.                       506669  IN      NS      m.root-servers.net.
.                       506669  IN      NS      g.root-servers.net.
.                       506669  IN      NS      h.root-servers.net.
.                       506669  IN      NS      c.root-servers.net.
.                       506669  IN      NS      j.root-servers.net.
.                       506669  IN      NS      i.root-servers.net.
.                       506669  IN      NS      l.root-servers.net.
;; Received 512 bytes from 127.0.0.1#53(127.0.0.1) in 5 ms

bg.                     172800  IN      NS      ns-ext.isc.org.
bg.                     172800  IN      NS      ns3.register.bg.
bg.                     172800  IN      NS      ns.register.bg.
bg.                     172800  IN      NS      ns2.register.bg.
bg.                     172800  IN      NS      bg.cctld.authdns.ripe.net.
bg.                     172800  IN      NS      ns4.register.bg.


;; Received 438 bytes from 192.5.5.241#53(192.5.5.241) in 11162 ms

speedy.bg.              345600  IN      NS      ns5.mydyndns.org.
speedy.bg.              345600  IN      NS      ns1.mydyndns.org.
speedy.bg.              345600  IN      NS      ns4.mydyndns.org.
speedy.bg.              345600  IN      NS      ns3.mydyndns.org.
speedy.bg.              345600  IN      NS      ns2.mydyndns.org.
dig: couldn't get address for 'ns5.mydyndns.org': no more
root@ns:/root #
And probably the reason is this:
Code: 
root@ns:/root # nslookup ns5.mydyndns.org
;; connection timed out; no servers could be reached

root@ns:/root #

But how can that be? I can resolve most of the domains in internet without problem, could it be my configuration error, or something that I need to update, or it is probably related to my ISP?

Thank you.
 
Aloha,

/etc/resolv.conf:
Code: 
nameserver 127.0.0.1
nameserver xx.xx.xx.xx # IP address of the other name server

So both DNS servers resolve from localhost and ns1 resolves also form ns2, ns2 resolves from localhost and ns1.

When I put in the /etc/resolv.conf the DNS servers of Google, or my home ISP's DNS servers, I got normal resolve. But all my local networks and workstations are configured to resolve from my DNS servers. This way even if I put the Google DNS servers in /etc/resolv.conf of my DNS servers and they are able to resolve the problem domains, all my workstations in my local networks are still unable to resolve them.
 
Without direct access to your configuration for troubleshooting, I am just going to ramble about what *should* be happening and perhaps if we kick it around a bit something will turn up.

:D

In your particular case, if at the command line, you ask it to resolve ns5.mydyndns.org, the resolver will look to see who is the first nameserver in /etc/resolv.conf:
Code: 
nameserver 127.0.0.1
and ask it for resolution. It goes to that file unconditionally and it is up to the nameservers listed in the file to resolve the FQDN. Again, this is completely a local operation.

Because you are running a DNS server locally, the resolver does not need to talk to an additional "nameserver" in /etc/resolv.conf *if* the configuration of forwarders in /var/named/etc/namedb/named.conf has been done correctly.

Use of a forwarder option in /var/named/etc/namedb/named.conf has a bearing on all queries given to a nameserver regardless of the source because it effects the DNS server and not the client. It also allows for queries to be resolved from a cache so that repeated queries for the same information can be processed more quickly and with no further network access.

Ideally, if one is operating a DNS locally, /etc/resolv.conf only needs to contain one entry:
Code: 
nameserver 127.0.0.1
and your /var/named/etc/namedb/named.conf will contain DNS servers that your DNS server will talk to for questions it cannot answer:
Code: 
// If you've got a DNS server around at your upstream provider, enter
// its IP address here, and enable the line below.  This will make you
// benefit from its cache, thus reduce overall DNS traffic in the Internet.

        forwarders {
                1.1.1.1;2.2.2.2;
        };

Alternatively, /var/named/etc/namedb/named.conf contains comments that detail how to use a populated /etc/resolv.conf file to retrieve forwarding DNS information.

My thoughts are that after you get local DNS resolution working correctly at the command line, the hosts on your network will start working correctly as well auto-magically. If you are running a firewall, it would not hurt to double-check your configurations to make sure that you are not somehow enforcing a "5 monkey" rule somewhere. Even though these errors do not feel like a firewall is stirring the pot .. ya never know.

:P

Hope that helps!
 
Hello johnblue,

I didn't do any changes to my firewall and it should not be a problem to resolve some domains, but not resolve some other domains because my firewall probably doesn't even know what is domain :D it's got only interfaces and local IPs in the configuration file.
Anyway, I turned it off just in case:

Code: 
root@ns:/root # nslookup speedy.bg
x;; connection timed out; no servers could be reached

root@ns:/root #
root@ns:/root # /etc/rc.d/pf stop
Disabling pf.
root@ns:/root #
root@ns:/root # nslookup speedy.bg
x;; connection timed out; no servers could be reached

root@ns:/root #
Then I started the PF back, as you can see, it's not the firewall.

About the /var/named/etc/namedb/named.conf, I got no forwarders listed there, but it have never been a problem before. And how does this affect only few certain domains, but don't affect all others? If it's really necessary, I can put forwarders my ISP's DNS servers and probably it will work, but the question remains: why my own DNS servers themselves can't resolve these domains? I am sure that if I put a forwarder DNS servers, it will work just like I can resolve through them if I put them if listed in /etc/resolv.conf.

This is the config file of my 1st DNS server:
Code: 
key rndc-key {
        algorithm hmac-md5;
        secret "..........."; # some secret
        };
controls {
        inet 127.0.0.1 port 953 allow { 127.0.0.1; } keys { rndc-key; };
        };

acl "trusted" {
        127.0.0.1; ..............   ### And some other IPs...
};

options {
        directory       "/etc/namedb/";
#        allow-recursion { any; };
        pid-file        "/var/run/named/pid";
        dump-file       "/var/dump/named_dump.db";
        statistics-file "/var/stats/named.stats";
        version         "My Company Primary DNS Server";
        listen-on       { 127.0.0.1; 192.168.10.5; xx.xx.xx.xx;}; ### xx = Internet IP
        hostname        "ns.mydomain.bg";
        query-source address * port 53;
        empty-zones-enable no;
};

zone "." {
        type hint;

        file "named.root";
};

zone "0.0.127.IN-ADDR.ARPA" {
        type master;
       file "master/localhost.rev";
};
zone "myzone.lan"{
        type master;
        file "master/db.myzone.lan"; ## This one should be resolvable only from my local nets
};

zone "samezone.com"{
        type master;
        file "master/db.samezone.com"; ## This should be the real Internet zone file
};
##### And some other zones are below, listed with the same syntax...
And also the file /etc/rc.conf
Code: 
root@ns:/root # cat /etc/rc.conf | grep -i named
named_enable="YES"
named_program="/usr/sbin/named"
named_flags="-u bind"
named_chrootdir="/var/named"
named_chroot_autoupdate="YES"
named_symlink_enable="YES"

This should give you the information you need. I guess I'll put the forwarders there and solve the issue tomorrow and probably it will work even better this way. But I really wanted to find the root cause of this issue.

Thank you.
 
Hello,

I commented this line:
Code: 
query-source address * port 53;
Then I was just going to configure the logging feature, but I tried once again to nslookup one of the problem domains. It worked this time. I don't know how and why, but it probably have something to do with the query-source address port. I went on the second DNS server where that line was not commented yet, tried to nslookup the same domain and it failed. At the moment I removed the line, everything start working normal again. Do you have any idea why and how this stuff works?

I'll add forwarders anyway, thank you for the help.
 
Glad you got it solved.

You would have to use for example tcpdump(8) to really see what is going on when port 53 is used as the source port. My guess is that some authoritative name servers do not like queries that originate from port 53.
 
You must log in or register to reply here.
Back
Top