Knowledge Base ISC Main Website Ask a Question/Contact ISC
Case-Insensitive Response Compression May Cause Problems With Mixed-Case Data and Non-Conforming Clients
Author: Michael McNally Reference Number: AA-01113 Views: 36752 Created: 2014-02-03 22:37 Last Updated: 2018-04-20 22:37 0 Rating/ Voters

BIND releases beginning with BIND 9.9.5, 9.8.7, and 9.6-ESV-R11 include a fix which we would like to highlight for your attention, as one customer has experienced an operational issue as a result of what might look, from the notes, like a completely innocuous change:

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 have learned of a case where 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.)

Control over case compression for non-compliant clients

Beginning from BIND 9.10.0, a feature was added to allow control over the case compression which is the default since change #3465.

Change #3731 introduces the "no-case-compress" ACL, which can override the default to ensure case-insensitive compression is used for responses to specified clients.

© 2001-2018 Internet Systems Consortium

For assistance with problems and questions for which you have not been able to find an answer in our Knowledge Base, we recommend searching our community mailing list archives and/or posting your question there (you will need to register there first for your posts to be accepted). The bind-users and the dhcp-users lists particularly have a long-standing and active membership.

ISC relies on the financial support of the community to fund the development of its open source software products. If you would like to support future product evolution and maintenance as well having peace of mind knowing that our team of experts are poised to provide you with individual technical assistance whenever you call upon them, then please consider our Professional Subscription Support services - details can be found on our main website.

Feedback 5
  • #
    [ Living_Stone]: BIND 9.9.5 security problem 2014-04-13 16:28

    1. in a DNS response packet, a string in question-section maybe different from answer-section because of case sensitive.
    2. when recursive DNS uses 9.9.5 and authoritive DNS uses others version like 9.9.4, which letter is uppercase in answer section is controlled by the person who send the recursive DNS request when TTL expire.

    Keep a string in question-section same as answer-section, response compression never cause problem.

  • #
    [Cathy Almond]: Re: BIND 9.9.5 security problem 2014-04-14 11:22

    We are planning to update this KB article with a table to clarify what behavior should be expected in different circumstances, and with different versions of BIND. Going forward, if you have an application that is impacted by case-sensitivity issues in name/domain labels, there will be an ACL that causes named to revert to its prior behaviour for the specific range of clients. This will be available in BIND 9.10, 9.8.6 and 9.8.8.

  • #
    [ Living_Stone]: 9.9.5 and 9.9.5-W1 case sensitive BUG 2014-04-13 06:28

    In a DNS response packet, it's case sensitive in QUESTION section, but it's always lower case in ANSWER section. This BUG will make serious problem in some security application.

  • #
    [Stacey Marshall]: 9.10.0b1 offers "no-case-compress" ACL 2014-04-01 15:20

    An ACL is available should it be needed to disable this feature for named clients. Note the ACL is currently not available in ESV releases.

    9.10.0b1 CHANGES documents:

    3731. [func] Added a "no-case-compress" ACL, which causes
    named to use case-insensitive compression
    (disabling change #3645) for specified
    clients. (This is useful when dealing
    with broken client implementations that
    use case-sensitive name comparisons,
    rejecting responses that fail to match the
    capitalization of the query that was sent.)
    [RT #35300]

  • #
    [Cathy Almond]: Re: 9.10.0b1 offers "no-case-compress" ACL 2014-04-04 12:06

    This new ACL is going to be available in 9.10.0 (noted already as being in 9.10.0b1), 9.9.6, and 9.8.8, as well as in subscription versions of BIND.

Quick Jump Menu