Help us test FTL v5.8 / dnsmasq v2.85

Help us test FTL v5.8 / dnsmasq v2.85

2021-03-31 Updates 60

Pi-hole embeds the DNS server dnsmasq, which is currently in release-candidate state for version 2.85. Please join us in the final testing of this version of dnsmasq, to help us ensure there are no major bugs before the final release. You may be receiving a few updates on this branch.

To get the release candidate version, run
pihole checkout ftl update/dnsmasq-v2.85

You can go back at any time using
pihole checkout ftl master

Please also go back to master before updating Pi-hole after the next release. This can be done at any time, also after the update happened. Support and discussions are possible on the linked Discourse thread.

dnsmasq: CHANGELOG

  • Fix problem with DNS retries in 2.83/2.84.
    The new logic in 2.83/2.84 which merges distinct requests for the same domain causes problems with clients which do retries as distinct requests (differing IDs and/or source ports.) The retries just get piggy-backed on the first, failed, request.
    The logic is now changed so that distinct requests for repeated queries still get merged into a single ID/source port, but they now always trigger a re-try upstream.
  • Avoid treating a dhcp-host which has an IPv6 address as eligible for use with DHCPv4 on the grounds that it has no address, and vice-versa.
  • Add dynamic-host option
    A and AAAA records which take their network part from the network of a local interface. Useful for routers with dynamically prefixes.
  • Teach bogus-nxdomain and ignore-address to take an IPv4 subnet.
  • Use random source ports where possible if source addresses/interfaces in use. CVE-2021-3448 applies.
    It’s possible to specify the source address or interface to be used when contacting upstream name servers: server=8.8.8.8@1.2.3.4 or server=8.8.8.8@1.2.3.4#66 or server=8.8.8.8@eth0, and all of these have, until now, used a single socket, bound to a fixed port. This was originally done to allow an error (non-existent interface, or non-local address) to be detected at start-up. This means that any upstream servers specified in such a way don’t use random source ports, and are more susceptible to cache-poisoning attacks.
    We now use random ports where possible, even when the source is specified, so server=8.8.8.8@1.2.3.4 or server=8.8.8.8@eth0 will use random source ports. server=8.8.8.8@1.2.3.4#66 or any use of query-port will use the explicitly configured port, and should only be done with understanding of the security implications. Note that this change changes non-existing interface, or non-local source address errors from fatal to run-time. The error will be logged and communication with the server not possible.
  • Change the method of allocation of random source ports for DNS. Previously, without min-port or max-port configured, dnsmasq would default to the compiled in defaults for those, which are 1024 and 65535. Now, when neither are configured, it defaults instead to the kernel’s ephemeral port range, which is typically 32768 to 60999 on Linux systems. This change eliminates the possibility that dnsmasq may be using a registered port > 1024 when a long-running daemon starts up and wishes to claim it. This change does likely slightly reduce the number of random ports and therefore the protection from reply spoofing. The older behaviour can be restored using the min-port and max-port config switches should that be a concern.
  • Scale the size of the DNS random-port pool based on the value of the dns-forward-max configuration.
  • TFTP tweak: Check sender of all received packets, as specified in RFC 1350 para 4.

Notable Replies

  1. Just updated a couple Pi3's with this build. I'll keep my eyes open for issues and report back.

  2. Updated both of my pi-holes (Ubuntu 20.04.2 LTS server) yesterday (2021-03-31) morning and all has been well thus far.

  3. started new FTL (update/dnsmasq-v2.85) yesterday (2021-03-31 23:05:57 local time).
    hopefully no logic errors...

    Epoch timestamp : 1617228000
    Date and time (Your time zone) : Thursday, April 1, 2021 12:00:00 AM GMT+02:00

    SELECT count(*) FROM "queries" WHERE timestamp > "1617228000";
    

    count: 7489

    SELECT count(*) FROM "queries" WHERE timestamp > "1617228000" and status is "12";
    

    count: 1289

    There is no noticeable impact on the user experience.

    edit
    todays results @ 09:00 local time (CET)

    today: 04/02/2021 -> 1617314400
    total # of queries today: 1681
    status  count   description
    0       0       Unknown status
    1       399     Domain contained in gravity database
    2       1128    Forwarded
    3       25      Known, replied to from cache
    4       5       Domain matched by a regex blacklist filter
    5       0       Domain contained in exact blacklist
    6       0       By upstream server (known blocking page IP address)
    7       0       By upstream server (0.0.0.0 or ::)
    8       0       By upstream server (NXDOMAIN with RA bit unset)
    9       44      Domain contained in gravity database (CNAME)
    10      0       Domain matched by a regex blacklist filter (CNAME)
    11      0       Domain contained in exact blacklist (CNAME)
    12      80      Retried query
    13      0       Retried but ignored query (DNSSEC)
    14      0       Already forwarded, not forwarding again
    

    /edit

  4. Running nicely here on Pi Zero W, with other Pi-Hole modules running dev branches.
    (for completeness, using latest unbound as DNS resolver)

    Ran the same check as @jpgpi250 , here are my results:

    today: 04/02/2021 -> 1617314400
    total # of queries today: 41707
    status  count   description
    0       0       Unknown status
    1       21660   Domain contained in gravity database
    2       19062   Forwarded
    3       133     Known, replied to from cache
    4       8       Domain matched by a regex blacklist filter
    5       0       Domain contained in exact blacklist
    6       0       By upstream server (known blocking page IP address)
    7       0       By upstream server (0.0.0.0 or ::)
    8       0       By upstream server (NXDOMAIN with RA bit unset)
    9       437     Domain contained in gravity database (CNAME)
    10      20      Domain matched by a regex blacklist filter (CNAME)
    11      0       Domain contained in exact blacklist (CNAME)
    12      387     Retried query
    13      0       Retried but ignored query (DNSSEC)
    14      0       Already forwarded, not forwarding again
    
  5. dnsmasq doesn't want to log such things. We don't mess with their log routines.

    pihole-FTL.log will only contain it when in DEBUG_QUERIES mode but it will surely log something about it.

    Yes, this will revive the IN_PROGRESS status that is currently deprecated by dnsmasq (as every query is currently forwarded). The individual queries will be summarized in a list by dnsmasq, however, FTL will report them as individual queries (because that's what they are). The first query will be FORWARDED, the others IN_PROGRESS (because we're waiting for the reply and not forwarding on our own).

    This is something we cannot control. In my opinion, the current behavior is defect and a fix warrants a v2.85rc3 (we are currently at rc2).

Continue the discussion discourse.pi-hole.net

55 more replies

Participants