Questions on VM's dyndns scripts + resolv.conf

[HarvesterOfBeer]

First off, thanks a boatload for your scripts and examples, Void Main! They kick ass. I've learned a lot.

I've been working with the dyndns scripts on a Fedora Core 1 system. The config stuff is all in the chroot tree at '/var/named/chroot/', and I think I've got the config files edited to be correct for the network I'm trying to set up.

I'm doing a basic private RFC1918 subnet connected through a dual-NIC host to another network (company net in this case). The gateway is running Shorewall, and the BIND and dhcpd that come with FC1. The domain on the company net is structured like "foo.com", and the domain I'd like to have on the private net is "testdomain.foo.com". NIC eth0 connecting to the company net will be set through DHCP (but reserved on the DHCP server) and eth1 will have a static IP.

After going through the various man pages and google hits, I'm still not sure how to configure resolv.conf (and maybe other config files) so that:

1. The machine resolves properly in either domain (gw.foo.com, gw.testdomain.foo.com).

2. DNS requests for machines outside of the private network are properly forwarded on to the company nameservers.

Any suggestions? Thanks!

-HoB[/list]

[Void Main]

Thanks man. I'll have to study this a little bit this evening and see what I can come up with (hopefully I don't forget).

[HarvesterOfBeer]

Thanks! I look forward to your reply.

Upon reading my original post, I can see where there may be some ambiguity in #2. What I want is for machines inside the private network to have successful DNS service not only for other machines in the private net, but for machines in the corporate network and the internet. I do not want to serve DNS (or DHCP for that matter) requests coming from the corporate net.

Thanks!

-HoB

[Void Main]

Yeah, just add some forward statements in your named.conf that point to your corporate server. Of course that would be unecessary if your corp servers are part of the Internet DNS hierarchy. If they are off-net as well then the forwarder statements will take care of it. Something on the order of:

Code: Select all

options {
  directory "/var/named";
  listen-on { 192.168.1.2; 127.0.0.1;};
  forwarders { 10.10.1.2; 10.10.2.2; };
};


As far as having all the domains in your search list in resolv.conf if would be something like:

Code: Select all

search corp.foo.com private.foo.com foo.com
nameserver 192.168.1.2


[HarvesterOfBeer]

Ok, that seems to work fine for hosts that are statically defined in the zone files. Wheee! Much better than my previous miserable attempt.

I cannot resolve hosts that are using dhcp (all Windows machines...mostly Win2K and XPPro at the moment, but over time there will also be Win2K3, Win98, and WinNT hosts) nor do hostnames that are defined with a fixed address hosts in the dhcpf.conf file resolve.

If somebody is willing to help me dig into this further, what data do you need from me?

Thanks!

-HoB

[Void Main]

Are those DHCP hosts on your private network or your corporate network, and do you have DHCP configured to enter their addresses into DNS when the lease is given out like in my samples?

[HarvesterOfBeer]

The DHCP'd hosts I'm trying to get DNS working for are inside the private network. The dhcpd.conf file is almost verbatim from your sample. Here's the dhcpd.conf file. Thanks!

-HoB

# Turn on Dynamic DNS:
ddns-update-style interim;
ddns-updates on;

# Don't allow clients to update DNS, make the server do it
# based on the hostname passed by the DHCP client:
deny client-updates;
allow unknown-clients;

#
# 192.168.0.0/255.255.255.0 Scope Settings
#
subnet 192.168.0.0 netmask 255.255.255.0 {

authoritative;

# Range of DHCP assigned addresses for this scope
range 192.168.0.2 192.168.0.64;
# 1 day
default-lease-time 86400;
# 2 days
max-lease-time 172800;

# Configure the client's default Gateway:
option subnet-mask 255.255.255.0;
option broadcast-address 192.168.0.255;
option routers 192.168.0.1;

# Configure the client's DNS settings:
option domain-name "test.foo.com";
option domain-name-servers 192.168.0.1;

# If you want the client to be configured to also use
# a WINS server:
option netbios-name-servers 192.168.0.1;
option netbios-node-type 8;

host site1 {
fixed-address 192.168.0.2;
hardware ethernet ff:ff:44:55:66;
}

# bunch of other host entries removed for brevity

}

[Void Main]

Do you see any *.jnl files in your /var/named directory? If not, are the directory permissions not allowing named to write the database files? Are there any error messages in your /var/log/messages that might hint at where the problem is? What does your /etc/named.conf look like? Are you allowing updates from localhost on those zones? Have you tried adding a dynamic DNS record manually using the "nsupdate" command? Might be a good idea to look over the man page. Hmmm, can't think of anything else to check, you should be able to pinpoint where the problem lies somewhere in there...

[HarvesterOfBeer]

Thanks for the reply. There were no .jnl files. The permissions for the whole tree (/var/named on down) are -rw-rw--- for named as user and group. Directories have 'x' set.

I added a machine successfully through nsupdate, and then it created the journal file. That machine now resolves properly.

Here's a snippet from the log showing the message when a client tries to update:

Dec 11 13:42:29 fedora named[4720]: client 192.168.0.4#1095: updating zone 'test.foo.com/IN': update failed: 'RRset exists (value dependent)' prerequisite not satisfied (NXRRSET)

Dec 11 13:42:29 fedora named[4720]: client 192.168.0.4#1098: update 'test.foo.com/IN' denied


That machine IP number has a fixed-address entry in the dhcpd.conf, but not in any of the named files. As far as I know, I'm ailowing updates from localhost on the necessary zones. Here's the named.conf. BTW, named is running chrooted to /var/named/chroot, so the named.conf lives in /var/named/chroot/etc.

options {
directory "/var/named";
listen-on { 192.168.0.1; localhost; };
forwarders { 192.168.2.13; 192.168.2.14; };
};

key "rndc-key" {
algorithm hmac-md5;
secret "C7WUBKVfEg4XsKo+Ilkz8A==";
};

controls {
inet 127.0.0.1 port 953 allow { 127.0.0.1; } keys { "rndc-key"; };
};

zone "." IN {
type hint;
file "named.ca";
};

zone "localhost" IN {
type master;
file "localhost.zone";
allow-update { none; };
};

zone "0.0.127.in-addr.arpa" IN {
type master;
file "named.local";
allow-update { none; };
};

zone "test.foo.com" in {
type master;
file "test.foo.com.zone";
allow-update { localhost; };
};

zone "0.168.192.in-addr.arpa" IN {
type master;
file "192.168.0.rev";
allow-update { localhost; };
};

[Void Main]

Hmmm, the DNS config looks right but there are some things that look a little odd to me in the DHCP config and I have questions about your machine's IP configs. Let's see if I have this right, it appears that your DNS server is 192.168.0.1 is that right? The DNS server and your gateway both are on the same box? In your log the first message looks normal, I have those in my log.

The second message (with the "denied" in it) seems to be key. The big problem I see is that it appears 192.168.0.4 is the address trying to do the DNS update and it should not be able to. It should get denied as you only are allowing updates from "localhost" on 192.168.0.1 which is the only machine that should be doing the dynamic updates. I have to assume you are also running dhcpd on 192.168.0.1 right? Are there any error messages in your messages log about 192.168.0.1 being denied? When a client asks for a DHCP assigned address and the DHCP server assigns one, the server should also do the nsupdate (although you can set it up to have the client do the update directly).

[HarvesterOfBeer]

Yes, the 192.168.0.1 machine is the gateway, named, and dhcpd box. I'll check the error messages on Monday and let you know.

My understanding is that you can have the clients irectly update the DNS records, or you can have the dhcp server do it. I'm under the impression that your scripts are set up to have the dhcp server handle the updates, yes?

Thanks!

-HoB

[Void Main]

Yes that is correct. If you want the clients to be able to do it then you need to open up the "allow-update" in your named.conf. You might add 192.168.0.1 alongside "localhost" to make sure your server is authorized but "localhost" should be enough for the server only updates. You'll want to add your entire client range if you want the clients to do the updates directly.

[HarvesterOfBeer]

Ok, I'll check into that. Is there anything I need to put in the named.conf or zone files to allow the clients to do the updates. I don't think I'm currently using the TSIG signed update scheme so the clients shouldn't need the key...

Thanks!

-HoB

[Void Main]

I believe the only think that needs to be done on the server side is to make sure the client is allowed via the "allow-updates" tag in named.conf.