Hi all,

I need help/document paper on HOWTO setup Dynamic DNS on RedHat 9. Some thing like windows 2000 Dynamic DNS. Thanks

Ben,

i thought i knew win2k pretty well but am not familiar with dynamic dns unless you mean 'obtain dns server automatically' in network device configuration which can be done with a dhcp client such as dhcpcd or dhclient

I want my dhcp client able to register name with my RedHat DNS. So that way I don/t worried about create an 'A' record for my host.
DNS on Windows server 2000 have this functionalily.

Anyone know how to get this setup in RedHat 9 DNS, please advise.

Thanks...

If you are going to be working with DNS, I recommend "DNS and Bind" and the "DNS & Bind Cookbook" both by O'Reilly. These are the bibles of DNS.

First you need to set up your domain to accept dynamic updates.

From "DNS & Bind Cookbook"

zone "foo.example" {
type master;
file "db.foo.example";
allow-update { 192.168.0.4; };
};

The zone statement should be modified to your domain name.

The file statement should be the name of the file your zone data will be stored in.

The allow-update statement should be modified to contain the hosts you want to be able to update DNS. This is typically your DHCP server. If you want *every* host on a subnet to be able to update DNS then change the IP to a subnet:

ex. 192.168.0/24; for a whole class C
192.168/16; for a class B
192/8; for a class A

Since it sounds like you will be running a mixed environment (windows/linux) you can't currently take advantage of Transaction SIGnatures (TSIG) to sign updates. If you could, there is a more granular control mechanism called update-policy.

You should also create a sub-domain for dynamic updates. This will prevent clients from naming themselves www and taking out your web server.

ex.

zone "foo.example" {
type master;
file "db.foo.example";
};

zone "dyno.foo.example" {
type master;
file "db.dyno.foo.example";
allow-update { 192.168.0/24; };
};

Now clients in the dyno subdomain can name themselves whatever they want without impact to production servers.

If a Windows client detects a conflicting name, it will try to delete it from DNS than add itself. This behavior can be modified as follows:

Microsoft Knowledge Base article Q246804 to tell the client not to delete conflicting records. The price? A client can't differentiate between an address being used by a different host with the same domain name and an address that formerly belonged to it, so if the client changes addresses, it can't automatically update the zone.
(DNS & Bind, 4th Edition)

Hope this was helpful.

-Glenn

Thanks Glenn,

Do I do anything on zone files locate at /var/named/ ?
Anything I need to do at client side and or at DHCP server?

Thanks again...

Ben,

try

www.pcquest.com

they carried an article on DDNS with explanation on how to set it up

Hello all :-)

In DDNS, which files DNS update client 'A record' on the DNS server. Is it the same files locate at /var/named/yourdomain.zone ?

My DDNS still not working, I am not sure what went wrong?

Thanks,

BEn

For DDNS to work. Do I really need to configure this file on my client?
---------------------------------------------------
/etc/dhclient.conf

send fqdn.fqdn "<client-fqdn>";
send fqdn.encoded on;
send fqdn.server-update off;

key <keyname> {
algorithm HMAC-MD5;
secret "<keydata">;
}

zone <zone-fqdn> {
key "<keyname>";
}
---------------------------------------------

<keyname> is the name of the key chosen when the key was generated

<keydata> is the string after the Key: line in the generated key file

Where I use this to generate the key:

$ dnssec-keygen -a HMAC-MD5 -b 512 -n HOST <keyname>

My question are:
1/ What is HOST here?
2/ What can I get\copy keydata?


Help...Help...

BEn

Sorry for the delay, my real job expects me to put in an appearance once in a while

Assuming a BIND DNS server (9.2.1+) and an ISC DHCP server (3.0+):

In all cases, replace foo.com with your domain name.

I. DHCP Server Configuration

On the DHCP Server, edit the dhcp.conf file and add:

ddns-domainname "foo.com";
ddns-rev-domainname "in-addr.arpa";

Note: do not modify the in-addr.arpa domain.

ddns-update-style interim;
ignore client-updates;

These statements tell the DHCP server to handle the dynamic updates for the clients

key dhcp-server.foo.com. {
algorithm hmac-md5;
secret "<see key section>";
}

dhcp-server should be changed to the hostname of your DHCP server

Finally, add zone statements to the dhcp.conf file:

zone foo.com {
primary 127.0.0.1;
key dhcp-server.foo.com.;
}

zone 0.1.168.192.in-addr.arpa. {
primary 127.0.0.1;
key dhcp-server.foo.com.;
}

Notes: The hostname in the key statement must match the key clause entered above.

I assumed that the DNS and DHCP server were on the same machine, hence the 127.0.0.1. If they are on different systems, change the Primary IP to that of your DNS server.

I also assumed that your IP subnet was 192.168.1. You should change the second zone to reflect your actual configuration. Remember the reverse notation for an in-addr.arpa domain name.

Remember that the trailing period (.) after the domain names is very important.

II. Key Setup
To set up the secret keys:

dnssec-keygen -a HMAC-MD5 -b 512 -n HOST dhcp-key

Where:
-a is the Algorithm
-b is the key size
-n is the key type (HOST is the type)
dhcp-key is the keyname

The dnssec-keygen command should be entered exactly as shown above.

The dnssec-keygen command will respond with a filename, similar to: dhcp-key.+157+22603

The file, dhcp-key.+157+22603.key should contain something similar to:

dhcp-key. IN KEY 512 3 157 XvqePraEZ0jNklEMu5lfzw==

The last field is the key that should replace <see key section>. The replacement is inclusive of the <> characters, but not the quotes.

III. DNS Server Configuration:

Now we need to work on the DNS server.
Add the key clause, from above, to the named.conf file:

key dhcp-server.foo.com. {
algorithm hmac-md5;
secret "<see key section>";
}

In the named.conf file modify the zone statements as follows:

zone "foo.com" {
type master;
file "db.foo.com";
update-policy {
grant dhcp-server.foo.com. wildcard *.nxdomain.com. A TXT;
};
};

zone "0.1.168.192.in-addr.arpa" {
type master;
file "db.192.168.1.0";
update-policy {
grant dhcp-server.foo.com. wildcard *.1.168.192.in-addr.arpa. PTR;
};
};

Notes:
foo.com should be changed to your domain name
db.foo.com should be changed to the file containing the "foo.com" zone records.
dhcp-server.foo.com should be changed to the hostname of your dhcp server.
.nxdomain.com will prevent the DHCP server from updating the domain name for the zone. This should not be changed.
0.1.168.192 should be changed to your IP subnet (in reverse notation)
db.192.168.1.0 should be changed to the file containing the "192.168.1.0" zone records.

This configuration only allows updates to the A and TXT records for the forward (foo.com) domain and PTR records for the reverse (192.168.1.0) domain.


This configuration is fairly straitforward and doesn't require you to change every client on your network. The servers do all the work for you, as it should be

I think I have everything here. Please let me know how you make out.

The examples I provided are heavily based upon the DNS&BIND Cookbook from O'Reilly. I strongly recommend this book.

-Glenn

we tried out your example and still could not get it to work and we are not sure why but we did use this tutorial and got it to work on the first try
this one doesnt use a key

http://voidmain.kicks-ass.net/redhat...namic_dns.html

the key i generated using your example gave me this:
dhcp-key. IN KEY 512 3 157 Hb3MYmhiav8nr+5FNZIGdi5UoI193Q5aHLwS4Uo/FIS9zI5t79gNHYoo gOZuJpuDZAGtDb6/MWhOqjUA8i+uWw==

which part is the key? i used the whole:
Hb3MYmhiav8nr+5FNZIGdi5UoI193Q5aHLwS4Uo/FIS9zI5t79gNHYoo gOZuJpuDZAGtDb6/MWhOqjUA8i+uWw==

and it gave me an error

Starting dhcpd: Internet Software Consortium DHCP Server V3.0pl1
Copyright 1995-2001 Internet Software Consortium.
All rights reserved.
For info, please visit http://www.isc.org/products/DHCP
/etc/dhcpd.conf line 7: invalid base64 character 32.
secret "Hb3MYmhiav8nr+5FNZIGdi5UoI193Q5aHLwS4Uo/FIS9zI5t79gNHYoo gOZuJpuDZAGtDb6
^
/etc/dhcpd.conf line 12: unknown key ns1.vnclassified.com.
key ns1.vnclassified.com.;
^
/etc/dhcpd.conf line 17: unknown key ns1.vnclassified.com.
key ns1.vnclassified.com.;
^
Configuration file errors encountered -- exiting

If you did not get this software from ftp.isc.org, please
get the latest from ftp.isc.org and install that before
requesting help.

If you did get this software from ftp.isc.org and have not
yet read the README, please read it before requesting help.
If you intend to request help from the dhcp-server@isc.org
mailing list, please read the section on the README about
submitting bug reports and requests for help.

Please do not under any circumstances send requests for
help directly to the authors of this software - please
send them to the appropriate mailing list as described in
the README file.

exiting.
[FAILED]

the tutorial on that site doesnt mention using a key other then the rndckey.....what is the benefit of using a key?
thanks for you help and info

also he doesnt use zones in the dhcp

could you tell me about that as well

Here are my configuration file that are currently working. There are a couple of chages from my previous note due to differences between the current software and the book.

Bind 9.2.1 named.conf

options {
directory "/var/named";
};

// DHCP Server Keyfile
// I shortened the key for clarity, you should use the full key.
// Note: This key MUST be enclosed by quotes
key sedona.bell.home. {
algorithm hmac-md5;
secret "OKW4+iyG4Vjy0YYiopBlxtlfAoeE1g==";
};

// This statement associates the key to a server.
server 127.0.0.1 {
keys { sedona.bell.home.; };
};

//
// a master nameserver config
//
// Hints file. Pretty standard.
zone "." IN {
type hint;
file "named.ca";
};

// Again a pretty standard localhost zone
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; };
};

// The forward zone I want to be able to update.
// Note the change in the grant statement. I replaced the *.nxdomain.com with *.bell.home.
// This only allows A and TXT record updates.
zone "bell.home" IN {
type master;
file "master/bell.home";
update-policy {
grant sedona.bell.home. wildcard *.bell.home. A TXT;
};
};

// The reverse domain to be updated.
zone "1.168.192.in-addr.arpa" IN {
type master;
file "master/192.168.1.rev";
update-policy {
grant sedona.bell.home. wildcard *.1.168.192.in-addr.arpa. PTR;
};

ISC DHCPD 3.0p1 dhcpd.conf
# dhcpd.conf
#

# option definitions common to all supported networks...
option domain-name "bell.home";
option domain-name-servers sedona.bell.home;

default-lease-time 600;
max-lease-time 7200;

# DDNS configurations
ddns-domainname "bell.home";
ddns-rev-domainname "in-addr.arpa";
ddns-update-style interim;
ignore client-updates;

# This defines the key to use
# Note this key must NOT be enclosed by quotes
key sedona.bell.home. {
algorithm hmac-md5;
secret OKW4+iyG4Vjy0YYiopBlxtlfAoeE1g==;
}

# Which zone do I want to update?
# Where is the primary DNS server?
# Which key should I use to authenticate the update?
zone bell.home. {
primary 127.0.0.1;
key sedona.bell.home.;
}

zone 0.1.168.192.in-addr.arpa. {
primary 127.0.0.1;
key sedona.bell.home.;
}

# If this DHCP server is the official DHCP server for the local
# network, the authoritative directive should be uncommented.
authoritative;

# Use this to send dhcp log messages to a different log file (you also
# have to hack syslog.conf to complete the redirection).
log-facility local7;

# This is a very basic subnet declaration.

subnet 192.168.1.0 netmask 255.255.255.0 {
range 192.168.1.10 192.168.1.30;
option routers bell-gw.bell.home;
}

This should do it If the Linux Gods are smiling

As I said, I am currently using these files successfully. If you still have problems, please post the errors.

Taking a look at your earlier error message, it looks like you didn't put a space between secret and the key. Even if you had; however, the quotes would still have nailed you (they did me ;( )

The shared keys are a means of ensuring that the server making the update request is really who you think it is. If all you use is an IP Address, anyone with the ability to spoof an IP will be able to update your DNS tables. Generally, a bad thing

Hopefully we got it now.

-Glenn

Oh one quick note. Once you start using DDNS, don't edit your zone files by hand any more. That will really screw things up since the state of the zone files is maintained in the actual db files and journal files.

BTW the journal files are not human readable.

You should probably use nsupdate to update your zones once you go dynamic.

-Glenn

Me and my buddy will try tomorrow morning. One other thing. How do you force client to update dns record with dns server without reboot the client. In microsoft environment. We used ipconfig/registerdns. Do we have such command like this exist in linux environment.

Again, thanks for help. We do appriciate your input here.

BEn,

i found these sites quite helpful
(i think they are nearly the same)

http://www.ibiblio.org/pub/Linux/docs/HOWTO/DNS-HOWTO
http://www.redhat.com/mirrors/LDP/HOWTO/DNS-HOWTO.html