Shot Names in BIND DNS take too Long

Question

I have Setup A Bind DNS , where I am trying to put an entry for resolving the short name. This get resolved but take too long and sometime the DNS times out. The short name is s3.ngsfdellpe

Entries from named.conf

options {
    listen-on port 53 { 127.0.0.1;10.209.194.15; };
    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-query {any;};
    allow-recursion {any;};
    //recursion no;

    //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";
};

logging {
        channel default_debug {
                file "data/named.run";
                severity dynamic;
        };
};

zone "." IN {
    type hint;
    file "named.ca";
};


zone"vxctf8500.com" IN {
type master;
file "forward.vxctf8500.com";
allow-update { none; };
};
zone"106.209.10.in-addr.arpa" IN {
type master;
file "reverse.vxctf8500.com";
allow-update { none; };
};

Forward zones Files ::

$TTL 1D
@   IN SOA ns1.vxctf8500.com. root.vxctf8500.com. (
                    0   ; serial
                    1D  ; refresh
                    1H  ; retry
                    1W  ; expire
                    3H )    ; minimum

       IN NS       vxctf8500.com.
       IN A     10.209.194.15



ns1   IN A 10.209.194.15

s3.ngsfdellpe   IN  A   10.209.106.59
s3.ngsfdellpe   IN  A   10.209.106.53
s3.ngsfdellpe   IN  A   10.209.106.54
s3.ngsfdellpe   IN  A   10.209.106.55
s3.ngsfdellpe   IN  A   10.209.106.56

Reverse zone files ::

$TTL 1D
@   IN SOA  ns1.vxctf8500.com. root.vxctf8500.com. (
                    0   ; serial
                    1D  ; refresh
                    1H  ; retry
                    1W  ; expire
                    3H )    ; minimum


                        IN NS   vxctf8500.com.
15                      IN PTR      ns1.vxctf8500.com.



59       IN PTR      s3.ngsfdellpe.
53       IN PTR      s3.ngsfdellpe.
54       IN PTR      s3.ngsfdellpe.
55       IN PTR      s3.ngsfdellpe.
56       IN PTR      s3.ngsfdellpe.

Answer 1

Can you give an example (command/ouput) of how you're trying to resolve the name, as well as the content of /etc/resolv.conf on the machine where you're testing this.

The trailing dot in reverse-zonefile states that the LHS name is a FQDN, but in fact it isn't, so your reverse entries should look like this instead:

59 IN PTR s3.ngsfdellpe.vxctf8500.com.

Resolving "short name" has nothing to do with how you configure the authoritative DNS it's just up to the client (e.g search or domain directive in /etc/resolv.conf on linux) how to handle this and append the suffix to the name prior to do the actual DNS-lookup.

Answer 2

As powo stated in his answer, this is more than likely an artifact of your /etc/resolv.conf configuration. The general rule is that the more search domains you have, the longer DNS lookups will take to fail when servers are unreachable.

Assuming the nss_dns module in glibc, the formula for maximum time to fail a lookup that does not end in . will look something like this:

(w+1)xyz

• w is the number of search domains defined. It's impossible to go below 1 unless the FQDN of the server has no domain component. (or you set the equivalent, domain .)
• x is timeout:x (default of 5), as defined in /etc/resolv.conf.
• y is attempts:y (default of 2), as defined in /etc/resolv.conf.
• z is the number of nameserver entries in /etc/resolv.conf that are not responding at the time of the DNS lookup. Only the first three entries are honored, so this is always a number between 0 and 3.

The preferred solution is making sure your DNS servers always respond, using a load balancer if necessary. In scenarios where this is not possible, it should be noted that the number of search domains (x) has an exponential impact on how long it takes your DNS lookups to fail.

---

(Yes, ndots will have an influence on this as well, but that's getting pedantic.)