BIND works internally, refused externally, on VPS name server
Linux - NetworkingThis forum is for any issue related to networks or networking.
Routing, network cards, OSI, etc. Anything is fair game.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
BIND works internally, refused externally, on VPS name server
I am trying to set up BIND service on a VPS server. I have got it working internally, but cannot access it from external machines. I have been searching this and other sites, but none of the suggested solutions seems to work.
When dig from the name server, I get a "Query status NOERROR" reply, but when I dig from a different server, I get a "Query status REFUSED" reply.
It does not appear to be a firewall/iptables problem - I can telnet into the server from outside on port 53. So I figure it must be a BIND configuration problem.
When dig from the name server, I get a "Query status NOERROR" reply, but when I dig from a different server, I get a "Query status REFUSED" reply.
I guess you're trying to query the dns for a domain that it's not authoritative for. If that's the case, then this is the correct answer since recursion is off.
If you run dig you'll see:
Quote:
; <<>> DiG 9.8.0-P2 <<>> google.com @x.x.x.x
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: REFUSED, id: 21023
;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0
;; WARNING: recursion requested but not available
;; QUESTION SECTION:
;google.com. IN A
;; Query time: 25 msec
;; SERVER: x.x.x.x#53(x.x.x.x)
;; WHEN: Sun Jun 26 11:01:52 2011
;; MSG SIZE rcvd: 28
1st of all, it looks like you missed the trailing dot in the NS RR above.
Now for the "REFUSED" error, I guess that ns2.yoursportsleague.com still thinks it's not authoritative for that domain, because of the error above.
By the way, to check that ns2.yoursportsleague.com is listening on port 53:
[steve@www ~]$ telnet ns2.yoursportsleague.com 53
Trying 74.208.234.121...
Connected to ns2.yoursportsleague.com (74.208.234.121).
Escape character is '^]'.
; <<>> DiG 9.8.0-P2 <<>> yoursportsleague.com @ns2.yoursportsleague.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: REFUSED, id: 11464
;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0
;; WARNING: recursion requested but not available
Still there is no aa flag (authoritative) in the response and due to this the query is refused. Of course it shouldn't happen as you allow recursion (which btw is not a wise thing to do). So could you post the new named.conf?
Quote:
By the way, to check that ns2.yoursportsleague.com is listening on port 53:
[steve@www ~]$ telnet ns2.yoursportsleague.com 53
Trying 74.208.234.121...
Connected to ns2.yoursportsleague.com (74.208.234.121).
Escape character is '^]'.
As you can see, I was able to connect.
Note that dns uses udp primarily, so being able to connect to it through telnet (tcp) does not mean much.
I set auth-nxdomain to yes and verified that all the zones were loaded. None of them resolve externally. iptables reports that port 53 is allowed for udp as well as tcp. No change:
It's not a firewall problem, or else you'd get a "connection timed out; no servers could be reached"
The problem is either the "recursion" or the "allow-query", that according to the config you posted are correct!!!! Anyway, can you remove all comments and the allow-recursion, allow-query, listen-on, auth-nxdomain and the acl directives, stop named and start it again. I'm also baffled why it does not respond authoritatively and denies recursion.
Also what do you mean that it's working internally?
BTW do you see something in the logs under /var/log? You may setup bind logging for more detailed logs, or use tcpdump to view packets
It works, but it's not responding authoritatively (still no aa flag).
Remove or comment out and the allow-query directive(s) and check logs, because your config is correct and it should work for anyone.
Are you sure this is the correct named.conf file? What is the output of
root 18262 18214 0 23:46 pts/0 00:00:00 grep named
named 20365 1 0 Jul01 ? 00:00:05 /usr/sbin/named -u named -c /etc/named.conf -u named -t /var/named/run-root
Since you're running named chrooted, /etc/named.conf should be a symlink to /var/named/run-root/etc/named.conf.
How did you install bind and what distro are you using? There are 2 "-u named" options above and the chroot directory is not a default one, so I guess you didn't use your distro's package manager to install it.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.