Home | History | Annotate | Line # | Download | only in arm
      1 .. Copyright (C) Internet Systems Consortium, Inc. ("ISC")
      2 ..
      3 .. SPDX-License-Identifier: MPL-2.0
      4 ..
      5 .. This Source Code Form is subject to the terms of the Mozilla Public
      6 .. License, v. 2.0.  If a copy of the MPL was not distributed with this
      7 .. file, you can obtain one at https://mozilla.org/MPL/2.0/.
      8 ..
      9 .. See the COPYRIGHT file distributed with this work for additional
     10 .. information regarding copyright ownership.
     11 
     12 .. _troubleshooting:
     13 
     14 Troubleshooting
     15 ===============
     16 
     17 .. _common_problems:
     18 
     19 Common Problems
     20 ---------------
     21 
     22 It's Not Working; How Can I Figure Out What's Wrong?
     23 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
     24 
     25 The best solution to installation and configuration issues is to
     26 take preventive measures by setting up logging files beforehand. The
     27 log files provide hints and information that can be used to
     28 identify anything that went wrong and fix the problem.
     29 
     30 EDNS Compliance Issues
     31 ~~~~~~~~~~~~~~~~~~~~~~
     32 
     33 EDNS (Extended DNS) is a standard that was first specified in 1999. It
     34 is required for DNSSEC validation, DNS COOKIE options, and other
     35 features. There are broken and outdated DNS servers and firewalls still
     36 in use which misbehave when queried with EDNS; for example, they may
     37 drop EDNS queries rather than replying with FORMERR. BIND and other
     38 recursive name servers have traditionally employed workarounds in this
     39 situation, retrying queries in different ways and eventually falling
     40 back to plain DNS queries without EDNS.
     41 
     42 Such workarounds cause unnecessary resolution delays, increase code
     43 complexity, and prevent deployment of new DNS features. In February
     44 2019, all major DNS software vendors removed these
     45 workarounds; see https://www.dnsflagday.net/2019/ for further details. This change
     46 was implemented in BIND as of release 9.14.0.
     47 
     48 As a result, some domains may be non-resolvable without manual
     49 intervention. In these cases, resolution can be restored by adding
     50 :namedconf:ref:`server` clauses for the offending servers, or by specifying ``edns no`` or
     51 ``send-cookie no``, depending on the specific noncompliance.
     52 
     53 To determine which :namedconf:ref:`server` clause to use, run the following commands
     54 to send queries to the authoritative servers for the broken domain:
     55 
     56 ::
     57 
     58            dig soa <zone> @<server> +dnssec
     59            dig soa <zone> @<server> +dnssec +nocookie
     60            dig soa <zone> @<server> +noedns
     61 
     62 
     63 If the first command fails but the second succeeds, the server most
     64 likely needs ``send-cookie no``. If the first two fail but the third
     65 succeeds, then the server needs EDNS to be fully disabled with
     66 ``edns no``.
     67 
     68 Please contact the administrators of noncompliant domains and encourage
     69 them to upgrade their broken DNS servers.
     70 
     71 Inspecting Encrypted DNS Traffic
     72 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
     73 
     74 .. note::
     75 
     76    This feature requires support from the cryptographic library that
     77    BIND 9 is built against.  For OpenSSL, version 1.1.1 or newer is
     78    required (use :option:`named -V` to check).
     79 
     80 By definition, TLS-encrypted traffic (e.g. DNS over TLS, DNS over HTTPS)
     81 is opaque to packet sniffers, which makes debugging problems with
     82 encrypted DNS close to impossible. However, Wireshark_ offers a
     83 solution_ to this problem by being able to read key log files. In order
     84 to make :iscman:`named` prepare such a file, set the ``SSLKEYLOGFILE``
     85 environment variable to either:
     86 
     87 - the string ``config`` (``SSLKEYLOGFILE=config``); this requires
     88   defining a :any:`logging` :any:`channel` which will
     89   handle messages belonging to the ``sslkeylog`` category,
     90 
     91 - the path to the key file to write (``SSLKEYLOGFILE=/path/to/file``);
     92   this is equivalent to the following :any:`logging` configuration:
     93 
     94   ::
     95 
     96      channel default_sslkeylogfile {
     97          file "${SSLKEYLOGFILE}" versions 10 size 100m suffix timestamp;
     98      };
     99 
    100      category sslkeylog {
    101          default_sslkeylogfile;
    102      };
    103 
    104 .. note::
    105 
    106    When using ``SSLKEYLOGFILE=config``, augmenting the log channel
    107    output using options like :any:`print-time` or :any:`print-severity` is
    108    strongly discouraged as it will likely make the key log file
    109    unusable.
    110 
    111 When the ``SSLKEYLOGFILE`` environment variable is set, each TLS
    112 connection established by :iscman:`named` (both incoming and outgoing) causes
    113 about 1 kilobyte of data to be written to the key log file.
    114 
    115 .. warning::
    116 
    117    Due to the limitations of the current logging code in BIND 9,
    118    enabling TLS pre-master secret logging adversely affects :iscman:`named`
    119    performance.
    120 
    121 .. _Wireshark: https://www.wireshark.org/
    122 .. _solution: https://wiki.wireshark.org/TLS
    123 
    124 Incrementing and Changing the Serial Number
    125 -------------------------------------------
    126 
    127 Zone serial numbers are just numbers  they are not date-related. However, many
    128 people set them to a number that represents a date, usually of the
    129 form YYYYMMDDRR. Occasionally they make a mistake and set the serial number to a
    130 date in the future, then try to correct it by setting it to the
    131 current date. This causes problems because serial numbers are used to
    132 indicate that a zone has been updated. If the serial number on the secondary
    133 server is lower than the serial number on the primary, the secondary server
    134 attempts to update its copy of the zone.
    135 
    136 Setting the serial number to a lower number on the primary server than the one
    137 on the secondary server means that the secondary will not perform updates to its
    138 copy of the zone.
    139 
    140 The solution to this is to add 2147483647 (2^31-1) to the number, reload
    141 the zone and make sure all secondaries have updated to the new zone serial
    142 number, then reset it to the desired number and reload the
    143 zone again.
    144 
    145 .. _more_help:
    146 
    147 Where Can I Get Help?
    148 ---------------------
    149 The BIND-users mailing list, at https://lists.isc.org/mailman/listinfo/bind-users, is an excellent resource for
    150 peer user support. In addition, ISC maintains a Knowledgebase of helpful articles
    151 at https://kb.isc.org.
    152 
    153 Internet Systems Consortium (ISC) offers annual support agreements
    154 for BIND 9, ISC DHCP, and Kea DHCP.
    155 All paid support contracts include advance security notifications; some levels include
    156 service level agreements (SLAs), premium software features, and increased priority on bug fixes
    157 and feature requests.
    158 
    159 Please contact info (a] isc.org or visit
    160 https://www.isc.org/contact/ for more information.
    161