Zonemaster is giving me the following error message:
When asked for SOA records on "wWw.NO8.be" and "wwW.nO8.BE", nameserver ns1.no8.be/2001:770:13f::35:1 returns different answers.
I believe that this is the only one (of three) authorities for
no8.be which is running NSD. I also believe that the answer should
depend only on zone data, and not be "modulated" by differences
between equivalent presentations of the question.
I suspect a bug in NSD's code for building the answer. Perhaps it's
a known one already?
The following script may help to visualize the behaviour.
Zonemaster is giving me the following error message:
When asked for SOA records on "wWw.NO8.be" and "wwW.nO8.BE",
nameserver ns1.no8.be/2001:770:13f::35:1 returns different
answers.
But there is no difference between these answers. Zonemaster must be
wrong? DNS is case insensitive, so these answers are identical.
NSD compresses the domain names in the answer towards the mangled
upper and lowercase of your question, which you then see repeated in
the answers. This makes the packet smaller.
The zone data is in lowercase, because NSD lowercases all its zone
data (whether primary or secondary zones). In case you were wondering
about the case of the zone data.
I have to echo the query section with its mangled upper and lowercase
because of 0x20 hacks that people are using to get extra entropy in
DNS messages.
> Hi.
>
> Zonemaster is giving me the following error message:
>
> When asked for SOA records on "wWw.NO8.be" and "wwW.nO8.BE",
> nameserver ns1.no8.be/2001:770:13f::35:1 returns different
> answers.
But there is no difference between these answers. Zonemaster must be
wrong? DNS is case insensitive, so these answers are identical.
I think that's an overstatement, and respectfully suggest careful
re-reading of Section 3.1 of RFC1034.
NSD compresses the domain names in the answer towards the mangled
upper and lowercase of your question, which you then see repeated in
the answers. This makes the packet smaller.
Of course it makes the response smaller, but it's not consistent
with (my reading of) the section of RFC1034 mentioned above: "When
you receive a domain name or label, you should preserve its case."
IMHO, the answer is "received" from the zone data, not from the
question.
The zone data is in lowercase, because NSD lowercases all its zone
data (whether primary or secondary zones). In case you were wondering
about the case of the zone data.
That seems to me to be an intrusion on the role of the zone
administrator, from whom the data is "received" (in the sense I used
above) by NSD in the zone file.
I have to echo the query section with its mangled upper and lowercase
because of 0x20 hacks that people are using to get extra entropy in
DNS messages.
I agree that echoing the query section as received is the only
acceptable action. I'm concerned about the answer section.
Maybe such a correction is working its way through to the production
instances. I was getting the error message yesterday.
If the Zonemaster Team are happy to be less strict about this, then
so am I. It's their job to identify the appropriate level of
pedantry (a term I'm not using pejoratively here); I'm just an
amateur.
==> It has been fixed in ZM. If you make a pull request of the last version of the engine () and test with the CLI (), you may find the difference. zonemaster-cli afnic.fr Seconds Level Message ======= ========= ======= 21.47 WARNING When asked for SOA records on “” and “”, nameserver ns2.nic.fr/192.93.0.4 returns different answers. 21.47 WARNING When asked for SOA records on “” and “”, nameserver ns2.nic.fr/2001:660:3005:1::1:2 returns different answers. 21.49 ERROR When asked for SOA records on “” with different cases, all servers do not reply consistently. 21.59 NOTICE SOA ‘mname’ nameserver (dnsmaster.nic.fr) is not listed in “parent” NS records for tested zone (ns1.nic.fr;ns2.nic.fr;ns3.nic.fr). 21.59 NOTICE SOA ‘refresh’ value (7200) is less than the recommended minimum (14400). 21.60 NOTICE SOA ‘retry’ value (1800) is less than the recommended minimum (3600). zonemaster-cli afnic.fr Seconds Level Message ======= ========= ======= 21.57 NOTICE SOA ‘mname’ nameserver (dnsmaster.nic.fr) is not listed in “parent” NS records for tested zone (ns1.nic.fr;ns2.nic.fr;ns3.nic.fr). 21.57 NOTICE SOA ‘refresh’ value (7200) is less than the recommended minimum (14400). 21.57 NOTICE SOA ‘retry’ value (1800) is less than the recommended minimum (3600).
- not to match my reading of RFCs 1034, 1035, and 4343;
- and not to match the default behaviour of BIND named (explained in
the article from ISC's Knowledge Base which I mentioned in an
earlier message).
Specifically, what NSD seems to be doing is copying the 0x20
"modulation" (my term, adopted on-the-fly for convenience) from the
query to the Question Section of the response (so far, so good:
that's required) and then propagating, by the use of shared
compression references, this modulation to the other sections of the
response.
Zonemaster is finding the modulation where it does not expect it,
and is therefore reporting an error.
Now, either Zonemaster is erroneously reporting correct (or at
worst, acceptable) behaviour as an error and thus has a bug, or else
NSD is behaving incorrectly and is the element which needs
correction.
My feeling is that the fault is with NSD, and that this should avoid
using shared compression references between Question and other
sections of the response for labels which differ between zone and
query data simply because of 0x20 modulation.
