Bug 72 - The order of records with overlapping resources determines which records resolve (version 1.2.3)
The order of records with overlapping resources determines which records reso...
Product: NSD
Classification: Unclassified
Component: Zonec Code
All Linux
: P2 major
Assigned To: NSD team
Depends on:
  Show dependency treegraph
Reported: 2004-01-06 17:38 CET by Andy Clark
Modified: 2004-01-07 10:34 CET (History)
0 users

See Also:

Example zone which exhibits strange behaviour (594 bytes, text/plain)
2004-01-06 17:41 CET, Andy Clark
Patch against 1.2.4 (901 bytes, patch)
2004-01-07 10:30 CET, Erik Rozendaal
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Andy Clark 2004-01-06 17:38:59 CET
Version 1.2.3

There appears to be a problem with records who's resources are within the
context of others, for example "users" and "ftp.users".

If you have an A-record in a zone file for "ftp.users" and another for "users",
if the record for "users" occurs after "ftp.users" then NSD will return a record
for "ftp.users" but not "users". Reversing the order ("users" first, then
"ftp.users") allows both records to be resolved.

ftp.users   IN   A
users       IN   A

With the above records, users will not resolve whereas ftp.users will.

users       IN   A
ftp.users   IN   A

With the above records, both will resolve.

In addition to this, a third record can be created as follows :-

www.users   IN   CNAME   users

The above additional record appears to have no effect on the other two, but a
dig on "www.users" will return the CNAME for "www.users" and the A-record for
"users" even when a direct dig for "users" fails.

This seems like a problem with zonec, so I've flagged accordingly.
Comment 1 Andy Clark 2004-01-06 17:41:45 CET
Created attachment 15 [details]
Example zone which exhibits strange behaviour
Comment 2 Miek Gieben 2004-01-06 18:04:34 CET
From the looks of it, i'd say you've been bit by this:

Comment 3 Andy Clark 2004-01-06 18:16:07 CET
It appears that the mailing-list thread you mentioned relates to the order of
entries in the nsd.zones file, whereas the issue I'm seeing relates to the order
of individual records in a single zone file (in fact, my nsd.zones file has only
one entry, for the test zone in question).

I'm not sure of the inner workings of nsd / zonec, so I guess it could be that
the underlying cause is the same. Sorry if I've duplicated an already-known bug.

Comment 4 Erik Rozendaal 2004-01-07 10:30:25 CET
Created attachment 16 [details]
Patch against 1.2.4
Comment 5 Erik Rozendaal 2004-01-07 10:31:45 CET
This bug was introduced in 1.1.0 and is present in 1.1.x, 1.2.x, and
1.3.0-alpha1. The bug is no longer present in 1.4.0-alpha1 due to the rewrite of
zonec and query resolution.

The above patch should fix this bug in 1.2.4.
Comment 6 Erik Rozendaal 2004-01-07 10:34:01 CET
Oops... of course I meant that the patch is against version 1.2.3 (there is no
1.2.4 yet).