OES11 DNS - resource records which contain invalid characters can cause an entire zone to fail to load

  • 7014504
  • 04-Feb-2014
  • 04-Feb-2014

Environment

Novell Open Enterprise Server 11 (OES 11) Linux Support Pack 1

Situation

DDNS updates to resource records using invalid characters can cause the entire zone to fail to load.
In the /var/opt/novell/log/named/named.run file you will see an error containing: general: dns/db: critical: Unable to get all RR's of zone <zonename>/IN with error 65537

Because of this a device with an invalid DNS name can give that invalid DNS / Host name to DHCP during it's DORA process, which can result in DHCP updating DNS with the invalid DNS name.  This invalid RR record will cause the dynamic updates to the zone to fail.  If an administrator sees that a zone is not getting valid updates they could delete the zones db file (a normal and recommended trouble shooting step) and reload named.  This will result in the companies main domain which was working but was not showing new and valid records, to not load at all. This could break name resolution for the companies main domain.

OES2 SP3 does not fail to load the zone with the invalid RR record.
OES11 SP1 does fail to load the entire zone with the invalid RR record

For example: If you have a resource record that contains a % symbol in the name then named will fail to load the entire zone that contains that resource record.

Steps to duplicate.

With a working OES11 SP1 DNS server and a test zone named test do the following:
Zone name
test
/etc/opt/novell/named/test.db contains the following

$ORIGIN .
$TTL 86400      ; 1 day
test                    IN SOA  tdefreese4.myzone. root.test. (
                                2012121751 ; serial
                                10800      ; refresh (3 hours)
                                3600       ; retry (1 hour)
                                604800     ; expire (1 week)
                                86400      ; minimum (1 day)
                                )
                        NS      tdefreese4.myzone.
$ORIGIN test.
record1                 A       1.1.1.1
record2                 A       2.2.2.2
record3                 A       3.3.3.3
~                                      

rcnovell-named restart

nslookup record1.test
Server:151.155.213.242
Address:151.155.213.242#53

Name:record1.test
Address: 1.1.1.1

Try to add an % symbol to "record1" in the test zone using the DNS/DHCP management console and you will  be told that it is an invalid character.
This is correct because that symbol is not a valid DNS name character.

However the record can be forced to be incorrect.
Using ConsoleOne change the DNS RR record for record1 and modify the DNIP:DNS Domain Name attribute to contain "record%1.test".

Restart DNS and test again using nslookup.

Notice that the nslookup test still gives the same results as before.

Double check the test.db and you will see that it contains the following:

$ORIGIN .
$TTL 86400      ; 1 day
test                    IN SOA  tdefreese4.myzone. root.test. (
                                2012121751 ; serial
                                10800      ; refresh (3 hours)
                                3600       ; retry (1 hour)
                                604800     ; expire (1 week)
                                86400      ; minimum (1 day)
                                )
                        NS      tdefreese4.myzone.
$ORIGIN test.
record1                 A       1.1.1.1
record2                 A       2.2.2.2
record3                 A       3.3.3.3
~                                    

Notice that the SOA serial number is unchanged so the test.db file remains unchanged.

That means that the DNS cache has the same old information as before.

This is all working as designed. Meaning that the updated record is not read into cache or written to the test.db file because the SOA Serial number is unchanged.

Now delete the /etc/opt/novell/named/test.db file and restart named.

In this scenario the test zone MUST be read into cache from eDir because the local file does not exist.

On OES 11 SP1 the test zone will fail to load and you will see the following in the /var/opt/novell/log/named/named.run file:

04-Feb-2014 10:42:40.515 general: dns/db: critical: Unable to get all RR's of zone test/IN with error 65537
04-Feb-2014 10:42:40.516 general: dns/zone: warning: zone test/IN: Loading from eDirectory failed
04-Feb-2014 10:42:40.516 general: dns/zone: error: zone test/IN: loading master file /etc/opt/novell/named/test.db: file not found
04-Feb-2014 10:42:40.517 general: server: notice: running
04-Feb-2014 10:43:36.103 general: dns/zone: error:

If you run the exact same test on OES2 SP3 you will see the test.db file is created with the new information from eDir as follows:

$ORIGIN .
$TTL 86400      ; 1 day
test                    IN SOA  tdefreese4.myzone. root.test. (
                                2012121751 ; serial
                                10800      ; refresh (3 hours)
                                3600       ; retry (1 hour)
                                604800     ; expire (1 week)
                                86400      ; minimum (1 day)
                                )
                        NS      tdefreese4.myzone.
$ORIGIN test.
record2                 A       2.2.2.2
record3                 A       3.3.3.3
record%1                A       1.1.1.1

If you now do an nslookup record%1.test you will get

nslookup record%1.test
Server:151.155.213.242
Address:151.155.213.242#53

Name:record%1.test
Address: 1.1.1.1

So if a process successfully modifies an eDir record to contain an illegal DNS character and the zone.db file is none existent (either by deletion or never existed in the first place) and named is restarted, that edited record will cause the entire zone to fail to load.