Hello All,
I have been pulling my hair out for the past week trying to figure this out.
I am some what familiar of how DNS/ BIND works, but I am at a total loss
here.
Here is what I want to happen:
I want a local subdomain server, ServerA, to host a zone "us.tridia.com",
which "us.tridia.com" is for private, internal machines. So, if
host1.us.trida.com queries for host2 in the same subdomain, it can happen.
If the query does not exist in the "us.tridia.com" zone, immediately go to
the second server, ServerB, which is in live IP space( the same sever which
has the "tridia.com" zone), and take it from there. I do not want ServerB to
know about hosts in ServerA, however I want ServerA to know about hosts in
ServerB and beyond.
I have setup a zone transfer to come from ServerB down into ServerA, for the
"tridia.com".
Everything is fine with that, I think. I can query "host1.tridia.com" and I
get immediate results.
However, if I use nslookup, and query "host1.us.tridia.com", I get a
non-existent host/domain.
As well, I get this for all domains. Like "www.yahoo.com" and
"www.redhat.com", it fails on them too.
ServerA does have resolve.conf to point to itself first, and has ServerB as
the second, but its like it doesn't want to pass the torch or something.
Here is the section out of my /etc/named.conf file:
-----
zone "us.tridia.com" in {
type master;
file "named.private-us.tridia";
};
zone "tridia.com" in {
type slave;
file "slave.corp.tridia";
masters {208.178.113.252;};
};
-----
Here is a section out of the named.private-us.tridia.com:
-----
$INCLUDE /var/named/soa
$ORIGIN us.tridia.com
IN MX 10 tridhcp.us.tridia.com.
IN MX 20 trins1.tridia.com.
host1 IN A 192.168.13.1
host2 IN A 192.168.13.2
-----
Here is a section out of the reverse file:
-----
$INCLUDE /var/named/soa
$ORIGIN 13.168.192.in-addr.arpa.
1 IN PTR host1.us.tridia.com.
2 IN PTR host2.us.tridia.com.
-----
And lastly, the mentioned SOA file:
-----
@ IN SOA tridhcp.us.tridia.com. support.tridia.com (
2000081502 ; Serial# - YYMMDDNN#
3600 ; Refresh
900 ; Retry
604800 ; Expire
86400 ) ; Minimum
; name servers
IN NS tridhcp.us.tridia.com.
IN NS trins1.tridia.com.
-----
I know there is a lot of information here.
If anyone can make sense of it, that would be awesome :)!
Thanks!
--------------------------------------------------------------
Graham P. Wooden
Tridia Corporation Web Services Dept.
678-269-1114 gra...@tridia.com
770-428-5009 (fax)
[ PGP Key: http://graham.g-rock.net/grahamPGP.txt ]
-------------------- http://www.tridia.com/ ------------------
Tridia intends to both meet and exceed your expectations for all of our
products and services. Please let us know how we are doing by contacting
gra...@tridia.com or c...@tridia.com. Thank you for your feedback!
> Hello All,
>
> I have been pulling my hair out for the past week trying to figure this out.
> I am some what familiar of how DNS/ BIND works, but I am at a total loss
> here.
>
> Here is what I want to happen:
> I want a local subdomain server, ServerA, to host a zone "us.tridia.com",
> which "us.tridia.com" is for private, internal machines. So, if
> host1.us.trida.com queries for host2 in the same subdomain, it can happen.
I assume ServerA has no direct connectivity to the Internet, right?
> If the query does not exist in the "us.tridia.com" zone, immediately go to
> the second server, ServerB, which is in live IP space( the same sever which
> has the "tridia.com" zone), and take it from there. I do not want ServerB to
> know about hosts in ServerA, however I want ServerA to know about hosts in
> ServerB and beyond.
This can work, but not with your understanding of "go to". See below.
> I have setup a zone transfer to come from ServerB down into ServerA, for the
> "tridia.com".
> Everything is fine with that, I think. I can query "host1.tridia.com" and I
> get immediate results.
> However, if I use nslookup, and query "host1.us.tridia.com", I get a
> non-existent host/domain.
This part I don't understand. According to the config files, ServerA is master
for us.tridia.com, so it should be able to resolve names in that zone
regardless of what other zones are defined. Did it work before the zone
transfers of the parent zone? Are you sure the zone is loading properly? Are
there any errors in the log file at load time? If you dump the database (using
"ndc dumpdb" or sending SIGINT to named), are the records for that zone in the
dump?
> As well, I get this for all domains. Like "www.yahoo.com" and
> "www.redhat.com", it fails on them too.
>
Did those work before you configured the zone transfers? If ServerA has no
direct Internet connectivity, I can't see how they could have worked in the
absence of some sort of forwarding arrangement.
> ServerA does have resolve.conf to point to itself first, and has ServerB as
> the second, but its like it doesn't want to pass the torch or something.
>
Nameservers don't use /etc/resolv.conf to make name-resolution decisions. If
you want ServerA to "pass the torch" to ServerB, then you need to explicitly
set up a forwarding arrangement between them. Put "forward only" and
"forwarders { x.x.x.x; };" (where x.x.x.x is ServerB's IP address) in ServerA's
"options" statement. Also, for this to work, ServerB needs to allow recursive
queries from ServerA. This configuration should permit ServerA to resolve names
through ServerB, but it'll only ask if the name isn't already in its cache or
authoritative data, so queries for names in us.tridia.com will never be
forwarded. At least, this is the way it *should* work, but apparently you have
some problem loading your internal domain, so you need to get that sorted out
before the forwarding setup will work.
- Kevin
Thanks Kevin for the reply. I think I know where to start!
ServerA does have connection to the Internet. It is behind a NAT firewall
machine.
I have opened up UDP and TCP ports 53 so it can communicate between the
servers and for the hosts behind the NAT to access ServerB if need be.
Great, I'll start with the fundamentals to make sure it can load it's own
subdomain first.
I believe that worked just fine until I did the zone transfer.... um.
I will confirm and write back.
Thanks again!
-Graham.