troubles with dns, journal keeps growing, bogus static IP

I'm running bind 9.9.7 on Slackware64 14.1. I have two problems (that I know of) with my dns. These may be related:

1. my domain zone file, /etc/samba/private/dns/hprs.local.zone.jnl, when listed with named-journalprint, is currently at 111,938 lines. It appears that it has everything from the day I first installed this host 8 months ago. There are hosts in the list that haven't been connected since then. Aren't these suppose to get "updated" into the main zone file periodically? If so, what process is supposed to do it?

2. All the legitimate workstations in the domain have IP addresses assigned by dhcpd running on this same server. I just added a new host (/etc/dhcpd.conf fragment):

host labrat {
    hardware ethernet D0:67:E5:xx:yy:zz;
    fixed-address 192.168.0.99;
}

DHCP *is* giving that host the correct address, but dns doesn't see it correctly:

$ host labrat
labrat.hprs.local has address 192.168.0.125

When I examine hprs.local.zone file, that *is* in fact the IP inside the zone file.

That IP for this host is also in the journal file. Lines in journal are:

111887  add WIN-6HM3EDL61FE.hprs.local. 3600 IN A       192.168.0.125
111890  del WIN-6HM3EDL61FE.hprs.local. 3600 IN A       192.168.0.125
111897  add labrat.hprs.local.  3600    IN      A       192.168.0.125
111898  add labrat.hprs.local.  3600    IN      TXT     "31c3a2afaf8f2ec7aeb8becc5c4f0d9e9e"

Open in new window


and my dhcpd log has:
Oct 29 19:06:14 mail dhcpd: DHCPDISCOVER from d0:67:e5:4f:02:6d via eth1
Oct 29 19:06:15 mail dhcpd: DHCPOFFER on 192.168.0.125 to d0:67:e5:4f:02:6d (WIN-6HM3EDL61FE) via eth1
Oct 29 19:06:18 mail dhcpd: DHCPDISCOVER from d0:67:e5:4f:02:6d (WIN-6HM3EDL61FE) via eth1
Oct 29 19:06:18 mail dhcpd: DHCPOFFER on 192.168.0.125 to d0:67:e5:4f:02:6d (WIN-6HM3EDL61FE) via eth1
Oct 29 19:06:26 mail dhcpd: DHCPDISCOVER from d0:67:e5:4f:02:6d (WIN-6HM3EDL61FE) via eth1
Oct 29 19:06:26 mail dhcpd: DHCPOFFER on 192.168.0.125 to d0:67:e5:4f:02:6d (WIN-6HM3EDL61FE) via eth1
Oct 29 19:06:26 mail named[5002]: client 192.168.0.2#56165: updating zone 'hprs.local/IN': adding an RR at 'WIN-6HM3EDL61FE.hprs.local' A
Oct 29 19:06:26 mail named[5002]: client 192.168.0.2#56165: updating zone 'hprs.local/IN': adding an RR at 'WIN-6HM3EDL61FE.hprs.local' TXT
Oct 29 19:06:27 mail dhcpd: Wrote 0 deleted host decls to leases file.
Oct 29 19:06:27 mail dhcpd: Wrote 0 new dynamic host decls to leases file.
Oct 29 19:06:27 mail dhcpd: Wrote 25 leases to leases file.
Oct 29 19:06:27 mail dhcpd: DHCPREQUEST for 192.168.0.125 (192.168.0.2) from d0:67:e5:4f:02:6d (WIN-6HM3EDL61FE) via eth1
Oct 29 19:06:27 mail dhcpd: DHCPACK on 192.168.0.125 to d0:67:e5:4f:02:6d (WIN-6HM3EDL61FE) via eth1
Oct 29 19:06:27 mail dhcpd: Added new forward map from WIN-6HM3EDL61FE.hprs.local. to 192.168.0.125

Open in new window

Where this certainly originally started is when I initially booted this new laptop in Windows (hence the WIN-6HM3EDL61FE hostname) and it simply got an IP address assigned from DHCPD. I named the Windows host 'labrat' and that name shows up a few lines later in the dhcpd log. Then I installed Linux/Ubuntu and it requested IP 192.168.0.126, but "unsuccessfully" updated the zone file:
Oct 29 19:41:27 mail dhcpd: DHCPDISCOVER from d0:67:e5:4f:02:6d (ubuntu) via eth1
Oct 29 19:41:28 mail dhcpd: DHCPOFFER on 192.168.0.126 to d0:67:e5:4f:02:6d (labrat) via eth1
Oct 29 19:41:28 mail named[5002]: client 192.168.0.2#56165: updating zone 'hprs.local/IN': update unsuccessful: labrat.hprs.local: 'name not in use' prerequisite not satisfied (YXDOMAIN)
Oct 29 19:41:28 mail dhcpd: DHCPREQUEST for 192.168.0.126 (192.168.0.2) from d0:67:e5:4f:02:6d (labrat) via eth1
Oct 29 19:41:28 mail dhcpd: DHCPACK on 192.168.0.126 to d0:67:e5:4f:02:6d (labrat) via eth1
Oct 29 19:41:28 mail named[5002]: client 192.168.0.2#56165: updating zone 'hprs.local/IN': update unsuccessful: labrat.hprs.local/TXT: 'RRset exists (value dependent)' prerequisite not satisfied (NXRRSET)
Oct 29 19:41:28 mail dhcpd: Forward map from labrat.hprs.local. to 192.168.0.126 FAILED: Has an address record but no DHCID, not mine.

Open in new window

After all that, I finally configured DHCPD to offer a specific IP (192.168.0.99), but got errors with "'name not in use' prerequisite not satisfed", presumably because the name <u>labrat</u> is already assigned to 192.168.0.125:
Oct 29 21:16:51 mail dhcpd: DHCPDISCOVER from d0:67:e5:4f:02:6d via eth1
Oct 29 21:16:51 mail dhcpd: DHCPOFFER on 192.168.0.99 to d0:67:e5:4f:02:6d via eth1
Oct 29 21:16:51 mail dhcpd: DHCPREQUEST for 192.168.0.99 (192.168.0.2) from d0:67:e5:4f:02:6d via eth1
Oct 29 21:16:51 mail dhcpd: DHCPACK on 192.168.0.99 to d0:67:e5:4f:02:6d via eth1
Oct 29 21:16:51 mail named[5002]: client 192.168.0.2#39066: updating zone 'hprs.local/IN': update unsuccessful: labrat.hprs.local: 'name not in use' prerequisite not satisfied (YXDOMAIN)
Oct 29 21:16:51 mail named[5002]: client 192.168.0.2#39066: updating zone 'hprs.local/IN': update unsuccessful: labrat.hprs.local/TXT: 'RRset exists (value dependent)' prerequisite not satisfied (NXRRSET)
Oct 29 21:16:51 mail dhcpd: Forward map from labrat.hprs.local. to 192.168.0.99 FAILED: Has an address record but no DHCID, not mine.

Open in new window

It should also be mentioned that IP 192.168.0.125 *is* in the hprs.local.zone and hprs.local.zone.jnl files, but was in neither yesterday, so the domain zone file is getting updated (but why the 111,000+ entries in the journal file?).

So, why is this all messed up and how do I fix it? I need labrat to be 192.168.0.99 and for the dns to forget about 192.168.0.125! Oh yeah, and for my journal file to *not* be 111,000+ lines!
LVL 1
jmarkfoleyAsked:
Who is Participating?
I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

Muhammad BurhanManager I.T.Commented:
0

Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
jmarkfoleyAuthor Commented:
I ran `rndc sync -clean` and that did clean up the zone file, but really? That's how it's supposed to work? journal files just grow infinitely until `rndc sync -clean` is run? I've never heard of that command before and over the past year have crawled through a dozen or so "how to set up dns" sites. None has ever mentioned that to my recollection!

I ran this with named running, but is it best to stop named first? Or does it have to be running to work?
0
jmarkfoleyAuthor Commented:
It looks like my 2nd issue (IP 192.168.0.125 versus 192.168.0.99) resolved itself. Today I get:

$ host labrat
labrat.hprs.local has address 192.168.0.99

I'm guessing that the problem here was that my zone file lease expiration was set to 8 hours so I had to wait 8 hours for the 192.168.0.125 lease to go away.

I'll leave this open a bit longer for further comments, esp. on the first part about syncing the journals.
0
ON-DEMAND: 10 Easy Ways to Lose a Password

Learn about the methods that hackers use to lift real, working credentials from even the most security-savvy employees in this on-demand webinar. We cover the importance of multi-factor authentication and how these solutions can better protect your business!

Dan CraciunIT ConsultantCommented:
DNS is just too important to configure it using internet tutorials.

Get the book and read it.

After that you'll be able to configure DNS and understand why it works or not.

HTH,
Dan
0
jmarkfoleyAuthor Commented:
I have the book. Still confusing.

In fact, just checked the book based on your comment. Maybe my edition is too old (Bind and DNS, O'Reiley, 4th Edition), does cover bind9, but no mention of infinitely growing journal files, `rndc sync` (though rndc is mentioned), nor cleaning journal files. Where did you come by this knowledge? The Book? Maybe I need to update to 5th edition.
0
Dan CraciunIT ConsultantCommented:
You have the book and you read it. Great!
There are some sysadmins that manage DNS without having a good understanding of it.

AFAIK, "rndc sync" is new, introduced with BIND 9.9.
In this case, to find out about the new features, you should read the release notes:
https://ftp.isc.org/isc/bind/9.9.0/RELEASE-NOTES-BIND-9.9.0.txt
0
jmarkfoleyAuthor Commented:
Ok, so then I'm curious ... how did netadmins deal with the growing journal file / clean problem before 9.9?

btw - my dns/dhcp setup is running on a Samba4 AD/DC replacing a Windows SBS 2008 server. Windows 7 workstations and Samba want to update the zone files, so there's a lot going on that is not "normal". Everything works just fine, and now I've put the `rndc sync -clean` into logrotate, so that problem is solved.

For a share of the points, can you tell me if I should stop named before doing the 'clean' or does it have to be running for rndc to work? I did it manually with named running.
0
Dan CraciunIT ConsultantCommented:
I use rndc so I don't need to restart named.
Especially on busy caching servers, rndc reload to re-read the zone configuration files without emptying the cache is a life saver.
0
It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today
Linux Networking

From novice to tech pro — start learning today.

Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.