Can't get dynamic DNS update working on Fedora Core 1

[mraible]

I have (previously) install the dynamic dns update on Red Hat 9 without any issues. However, I am having issues with Fedora Core 1. I removed the included rndc.key from named.conf and regenerated both rndc.conf and the contents of rndc.key - here's what I have:

Code: Select all

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

key "rndc-key" {
      algorithm hmac-md5;
      secret "xxx";
};

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

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

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

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

zone "raibledesigns.home" in {
        type master;
        file "raibledesigns.home.zone";
        allow-update { 127.0.0.1; };
};

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

And my rndc.conf has:

Code: Select all

key "rndc-key" {
        algorithm hmac-md5;
        secret "xxx";
};

options {
        default-key "rndc-key";
        default-server 127.0.0.1;
        default-port 953;
};

My secrets do match. When I restart named, I get the following error and it won't load my LAN's config (raibledesigns.home.zone):

Code: Select all

Nov 26 11:55:47 drevil named[4317]: invalid command from 127.0.0.1#32810: bad auth
Nov 26 11:55:48 drevil named[4317]: shutting down
Nov 26 11:55:48 drevil named[4317]: stopping command channel on 127.0.0.1#953
Nov 26 11:55:48 drevil named[4317]: no longer listening on 127.0.0.1#53
Nov 26 11:55:48 drevil named[4317]: no longer listening on 192.168.0.2#53
Nov 26 11:55:48 drevil named[4317]: exiting
Nov 26 09:55:48 drevil named: named shutdown succeeded
Nov 26 11:55:50 drevil named[4351]: starting BIND 9.2.2-P3 -u named -t /var/named/chroot
Nov 26 11:55:50 drevil named[4351]: using 1 CPU
Nov 26 11:55:50 drevil named[4351]: loading configuration from '/etc/named.conf'
Nov 26 09:55:50 drevil named: named startup succeeded
Nov 26 11:55:50 drevil named[4351]: no IPv6 interfaces found
Nov 26 11:55:50 drevil named[4351]: listening on IPv4 interface lo, 127.0.0.1#53
Nov 26 11:55:50 drevil named[4351]: listening on IPv4 interface eth0, 192.168.0.2#53
Nov 26 11:55:50 drevil named[4351]: command channel listening on 127.0.0.1#953
Nov 26 11:55:50 drevil named[4351]: running

Any ideas?

When I try to update from my OS X box, I get the following in /var/log/messages:

Code: Select all

Nov 26 09:57:53 drevil dhcpd: if IN A foxxy.voidmain.home domain doesn't exist add 86400 IN A foxxy.
voidmain.home 192.168.0.198 add 86400 IN TXT foxxy.voidmain.home "31928ca9ec0b318d81f3dac9f14626670b
": timed out.
Nov 26 09:57:53 drevil dhcpd: DHCPREQUEST for 192.168.0.198 from 00:0a:95:f2:86:9c via eth0
Nov 26 09:57:53 drevil dhcpd: DHCPACK on 192.168.0.198 to 00:0a:95:f2:86:9c (foxxy) via eth0
Nov 26 09:57:54 drevil dhcpd: if IN A foxxy.voidmain.home domain doesn't exist add 86400 IN A foxxy.
voidmain.home 192.168.0.198 add 86400 IN TXT foxxy.voidmain.home "31928ca9ec0b318d81f3dac9f14626670b
": timed out.
Nov 26 09:57:54 drevil dhcpd: DHCPREQUEST for 192.168.0.198 from 00:0a:95:f2:86:9c (foxxy) via eth0
Nov 26 09:57:54 drevil dhcpd: DHCPACK on 192.168.0.198 to 00:0a:95:f2:86:9c (foxxy) via eth0

[Void Main]

Very bad timing. I am just about to leave for 4 days for the holiday but initially I see your log has "voidmain.home" errors yet you have no "voidmain.home" zone defined in your named.conf. It may very well have nothing at all to do with your problem and I am sorry I can't look into it in more detail right now, hopefully someone else can help you work through it, otherwise it will be at least Monday before I can help. I can say that I have upgraded all my RH9 boxes to Fedora and haven't had any dynamic DNS issues. Sorry about that!

[mraible]

Rebooting got rid of "voidmain.home"

I think my issue has to do with rndc - when I shut down named, I get the following error:

[root@drevil chroot]# /etc/init.d/named stop
Stopping named: rndc: connection to remote host closed
This may indicate that the remote server is using an older version of
the command protocol, this host is not authorized to connect,
or the key is invalid.
[ OK ]

I re-generated my rndc key using rndc-confgen, but it doesn't seem to be working.

[Void Main]

Hmm, is your named running? When I run "service named status" I get:

Code: Select all

# service named status
number of zones: 7
debug level: 0
xfers running: 0
xfers deferred: 0
soa queries in progress: 0
query logging is OFF
server is up and running


It does look like your rndc files are messed up. What do your /etc/rndc.key and /etc/rndc.conf fils look like? Mine look like this:

/etc/rndc.conf:

Code: Select all

options {
        default-server  localhost;
        default-key     "key";
};
 
server localhost {
        key     "key";
};
 
key "key" {
        algorithm       hmac-md5;
        secret "void main's secret key removed from here but had a lot of letters";
};


/etc/rndc.key

Code: Select all

key "rndckey" {
        algorithm       hmac-md5;
        secret "void main's secret key removed from here but had a lot of letters";
};


and at the end of my /etc/named.conf I have:

Code: Select all

include "/etc/rndc.key";


The rndc-genconf should generate something similar. You could copy the above and insert the actual base64 key string from the rndc-genconf generated one and insert in both spots where I have replaced it above with the "void main" comment. It should just work.

[mraible]

It doesn't look like named is running when I looked at this tonight:

Code: Select all

[root@drevil mraible]# /sbin/service named status
rndc: connection to remote host closed
This may indicate that the remote server is using an older version of
the command protocol, this host is not authorized to connect,
or the key is invalid.


However, when I tried to restart it, it said it was running. I did your suggestions - and now my files look *exactly* the same as the files I downloaded from your site - except for my own domain name and my own key. I'm sure it's something super simple, I'm just not seeing it. Here's what I get (after your mods) when I do ipconfig /renew on my XP box:

Code: Select all

Dec  2 22:05:55 drevil dhcpd: DHCPDISCOVER from 00:07:e9:ea:3b:a5 (fatbastard) via eth0
Dec  2 22:05:56 drevil dhcpd: DHCPOFFER on 192.168.0.199 to 00:07:e9:ea:3b:a5 (fatbastard) via eth0
Dec  2 22:05:58 drevil dhcpd: if IN A fatbastard.raibledesigns.home domain doesn't exist add 43200
N A fatbastard.raibledesigns.home 192.168.0.199 add 43200 IN TXT fatbastard.raibledesigns.home "31a
28484332e8162dfafe5f272886dac0": timed out.
Dec  2 22:05:58 drevil dhcpd: DHCPREQUEST for 192.168.0.199 (192.168.0.2) from 00:07:e9:ea:3b:a5 (f
tbastard) via eth0
Dec  2 22:05:58 drevil dhcpd: DHCPACK on 192.168.0.199 to 00:07:e9:ea:3b:a5 (fatbastard) via eth0


I can't ping fatbastard or do "host fatbastard":

Code: Select all

[mraible@drevil mraible]$ ping fatbastard
ping: unknown host fatbastard
[mraible@drevil mraible]$ host fatbastard
Host fatbastard not found: 3(NXDOMAIN)


My /etc/resolve.conf has:

Code: Select all

search raibledesigns.home
nameserver 127.0.0.1
nameserver 216.148.227.68
nameserver 204.127.202.4


[mraible]

I finally solved the problem - which I believe was caused by having a different version of rndc than I did of named. This might have been caused when I did configure, make, make install with bind 9.2.3. I did rpm -e bind and then proceeded to uninstall and the dependencies using rpm -e dependency-name. Then I tried doing configure, make, make install again with bind 9.2.3. It didn't install the named service, and I couldn't get it working without it, so I reverted back to the RPM route (w/o uninstalling 9.2.3). I read somewhere it's easier to remove the startup script than to uninstall.

Then I did apt-get install bind. It downloaded bind-utils and bind and installed them. I renamed my *.rpmsave files back to their original names (i.e. named.conf, rndc.conf, etc.) and restarted named. No issues now and everything works!

Thanks for the great howto!

Matt[/i]

[knothead]

I found this thread when I was struggling with ddns on fedora core 1. The problem I was having was that /etc/named.conf doesn't do a thing on fedora if you have bind-chroot installed (rpm -qa | grep bind-chroot). You have to edit /var/named/chroot/etc/named.conf. By the same token, none of my zones were being loaded either. They're located in /var/named/chroot/var/named/. There's a chroot directory in /var/named/chroot/var/named: just ignore it and you should be fine. I'm not sure why it's there but putting files in there doesn't seem to have an effect. I realized that the syslog (tail -f /var/log/messages) prints out info from named when zones are loaded, and that I was missing those lines in my syslog. I hope this helps someone avoid the same problem.

Ryan

[mraible]

I found this thread when I was struggling with ddns on fedora core 1. The problem I was having was that /etc/named.conf doesn't do a thing on fedora if you have bind-chroot installed (rpm -qa | grep bind-chroot). You have to edit /var/named/chroot/etc/named.conf. By the same token, none of my zones were being loaded either. They're located in /var/named/chroot/var/named/. There's a chroot directory in /var/named/chroot/var/named: just ignore it and you should be fine. I'm not sure why it's there but putting files in there doesn't seem to have an effect. I realized that the syslog (tail -f /var/log/messages) prints out info from named when zones are loaded, and that I was missing those lines in my syslog. I hope this helps someone avoid the same problem.

Ryan

I actually ran into this problem again. After reading your post above, I simply removed bind-chroot (rpm -e bind-chroot) and it fixed the problem. Any idea what bind-chroot does and why I might need it?

Thanks,

Matt

[Linux Frank]

From rpmfind.net

The bind-chroot packages runs the DNS server daemon under the non-root user and group and in the chroot()ed directory.

Does not look like you need it unless you need someone else to have control of Bind without root access. Although I'm no expert.

[Void Main]

When you run something in a "chrooted" directory it is similar to running something in a "jail" in BSD. Basically it restricts the program from seeing your entire directory structure. It can only see what is under the new root directory that was chrooted to. So if someone where to find a buffer overflow exploit in bind (what are the chances?) they can not get access to the rest or your system through it. It is *much* more secure. Having said that, I have never run the chrooted version of bind personally. I have had a machine exploited through bind a few years ago and this would have prevented the root kit from being installed and having the machine turned into a DDoS client.

[Linux Frank]

Thanks Void, that is so much clearer than the description I had, which rabbited on for about 10 pages about permissions, and never gave a summary statement or anything, and left me feeling rather lost. Now I understand that some of the description makes more sense.