• Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 5675
  • Last Modified:

Dynamic DNS updates fail, journal rollforward error

I have a DHCP server with 2 NICs and IP forwarding; the DHCP server (server2) runs off NIC2 /subnet2 and the backup DNS server (also server2) runs off NIC1 in subnet1.
The client is accepting DHCP offers from server2 but can't resolve any URLs except www.mydomain.com.
The error on server1 is:
named[pid]: zone mydomain.com/IN: journal rollforward failed: no more
I have jnl files in /var/named/chroot/var/named with 660 permissions (I had to create those files) so I don't know what to do next.  Ideas?
The error on server2 is:
Oct 13 10:08:10 server2 named[pid]: client server2-ip#33232: update forwarding 'mydomain.com/IN' denied
Oct 13 10:08:10 server2 dhcpd: Unable to add forward map from client.mydomain.com to 192.168.1.131: timed out

0
sara_bellum
Asked:
sara_bellum
  • 13
  • 13
  • 8
1 Solution
 
nociSoftware EngineerCommented:
Is the process the name daemon is running under the owner of the /var/named/chroot/var/named directory? named should be able to handle file creation in there that way.
0
 
sara_bellumAuthor Commented:
The bind daemon is running as named on both servers
All  /var/named/chroot/var/named files on the primary server are owned by named.named with 644 permissions.
On the secondary server, all zone files in the slaves folder are owned by named.named, but the default localdomain.zone, localhost.zone, named.broadcast, named.ca, named.local and named.zero (is this one for ipv6?) files in /var/named/chroot/var/named are all owned by root.named, with 640 permissions.  I'm changing the permissions & ownership of these files to match the primary server; we'll see if this helps :)
 
0
 
nociSoftware EngineerCommented:
The next question, did you setup authentication between the DHCP server and the DNS server?
0
 The Evil-ution of Network Security Threats

What are the hacks that forever changed the security industry? To answer that question, we created an exciting new eBook that takes you on a trip through hacking history. It explores the top hacks from the 80s to 2010s, why they mattered, and how the security industry responded.

 
Gabriel OrozcoSolution ArchitectCommented:
named need to be able to
a) write to the directory
b) overwrite the zone files.

when named is running, it creates the zone files to maintain a database of updates.
when named closes, it updates the zone files and you can delete the .jnl ones. I do it more or less often. monthly...
0
 
sara_bellumAuthor Commented:
No noci, I didn't set up authentication between the dhcp and the dns server...not sure if that's the problem (yet).
The permissions on /var/named/chroot/var/named are 750 and the permissions on the zone files are 644 (both servers now).  That should be sufficient for the named daemon to write/overwrite to files which it owns, so I don't understand why I see these errors:
(192.168.1.1 = server1, 192.168.1.2 = server2 secondary dns, 192.168.2.3 = dhcp NIC on server2)
# Oct 16 00:13:39 server1 named[4879]: client 192.168.1.2#33284: update 'mydomain.com/IN' denied
# Oct 16 00:13:39 server2 named[11532]: client 192.168.1.2#33284: update forwarding 'mydomain.com/IN' denied
# Oct 16 00:13:39 server2 dhcpd: Unable to add forward map from client_host.mydomain.com to 192.168.2.3: timed out

 
0
 
Gabriel OrozcoSolution ArchitectCommented:
okay...

I see you have not used dns-sec before.
you need to create a unique key for your domain. then you need to add that key to your zone definition on named.conf so named knows which key updates which zone.

then you need to add the key to your dhcpd.conf so dhcp knows which key to use to update that zone.

-create key:
dnssec-keygen -a hmac-md5 -b 128 -n HOST DHCP_UPDATER

this will create two files in /etc with KDHCP_UPDATER.*
look at these and inside you will find a string like:  w5vhjpxxgSR6jxEvG2L06g==

that string you need to add in your named.conf like in
key DHCP_UPDATER {
  algorithm hmac-md5;
  secret w5vhjpxxgSR6jxEvG2L06g==;
};

now you add to your zone like:
zone "your.internal.dns" {
        type master;
        allow-update   { key DHCP_UPDATER; };
        file "your.internal.dns.zone";
};

-------------------------------------------------------------
and in your dhcpd.conf:

key DHCP_UPDATER {
  algorithm hmac-md5;
  secret w5vhjpxxgSR6jxEvG2L06g==;
};

zone "your.internal.dns" {
  key DHCP_UPDATER;
}

#assuming your network is 192.168.0.0/24, this is the reverse resolver:
zone 0.168.192.in-addr.arpa {
  key DHCP_UPDATER;
}
allow client-updates;

This should work... I have it working on an old install

0
 
nociSoftware EngineerCommented:
Well it is almost answered now...
But there are some finer details...
You will also need a primary statement to specify the DNS server to update for the zone (MASTER).
 so the dhcpd.conf  should contain:

--8<--
key DHCP_UPDATER {
  algorithm hmac-md5;
  secret w5vhjpxxgSR6jxEvG2L06g==;
};

zone "mydomain.com" {
  primary 192.168.1.1;
  key DHCP_UPDATER;
};
# your network is 192.168.1.0/24, this is the reverse resolver:
zone 1.168.192.in-addr.arpa {
  primary 192.168.1.1;
  key DHCP_UPDATER;
};
--8<--
#The allow client-updates is not needed (it's default).
For this part try then 'man dhcpd.conf' it is quite detailed why options might be needed.

Also you need to setup signaling of updates between the primary dns server and the secondary ones:

Like alowing transfers from the server1 -> server2

in server1 named.conf:
--8<--
zone "1.168.192.in-addr.arpa" {
        type master;
        notify yes;
        file "pri/db.192.168.1";
        allow-transfer { 192.168.1.2; };
        allow-query { 127/8; 192.168.1/24; };
        forwarders  { };
        allow-update { key DHCP_UPDATER; };
};
zone "mydomain.com" {
        type master;
        notify yes;
        file "pri/db.mydomain.com";
        allow-transfer { 192.168.1.2; };
        allow-query { 127/8; 192.168.1/24; };
        forwarders  { };
        allow-update { key DHCP_UPDATER; };
};

-8<--
You don't actualy need the forwarders clause, it just means it won't look further if the named doesn't know the answer.


on server2:

--8<--
zone "1.168.192.in-addr.arpa" {
        type slave;
        master { 192.168.1.1; } ;
        file "sec/db.192.168.1";
        allow-transfer { };
        allow-notify { 192.168.1.1; }; # optional
        allow-query { 127/8; 192.168.1/24; }; # this audience might be wider.... if its public DNS
        forwarders  { };
};
zone "mydomain.com" {
        type slave;
        master { 192.168.1.1; } ;
        file "sec/db.mydomain.com";
        allow-transfer {  };
        allow-notify { 192.168.1.1; }; #not exactly needed as master is the default here
        allow-query { 127/8; 192.168.1/24; };   # this audience might be wider....
        forwarders  { };
};
--8<--
More info on bind here:
http://www.bind9.net/manual/bind/9.3.2/Bv9ARM.html
0
 
nociSoftware EngineerCommented:
A bit of background:

the DHCP servers update the primary domain controller (just one).
The DNS infrastructure should synchronise itself. (primary -> secondaries).

This way DNS should be consistent (if not only one place to look nl zone transfers).
IF the master doesn't get updated check the DHCP -> primary connection.

HIH.
0
 
Gabriel OrozcoSolution ArchitectCommented:
right as noci write....
0
 
sara_bellumAuthor Commented:
Thank you both very much!  I've been awake for far too long, hopefully this will be coherent.  
The named daemon restarts without error on both servers but dhcp on server2 fails due to configuration errors.  I think the forward and reverse zone declarations are supposed to be part of the subnet declaration but I'm too tired to look up the man pages.  Wasn't sure what options or initial parameters need to be declared either.  What I have now is this, roughly:
server2#cat /etc/dhcpd.conf
authoritative;
ddns-update-style interim;
ignore client-updates;

key DHCP_UPDATER {
        algorithm hmac-md5;
        secret 1234567890;
        };

zone "zone.mydomain.com" {  #the name of the forward lookup file
  primary 192.168.1.1;
  key DHCP_UPDATER;
};

zone "zone.rev.mydomain" {   #the name of the reverse lookup file
  primary 192.168.1.1;
  key DHCP_UPDATER;
};

subnet 192.168.1.128 netmask 255.255.255.128 {

# --- default gateway
        option routers                  192.168.1.129;  #address of the dhcp server (NIC2 on server2, subnet2)
        option subnet-mask              255.255.255.128;
        option domain-name              "mydomain.com";
        option domain-name-servers      192.168.1.1;
        option ip-forwarding            off;
        option nntp-server              192.168.1.1;  #this should be the network time protocol server IP

range dynamic-bootp 192.168.1.130 192.168.1.140;
        default-lease-time 21600;
        max-lease-time 43200;

        # we want the nameserver to appear at a fixed address
        host ns {
                next-server server1.mydomain.com;
                hardware ethernet 00:11:22:33:44:55;
                fixed-address 192.168.1.1;
        }
}

subnet 192.168.1.0 netmask 255.255.255.128 {
 }

Let me know what needs fixing, thanks!

0
 
Gabriel OrozcoSolution ArchitectCommented:
instead
ignore-client-updates
you need
allow-client-updates

and also this
secret 1234567890;

need to be the one you get from creating your own key, as I wrote before.
0
 
nociSoftware EngineerCommented:
The zone statement should contain the name string, not the lookup file.
for both dhcpd aswell as bind.

zone "mydomain.com" {
}

and
zone "1.168.192.in-addr.arpa" {
}

are required.

nntp-server is a news server, you probably mean ntp-servers in dhcpd.conf
The next server only makes sense if you use that server as boot image loader ...
and that makes no sense at all,  [to have a system that needs an address to load its os-loader
from pointing to itself....].

Also it is generaly not wise to have critical infrastructure servers on DHCP
(those are DHCP server and DNS servers, also LDAP servers, KERBEROS servers
are in this category (also Windows DOMAIN controlers).
Those servers need to have fixed addresses.

0
 
sara_bellumAuthor Commented:
Thanks again!

Should have caught the "ignore client updates" but there we are.  The secret file is md5-generated, I just didn't want to post the key online.  I changed the zone file references from file names  to the name of the forward and reverse domains, so I think the fixes you recommend are covered.  I understand that the DHCP server should not be on a critical infrastructure server, but I've complied as far as I can with limited hardware - the secondary DNS on server 2 runs off NIC1, and the only service running on NIC2 is DHCP (which will only support a few clients on my LAN).  My primary and secondary dns and mail servers and the dhcp server all have fixed IP addresses.  

The errors that show up when I try starting up dhcp:
server2 # service dhcpd start
Oct 17 15:19:32 server2 dhcpd: /etc/dhcpd.conf line 15: expecting hostname.
Oct 17 15:19:32 server2 dhcpd: zone "mydomain.com"
Oct 17 15:19:32 server2 dhcpd: ^
Oct 17 15:19:32 server2 dhcpd: /etc/dhcpd.conf line 18: expecting a parameter or declaration
Oct 17 15:19:32 server2 dhcpd: };
Oct 17 15:19:32 server2 dhcpd: ^
Oct 17 15:19:32 server2 dhcpd: /etc/dhcpd.conf line 21: expecting hostname.
Oct 17 15:19:32 server2 dhcpd: zone "1.168.192.in-addr.arpa"
Oct 17 15:19:32 server2 dhcpd: ^
Oct 17 15:19:32 server2 dhcpd: /etc/dhcpd.conf line 24: expecting a parameter or declaration
Oct 17 15:19:32 server2 dhcpd: };
Oct 17 15:19:32 server2 dhcpd: ^
Oct 17 15:19:32 server2 dhcpd: WARNING: Host declarations are global.  They are not limited to the scope you declared them in.
Oct 17 15:19:32 server2 dhcpd: Configuration file errors encountered -- exiting

I thought there might be a conflict between the options declared for the two subnets and the zone declarations  in dhcpd.conf, since both specify  a domain-name server/primary server and a domain name.
0
 
Gabriel OrozcoSolution ArchitectCommented:
key DHCP_UPDATER {
        algorithm hmac-md5;
        secret 1234567890;
}

zone "mydomain.com" {  
  key DHCP_UPDATER;
}

zone 1.168.192.in-addr.arpa {
  key DHCP_UPDATER;
}


that should be it for dhcpd.conf
0
 
sara_bellumAuthor Commented:
I have good news and bad news:  I changed the encryption key to the Fedora/Redhat default used in updating DNS (rndc.key) and was able to start the DHCP server on server2 with only the Warning error shown earlier.  Now external DNS requests are forwarded from the client to server1.  But the server1 error reads;
Oct 17 22:53:46 server1 named[16374]: client 192.168.1.131#1507: updating zone 'mydomain.com/IN': update failed: 'RRset exists (value dependent)' prerequisite not satisfied (NXRRSET)
Oct 17 22:53:46 server1 named[16374]: client 192.168.1.131#1510: update 'mydomain.com/IN' denied
I've checked the zone files and can find no resource records related to this client; I've run ipconfig /flushdns on the client, so I don't know what else to look for...
0
 
Gabriel OrozcoSolution ArchitectCommented:
this is a problem with ISC's dhcpd... last time I checked they were not agreeing in a final solution on how to do this updates, but that was a while ago.

at that time the best option was to have in dhcpd.conf:
ddns-update-style interim;
ddns-updates on;
0
 
Gabriel OrozcoSolution ArchitectCommented:
forgot to say: maybe you want to delete previous records for your machines, since if they do not exist dhcpd will add them with some TXT records to help identify which record it can delete/update.

maybe starting with an almos-empty zone file?
0
 
sara_bellumAuthor Commented:
Thanks :)  I tried the above without result. I host more than one domain, for training mostly, and domain2 supports web and mail.  So  I changed /etc/named.conf on server1 and 2 and /etc/dhcpd.conf on server2 to accept ddns updates for domain2.  The error is now:
server1 named[19768]: client 192.168.1.2#33321: update 'domain2.com/IN' denied
So server2 requests to update dns records for domain2 are denied.
To recap, /etc/named.conf now has these lines in forward and reverse lookup for domain2 on both servers:
  allow-transfer { 192.168.2.3; };    //NIC2 DHCP server address
  allow-query { 127/8; 192.168.1.0/25; 192.168.1.128/25; };
  forwarders {};
  allow-update { key "rndckey"; };
and dhcpd.conf has the domain name and name server set to domain2.com
 /etc/hosts on both servers show the primary domain only, but /etc/resolv.conf shows
search domain1.com domain2.com
I don't know where else to look for what could be causing this error.
0
 
nociSoftware EngineerCommented:
In your log you see that not the dhcp server but a users system will update the DNS, this is not what you want!!!, then anybody can modify your DNS.
(unless 192.168.1.131 is the dhcp server...?)

The zonefile should ONLY contain the SOA record, the NS records and the A or PTR records needed for the permanent servers (DNS, DHCP, routers etc.).

The DHCP server can be on a critical server, it is that those critical servers MUST have a fixed addresses (configured on their interface), and not acquire an
address through DHCP.
0
 
nociSoftware EngineerCommented:
ok back to basics...

that allow-transfer and has NOTHING to do with dhcp.
transfer is communication from a primary server to a secondary server (zone content or RR (resource records).)
the notify statements are needed to tell a secondary DNS to retrieve a new collecection of RR's from the primary.

allow-query is who (ip range) is allowd to send queries for individual records to the DNS server.

Fix that first, as a stand alone issue. (update the counter in the SOA record) end do a reload of the zone and see if the secondary
server also initiates a zone transfer. IF that works the next issue is to have your primary DNS server get updates from DHCP.

You can configure as many keys in the named.conf as you like, it might be wise to different ones
f.e. one for each domain that need to get updated, one for controlling your server (SHOULD be a separate one).
If you totaly control all hosted domains use one for them.

the allow-update statements grants access to a dhcp server to do updates in then zone.

The resolv.conf file is needed by the resolver library (part of glibc) to translate a namelookup 'xxxx' as either 'xxxxx.' or 'xxxx.domain1.com.' or 'xxxx.domain2.com.'
(yyyy.zzzz or search for as 'yyyy.zzzz.' , 'yyyy.zzzz.domain1.com.' or 'yyyy.zzzz.domain2.com.')
(the end . means no other additions to the name are allowed). A dns server ONLY answers queries for a complete name including domains.
The search ends on first match.

dig is the tool of trade for dns debugging, as well as the logging done by the named daemon.
nslookup used to be the tool, but is ambiguous as it also uses the resolver library to work, and only show part of the answer.

dig xxxx     will do a lookup for xxxx, dig xxxx.domain1.com will try to find just that name. (more options are available)
As an answer it show the actual query sent, the full response received including extra names and hints that are supplied.



0
 
sara_bellumAuthor Commented:
noci, I don't know what gives you the impression that my dhcp server does not have a fixed address!  To recap:
192.168.2.3 = DHCP server = NIC2 on server2
192.168.1.2 = server2
192.168.1.1 = server1
I don't have the DHCP server listed in the zone file because you can't assign a host name to a NIC, unless I'm missing something.
0
 
nociSoftware EngineerCommented:
in dhcpd.conf
--8<--
zone "domain2.com" {
  primary 192.168.1.1;
  key DHCP_UPDATER;
};
--8<--
is needed to also insert domain2.com records.

If you have a separate ip range then:
--8<--
# your network is 192.168.2.0/24, this is the reverse resolver:
zone 2.168.192.in-addr.arpa {
  primary 192.168.1.1;
  key DHCP_UPDATER;
};
--8<--
is also needed.

Also keep in mind that initial discovery is done using a MAC multicast received by all machines on the LAN,
after the address is confirmed IP rules apply ==> you need to setup routing between the 192.168.1.0/24 and 192.168.2.0/24
networks EVEN if they are on the same wire. That's why you need routers between networks and not bridges.
0
 
nociSoftware EngineerCommented:
This gave me the impression: from your dhcp config....
--8<--
        # we want the nameserver to appear at a fixed address
        host ns {
                next-server server1.mydomain.com;
                hardware ethernet 00:11:22:33:44:55;
                fixed-address 192.168.1.1;
        }
--8<--
A host name is only partly related to a dns name... it is because some programs assume that relationship.
to the outside world the hostname is insignificant. There only the ip address matters and an IP address can have many names.

It should have only one A record together with an PTR record for reverse lookup.
but you can have more CNAME records.

In fact the internet can function very well without DNS, its us humans that can cope badly with numbers,
we can better handle names. That where DNS kicks in..
The socket library function (listen(), connect(), socket() etc.) can't handle names.
DNS only maps names to ip addresses and back.
A browser (and many other tools) take the extra step to first try to translate a name to a number and then use that number to access

The DNS system came into life almost 15 years after ARPA net started. Before that hostnames and the hostname files were used for this translation.

Now a browser first hands a name to the resolver library, that opens a UDP socket and fires a request to the DNS server (all according the resolv.conf)
and translates the received address to a form that can be handled with the connect at al functions.

You could have the server2 named like:

server1.domain1.com. IN A 192.168.1.1
server2.domain2.com. IN A 192.168.2.3
server2.domain1.com. IN A 192.168.1.2
ns1.domain1.com. IN CNAME server1.domain1.com.
ns2.domain1.com. IN CNAME server2.domain1.com.
ns1.domain2.com. IN CNAME server2.domain2.com.
dhcp.domain1.com. IN CNAME server2.domain1.com.
dhcp.domain2.com. IN CNAME server2.domain2.com.

and reverse:

2.1.168.192.in-addr.arpa. IN PTR server2.domain1.com.
3.2.168.192.in-addr.arpa. IN PTR server2.domain2.com.
1.1.168.192.in-addr.arpa. IN PTR server1.domain1.com.

And in your case you don't need forwarding and routing setup as your dhcp server sits on both networks.
0
 
sara_bellumAuthor Commented:
Thanks very much!  From the above I figured that it would be a lot more efficient to move domain2.com from server1 to server2, so the primary server for domain2.com is now server2 (and the alternate is server1).
I also have a forward and reverse file for each zone on each server - for that reason using "zone x.168.192.in-addr.arpa" was confusing: which domain should apply? (presumably the domain in /etc/hosts, but then the other reverse zone files will have other designators in /etc/named.conf, so I wasn't sure).  From your example it looks like I could combine the domain RRs into one zone file, but let me know about that.

I can update secondary zone files in both directions now (from server1 to server2 and vice versa), so DNS works as long as I don't activate DHCP.  When the laptop acquires a DHCP address from NIC2 on server2, the DNS error is:
server2 named[19769]: client 192.168.1.2#32809: update 'domain2.com/IN' denied
server2 dhcpd: Unable to add forward map from lappy.domain2.com to 192.168.2.4: timed out
server2 dhcpd: DHCPREQUEST for 192.168.2.4 (192.168.2.3) from 00:11:22:33:44:55 (lappy) via eth1
server2 dhcpd: DHCPACK on 192.168.2.4 to 00:11:22:33:44:55 (lappy) via eth1
I removed the 'host ns' portion of dhcpd.conf which tied server1 to a hardware address.  I'll keep looking for what's causing this error, but don't want to waste time looking for the wrong answer, so I post this now.
TIA
0
 
Gabriel OrozcoSolution ArchitectCommented:
server2 dhcpd: Unable to add forward map from lappy.domain2.com to 192.168.2.4: timed out

check you can access dns on 192.168.2.4. This is:
a) you have your named working
b) you do not have port tcp/udp 53 filtered by a firewall
0
 
nociSoftware EngineerCommented:
Hm, you can "update secondary files in both directions now"?....

There should be ONE primary server for eache zone you use.....

If you have a zone for reverse mapping (PTR records)  that naming is along y.x.w.in-addr-arpa for any w.x.y.z type of address, if they fold into
one zone they need to be on the same primary.

In DNS you setup things so that a primary receives updates and fans them out to secondary servers.. (single point of access for the outside world,
less changes needed when maintaining either intra DNS infra structure or extra DNS infra.)
Pay attention to setup up zonetransfers correctly.

In DHCP you tell which server is the primary for that zone (primary statement in the zone declaration).
DHCP as such should work all needed settings need to land on the end nodes.

Then
In BOTH DHCP and primary DNS('s) you setup authentication to allow access from DHCP to the primary DNS.

Your error message tells me:
that DHCP server 192.168.1.2 tried to update "domain2.com" on DNS server "server2".
It cannot add the RR: 'lappy.domain2.com IN A 192.168.2.4" to the server.
After that lappy requests the address from the DHCP server (it allready knowns it address from a bit earlier conversation)
and the request comes from the 00:11:... macaddress on adapter eth1.
and the dhcp server achknowleges the address use.

Appearantly the server2 DNS server doesn't allow updates from 192.168.1.2  for the domain2.com (maybe you should also allow localhost (127.0.0.1),
and point the primary to localhost for the domain2.com?)
If the primary is on server1 then see that there is a primary statement in the dhcp zone config.

It has nothing to do with filtering as the request is received by named and denied, named doesn't answer those requests. hence the timeouts.

My advice in your case:
Make server1 secondary for all your private zones
Make server2 primary for all your zones,
make server2 dhcp server
Only allow updates from localhost and have dhcp only update the localhost named daemon.
[ Simplest solution ]


0
 
sara_bellumAuthor Commented:
I made server2 primary for domain2.com, which I plan to use for DHCP per your recommendation, since server2 has two NICs.
server1 remains primary for my other domains, and none of my domains are private.  

Zone updates (for different zones) are accepted by both servers, however DHCP clients on domain2.com still cannot resolve URLs outside my LAN.
The problem is probably my DNS configuration, however I can't find information about configuring DNS with multiple NICs on Linux. With this entry in the forward zone file of the primary server:
'dhcp.domain2.com IN A 192.168.2.3 '
zone updates are accepted by the secondary server, but when I replace the dhcp A record with a CNAME record:
'dhcp.domain2.com IN CNAME server2.domain2.com'
zone updates for domain2.com are denied by the secondary server
(server2.domain2.com has its own A record of course, so there are now two A records with the same host name, each in a different subnet.)
There are also two PTR records for server2 in the reverse zone file for domain2.com (one for each NIC).  I've tried configuring them this way:
192.168.1.2   IN PTR server2.domain2.com
192.168.2.3   IN PTR server2.domain2.com
...and also this way
192.168.1.2   IN PTR server2.domain2.com
192.168.2.3   IN PTR dhcp.domain2.com
But once I assign two different IP addresses to the same host in the forward DNS zone file, zone updates are denied or refused by the secondary server.

I will try your localhost recommendation next, but I should know the answer to the DNS question to get this right, since there should be a standard for configuring DNS zone files with mutliple NICs on a Linux server.  TIA!


0
 
nociSoftware EngineerCommented:
Bind will listen on all interfaces unless it is pointed to by one.
Also forget the notion that a system has only ONE ip name. It has a hostname,
for IP all interfaces have a different address => a different name. The notion that a host has a hostname equal to dns name
only holds for single interfaced systems.

You can configure the interfaces a server is listening on through the listen-on directive in the named.conf.
0.0.0.0 would mean to listen on all available interfaces.

Actualy the names are bogus for IP as such... all stuff should be resolvable from an IP address alone.
(As the IP address is the ONLY thing you can check when talking to another party)
But configurations are name based (we humans make the configuration files)

To transform the number to the name the PTR is used.
The update might fail because the name server expected the updates through the other port (depending on the ip number
in a zone file; you might need 2  ipaddresses there one for either interface.)
Or the PTR lookup for a name and looking for the A record using that name yields a different address.
Name and number collisions are unwise.
If a entry exists like:

name1 IN A 192.168.5.6
name1 IN A 192.168.6.7
name1 IN A 192.168.7.8

You will receive an answer for name1 where the first time you get:
192.168.5.6 192.168.6.7 192.168.7.8
then
192.168.6.7 192.168.7.8 192.168.5.6
then
192.168.7.8 192.168.5.6 192.168.6.7
Where only the first one is actualy be used, you then might run into issues theat is sometimes works and sometimes doesn't
depending on when namelookups are done (start of program, continuous lookup etc)

Regarding resolving:
Can you ping from your laptop to: 192.168.1.2 and 192.168.1.1?
(numeric addresses, to keep DNS issues asside)
If not that you might need to add forwarding to you server2 configuration. (It will then act as a router between the
192.168.1.x and 192.168.2.x network.

You might need to add multiple nameservers to the dhcp response if the various nameservers don't serve the same zones.
0
 
sara_bellumAuthor Commented:
I'm terribly sorry this process has taken so long - so I'm just about ready to close this out and award points because we can't be guaranteed success.  I have disabled IP forwarding but with server2 as primary DNS for domain2 and as DHCP server, I can ping both NICs on server2 from the laptop.  Also, the domain2.com zone file is now configured with server2 A records for both NICs and a CNAME record for dhcp.mydomain2.com pointing to server2.  No errors on named startup or zone transfers, and no errors on DHCP startup, so far so good.  But as before, DNS does not resolve outside www.mydomain2.com for DHCP clients:
Oct 27 13:55:42 server2 named[30498]: client 192.168.1.2#32971: update 'mydomain2.com/IN' denied
Oct 27 13:55:42 server2 dhcpd: Unable to add forward map from lappy.mydomain2.com to 192.168.2.4: timed out
So server2 isn't allowing DHCP to update its zone file.
The problem may be that I am using the same rndc.key to authenticate zone transfers and dhcpd, which looks ok since dhcpd must update the bind / named files, but I suspect that there's a permissions problem somewhere, since I'm getting the same DNS errors from server2 as I was when the laptop DHCP client was trying to resolve DNS from server1.
http://odin.himinbi.org/firewall_setup/#dhcp talks about an audit that points to the problem, but that's on FC3, and my machine is on FC6, so that may be resolved, and I wasn't able to find the audit file that he referred to.  
Unless something obvious pops up, I'll probably move on to trying to run DHCP off a Linksys router, which I know can work but it slows things down, especially because it's wireless.
 
0
 
nociSoftware EngineerCommented:
It doesn't matter which key u use for updating.
You can have on or as many as you like (1 for each DNS manager to keep thins safe f.e.
And is one leaves the company you only need to disable one key and don't have to issue averybody with a new password/secret. (Multile keys is a bout security management).
If you have several less trusted DHCP servers through a company, you could create a subzone for each and issue them keys to update their own subzone (keeps your master zone clean).

To allow any DNS resolving from domain2 to any place elsewahere, you need have to named on server2 do recursive lookups (handles to whole dns queries itself) or have unsolved requests forwarded to another system.
The recusion should be enabled by default, but might be disabled though a
  "recursion false; " or "allow-recursion { none ; } ;".....
in the option section.
Forwarders can be declared through (in the oiption section):
forwarders {
     isp-dns1.nameserver;
     isp-dns2.nameserver;
};

The erros have nothing to do with solving names., it sais 192.168.1.2 is deneid access to update mydomain2.com, and dhcp complaining that the bind server did not return an result.

Please read up on terminology:

resolution/resolving:  translating a request through a query to a dns server. (mostly done in the C runtime library with gethostbyname, gethostbyaddress etc al.) It uses the /etc/resolv.conf file for locating dns servers.
(forward request: translate a name through {a range of Cname's } and an A record to a numrec address.
reverse lookup , translate a numeric address through a PTR record to a name.)

The audit messages mentioned can be found in the syslog's logging (which file depends on the /etc/syslog.conf)
grep audit: /var/log/*
grep audit: /var/log/*/*       # in the case of metalog like logservers
Those audit messages are generated by the linux kernel.
It also refers to a setup problem where a selinux ( security enhanced linux ) kernel was not allowing access
from one process to another. It is about authorisation setup (configuration of selinux) that need to be configured. You might have similar problems if you can find audit records AND you use a selinux based kernel.

Your problems are with updating a zone file:  The first line in the message says it: access to update a zone is denied....
- problems can include: unable to write to zone files, create new files in the directoy where the zone file is stored, invalid authorisation key, mixedup symlinks etc.
0
 
sara_bellumAuthor Commented:
Thanks! I found this link:
http://www.linuxforums.org/forum/redhat-fedora-linux-help/66530-dynamic-dns-updates-not-working-fc4.html
so I checked the SELINUX settings on my server and enabled "Allow named to overwrite master zone files." (disabled by default).  Now lappy's jnl files are in /var/named/chroot/var/named, and  /var/log/messages shows this:
Oct 29 22:29:37 server2 named[7548]: zone domain2.com/IN: sending notifies (serial 20071031)
Oct 29 22:29:37 server2 dhcpd: Added new forward map from lappy.domain2.com to 192.168.2.4
Oct 29 22:29:37 server2 named[7548]: client 192.168.1.2#33038: updating zone 'zone.rev.domain2/IN': deleting rrset at '131.1.168.192.zone.rev.domain2' PTR
Oct 29 22:29:37 server2 named[7548]: client 192.168.1.2#33038: updating zone 'zone.rev.domain2/IN': adding an RR at '4.2.168.192.zone.rev.domain2' PTR
Oct 29 22:29:37 server2 named[7548]: journal file zone.rev.domain2.jnl does not exist, creating it
Oct 29 22:29:37 server2 dhcpd: added reverse map from 4.2.168.192.zone.rev.domain2 to lappy.domain2.com
Oct 29 22:29:37 server2 dhcpd: DHCPREQUEST for 192.168.2.4 (127.0.0.1) from 00:00:39:2b:fc:9e (lappy) via eth1
Oct 29 22:29:37 server2 dhcpd: DHCPACK on 192.168.2.4 to 00:00:39:2b:fc:9e (lappy) via eth1
Oct 29 22:29:37 server2 named[7548]: client 192.168.1.1#44174: zone transfer 'domain2.com/IXFR/IN' denied
Oct 29 22:29:37 server2 named[7548]: client 192.168.1.1#44175: zone transfer 'domain2.com/AXFR/IN' denied
...which is progress.  Lappy (the DHCP client) still can't resolve URLs on the Internet, but after stopping the named service on server1 and restarting named and dhcpd on server2 and running ipconfig /renew on lappy, server2 continues to resolve Internet URLs and lappy.domain2.com, but lappy still fails to resolve yahoo.com - so the issue is with server2.  Not sure where to look at this point, but I'll keep on digging :)
0
 
nociSoftware EngineerCommented:
Look into the forwarding { ... ; } ; section in the options section in named.conf.
If it isn't there then add it with the ip addresses of your isp's dns  server.

BTW you still need to enable zone transfers from server2 (domain2 zone) to server1. Appearantly it tries to download the zone. but is denied access by named... (Maybe also selinux settings?, or just named,conf
see earlier posting, allow transfer and notify...).

or enable recursive lookup, where your DNS server will search the internet from the root servers down to
the actual name servers needed.
Of course you need to be able to send & receive UDP queries to the internet.

And is it realy only DNS resolving?
Does dig answer a question?
f.e.:
dig www.google.com

Or do you mean it can't reach the internet.  (packet forwarding) on server2. ( or server1).
ping to a known address on the internet works or not.?
ping 66.249.93.99
Should be able to anser (try it from server1, server2 and lappy.
If server1 works and the others done't check firewall & packet forwarding setup on server1
   and maybe routersetup on server2
if server1 and server2 work then check packet forwarding

To help please show the output of 'netstat -rn'  on both servers
Does pinging from lappy to server1 work (ping 192.168.1.1 from lappy?)
0
 
sara_bellumAuthor Commented:
I've run out of time to fix this, sadly.  My priority is for DNS to run without error on both servers, and to avoid that, I had to disable allow-tranfer from the NIC2 IP address in /etc/named.conf because zone transfers from server2 to server1 were denied with that option enabled. I've tested my DNS settings for domain2.com with dnsstuff.com as I had some time ago, and after the changes it still tests ok.  

However, without the allow-transfer provision in /etc/named.conf, dns requests from dhcp clients are not forwarded from NIC2 to NIC1, so there's no forward mapping from lappy.domain2.com to the IP address it acquires from DHCP on NIC2.
I guess I could re-enable IP forwarding, but it's a crap-shoot.   I could also try checking SELINUX settings on server1, maybe if I fix something there it won't deny zone updates from domain2.com when that domain is getting updates from dhcp clients.  But these ideas and others must be tested individually, and it will take months of effort, given how much time it's taken me already :(  Btw, server2 is on Fedora Core 6, and I'm now unable to receive any package updates for listed rpm's not yet installed, so if I continue to use this OS, I'll have to get another hard drive, download Fedora Core 7, back up all my config files, etc, which is very time-consuming.
But I've benefited from your guidance, thanks very much!
   
0
 
sara_bellumAuthor Commented:
I got it to work, finally!  I needed to chmod my zone files to 440 - in this way dhcp clients have access to /var/named/chroot/var/named, but cannot modify the forward and reverse zone files themselves.  This problem occurred with my XP client - not sure if the problem would have happened with the Linux client, will try connecting that client next.
0

Featured Post

 The Evil-ution of Network Security Threats

What are the hacks that forever changed the security industry? To answer that question, we created an exciting new eBook that takes you on a trip through hacking history. It explores the top hacks from the 80s to 2010s, why they mattered, and how the security industry responded.

  • 13
  • 13
  • 8
Tackle projects and never again get stuck behind a technical roadblock.
Join Now