Case-Insensitive Response Compression May Cause Problems With Mixed-Case Data and Non-Conforming Clients

Michael McNally mcnally at isc.org
Mon Feb 3 22:57:20 UTC 2014


Hello, BIND Workers,

ISC would like to make you aware of a recent change in the
behavior of BIND that has been reported by one customer to
have caused an operational issue in their environment due
to its effect on the case of data returned in response to
client queries.

The remainder of this posting explains the potential issue,
which we believe will not affect most operators, but you
should be aware of the potential in case you are one of
those affected.  This explanation is also provided in our
Knowledge Base:  https://kb.isc.org/article/AA-01113

--

The most recent maintenance releases of BIND (9.9.5, 9.8.7,
and 9.6-ESV-R11) include a fix which we would like to highlight
for your attention:

   3645. [protocol] Use case sensitive compression when
         responding to queries. [RT #34737]

This change was made to bring BIND into compliance with RFC 1034,
which states:

   By convention, domain names can be stored with arbitrary
   case, but domain name comparisons for all present domain
   functions are done in a case-insensitive manner, assuming
   an ASCII character set, and a high order zero bit.  This
   means that you are free to create a node with label "A"
   or a node with label "a", but not both as brothers; you
   could refer to either using "a" or "A".  When you receive
   a domain name or label, you should preserve its case.

Change #3645 was present in the precursor development releases for
9.9.5 et al but we received no reports of problems during the alpha
and beta test periods.  We still believe the change is correct in
terms of compliance with the RFC, and BIND has been performing
case-preserving compression for zone transfers for years without
issue -- this change affects the data returned by regular queries --
however, we wish to inform you that a customer whose DNS data
included both upper-case and lower-case representations of identical
names experienced operational problems with client appliance devices
that did not correctly implement the corresponding part of the
paragraph above; that is, that domain name comparisons be done in
a case-insensitive manner.

Case was not previously being preserved by the server when
compression was being used and as a result change #3645 had
the effect in this customer's environment of causing a different
reply to be returned by BIND 9.9.5 et al.  In conjunction with the
case-sensitivity of the misbehaving client devices, an operational
issue was created by this mismatch.  Operators encountering
similar issues should be able to correct them by providing
the exact case expected by client devices in their zone data
(both in the domain names themselves and in references to those
names in records of type NS, MX, SRV, CNAME, and other record
types which use a domain name as their data.)

Currently ISC are assessing whether the impact of this change
justifies further measures or whether the change in BIND should
stand as written.  One key piece of information that would inform
our decision is an estimate of the frequency of operational problems
that might be caused by this change.  So far we have no clear cues
how to estimate that frequency based on our single report received.
You can aid us by informing us of any issues encountered that you
believe are related to this change in case preservation.
Please send reports to bind9-bugs at isc.org

Michael McNally
ISC Support


More information about the bind-workers mailing list