LinuxQuestions.org - BIND refuses queries... stumped as to why

- Linux - Server (https://www.linuxquestions.org/questions/linux-server-73/)

- - BIND refuses queries... stumped as to why (https://www.linuxquestions.org/questions/linux-server-73/bind-refuses-queries-stumped-as-to-why-789332/)

nnbnbnnbnn

02-15-2010 05:53 PM

BIND refuses queries... stumped as to why

Greetings all, you will excuse my newbie account as it seems I can't get the forum to recover my account password.

At any rate, I am currently running the latest version of Bind, and for some completely unknown reason I can NOT get queries to work for PTR records. All queries to the servers for reverse name lookup get query denied:

Using domain server:
Name: 66.150.173.1
Address: 66.150.173.1#53
Aliases:

Host 27.173.150.66.in-addr.arpa not found: 5(REFUSED)

And it shows in my logs:

Feb 15 15:49:03 mail1 named[19789]: client 98.232.45.87#58902: query (cache) '27.173.150.66.in-addr.arpa/PTR/IN' denied
Feb 15 15:49:03 mail1 named[19789]: client 98.232.45.87#42598: query (cache) '27.173.150.66.in-addr.arpa/PTR/IN' denied
Feb 15 15:52:59 mail1 named[19789]: client 173.160.151.225#65200: query (cache) '1.173.150.66.in-addr.arpa/PTR/IN' denied
Feb 15 15:52:59 mail1 named[19789]: client 173.160.151.225#52885: query (cache) '27.173.150.66.in-addr.arpa/PTR/IN' denied

I am at my wits ends with the piece of crap. Can anyone shine some light on why this damn Bind install won't respond to these queries??

For reference here is my named.conf:

Code:

# cat named.caching-nameserver.conf

options {

        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            { localhost; localnets; 66.150.173.0/26; };

};



include "/etc/rndc.key";

include "/etc/named.rfc1912.zones";



zone "chaps.co.kr" {

        type master;

        file "masters/chaps.co.kr.zone";

        allow-transfer { 66.150.173.2; };

        allow-query { any; };

        allow-update { none; };

};



zone "digimonbattle.com" {

        type master;

        file "masters/digimonbattle.com.zone";

        allow-transfer { 66.150.173.2; };

        allow-query { any; };

        allow-update { none; };

};



zone "wemade.net" {

        type master;

        file "masters/wemade.net.zone";

        allow-transfer { 66.150.173.2; };

        allow-query { any; };

        allow-update { none; };

};



zone "wemadeusa.com" {

        type master;

        file "masters/wemadeusa.com.zone";

        allow-transfer { 66.150.173.2; };

        allow-query { any; };

        allow-update { none; };

};



zone "0-59.173.150.66.in-addr.arpa" {

        type master;

        file "masters/0-59.173.150.66.in-addr.arpa.zone";

        allow-transfer { 66.150.173.2; };

        allow-query { any; };

        allow-update { none; };

};

kbp	02-15-2010 06:09 PM

You might be running into this issue, have a read:

Quote:

ISC Support Bulletin - July 2007
Document last updated: 2007-07-30

There has been some confusion surrounding the changes to the "allow-recursion" and "allow-query-cache" options made with BIND 9.4.1-P1.

This document will attempt to clarify the change and the impact that it makes on BIND servers.

In BIND 9.3, there was no segregation of queries between cache and authoritative data.

The release of BIND 9.4 added fine-grained differentiation between queries against authoritative data ("allow-query") and cached data ("allow-query-cache"). This allows more precise control, particularly if you do not want your clients to use any cached data, for example, in an authoritative-only nameserver.

Prior to the release of BIND 9.4.1-P1, the default action of "allow-recursion" and "allow-query-cache" was to permit the query. The P1 patch to BIND 9.4.1 caused two changes in this behavior:

1) If not explicitly set, the ACLs for "allow-query-cache" and "allow-recursion" were set to "localnets; localhost;".

2) If either "allow-query-cache" or "allow-recursion" was set, the other would be set the same value.

Upgrading from the BIND 9.3 branch to BIND 9.4.1-P1 will significantly restrict those servers that were previously recursive servers for more than "localhost; localnets;" unless configuration changes are made.

To retain the behavior prior to BIND 9.4.1-P1, the following entries should be created in your named.conf file:
Code:

options {
...
allow-recursion { any; };
allow-query { any; };
allow-query-cache { any; };
...
};

We strongly advise against this configuration because clients spoofing queries can use your servers to launch distributed denial-of-service attacks.

The recommended method is to create ACLs that match hosts that should be allowed access to cache and recursion on the servers. For example, if you wanted to provided recursion and access to the cache to clients you trusted, you could list them in an ACL such as the following:
Code:

acl "trusted" {
192.168.0.0/16;
10.153.154.0/24;
localhost;
localnets;
};

options {
...
allow-query { any; };
allow-recursion { trusted; };
allow-query-cache { trusted; };
...
};

This example ACL includes 192.168.0.0/16 and 10.153.154.0/24 as sample networks that would require access. You must replace these sample networks with networks that correctly reflect your environment. This will allow anyone to query your server for authoritative data, but only those hosts within the "trusted" ACL access to your cache and recursion.

hth

nnbnbnnbnn

02-15-2010 09:15 PM

well I appear to have stuck my foot in my mouth just a bit. It appears that I am tracking the latest version of Bind that CentOS bundles and that is the 9.3 branch. So while that article gave me some ideas, it didn't result in a repair.

What I did discover is that in my config file if I open the option that restricts people from doing recursive queries, the reverse zone starts working:

from

Code:

options {

        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            { localhost; localnets; 66.150.173.0/26; };

};

Code:

options {

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

};

However that allows anyone then to do DNS queries against my machines for any zone and that isn't something that I want. Any ideas?

chrism01

02-15-2010 10:08 PM

I think you want views/match-clients etc http://www.zytrax.com/books/dns/ch7/view.html

Smartpatrol

02-16-2010 10:32 PM

...

devwatchdog

02-16-2010 11:54 PM

Admittedly, I have limited experience setting up DNS servers overall. I know enough to be dangerous I suppose.

I recently set up the most basic config for a bind caching DNS server:

root@mars:/etc# named -v
BIND 9.6.1-P3
root@mars:/etc#

Granted, this is a different version than yours, but I think the basic issue with which you are dealing is common between them.

I was looking at the rejections you were seeing in your logs, and then checked the 'allow-query' option you have set. It looks like you're limiting queries from public address space to those contained within 66.150.173.0/26. I thought I'd run a test on my DNS server to see how it would react to altering the 'allow-query' option.

I fired up the laptop where the DNS server is installed, and issued this command:

jcwx@haley:/tmp$ host google.com 10.xx.xx.117
Using domain server:
Name: 10.xx.xx.117
Address: 10.xx.xx.117#53
Aliases:

google.com has address 209.85.225.99
google.com has address 209.85.225.105
google.com has address 209.85.225.147
google.com has address 209.85.225.106
google.com has address 209.85.225.103
google.com has address 209.85.225.104
google.com mail is handled by 400 google.com.s9b2.psmtp.com.
google.com mail is handled by 200 google.com.s9a2.psmtp.com.
google.com mail is handled by 100 google.com.s9a1.psmtp.com.
google.com mail is handled by 300 google.com.s9b1.psmtp.com.
jcwx@haley:/tmp$

I then edited my named.conf file and added this to the options file:

allow-query {192.168.3.0/24;};

That effectively negates any of my systems here as I don't use that network. I could have used 'none' and achieved the same thing.

I then ran a query against that server again:

jcwx@haley:/tmp$ host google.com 10.xx.xx.117
Using domain server:
Name: 10.xx.xx.117
Address: 10.xx.xx.117#53
Aliases:

Host google.com.lan not found: 5(REFUSED)

This is what I found in /var/log/messages:

Feb 16 23:29:09 mars named[16978]: client 10.xx.xx.103#51048: query (cache) 'google.com/A/IN' denied
Feb 16 23:29:09 mars named[16978]: client 10.xx.xx.103#33745: query (cache) 'google.com.lan/A/IN' denied

I did a reverse lookup and of course the same response was received, and the rejection was logged in a similar manner.

You're receiving requests from 98.232.45.87#42598 and 173.160.151.225#65200, and they're being rejected because they aren't within the 66.150.173.0/26 subnet.

Hope that helps.

-- I'm reading on the zone definitions now. Dunno, perhaps those override the first allow-query option.

devwatchdog

02-17-2010 12:12 AM

Quote:

Originally Posted by nnbnbnnbnn (Post 3865086)

Code:

options {

        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            { localhost; localnets; 66.150.173.0/26; };

};

Code:

options {

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

};

However that allows anyone then to do DNS queries against my machines for any zone and that isn't something that I want. Any ideas?

Hmmnn...well, it seems that pretty much knocks out my first post.

Apparently I wasn't reading for content earlier. Crap.

I see what you mean about your DNS servers being open for use for any queries at that point. Time to do some reading. Has to be a way to accomplish that, and a relatively common one at that.

devwatchdog

02-17-2010 01:50 AM

I set up a test, where I added a zone to a named.conf I crafted from the one you posted in your OP.

Code:

root@mars:/var/log# cat /etc/named.conf

options {

        directory              "/var/named/caching-example";

        dump-file              "/var/named/caching-example/cache_dump.db";

        statistics-file        "/var/named/caching-example/named_stats.txt";

        memstatistics-file      "/var/named/caching-example/named_mem_stats.txt";

        allow-query            { localhost; 10.xx.xx.0/24; };

};



include "/etc/rndc.key";



zone "example.com" {

        type master;

        file "example.com.zone";

        allow-transfer { 66.150.173.2; };

        allow-query { any; };

        allow-update { none; };

};

root@mars:/var/log#

I added the example.com.zone file, of which the contents were found in an example file I found online:

Code:

root@mars:/var/log# cat /var/named/caching-example/example.com.zone 

; public zone master file

; provides minimal public visibility of external services

example.com.  IN      SOA  ns.example.com. root.example.com. (

                              2003080800 ; se = serial number

                              3h        ; ref = refresh

                              15m        ; ret = update retry

                              3w        ; ex = expiry

                              3h      ; min = minimum

                              )

              IN      NS      ns1.example.com.

              IN      NS      ns2.example.com.

              IN      MX  10  mail.example.com.

ns1          IN      A      192.168.254.1

ns2          IN      A      192.168.254.2

mail          IN      A      192.168.254.3

www          IN      A      192.168.254.4

ftp          IN      A      192.168.254.5

root@mars:/var/log#

I wasn't too worried about the contents of the file itself, as long as they would return something on a query, which worked well enough. I got a response when running a query from within my lan.

I then forwarded port 53 from the public interface on my firewall to the laptop where that DNS server is installed. Logged into a router on another network, and ran these queries:

Code:

myatta:~# host example.com 71.xx.xx.xx

example.com has no A record at xx.xx.xx.xx.com (Authoritative answer)

myatta:~# host -a example.com 71.xx.xx.xx

example.com                SOA        ns.example.com root.example.com (

                        2003080800        ;serial (version)

                        10800        ;refresh period (3 hours)

                        900        ;retry interval (15 minutes)

                        1814400        ;expire time (3 weeks)

                        10800        ;default ttl (3 hours)

                        )

example.com                NS        ns1.example.com

example.com                NS        ns2.example.com

example.com                MX        10 mail.example.com

myatta:~# host ns1.example.com 71.xx.xx.xx

ns1.example.com            A        192.168.254.1

myatta:~# host -t MX example.com 71.xx.xx.xx

example.com                MX        10 mail.example.com

myatta:~# host mail.example.com 71.xx.xx.xx

mail.example.com            A        192.168.254.3

myatta:~#

The DNS server was doing what it was supposed to at that point.

I then ran this query to see if it would resolve a domain not hosted on that server:

Code:

myatta:~# host -a google.com 71.xx.xx.xx

google.com ANY record query refused by 71.xx.xx.xx.xx.xx.com

And I found this in the logs:

Feb 17 01:25:48 mars named[21750]: client 24.xx.xx.xx#41357: query (cache) 'google.com/ANY/IN' denied

In the configuration I have set up, my DNS server will not answer for any domain for which it does not have a record defined when queried from an external host. It resolves names properly from the lan.

I tried to emulate your config as best I could. I really can't explain why your config doesn't work.

Noway2

02-17-2010 05:01 AM

Smartpatrol had a good point. You are working with an address in the range of 66.150.173.0/26, which will if I am reading my CIDR notation correct, will allow you to have 15 hosts ranging from 66.150.173.1 to 66.160.173.15. There is a problem with this range: it is already owned, allocated and handled by a name server. It is PUBLIC! If this public address range isn't yours, i.e, if you are not leasing it from Internap Network Services Corporation, you will run into problems with conflicts.

The other posts in this thread, where attempts to duplicate your problem have failed are with private address ranges. Perhaps this is your problem.

devwatchdog

02-17-2010 08:52 AM

Quote:

Originally Posted by Noway2 (Post 3866652)

Well, the test I set up was indeed done via public space -- I didn't set up a PTR record for my little test, but I'm doing that now. The data being returned in the little testing environment is irrelevant, due to the fact I'm only looking for what I defined as the IP addresses or domain names in the zone I created.

As to someone else owning the IP range that the OP is working with -- I would imagine this is hardly uncommon. ISPs own blocks of public IP space. Those blocks are then split up into smaller blocks and used by clients.

I thought I tested the OP's DNS server (66.150.173.1) earlier this morning, to find it not accepting connections. Anyhow, it is now and I see exactly the issue. If anyone has actually done any testing on the OP's domains they would have seen that the DNS server being used presently is none other than the one at 66.150.173.1.

I was thrown a bit when I started getting reverse resolution, but realized that wasn't the case, for I was running name queries first, then a reverse query. My local name servers are caching, so when I request a reverse lookup, the request isn't going back to 66.150.173.1. It is merely being answered by my local DNS server. I could see via traffic dumps that there wasn't any traffic to/from 66.150.173.1 on the reverse requests.

Here is an example of the query I send:

Code:

jcwx@haley:~$ host -a 66.150.173.20 66.150.173.1

Trying "20.173.150.66.in-addr.arpa"

Received 44 bytes from 66.150.173.1#53 in 87 ms

Trying "20.173.150.66.in-addr.arpa"

Using domain server:

Name: 66.150.173.1

Address: 66.150.173.1#53

Aliases: 



Host 20.173.150.66.in-addr.arpa not found: 5(REFUSED)

Received 44 bytes from 66.150.173.1#53 in 84 ms

jcwx@haley:~$

No need to post the traffic capture on it. Needless to say it's bidirectional and reflects the refusal show.

To the OP: could we see the contents of the 0-59.173.150.66.in-addr.arpa file? I imagine that is where the PTR records are defined.

devwatchdog

02-17-2010 11:51 AM

I got reverse lookups to work. The reverse on the MX record doesn't work for some reason, but that's some sort of a syntax issue.

Code:

myatta:~# host ftp.example.com 71.xx.xx.66

ftp.example.com            A        192.1.254.5

myatta:~# host 192.1.254.5 71.xx.xx.66

Name: example.com

Address: 192.1.254.5



myatta:~#

It works for only some of the addresses, and even the example above isn't quite right, as that should return ftp.example.com for the reverse lookup. Still, it's semi-functional and not refusing the reverse lookups.

I changed the IP addresses to public, as bind was complaining about serving up private IP via the public interface.

The two zones look like this:

Code:

include "/etc/rndc.key";



zone "example.com" {

        type master;

        file "example.com.zone";

        allow-transfer { 66.150.173.2; };

        allow-query { any; };

        allow-update { none; };

};



zone "254.1.192.in-addr.arpa" {

        type master;

        file "254.1.192.in-addr.arpa";

        allow-transfer { 66.150.173.2; };

        allow-query { any; };

        allow-update { none; };

};

and my screwed up reverse lookup file:

Code:

root@mars:/var/named/caching-example# cat 254.1.192.in-addr.arpa 

$TTL 2d ; 172800 secs

$ORIGIN 254.1.192.in-addr.arpa.

@        IN        SOA        ns1.example.com. admin.example.com. (

                        2006051501      ; Serial

                        10800          ; Refresh after 3 hours

                        3600            ; Retry after 1 hour

                        604800          ; Expire after 1 week

                        300 )          ; Negative Reponse TTL      

        IN      NS      ns1.example.com.

        IN      NS      ns2.example.com.

 

1        IN        PTR        ns1.example.com.

2        IN        PTR        ns2.example.com.

5        IN        PTR        example.com.

10        IN        PTR        mail.example.com.

20        IN        PTR        www.example.com.

30        IN        PTR        ftp.example.com.

I'm sure what I've got wrong is pretty basic, and probably rather obvious too, but I've been messing around with it enough that it is time to get away from bind for a little while. I'll take a look at it again sometime later.

All times are GMT -5. The time now is 08:19 AM.