17

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 ungl.org

; <<>> DiG 9.5.1-P2.1 <<>> ungl.org
;; 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

;; QUESTION SECTION:
;ungl.org.                      IN      A

;; ANSWER SECTION:
ungl.org.               38400   IN      A       188.165.34.72

;; AUTHORITY SECTION:
ungl.org.               38400   IN      NS      ns.kimsufi.com.
ungl.org.               38400   IN      NS      r29901.ovh.net.

;; ADDITIONAL SECTION:
ns.kimsufi.com.         85529   IN      A       213.186.33.199

;; Query time: 1 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; 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 @87.98.167.208 ungl.org

; <<>> DiG 9.5.1-P2.1 <<>> @87.98.167.208 ungl.org
; (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

;; QUESTION SECTION:
;ungl.org.                      IN      A

;; Query time: 1 msec
;; SERVER: 87.98.167.208#53(87.98.167.208)
;; WHEN: Sat Mar 13 01:01:35 2010
;; MSG SIZE  rcvd: 26

my zone file for this domain is

$ttl 38400
ungl.org.       IN  SOA r29901.ovh.net. mikey.aol.com. (
                201003121
                10800
                3600
                604800
                38400 )
ungl.org.       IN  NS  r29901.ovh.net.
ungl.org.       IN  NS  ns.kimsufi.com.
ungl.org.       IN  A   188.165.34.72
localhost.      IN  A   127.0.0.1
www             IN  A   188.165.34.72

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 http://www.kb.cert.org/vuls/id/800113

    // 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 {
    //  0.0.0.0;
    // };

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

named.conf.local:

//
// 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 "eugl.eu" {
         type master;
         file "/etc/bind/eugl.eu";
         notify no;
};


zone "ungl.org" {
         type master;
         file "/etc/bind/ungl.org";
         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!

thanks

8 Answers8

24

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.

w00t
  • 1,164
  • 3
  • 19
  • 35
5

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 { 127.0.0.1; };. You'll need to add the appropriate IP address in there.

John Gardeniers
  • 27,458
  • 12
  • 55
  • 109
  • I've changed this to the server's internet IP address (188.165.34.72) and reloaded bind but I'm still getting the same refused message –  Mar 13 '10 at 03:24
  • 1
    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 06:28
  • The URL seems to be working now, but still shows the same refused status from my other server –  Mar 13 '10 at 11:42
4

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

1

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.

ZaphodB
  • 673
  • 3
  • 10
1

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 @12.34.56.78 mydomain.com 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.

1

I had to enter an explicit reference for the network I wished to allow recursion. Specifying "any" did not help. By default (Umbutu Server 15) there was no entry for this in the /etc/bind/named.conf.options file.

recursion yes;  << needed to add this but did not resolve greater prob
allow-recursion { any; }; << this did not work
allow-recursion { 10.1.0.0/16; }; << this did the trick
HBruijn
  • 77,029
  • 24
  • 135
  • 201
Iradw
  • 11
  • 1
0

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

Your server on 188.165.34.72 (r29901.ovh.net) 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.

Alnitak
  • 21,191
  • 3
  • 52
  • 82
  • NOTIMPL is not implemented? Why would it have features that aren't implemented enabled by default? –  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 http://www.isc.org/software/bind/documentation/arm95 – 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
0

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;
j0k
  • 411
  • 9
  • 16