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

So, any clue?

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:

Hi,

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)

Thank you for your answer,

Regards,
Wilemr

I noticed you have 2 different zones. . .you didn't do anything like views crazy stuff like that, did you?

What do you mean by 2 different zones? you can have N zones in a named.conf file, don't you?

If you don't know what a view is, then nevermind. ;)

Can you post up your named.conf so we can see if there's anything wrong with that?

Ok, here goes mi named.conf

//Note: 1.2.3.4 represents the public-ip of the DNS server

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

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:


So, 1234-zone-file says:

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.

Once again I want to thank you.

Wilmer

Very strange. . .

I can't really think of any other reason.

Stupid idea, but you might try telling it to allow-query from both address ranges. It's just like allow-transfer in it's syntax.

Beyond that, the only other thing I can suggest is maybe try setting up views, but I doubt that would work. It's a reach.

Possible routing problem for the outside IP? It can receive but not send....

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.

Regards,
Wilmer

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!

Thenk you for your time and patience

Wilmer

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.