1

I have set up a Bind9 DNS server on my development VM which is running Debian Wheezy. My addresses resolve from my host machine (Win7) to my dev VM, and I can ping from there. Internally on the VM, I can ping my names (www, share, my_name, etc.) and it resolves to the correct ip (11.11.11.11). But when I ping my full FDQN (www.app.dev), it resolves to localhost. This is not true for my_name.app.dev, only the CNAME entries in my db.app.dev file in my /etc/bind/ folder. So if I ping www, resolves to 11.11.11.11, www.app.dev resolves to 127.0.0.1. Pinging www.app.dev or just www from outside the DNS VM resolves fine. Is this expected behavior or am I missing something?

Here are the files I think you want. I added resolv.conf in case there's something wrong there.

/etc/bind/zones/db.app.dev

$TTL    604800
@   IN  SOA app.dev. root.app.dev. (
                 15     ; Serial
             604800     ; Refresh
              86400     ; Retry
            2419200     ; Expire
             604800 )   ; Negative Cache TTL
;

app.dev.   IN NS my_name.app.dev.
app.dev.   IN A 11.11.11.11
;@  IN  A   127.0.0.1
;@  IN  AAAA    ::1
my_name     IN A 11.11.11.11
gateway     IN A 11.11.11.2
vmhost      IN A 11.11.11.1
www         IN CNAME app.dev.
stream      IN CNAME app.dev.

/etc/bind/named.conf.local

include "/etc/bind/zones.rfc1918";

zone "app.dev" {
    type master;
    file "/etc/bind/zones/db.app.dev";
};

zone "11.11.11.in-addr.arpa" {
    type master;
    file "/etc/bind/zones/db.11";
};

/etc/resolv.conf

domain app.dev
search app.dev
nameserver 11.11.11.11

Here is the hosts file /etc/hosts

127.0.0.1                       localhost
11.11.11.11 my_name.app.dev     my_name

# The following lines are desirable for IPv6 capable hosts
#::1     localhost ip6-localhost ip6-loopback
#ff02::1 ip6-allnodes
#ff02::2 ip6-allrouters

dig provided: dig www.app.dev any #=>

; <<>> DiG 9.8.4-rpz2+rl005.12-P1 <<>> www.app.dev any
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 51223
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 1

;; QUESTION SECTION:
;www.app.dev.           IN  ANY

;; ANSWER SECTION:
www.app.dev.        604800  IN  CNAME   app.dev.


;; AUTHORITY SECTION:
app.dev.        604800  IN  NS  my_name.app.dev.

;; ADDITIONAL SECTION:
my_name.app.dev.        604800  IN  A   11.11.11.11

;; Query time: 2 msec
;; SERVER: 11.11.11.11#53(11.11.11.11)
;; WHEN: Wed Aug 13 12:48:15 2014
;; MSG SIZE  rcvd: 78

here is the ping: ping www.app.dev

PING www.app.dev (127.0.0.1) 56(84) bytes of data.
64 bytes from localhost (127.0.0.1): icmp_req=1 ttl=64 time=0.035 ms
64 bytes from localhost (127.0.0.1): icmp_req=2 ttl=64 time=0.032 ms
64 bytes from localhost (127.0.0.1): icmp_req=3 ttl=64 time=0.038 ms
^C
--- www.app.dev ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2000ms
rtt min/avg/max/mdev = 0.032/0.035/0.038/0.002 ms
  • how is bind configured? Master, slave, or simply replication? If it's not just replication; can you post a copy of the zone file (sanitized)? – ericx Aug 13 '14 at 15:42
  • @ericx, I'm not sure what the differences are but here are the files – paulski Aug 13 '14 at 15:56
  • Can you include dig output that shows the problem? – Håkan Lindqvist Aug 13 '14 at 17:08
  • As @HåkanLindqvist has suggested, a dig would be helpful. I have suggestions; but since I can't format in a comment, they appear below. – ericx Aug 13 '14 at 17:42
  • @pdom without ANY would have been more helpful, that would match the actual query that would be happening (and we would get to see the A record as well). – Håkan Lindqvist Aug 13 '14 at 18:05
0

if you have www setup as your machine hostname in your hosts file (/etc/hosts), it will resolve there first from the local machine (hosts is checked before the resolvers you have setup). Check your hosts file...

  • I added the hosts file. I guess that explains why the my_name.app.dev ping resolves correctly. Does that mean that the other ip resolutions ARE expected behavior, or is something not configured correctly? – paulski Aug 13 '14 at 16:08
  • They are not expected behavior. Your dig gives the correct result but ping picks the loopback IP address incorrectly. Perhaps it has cached the result from earlier when you had an entry in /etc/hosts pointing to the loopback address? Reboot and try again :) – Tommiie Sep 4 '18 at 11:45
0

I forget where isc-bind defaults its logs to; so consider the following addition to your named.conf. This is the logging config I've used for the last 10 years or so. It is probably a bit excessive; but it shouldn't miss anything. I'm running on FreeBSD; so the location of the logs may not be perfect. You will also have to create the namedb subdirectory and make it writable by BIND (in my case that is bind:wheel 755). After you are sure you have good logging (you may already), grep for error in /var/log/namedb/general.

You are doing this to be sure that named is happy with your configuration.

(I actually have all this in a file called named.logs and I copy it around and include it. Contents haven't changed since the introduction of ver. 9 removed the "statistics" category.)

logging {
    channel "default_debug" {
    file "/var/log/named.run";  // Redefine the built-in debug
                    // channel; so named.run is
                    // written to a consistent location
    severity dynamic;       // log at the server's
                    // current debug level
    };
    channel "default" {
    file        "/var/log/default" versions 3 size 100k;
    severity    debug;
    //severity  debug 3;
    print-category  yes;
    print-severity  yes;
    print-time  yes;
    };
    channel "general" {
    file        "/var/log/general" versions 3 size 100k;
    severity    debug;
    print-category  yes;
    print-severity  yes;
    print-time  yes;
    };
    channel "database" {
    file        "/var/log/database" versions 3 size 100k;
    severity    debug;
    print-category  yes;
    print-severity  yes;
    print-time  yes;
    };
    channel "security" {
    file        "/var/log/security" versions 3 size 100k;
    severity    debug;
    print-category  yes;
    print-severity  yes;
    print-time  yes;
    };
    channel "resolver" {
    file        "/var/log/resolver" versions 3 size 100k;
    severity    debug;
    print-category  yes;
    print-severity  yes;
    print-time  yes;
    };
    channel "xfer" {
    file        "/var/log/xfer" versions 3 size 100k;
    severity    debug;
    print-category  yes;
    print-severity  yes;
    print-time  yes;
    };
    channel "notify" {
    file        "/var/log/notify" versions 3 size 100k;
    severity    debug;
    print-category  yes;
    print-severity  yes;
    print-time  yes;
    };
    channel "client" {
    file        "/var/log/client" versions 3 size 100k;
    severity    debug;
    print-category  yes;
    print-severity  yes;
    print-time  yes;
    };
    channel "unmatched" {
    file        "/var/log/unmatched" versions 3 size 100k;
    severity    debug;
    print-category  yes;
    print-severity  yes;
    print-time  yes;
    };
    channel "network" {
    file        "/var/log/network" versions 3 size 100k;
    severity    debug;
    print-category  yes;
    print-severity  yes;
    print-time  yes;
    };
    channel "update" {
    file        "/var/log/update" versions 3 size 100k;
    severity    debug;
    print-category  yes;
    print-severity  yes;
    print-time  yes;
    };
    channel "queries" {
    file        "/var/log/query.log" versions 3 size 5m;
    //severity  debug;
    //print-category    yes;
    //print-severity    yes;
    print-time  yes;
    };
    channel "dispatch" {
    file        "/var/log/dispatch" versions 3 size 100k;
    severity    debug;
    print-category  yes;
    print-severity  yes;
    print-time  yes;
    };
    channel "dnssec" {
    file        "/var/log/dnssec" versions 3 size 100k;
    severity    debug;
    print-category  yes;
    print-severity  yes;
    print-time  yes;
    };
    channel "lame-servers" {
    file        "/var/log/lamoes" versions 3 size 100k;
    severity    debug;
    print-category  yes;
    print-severity  yes;
    print-time  yes;
    };
    channel "statistics" {
    // This is for cricket
    file        "/var/log/stats.log" versions 3 size 1k;
    };

    category "default"      { "default"; };
    category "general"      { "general"; };
    category "database"     { "database"; };
    category "security"     { "security"; };
    category "config"       { "general"; };
    category "resolver"     { "resolver"; };
    category "xfer-in"      { "xfer"; };
    category "xfer-out"     { "xfer"; };
    category "notify"       { "notify"; };
    category "client"       { "client"; };
    category "unmatched"    { "unmatched"; };
    category "network"      { "network"; };
    category "update"       { "update"; };
    category "queries"      { "queries"; };
    category "dispatch"     { "dispatch"; };
    category "dnssec"       { "dnssec"; };
    category "lame-servers" { "lame-servers"; };
//    category "statistics" { "statistics"; };
};

If it is clear that named is running without errors, you need to do some dig's (as requested by @Håkan Lindqvist to see specifically what is being reported. e.g.:

dig @127.0.0.1 my_name.app.dev.
dig @11.11.11.11 my_name.app.dev.

Windows doesn't have dig; so you are limited to the deprecated nslookup and will (I believe) have to use the interactive mode. Specify various "servers" and query "my_name.app.dev."

Please let us know what you see.

  • Windows doesn't ship with dig but there's nothing stopping you from using dig on Windows. The Windows builds of BIND include dig.exe isc.org/downloads – Håkan Lindqvist Aug 13 '14 at 18:19
  • @HåkanLindqvist true – ericx Aug 13 '14 at 18:28

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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