Server Fault is a question and answer site for system and network administrators. It's 100% free, no registration required.

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I can't seem to work out why my DNS isn't working properly, if I run dig from the nameserver it functions correctly:

# dig

; <<>> DiG 9.5.1-P2.1 <<>>
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 24585
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 1

;                      IN      A

;; ANSWER SECTION:               38400   IN      A

;; AUTHORITY SECTION:               38400   IN      NS               38400   IN      NS

;; ADDITIONAL SECTION:         85529   IN      A

;; Query time: 1 msec
;; WHEN: Sat Mar 13 01:04:06 2010
;; MSG SIZE  rcvd: 114

but when I run it from another server in the same datacenter I receive:

# dig @

; <<>> DiG 9.5.1-P2.1 <<>> @
; (1 server found)
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: REFUSED, id: 18787
;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0
;; WARNING: recursion requested but not available

;                      IN      A

;; Query time: 1 msec
;; WHEN: Sat Mar 13 01:01:35 2010
;; MSG SIZE  rcvd: 26

my zone file for this domain is

$ttl 38400       IN  SOA (
                38400 )       IN  NS       IN  NS       IN  A
localhost.      IN  A
www             IN  A

and the named.conf.options is default:

options {
    directory "/var/cache/bind";

    // If there is a firewall between you and nameservers you want
    // to talk to, you may need to fix the firewall to allow multiple
    // ports to talk.  See

    // If your ISP provided one or more IP addresses for stable 
    // nameservers, you probably want to use them as forwarders.  
    // Uncomment the following block, and insert the addresses replacing 
    // the all-0's placeholder.

    // forwarders {
    // };

    auth-nxdomain no;    # conform to RFC1035
    listen-on-v6 { ::1; };
    listen-on {; };
    allow-recursion {; };


// Do any local configuration here

// Consider adding the 1918 zones here, if they are not used in your
// organization
// include "/etc/bind/zones.rfc1918";

zone "" {
         type master;
         file "/etc/bind/";
         notify no;

zone "" {
         type master;
         file "/etc/bind/";
         notify no;

The server is running Ubuntu 9.10 and Bind 9, if anyone can shed some light on this for me it'd make me very happy!


share|improve this question
What does your "options" section of the bind config look like on the server that isn't behaving? By default on ubuntu I believe it is all in /etc/bind/named.conf.options – Cory J Mar 13 '10 at 0:13
I've updated the question, I've not changed anything in the options yet – Mikey Mar 13 '10 at 0:20
How about the zone definition in named.conf.local? – ktower Mar 13 '10 at 3:49
Added to the main post – Mikey Mar 13 '10 at 11:43

although I may be digging up an old thread, I'm doing so because this is one of the most relevant results while doing a google search for "query status refused".

In my particular case, I found that I had to include allow-query { any; }; in each zone definition in named.conf.

share|improve this answer

Just at a quick glance it appears to me that it's not configured to listen to the rest of the world due to listen-on {; };. You'll need to add the appropriate IP address in there.

share|improve this answer
I've changed this to the server's internet IP address ( and reloaded bind but I'm still getting the same refused message – Mikey Mar 13 '10 at 3:24
Is there a local firewall on that machine? You may need to open the ports (53 TCP and UDP). – John Gardeniers Mar 13 '10 at 6:28
The URL seems to be working now, but still shows the same refused status from my other server – Mikey Mar 13 '10 at 11:42

I do the samething but I put allow-query option in named.conf.options

share|improve this answer

I had exactly the same problem (dig status NOERROR locally, dig status REFUSED from the outside), and the solution was changing the match-clients from "localhost" (which is the default for bind install) to "any" (later I may find out what the exact ip of my domain name provider is and restrict it to that specific ip for security reasons). Also, I changed the view name from local_something to default. The name really doesn't matter.

view default {
        match-clients      { any; };
        match-destinations { any; };
        include "/etc/named.rfc1912.zones";

That was really the issue with this "dig status refused" business. Right after I changed the match-clients parameter, my dig @ queries started to resolve with NOERROR status, and the domain name provider (godaddy) immediately cached the nameserver record. Since my zone files were already properly configured, the domain name instantly became visible on the internet.

I was banging my head against the wall for quite a while to solve this one, though.

share|improve this answer
Could you clarify, which file on which computer did you modify? – Alexey May 6 '15 at 5:31

Are you sure you're sending the queries to the right place?

Your server on ( is running BIND 9.5.1-P2.1 - it answers a query for dig @ip version.bind ch txt as expected with that response string.

However the IP address you quoted above returns a NOTIMPL error, even though there's nothing in your quoted config file about the *.bind pseudo-records and BIND requires explicit configuration to disable them.

share|improve this answer
NOTIMPL is not implemented? Why would it have features that aren't implemented enabled by default? – Mikey Mar 13 '10 at 15:36
If it's BIND, there's an option called "version" which tells it to send a user-specified value to that query, or "none" to disable the feature. If the option is unspecified, it returns the actual version number. You've quoted no such option, which makes me suspect you're not talking to the right server. See – Alnitak Mar 13 '10 at 22:33
I've checked further - on my MacOSX box with bind 9.6.0, setting "version" to "none" returns NOERROR and not the NOTIMPL error I'm seeing from that IP. – Alnitak Mar 13 '10 at 23:14

NOERROR when it is not accompanied by a resource record (RR) means that there is no such record, so when you get a NOERROR response and no 'record' upon setting "version" to "none" then it is working as expected.

There also is an allow-query configuration statement with BIND9 however i think the default is to allow queries from anywhere.

share|improve this answer

Because you permit the recursion only from your local machine.

If you want to permit add the appropriate ip address and you need to change listen on value to any adapter from your local machine or put the ip address of the interface of the local machine:

listen-on { any;} or x.x.x.x;
share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.