DNS Server (bind9) works on the private network but not in the public one!
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.
DNS Server (bind9) works on the private network but not in the public one!
Hi there,
I am trying to configure bind9 on a debian Sarge (Testing) box. I made all the .conf files and the servers starts ok (as the log -/var/log/daemon.log- says). The box handling Bind9 has a Publia IP address and a private address.
I turn down all the firewall rules and I can reach the server from outside the network, I can ping it, traceroute it, telnet it (to port 53) and ssh it BUT when I try aquery like this:
dig someBox @public_ip
All I get is:
;; global options: printcmd
;; connection timed out; no servers could be reached
and when I try the same query from inside the network (using the private IP address of the DNS server) it WORKS FINE!
dig someBox (the box same as above) @private_IP_ADDRESS_of_the_same_DNS_SERVER
;; global options: printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 32024
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 1
Are you sure that bind listens on your both IPs. There is a "listen-on" directive in named.conf that lists the interfaces that bind listens. Check to see if you have define it. If not add a line like the following:
I think that Bind is listening in all the interfaces even though I haven't said that in the named.conf file (as you recomended). When i say "I think named is listening in the interfaces" is because of the log:
Jun 9 06:55:29 estacion2 named[20266]: starting BIND 9.2.4 -u bind
Jun 9 06:55:29 estacion2 named[20266]: using 1 CPU
Jun 9 06:55:29 estacion2 named[20266]: loading configuration from '/etc/bind/named.conf'
Jun 9 06:55:29 estacion2 named[20266]: listening on IPv4 interface lo, 127.0.0.1#53
Jun 9 06:55:29 estacion2 named[20266]: listening on IPv4 interface eth0, 192.168.0.47#53
Jun 9 06:55:29 estacion2 named[20266]: listening on IPv4 interface eth0:1, public_ip#53
Jun 9 06:55:29 estacion2 named[20266]: command channel listening on 127.0.0.1#953
Jun 9 06:55:29 estacion2 named[20266]: command channel listening on ::1#953
Jun 9 06:55:29 estacion2 named[20266]: zone 127.in-addr.arpa/IN: loaded serial 1
Jun 9 06:55:29 estacion2 named[20266]: zone public_ip.in-addr.arpa/IN: loaded serial 1
Jun 9 06:55:29 estacion2 named[20266]: zone localhost/IN: loaded serial 1
Jun 9 06:55:29 estacion2 named[20266]: zone bla_bla/IN: loaded serial 200506031
Jun 9 06:55:29 estacion2 named[20266]: running
So, Do I need to add those lines you told me?
I haven't said that the Server onli has 1 ethernet card I am using aliases (as you can see in the log that the public ip is setted at eth0:1)
zone "." {
type hint;
file "/etc/bind/db.root";
};
zone "localhost" {
type master;
file "/etc/bind/db.local";
};
zone "127.in-addr.arpa" {
type master;
file "/etc/bind/db.127";
};
zone "3.2.1.in-addr.arpa" {
type master;
file "/etc/bind/1.2.3";
};
$TTL 3D
@ IN SOA dns.havingproblems.org. someone.dns.havingproblems.org. (
200506031
8H
2H
4W
1D )
;
NS dns.havingproblems.org.
;
localhost A 127.0.0.1
dns.havingproblems.org. A 1.2.3.4 www.havingproblems.org. A 5.6.7.8
//**************************
That's all ... I hope you can help me
I want to repeat that FROM the LOCAL nerwork it WORKS OK!
Originally posted by wjleon Ok, here goes mi named.conf
//Note: 1.2.3.4 represents the public-ip of the DNS server
Code:
options {
directory "/var/cache/bind";
listen-on {
127.0.0.1;
192.168.0.47;
1.2.3.4;
};
forward first;
forwarders {
150.188.4.200;
};
auth-nxdomain no; # conform to RFC1035
};
logging {
channel query_logging {
file "/var/log/named_querylog"
versions 3 size 100M;
print-time yes; // timestamp log entries
};
category queries {
query_logging;
};
category lame-servers { null; };
};
zone "." {
type hint;
file "/etc/bind/db.root";
};
zone "localhost" {
type master;
file "/etc/bind/db.local";
};
zone "127.in-addr.arpa" {
type master;
file "/etc/bind/db.127";
};
zone "3.2.1.in-addr.arpa" {
type master;
file "/etc/bind/1.2.3";
};
$TTL 3D
@ IN SOA dns.havingproblems.org. someone.dns.havingproblems.org. (
200506031
8H
2H
4W
1D )
;
NS dns.havingproblems.org.
;
localhost A 127.0.0.1
dns.havingproblems.org. A 1.2.3.4 www.havingproblems.org. A 5.6.7.8
//**************************
That's all ... I hope you can help me
I want to repeat that FROM the LOCAL nerwork it WORKS OK!
Thanks in advance
Regards,
Wilmer
I think the issue is that you don't have a forward lookup zone specified. The zone info you post is for a forward lookup, but in the named.conf, you have 3.2.1.in-addr.arpa, and that's for reverse lookup. Just change it to something like zone "mynet" and restart your bind server. See what happens.
[edit]Your dig request is incorrect, I believe. It's
Code:
dig (servername) (name) (type)
So dig @a.root-servers.net . ns will get you the root servers list.
Ok, I made a mistae when posting my named.conf (because it's splitted in more than 1 file), Here goes the whole file:
Code:
options {
directory "/var/cache/bind";
listen-on {
127.0.0.1;
192.168.0.47;
1.2.3.4;
};
forward first;
forwarders {
150.188.4.200;
};
auth-nxdomain no; # conform to RFC1035
};
logging {
channel query_logging {
file "/var/log/named_querylog"
versions 3 size 100M;
print-time yes; // timestamp log entries
};
category queries {
query_logging;
};
category lame-servers { null; };
};
zone "." {
type hint;
file "/etc/bind/db.root";
};
zone "localhost" {
type master;
file "/etc/bind/db.local";
};
zone "127.in-addr.arpa" {
type master;
file "/etc/bind/db.127";
};
zone "3.2.1.in-addr.arpa" {
type master;
file "/etc/bind/1.2.3";
};
zone "1234-zone" {
type master;
file "/etc/bind/1234-zone-file";
allow-transfer {
150.188.4.0/24;
};
};
So, 1234-zone-file says:
Code:
$TTL 3D
@ IN SOA dns.havingproblems.org. someone.dns.havingproblems.org. (
200506031
8H
2H
4W
1D )
;
NS dns.havingproblems.org.
;
localhost A 127.0.0.1
dns.havingproblems.org. A 1.2.3.4
www.havingproblems.org. A 5.6.7.8
I'd like to point point out that the dns server is logging the queries and that actually all the queries that I performed are being logged (even those peformed outside the network). The point is that when I query the dns server from outside the network I do not get an answer.
I don't think it is a Routing problem because I can ssh that server! and being in the server I can ssh other servers ... Buty if you have idea of how can I test that it is not routing, they will be welcome.
What i'm getting at is access to the external ip from outside of your private lan.
I'm assuming that you have two boxes and that you have physical access (console) to the dns server.
Set up the dns server with one ip, its external one first. Get it working and be able to do a lookup using the
second box, from outside of your private lan. Once you have it working then get it local as well.
Do you have a firewall/router in place. Is port forwarding turned on for access to the dns server? Does it need to be?
I don't think that this is a problem with your dns setup sounds more like a networking problem.
Ok, here goes an explanation a little bit more detailed
At first let's be clear in names I am going to use in this post:
let Lan A refers to the Lan I am now
let Lan B refers to the private-lan where the DNS Server is
let Lan C refers to the public-lan where the DNS Server is
pub-dns-ip = public ip of DNS Server is goint to be 1.2.3.4
pri-dns-ip = private ip of DNS Server is 192.168.0.47
dnsBox is going to represent the DNS server which belongs to lans B and C
luluBox is going to represent a compuer on Lan B
myBox is going to represent a computer on lan A
so here it goues.
Being in myBox I can ssh dnsBox through pub-dns-ip. Once I have done that I can reach (via ssh) luluBox. If I ask dnsBox to resolve any name, it is going to success BUT only if I ask that using pri-dns-ip, i.e. dig anything @pri-dns (from luluBox, of course)
Being in myBox it fails if I try to do:
dig anything @pub-dns
Note that there is no firewall between dns-box and the Internet, just a router which I don't have access to, so I don't know if they are filtering things. I just know that dns-box is LOGGING All the queries I perform, it doesn't matter if I ask from myBox, luluBox or dnsBox it Logs the queries so the router is passing the dns-requests.
I don't see why people handling the router could be filterinrg dns responses (if they let pass the request)
So now that I have made a picture of the whole scenario can you please give me some peace of light? I'm broken down here!
Jun 9 06:55:29 estacion2 named[20266]: listening on IPv4 interface eth0, 192.168.0.47#53
Jun 9 06:55:29 estacion2 named[20266]: listening on IPv4 interface eth0:1, public_ip#53
Just a thought here, but why are you using the same interface for both public and private lan?
Have you taken care of the routing issues involved with this type of configuration? especially the reply packets.
I would also think you need to use some sort of iptable rules to force packets received on the aliased interface to be sent back out on the aliased interface. Using tcpdump should confirm whether or not the reply packets are being sent back on the primary interface.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.