BIND - Redundant root server queries.

Discussion in 'General Server' started by Reggle, Nov 20, 2013.

  1. Reggle

    Reggle New Member

    Messages:
    4
    Likes Received:
    0
    Trophy Points:
    1
    Hi all,


    My first post on this forum. I'm Reggle from Belgium, and a beginner on Linux.

    The issue I'm having is with BIND (the DNS server on *nix).

    So I've got BIND9 running on a machine here and it's providing DNS for the subnet at home. Note that I don't have a registered domain so it's a .local. For the remaining of the internet I have forwarders defined. While everything works, I do see an occasional query for the root servers. Below output of tcpdump.

    Code:
    21:01:15.650751 IP 192.168.168.5.35724 > 8.8.8.8.53: 24004+ [1au] NS? . (28)
    21:01:15.670749 IP 8.8.8.8.53 > 192.168.168.5.35724: 24004$ 14/0/1 NS g.root-servers.net., NS c.root-servers.net., NS j.root-servers.net., NS i.root-servers.net., NS m.root-servers.net., NS b.root-servers.net., NS h.root-servers.net., NS e.root-servers.net., NS d.root-servers.net., NS a.root-servers.net., NS k.root-servers.net., NS l.root-servers.net., NS f.root-servers.net., RRSIG (397)
    This happens up to multiple times a minute. I do not see any A or AAAA queries for those root servers.

    I have a root.db file which was present in the BIND9 package which contains all root server NS, A and AAAA records and is up to date (verified). The named.conf contains the following zone, which is also verified to be working:
    Code:
    zone "." {
      type hint;
      file "/etc/bind/root.db";
    };
    I'm assuming correct syntax because BIND starts. I've made plenty of typo's in the last two weeks to see BIND fail on restart when the syntax isn't correct.
    My question: is this normal behaviour? I seem to be spamming upstream DNS servers with redundant queries. How can I change this?
  2. ryanvade

    ryanvade Administrator Staff Member Staff Writer

    Messages:
    1,567
    Likes Received:
    501
    Trophy Points:
    113
    Welcome.

    I am sorry that your issue has not been resolved at that other Networking forum...

    Honestly I am not a network anything. I focus on the kernel and other internals. Perhaps this manual will help?

    http://ftp.isc.org/isc/bind9/cur/9.9/doc/arm/Bv9ARM.pdf

    Is this phenomenon causing serious traffic?
  3. Reggle

    Reggle New Member

    Messages:
    4
    Likes Received:
    0
    Trophy Points:
    1
    Hi Ryan,

    That's the nicest RTFM I've ever got :)

    But thanks! I didn't find that guide using Google yet and some commands in it I've used to make optimize BIND.
    However, no solution for the issue yet. Could someone who has BIND running verify if they see the same thing?

    Best regards,

    Reggle
  4. Reggle

    Reggle New Member

    Messages:
    4
    Likes Received:
    0
    Trophy Points:
    1
    It stopped. I have no idea why. The 'issue' survived BIND restarts and even system reboots, but after using the dig tool for tracing NS records it stopped.
    Although I changed a for parameters and added a forward zone for one domain in the mean time, I'm sure that didn't help because I restarted BIND after it and saw the NS root queries at that time.
  5. Reggle

    Reggle New Member

    Messages:
    4
    Likes Received:
    0
    Trophy Points:
    1
    Bump of an old thread. Although I usually dislike people doing it, this is the only tread I can find by Googling and it's my own.

    One year later and the problem is still there. In fact it arrived again after a day but I didn't bother posting anymore.
    By now I've installed BIND9 on a second system (x64, the other was ARM-based) which has the same effects. And BIND9 has been updated as well. Clearly it's not version-specific but I still can't figure out what's wrong.

    For the unfortunate soul who finds this tread because of the same issue: I did find a partial workaround with iptables. The root query is an NS record with dot (.) for payload, which makes that it has a few unique bytes in the packet at a fixed offset. Using raw byte matching you can filter these out with minimum CPU penalty:

    iptables -A OUTPUT -p udp --dport 53 -m u32 --u32 "0x2a=0x2000100" -j DROP

    To know what it does in detail you can check the packets in tcpdump or Wireshark: at offset 42 (0x2a) it will match NS records (that first 2) of dot (the 00 after the 1)
    This stops the queries but will spam logging (/var/log/syslog) with alerts of unreachability. Still looking to /dev/null this. Any help with that would be appreciated as well :)

Share This Page