4

I'm trying to setup my first BIND9 DNS server for a small local network and can't seem to get it working. I want to create a 'local' domain of max.app

As far as I can tell named is running, but it doesn't seem to be serving my domain records?

service named start

Returns OK, and the demon is running on boot.

If I try and ping mac1 I get: unknown host mac1

If I try and ping mac1.max.app I get: unknown host mac1

When I try nslookup I get:

nslookup max.app
Server: 8.8.8.8
Address:    8.8.8.8#53

Non-authoritative answer:
Name:   max.app
Address: 67.192.47.244

As you can see I'm not serving records from my local bind service (192.168.100.10)

My /etc/resolv.conf file looks like this:

# Generated by NetworkManager
search max.app
nameserver 192.168.100.10
nameserver 8.8.8.8
nameserver 8.8.4.4

My /etc/named.conf file looks like this:

acl local-network { 192.168.100.0/24;  }; 

options {
    listen-on port 53 { 127.0.0.1; 192.168.100.10; };
    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     { local-network;  };
    recursion yes;

    query-source address * port 53;

    dnssec-enable yes;
    dnssec-validation yes;
    dnssec-lookaside auto;

    /* Path to ISC DLV key */
    bindkeys-file "/etc/named.iscdlv.key";
};


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


zone "max.app" IN {   
    type master;   
    file "max.app.zone";   
    allow-update { none; }; 
};

zone "100.168.192.in-addr.arpa" IN {
    type master;   
    file "max.app.rr.zone";   
    allow-update { none; }; 
};

My /var/named/max.app.zone file looks like this:

$ORIGIN max.app. 
$TTL 86400 
@   IN  SOA dns1.max.app.   email.gmail.com. (
            2001062501 ; serial                     
            21600      ; refresh after 6 hours                     
            3600       ; retry after 1 hour                     
            604800     ; expire after 1 week                     
            86400 )    ; minimum TTL of 1 day  


    IN  NS  dns1.max.app.   

dns1    IN  A   192.168.100.10
CentOS1 IN  A   192.168.100.15
CentOS2 IN  A   192.168.100.25

mac1    IN  A   192.168.100.50
mac2    IN  A   192.168.100.55
mac3    IN  A   192.168.100.60

www     IN  CNAME   CentOS1

My /var/named/max.app.rr.zone file looks like this:

$ORIGIN 100.168.192.in-addr.arpa. 
$TTL 86400 
@   IN  SOA dns1.max.app.   email.gmail.com. (
            2001062501 ; serial                     
            21600      ; refresh after 6 hours                     
            3600       ; retry after 1 hour                     
            604800     ; expire after 1 week                     
            86400 )    ; minimum TTL of 1 day           

    IN  NS  dns1.max.app.

10  IN  PTR dns1.max.app.
15  IN  PTR CentOS1.max.app.
20  IN  PTR CentOS2.max.app.

50  IN  PTR mac1.max.app.
55  IN  PTR mac1.max.app.
60  IN  PTR mac1.max.app.

Service named status returns:

version: 9.7.0-P2-RedHat-9.7.0-5.P2.el6_0.1
CPUs found: 2
worker threads: 2
number of zones: 15
debug level: 0
xfers running: 0
xfers deferred: 0
soa queries in progress: 0
query logging is OFF
recursive clients: 0/0/1000
tcp clients: 0/100
server is up and running
named (pid  1121) is running.

This "number of zones: 15" seems a bit odd? When I only have 1 zone defined in named.conf

UPDATE 7/14 5:45PM CST

Ok I've followed the suggestions below but things still don't seem to want to work.

Added to /etc/sysconfig/iptables

-A RH-Firewall-1-INPUT -p udp -m udp --dport 53 -j ACCEPT
-A RH-Firewall-1-INPUT -p tcp -m tcp --dport 53 -j ACCEPT

dig @192.168.100.10 mac1.max.app a returns:

; <<>> DiG 9.6.0-APPLE-P2 <<>> @192.168.100.10 mac1.max.app a
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 48036
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 1

;; QUESTION SECTION:
;mac1.max.app.      IN  A

;; ANSWER SECTION:
mac1.max.app.   86400   IN  A   192.168.100.15

;; AUTHORITY SECTION:
max.app.        86400   IN  NS  dns1.max.app.

;; ADDITIONAL SECTION:
dns1.max.app.       86400   IN  A   192.168.100.10

;; Query time: 8 msec
;; SERVER: 192.168.100.10#53(192.168.100.10)
;; WHEN: Thu Jul 14 17:30:53 2011
;; MSG SIZE  rcvd: 85

dig @192.168.100.10 mac1.max.app ns returns

; <<>> DiG 9.6.0-APPLE-P2 <<>> @192.168.100.10 mac1.max.app ns ; (1 server found) ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 28099 ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0

;; QUESTION SECTION: ;mac1.max.app. IN NS

;; AUTHORITY SECTION: max.app. 86400 IN SOA dns1.max.app. email.gmail.com. 2001062501 21600 3600 604800 86400

;; Query time: 8 msec ;; SERVER: 192.168.100.10#53(192.168.100.10) ;; WHEN: Thu Jul 14 17:18:23 2011 ;; MSG SIZE rcvd: 94

nslookup show that named is listing on port 53

tcp   0   0 dns1:53                    *:*   LISTEN   2880/named
tcp   0   0 localhost.localdomain:53   *:*   LISTEN   2880/named
Nick Faraday
  • 149
  • 1
  • 3
  • Are you doing the pinging from the nameserver, or from some other machine? I would try adding the following to your resolv.conf: nameserver localhost – David W Jul 11 '11 at 23:31
  • Ya I'm on the DNS box. I tried swapping out the IP address for localhost in the resolv.conf file... no luck. – Nick Faraday Jul 11 '11 at 23:50
  • 2
    Don't hijack other people's domains; it's causing you problems now, and it'll only cause further hassle in the future. – womble Jul 11 '11 at 23:52
  • @womble how is it causing problems now? I really don't think that has anything to do with the current problem. Its on a local network that myself and one other dude use, hijacking is a bit harsh. – Nick Faraday Jul 12 '11 at 00:00
  • 1
    Well, you already can't be sure that the answers you're getting are your own; down the line, if you want to access the legitimate `max.com` you'll be SOL. There are already domains available specifically for this purpose (`.local`). "Hijacking" is the correct term for what you're doing. – womble Jul 12 '11 at 05:07
  • sorry to throw in a 'me too', but womble is correct. it's simply bad practice to use a domain for which you do not have proper authority. use max.local - or max.coom, or max.comm or max.company, or max.nickfaraday or max.x or whatever suits your fancy. there simply is no valid reason to use someone else's domain for this experiment. as has been confirmed by the courts, a domain name is tangible, fungible *property*. regardless of your intentions (which make no mistake, i presume to be good), you're using someone else's property without authority if you use max.com. and besides all that, as wom – anastrophe Jul 12 '11 at 18:06
  • 1
    Fair enough... I've changed the TDL to .app and have made the changes to the question above. So now the domain reads [max.app] same issue persists. – Nick Faraday Jul 13 '11 at 18:58
  • That is not the `dig` command that `Cakemox` specified. – JdeBP Jul 25 '11 at 10:01
  • Just because .app doesn't conflict with an assigned TLD now, don't mean that it never will (https://en.wikipedia.org/wiki/Generic_top-level_domain). Also .local is defined for use with multicast DNS (https://en.wikipedia.org/wiki/.local). There is currently no TLD reserved for private use. See https://serverfault.com/questions/17255/top-level-domain-domain-suffix-for-private-network and use your own real domain. – neirbowj Jun 18 '16 at 21:37
  • ". I've changed the TDL to .app" Not a good idea. `.app` is now in IANA root, handled by Google. So it is a live **TLD**. Don't hijack any random string and expect it it will remain unique. This probably has an easy solution: use designated TLDs (`.example`, `.test`, `.invalid`) for tests and for live do this: create a domain, anyone in any TLD, so it exists, and use it as suffix of all your internal needs. This is futureproof. – Patrick Mevzek Jul 29 '22 at 22:08
  • In general it is a bad idea to use bind as both recursive and authoritative at the same time. You will suffer endless stream of problems. – Patrick Mevzek Jul 29 '22 at 22:12

3 Answers3

2

Some suggestions:

Remove the two google nameservers from your resolv.conf. Your nameserver is failing, but you're not getting much useful information because nslookup is falling through to the next nameserver.

Use dig instead if nslookup. The status response from dig is helpful in troubleshooting.

dig @192.168.100.10 mac1.max.app. a
dig @192.168.100.10 max.app. ns

Make sure you check your logs to see if your zone is actually loading.

Check netstat to make sure named is listening on port 53 of the appropriate interface.

Cakemox
  • 24,141
  • 6
  • 41
  • 67
0

Even if far after the battle, my tips for troubleshooting things like that are quite simple:

  • use named-checkzone to double check validity of your zonefile(s)
  • use named-checkconf to double check validity of your bind configuration file
  • increase logging in it
  • do queries with dig + @ flag to direct traffic precisely to the server, and assess the replies plus what happens in the logfiles.

But in short the MAJOR things NOT TO DO (so to stop doing before even trying to solve problems):

  • hijack any currently existing or random name/TLD and pretend it will never create collision; this is wrong way to see the problem
  • use same bind as both authoritative and recursive

As for this specific case, the dig given at the end is PERFECTLY normal and EXACTLY what expected.

The request was "mac1.max.app ns" (note the record type of "ns" being asked) towards a nameserver that ought to be authoritative on zone max.app.

Since that name mac1.max.app does NOT have NS records, but only one A record, the nameserver has to answer:

  • with a return code of NOERROR because the name exists
  • with no content in ANSWER section because, indeed, there are no NS records for mac1.max.app
  • but since it is authoritative on max.app, it gives in AUTHORITATIVE section the SOA record of the zone in which the record is, which is indeed max.app.

It is easy to reproduce the same thing with any given name, let us try with www.nic.app (showing the danger as outlined in comments above to use any arbitrary name, as .app was awarded to Google and hence is now a completely valid and public TLD) which certainly should have A record and others but no NS records (things would be different if the name has a CNAME record)

  1. Authoritative nameservers for nic.app:
$ dig NS nic.app +short
ns2.google.com.
ns4.google.com.
ns3.google.com.
ns1.google.com.
  1. Asking any of them for our query:
$ dig NS www.nic.app @ns3.google.com.

; <<>> DiG 9.18.4 <<>> NS www.nic.app @ns3.google.com.
;; global options: +cmd
;; Sending:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 355
;; flags: rd ad; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
; COOKIE: 198fd01a7c794358
;; QUESTION SECTION:
;www.nic.app.       IN NS

;; QUERY SIZE: 52

;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 355
;; flags: qr aa rd; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1
;; WARNING: recursion requested but not available

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512
;; QUESTION SECTION:
;www.nic.app.       IN NS

;; AUTHORITY SECTION:
nic.app.        1m IN SOA ns1.google.com. dns-admin.google.com. (
                463794447  ; serial
                900        ; refresh (15 minutes)
                900        ; retry (15 minutes)
                1800       ; expire (30 minutes)
                60         ; minimum (1 minute)
                )

;; Query time: 54 msec
;; SERVER: 216.239.36.10#53(ns3.google.com.) (UDP)
;; WHEN: Fri Jul 29 17:32:06 EST 2022
;; MSG SIZE  rcvd: 100

As expected, and per design of the DNS protocol:

  • NOERROR return code, as the name exist, but not that type
  • hence no content in ANSWER section as no NS records on that name
  • but SOA record in AUTHORITY section to show the "start" (highest level/closest to root) of the zone in which the record we query for exists

As such there is really nothing to troubleshoot in this question, things are working as designed, if not as expected, but to answer that there would need more details on the expectations. Or just trying queries for the A record type and not the NS one.

Patrick Mevzek
  • 9,273
  • 7
  • 29
  • 42
0

Your named is configured to listen on 127.0.0.1 and ::1 but your hosts resolve.conf says to ask on 192.168.100.10 try changing your listen-on directive to

listen-on {
    127.0.0.1;
    192.168.100.10;
    };

Also check that your firewall is allowing connections on port 53. I have the following lines in my /etc/sysconfig/iptables to do this

-A RH-Firewall-1-INPUT -p udp -m udp --dport 53 -j ACCEPT
-A RH-Firewall-1-INPUT -p tcp -m tcp --dport 53 -j ACCEPT
user9517
  • 114,104
  • 20
  • 206
  • 289