LinuxQuestions.org
Welcome to the most active Linux Forum on the web.
Go Back   LinuxQuestions.org > Forums > Linux Forums > Linux - Server
User Name
Password
Linux - Server This forum is for the discussion of Linux Software used in a server related context.

Notices

Reply
 
Search this Thread
Old 02-15-2010, 05:53 PM   #1
nnbnbnnbnn
LQ Newbie
 
Registered: Feb 2010
Posts: 2

Rep: Reputation: 0
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; };
};
 
Old 02-15-2010, 06:09 PM   #2
kbp
Senior Member
 
Registered: Aug 2009
Posts: 3,758

Rep: Reputation: 643Reputation: 643Reputation: 643Reputation: 643Reputation: 643Reputation: 643
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
 
Old 02-15-2010, 09:15 PM   #3
nnbnbnnbnn
LQ Newbie
 
Registered: Feb 2010
Posts: 2

Original Poster
Rep: Reputation: 0
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; };
};
to
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?
 
Old 02-15-2010, 10:08 PM   #4
chrism01
Guru
 
Registered: Aug 2004
Location: Sydney
Distribution: Centos 6.5, Centos 5.10
Posts: 16,232

Rep: Reputation: 2023Reputation: 2023Reputation: 2023Reputation: 2023Reputation: 2023Reputation: 2023Reputation: 2023Reputation: 2023Reputation: 2023Reputation: 2023Reputation: 2023
I think you want views/match-clients etc http://www.zytrax.com/books/dns/ch7/view.html
 
Old 02-16-2010, 10:32 PM   #5
Smartpatrol
Member
 
Registered: Sep 2009
Posts: 196

Rep: Reputation: 38
...

Last edited by Smartpatrol; 03-11-2010 at 10:04 PM.
 
Old 02-16-2010, 11:54 PM   #6
devwatchdog
Member
 
Registered: Jan 2010
Posts: 198

Rep: Reputation: 44
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.

Last edited by devwatchdog; 02-17-2010 at 12:03 AM.
 
Old 02-17-2010, 12:12 AM   #7
devwatchdog
Member
 
Registered: Jan 2010
Posts: 198

Rep: Reputation: 44
Quote:
Originally Posted by nnbnbnnbnn View Post
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; };
};
to
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.
 
Old 02-17-2010, 01:50 AM   #8
devwatchdog
Member
 
Registered: Jan 2010
Posts: 198

Rep: Reputation: 44
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.

Last edited by devwatchdog; 02-17-2010 at 01:54 AM.
 
Old 02-17-2010, 05:01 AM   #9
Noway2
Senior Member
 
Registered: Jul 2007
Distribution: Ubuntu 10.10, Slackware 64-current
Posts: 2,124

Rep: Reputation: 776Reputation: 776Reputation: 776Reputation: 776Reputation: 776Reputation: 776Reputation: 776
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.
 
Old 02-17-2010, 08:52 AM   #10
devwatchdog
Member
 
Registered: Jan 2010
Posts: 198

Rep: Reputation: 44
Quote:
Originally Posted by Noway2 View Post
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.
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.

Last edited by devwatchdog; 02-17-2010 at 08:54 AM.
 
Old 02-17-2010, 11:51 AM   #11
devwatchdog
Member
 
Registered: Jan 2010
Posts: 198

Rep: Reputation: 44
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.
 
  


Reply


Thread Tools Search this Thread
Search this Thread:

Advanced Search

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is Off
HTML code is Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Queries about bind... cj_cheema Linux - Server 1 04-11-2009 11:14 AM
How to log some kind of queries with BIND 9 sjfdj Linux - Server 1 09-17-2008 04:33 AM
Securing BIND queries broadcast Linux - Security 3 09-22-2006 09:18 PM
DNS Refuses to Make Authoritative Queries gizza23 Linux - Networking 6 06-27-2006 08:48 AM
Runaway queries in BIND mj.fear Linux - Newbie 1 11-06-2005 01:09 PM


All times are GMT -5. The time now is 10:49 AM.

Main Menu
My LQ
Write for LQ
LinuxQuestions.org is looking for people interested in writing Editorials, Articles, Reviews, and more. If you'd like to contribute content, let us know.
Main Menu
Syndicate
RSS1  Latest Threads
RSS1  LQ News
Twitter: @linuxquestions
identi.ca: @linuxquestions
Facebook: linuxquestions Google+: linuxquestions
Open Source Consulting | Domain Registration