Bug 234494 - dns/maradns: Memory exhaustion crash with default config
Summary: dns/maradns: Memory exhaustion crash with default config
Status: Closed DUPLICATE of bug 259921
Alias: None
Product: Ports & Packages
Classification: Unclassified
Component: Individual Port(s) (show other bugs)
Version: Latest
Hardware: Any Any
: --- Affects Only Me
Assignee: Norikatsu Shigemura
URL:
Keywords: crash, needs-qa
Depends on:
Blocks:
 
Reported: 2018-12-29 21:03 UTC by Nino
Modified: 2023-06-14 08:08 UTC (History)
3 users (show)

See Also:
je3kmz: merge-quarterly+
je3kmz: exp-run+


Attachments
maradns-2.0.16.patch (2.61 KB, patch)
2019-01-07 06:58 UTC, takefu
takefu: maintainer-approval-
Details | Diff
maradns-2.0.16.patch (2.61 KB, patch)
2019-02-04 01:30 UTC, takefu
takefu: maintainer-approval+
Details | Diff
maradns-2.0.17.patch (2.76 KB, patch)
2019-04-19 08:15 UTC, takefu
no flags Details | Diff
maradns-3.5.0021.patch (14.88 KB, patch)
2022-03-30 08:18 UTC, takefu
no flags Details | Diff
maradns-3.5.0036.patch (18.64 KB, patch)
2023-06-14 02:33 UTC, takefu
no flags Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Nino 2018-12-29 21:03:39 UTC
12.0-RELEASE FreeBSD 12.0-RELEASE r341666 GENERIC  i386 w/ 512MB RAM

After upgrading the system to 12.0-RELEASE and updating MaraDNS to the latest package (2.0.15), MaraDNS started consistently crashing with the following error in the log:

Dec 28 12:58:31 srv /usr/local/sbin/maradns: Aieeeeee, can not allocate memory!

Traced the error to the following code section in js_alloc() in JsStrOS.c:

    data = (void *)malloc(unit_count * unit_size);
    ...
    if(data == NULL) {
        /* Securty: In a situtation where we can not allocate memory,
           the subsequent behavior of the program is undefined.  Hence,
           the best thing to do is exit then and there */
        printf("Aieeeeee, can not allocate memory!");
        exit(64);
        return (void *)0;
        }

Results in the following trace:

    mmap(0x0,20480,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_ANON,-1,0x0) ERR#12 'Cannot allocate memory'
    write(1,"Aieeeeee, can not allocate memor"...,34) = 34 (0x22)
    exit(0x40)

MaraDNS appears to limit memory usage itself to about 2.5MB by default:

    setrlimit(RLIMIT_VMEM,{ cur=2646016,max=2646016 }) = 0 (0x0)

I have checked the arguments to malloc (unit_count, unit_size) and the overall memory allocation and there doesn't appear to be a bug or a leak. While MaraDNS is not memory-hungry, it seems that small heap size and some heap fragmentation is enough to exhaust the available memory. 

Workaround is to add max_mem parameter to mararc config. I have set it to 8MB (in bytes) and that helped to avoid crash so far. Will keep monitoring and update the PR if further crashes are experienced.
Comment 1 Kubilay Kocak freebsd_committer freebsd_triage 2018-12-30 01:35:53 UTC
It's difficult to determine what a good (safe, reasonable) default configuration might be for most port/package users.

Docs state:

"""
max_mem determined the maximum amount of memory MaraDNS is allowed to allocate. This is a numeric variable, and the value is in kilobytes. The default value of this is to allocate 1 megabyte for MaraDNS' general use, and in addition, to allocate 1536 bytes for each element we can have in the cache or DNS record that we are authoritatively serving.

If, for whatever reason, you wish to disable this feature, add the following lint to your mararc file:

max_mem = 0
"""

The "and in addition" bit reads like the the max_mem value is variable based on the data that is being served. I have not verified this.

Is the default max_mem value specified statically in a configuration file that maradns uses out of the box for the freebsd ports/packages, or is it an internal default value if not specified in a configuration?
Comment 2 Nino 2018-12-30 04:17:56 UTC
The value is hard-coded in the source if there is no specific override value in the conf file:

    maxprocs = read_numeric_kvar("max_mem",
               1048576 + thread_overhead +
               ((cache_size + dns_records_served) * 1536));
    if(maxprocs < 262144 && maxprocs > 0) { maxprocs = 262144; }
    if(maxprocs > 0) {
      rlim.rlim_cur = rlim.rlim_max = maxprocs;
      if(setrlimit(MAX_MEM,&rlim) != 0) {

max_mem depends on the number of records served. In my case, I only have ~20 records, so the limit is still dominated with the (default) cache_size of 1024. In fact, with no records served, memory limit is exactly 2621440 (1048576+1024*1536) which possibly suggests this is a typo in the code (262144 instead of 2621440). 

NB - quoted documentation is wrong, max_mem is in bytes and not kilobytes (installed man page is correct).
Comment 3 takefu 2019-01-07 06:58:34 UTC
Created attachment 200858 [details]
maradns-2.0.16.patch

Update to 2.0.16

Fix:
  broken in 12.0-RELEASE.
  IPv6 support for sample files.
  portlint(1) complied.
Comment 4 takefu 2019-02-04 01:30:03 UTC
Created attachment 201702 [details]
maradns-2.0.16.patch

fix server/MaraDNS.c
Comment 5 takefu 2019-04-19 08:15:41 UTC
Created attachment 203789 [details]
maradns-2.0.17.patch

Update up 2.0.17
Comment 6 Kenji Takefu freebsd_committer freebsd_triage 2019-04-22 02:53:59 UTC
(In reply to takefu from comment #5)

approval
Comment 7 Kenji Takefu freebsd_committer freebsd_triage 2019-07-22 03:09:34 UTC
Time has passed for a long time. I don't have permission to commit, so I want you to act on your behalf.

:~(
Comment 8 Daniel Engberg freebsd_committer freebsd_triage 2022-03-26 17:32:02 UTC
Upstream is at 3.5.0021, can one of you please provide a new and updated patch?
Comment 9 takefu 2022-03-30 08:18:00 UTC
Created attachment 232812 [details]
maradns-3.5.0021.patch

Update to 3.5.0021
Comment 10 takefu 2023-06-14 02:33:00 UTC
Created attachment 242770 [details]
maradns-3.5.0036.patch

Update to 3.5.0036

https://maradns.samiam.org/changelog.html


maradns-3.5.0036:
This is a stable release of MaraDNS:

        Fix for CVE-2023-31137 

    (2023-05-02) 

maradns-3.4.10:
This is a legacy release of MaraDNS:

        Fix for CVE-2023-31137 

    (2023-05-02) 

maradns-3.5.0035:
This is a stable release of MaraDNS:

        Hotfix: Block hashes now work in the Windows compile of Deadwood
        Markdown version of documents added
        Minor doc fixes 

    (2022-12-21) 

maradns-3.5.0034:
This is a stable release of MaraDNS:

        “block hash” tools completed: blockHashRead and blockHashMake
        Block hash tools now install with MaraDNS and have man pages
        Deadwood now has block hash support: The ability to block over 200,000 domains while using only 10 megabytes of memory or so
        Block hash information added to Deadwood man page
        Update Lunacy documentation to be consistent with the MaraDNS version of Lunacy (which, unlike the standalone version, does not have spawner or lfs)
        Because some servers in early 2011 responded to AAAA queries with “server fail”, Deadwood treated these server fails as “no AAAA there”. This made IPv6 more fragile; here in 2022 those poorly designed DNS servers look to be no more, so we can correctly treat “server fail” for AAAA queries as “try again”. 

    (2022-12-19) 

maradns-3.5.0033:
This is a stable release of MaraDNS:

        coLunacyDNS now uses the 2022-12-06 version of Lunacy; this means the Lunacy Git version and the version in MaraDNS are the same code (albeit without lfs or spawner in the MaraDNS version)
        Lunacy (Lua 5.1 fork) now uses editline (and not readline) for history
        coLunacyDNS update to 1.0.014: RFC8482 packets now have a 0 TTL, and the underlying Lunacy (Lua 5.1) code is now based on the 2022-12-06 version of Lunacy
        Begin work on “block hash” support. The plan is to use these “block hash” files to allow Deadwood to have a large list of hosts to block (a large blocklist or “naughty list”) while using a minimum amount of memory without sacrificing performance. 

    (2022-12-06) 

maradns-3.5.0032:
This is a stable release of MaraDNS:

        "make install" now installs coLunacyDNS and lunacy
        "make uninstall" now properly removes files, and disables the maradns/colunacydns/deadwood systemd services 

    (2022-11-29) 

maradns-3.5.0031:
This is a stable release of MaraDNS:

        "make install" now installs working files to start MaraDNS at system start up in Ubuntu22.04 (systemd).
        While there are no plans to remove the support, the script called by "make install" no longer attempts to install system startup files on systems without systemd unless called with a special "--unsupported" argument.
        Duende man page updated to note systemd does everything Duende does on non-systemd systems.
        Since MaraDNS has Duende, no need for Deadwood to have Duende too. 

    (2022-11-28) 

maradns-3.5.0030:
This is a stable release of MaraDNS:

        MaraDNS no longer accepts ANY queries as per RFC8482. The older behavior can be restored by editing MaraDNS’ configuration file.
        maradns.exe updated to 2022-11-26 to have RFC8482 compliant behavior.
        MaraDNS automated tests updated to pass with RFC8482 behavior 

    (2022-11-26) 

maradns-3.4.09:
This is a legacy release of MaraDNS:

        MaraDNS and Deadwood no longer allow ANY queries as per RFC8482 

    (2022-11-25) 

maradns-3.5.0029:
This is a stable release of MaraDNS:

        Deadwood now implements RFC8482: All ANY and HINFO queries now return a RFC8482 reply by default. The older behavior can be restored by editing Deadwood’s configuration file.
        Documentation updates: Updated security bug reporting policy, Document maradns.exe for Windows is unsupported, document new rfc8482 behavior, note changes made for MaraDNS 3.4.08, etc.
        Windows builds of Deadwood now use dates for version numbers. This way, I don’t need to update the .exe binary if a release without Deadwood source changes is made. 

    (2022-11-25) 

maradns-3.4.08:
This is a legacy release of MaraDNS:

        Y2038 fixes backported to the 3.4 version of MaraDNS and Deadwood
        Windows32 binaries of the 3.4 version of MaraDNS/Deadwood updated 

    (2022-11-19) 

maradns-3.5.0028:
This is a stable release of MaraDNS:

        Y2038 issues with MaraDNS for win32 have been addressed
        maradns.exe restored; things tested and look to run after Y2038
        Clarify that MaraDNS needs restart to reload zones in man pages 

    (2022-11-17) 

maradns-3.5.0027
This is a stable release of MaraDNS:

        HOTFIX: 3.5.0026 introduced bug where zone files without a SOA record last edited before mid-2020 would have an incorrect serial in the synthetic SOA record. Fixed.
        Y2038 fix for serials in zone files without a SOA edited after the Y2038 cutoff on systems with a 32-bit time_t
        Only update Deadwood.exe in Git when doing the win32 build 

    (2022-11-12) 

maradns-3.5.0026
This is a stable release of MaraDNS:

        coLunacyDNS updated to 1.0.012 (minor speed up with the SipHash code)
        A number of old unused tests and scripts moved over to https://github.com/samboy​/MaraDNS-attic/. This is old stuff which hasn’t beed used for about 15 years.
        Fixing minor potential Y2038 issues in MaraDNS and Deadwood code base.
        Since localtime() won’t work come 2038 if time_t is 32-bit, I have updated code to not show localtime() derived timestamps if time_t is 32 bits. I would rather not show any timestamp than show one with a wrong date come 2038, and people with a 64-bit time_t (pretty much any system from the last five years) will see no change. This only affects MaraDNS’s logging, and only in the rare case of timestamp_type being set in a mararc file.
        Deadwood has a feature where it won’t load the cache if the dwood3rc file has been changed more recently than the cache file. This feature has been disabled on systems with a 32-bit time_t; the workaround is for the user to be sure to delete their cache after they alter their dwood3rc file (or to upgrade to a system with a 64-bit time_t). This is only in effect if cache_file is set and used.
        Synthetic serial numbers now have their highest possible value be in the year 2841 or 4294; serials are now, as per RFC1035, unsigned 32-bit numbers. If you’re in the 2800s and reading this, thank you for using my code so many years later, and synthetic SOA serials will wrap around, so be sure your secondaries only require the serial to change and that it doesn’t have to increment. Another option for 29th century MaraDNS users is to have SOA records in your zone files and set the serial by hand. 

    (2022-11-11) 

maradns-3.4.07:
This is a legacy release of MaraDNS:

        Deadwood updated to 3.4.07
            doc/Deadwood.txt was blank file. Fixed.
            Deadwood’s document building process now uses the 3.5 Lua instead of the older 3.4 Perl scripts.
            Have doc/Makefile be compatible with maramake
        Since MaraDNS 3.5 now uses maramake as the official make platform, update the 3.4 branch to work with the 3.5 toolchain, so I do not have to maintain two toolchains.
        MaraDNS 3.4 still uses the Perl scripts and Lynx/Links to build documents; only Deadwood’s document processing has been updated (but this will probably change in a future 3.4 release, again so I only have to maintain one toolchain) 

    (2022-11-10) 

maradns-3.5.0025:
This is a stable release of MaraDNS:

        The ej2man, ej2txt, and ej2html tools have been rewritten in Lua 5.1
        The old ej tools are now at https://github.com/samboy​/MaraDNS-attic/
        bind2csv2.py now at https://github.com/samboy​/MaraDNS-attic/
        All documents now render with the Lua EJ tools
        Makefiles are now POSIX compliant, as long as the make implementation allows the / character in make targets
        Tweak Deadwood Makefile to not regenerate DwRandPrime.h 

    (2022-10-31) 

maradns-3.5.0024:
This is a stable release of MaraDNS:

        Minor security fix for Deadwood to ensure that no more than 83 queries are made to solve a given request when run as a fully recursive server. This only affects setups where root_servers is set in the Deadwood dwood3rc configuration file.
        Some Deadwood tests have been made more robust so they are much less likely to randomly fail.
        Update Alpine 3.14 Dockerfile to have lua5.1-bit32 and patch. This Docker image can test both the legacy 3.4 and the current 3.5 branches of MaraDNS.
        Deadwood no longer changes its random prime for the hash compressor every time it is compiled, unless the new Makefile.randomprime file is used.
        The ej tools to make the MaraDNS documentation are now unified. ej is a format I came up with in early 2002 to give MaraDNS a unified documentation format.
        Move coLunacyDNS to the top-level directory instead of hiding it in deadwood-${VERSION}/tools/ lunacy is now in coLunacyDNS/ instead of deadwood-${VERSION}
        Begin work on making Lua versions of the ej tools, to remove the final Perl dependency MaraDNS currently has. Right now we have a Lua script to convert .ej files in to .html files. We are still using the Perl tools to make documents until this work is done and tested.
        time-test.c tool added to make sure we will be OK after Y2038 on systems with a 32-bit time_t. Yes, MaraDNS is Y2038 compliant on such systems as long as the underlying timestamp is being updated.
        Update the version of lunacy (Lua 5.1 fork) included with MaraDNS to fix a theoretical issue with its RadioGatun[32] implementation, and to give lunacy lunacy.today() support (so that we can use the lunacy included with MaraDNS to build the MaraDNS documents) 

    (2022-10-24) 

maradns-3.4.06:
This is a legacy release of MaraDNS:

        Minor security fix for Deadwood to ensure that no more than 83 queries are made to solve a given request when run as a fully recursive server. This only affects setups where root_servers is set in the Deadwood dwood3rc configuration file. 

    (2022-10-24) 

maradns-3.4.05:
This is a legacy release of MaraDNS:

        Deadwood updated to 3.4.05
        Deadwood tests are now 3.4 backports of the current 3.5 tests
        Legacy testing platform is now Alpine 3.14. See the Dockerfile in the Deadwood sqa directory for the full platform setup.
        MaraDNS tests are now the current 3.5 MaraDNS tests (no backporting needed)
        All regression tests pass again
        rg32hash.tar.gz, used for testing, added to Deadwood 3.4 tree
        No security fixes 

    (2022-10-18) 

maradns-3.5.0023:
This is a stable release of MaraDNS:

        Testing update: All tests can run in a Ubuntu 22.04 Docker image or an Alpine Linux 3.14 Docker image. Both Dockerfiles are included.
        Testing update: Perl scripts no longer used for the regression tests
        Bugfix: min_ttl now works for all cached entries
        Recursive update: CNAME chains with out-of-bailiwick records are now resolved the same way as other DNS servers
        Development environment updated to Ubuntu 22.04
        Documentation clean up and updates 

    (2022-10-17) 

maradns-3.4.04:
This is a legacy release of MaraDNS:

        Deadwood updated to 3.4.04 (no security updates)
            Backport min_ttl to legacy branch
            Some minor code cleanup 

    (2022-10-16) 

maradns-3.4.03:
This is a legacy release of MaraDNS:

        Backport CVE-2022-30256 to MaraDNS 3.4

    (2022-08-03) 

maradns-3.5.0022:
This is a stable release of MaraDNS:

        Make incomplete last line non-fatal in Windows
        Documentation updates based on user feedback
        New Deadwood parameter: maxttl_reduce_labels for tweaking how many lables a DNS label for a NS referral can have before reducing its TTL.
        Mitigations for an issue where “ghost domains” could stay in the cache longer. This is a low impact security issue with a CVE number: CVE-2022-30256. 

    (2022-05-07) 

maradns-3.5.0021:
This is a stable release of MaraDNS:

        MaraDNS now, by default, will compile with IPv6 support. See MaraDNS GitHUB ticket #97 for discussion.
        One line patch for coLunacyDNS against CVE-2014-5461. This only affects coLunacyDNS (not MaraDNS and not Deadwood); in the context of coLunacyDNS, I can not reproduce the exploit, and only people running untrusted Lua scripts would be vulnerable. 

    (2021-07-28) 

maradns-3.5.0020:
This is a stable release of MaraDNS:

        New parameter: source_ip4, to specify the source IP when sending a query to an upstream or authoritative DNS server.
        Makefile.centos8 file for Deadwood renamed Makefile.Ubuntu2004 (i.e. it’s now a Makefile for Ubuntu 20.04) 

    (2021-05-15) 

maradns-3.5.0019:
This is a stable release of MaraDNS:

        One line change to zoneserver.c to make it work better with systemd
        Synthetic IP generator example (e.g. 10.1.2.3.ip4.internal resolves to 10.1.2.3) added to coLunacyDNS documentation 

    (2021-03-16) 

maradns-3.5.0018:
This is a stable release of MaraDNS:

        coLunacyDNS updated to 1.0.010 (Ubuntu 20.04 testing found a minor select() bug)
        Since RedHat has broken their pinky promise to support CentOS 8 until 2029, MaraDNS has moved from CentOS 8 to Ubuntu 20.04 LTS (RPM .spec files removed; Docker container now runs Ubuntu 20.04) 

    (2020-12-20) 

maradns-3.5.0017:
This is a stable release of MaraDNS:

        coLunacyDNS update: We can now specify the “Authoritative” and “Recursion available” flags in the reply.
        coLunacyDNS update: We can now specify a TTL for the reply, to be anywhere from 0 seconds (do not cache) to a little over 90 days.
        coLunacyDNS version updated to be 1.0.009. 

    (2020-10-02) 

maradns-3.5.0016:
This is a stable release of MaraDNS:

        Unstable mmLunacyDNS code removed from tree (coLunacyDNS can do anything mmLunacyDNS could do)
        coLunacyDNS bug fixes: We return with an error if the Lua code attempts to return an invalid IPv4 address to the client (before, the code incorrectly returned 255.255.255.255)
        coLunacyDNS returns helpful errors if the processQuery return value is invalid in various ways.
        coLunacyDNS now has 100%* testing coverage. *Some sanity tests which protect coLunacyDNS from security threats which can not be readily reproduced are disabled in testing mode.
        coLunacyDNS is now at version 1.0.008 

    (2020-09-01) 

maradns-3.5.0015:
This is a stable release of MaraDNS (coLunacyDNS is now stable):

        coLunacyDNS is now stable (1.0.007) with a full SQA testing suite and well over 90% code coverage in its tests.
        mmLunacyDNS has been removed; coLunacyDNS can do everything mmLunacyDNS could do, and this saves me the bother of maintaining two code bases.
        askmara now compiles with IPv6 support (the code has been there, but is finally getting enabled) 

    (2020-08-29) 

maradns-3.5.0014:
This is a stable release of MaraDNS (Please note that coLunacyDNS and mmLunacyDNS are still unstable):

        coLunacyDNS’s Lua script can now specify IPv6 addresses in standard “colon” format, e.g. co1Data="2001:db8::1"
        coLunacyDNS now handles ANY (and HINFO) queries as per RFC8482
        coLunacyDNS documentation updates: Various cleanup. Also, the example coLunacyDNS .lua files now return “not there” when we ask for a hostname which does not have a given record. 

    (2020-08-20) 

maradns-3.5.0013:
This is a stable release of MaraDNS (Please note that coLunacyDNS and mmLunacyDNS are still unstable):

        coLunacyDNS now has support for binding to IPv6 addresses. Both the *NIX (Linux) and the Windows32 binary can bind to an IPv6 socket.
        Some other bug fixes and cleanup, mainly with coLunacyDNS. 

    (2020-08-19) 

maradns-3.5.0012:
This is a stable release of MaraDNS (Please note that coLunacyDNS and mmLunacyDNS are still unstable):

        mmLunacyDNS security fix: We now use a secure hash compression function (HalfSipHash-1-3) for string hashing.
        coLunacyDNS: hash compression function updated from 64-bit SipHash-2-4 to 32-bit HalfSipHash-1-3. Compile time warnings removed from code.
        lunacy: The code by default now uses HalfSipHash-1-3 for string hash compression. Default compile optimization is now -O3 

    (2020-08-12) 

maradns-3.5.0011:
This is a stable release of MaraDNS (Please note that coLunacyDNS and mmLunacyDNS are still unstable):

        min_ttl parameter added; this is the minimum time we keep a record in the cache (in seconds)
        Deadwood now compiles with IPv6 support by default. For systems without IPv6 support, -DNOIP6 can be set when compiling Deadwood.
        Automated tests now all run inside of Podman (Docker) container and all pass. Tests are now completely automated, and can run from cron (and can be adapted to run inside Jenkins).
        I now run automated tests against MaraDNS every night on my server which runs cron jobs.
        coLunacyDNS update: Bug where only one thread could be contacting an upstream DNS server at a time fixed. 

    (2020-08-10) 

maradns-3.5.0010:
This is a stable release of MaraDNS:

        Hotfix: coLunacyDNS no longer fails after 20 calls to processQuery() (we now properly clean the main stack before calling processQuery() in a co-routine).
        Security update: MaraDNS, Deadwood, and Duende now default to the user ID 707 instead of 99/66. This minimizes the chances of the user used by MaraDNS being used by other processes, which could be a security leak under some circumstances. The problem with running multiple services as "nobody" is that the "nobody" account is only as secure as the least secure service running as that account.
        coLunacyDNS feature update: coLunacyDNS can now open and read files (for security reasons, only in the same directory coLunacyDNS is running in). In addition, the code to implement IPv6 sockets is well under way. 

    (2020-08-06) 

maradns-3.5.0009:
This is a stable release of MaraDNS:

        Add new program: coLunacyDNS. This is a DNS server which runs a Lua function every time it gets a DNS query. It uses Lua threads ("co-routines") to have a function which can get a DNS packet from an upstream server and return the result for processing by the Lua script (doing all this required setting up an entire select()-based state machine). coLunacyDNS also supports sending proper "not there" replies and both sending and receiving IPv6 DNS records (but presently only over IPv4).
        Deadwood ip6 records can now have dashes and spaces in them to make reading a 128-bit IP easier.
        SQA tests have been updated to run in CentOS 8. 

    (2020-08-03) 

maradns-3.5.0008:
This is a stable release of MaraDNS:

        Add new program: mmLunacyDNS. This is an updated version of the microdns program, a program which always returns the same IP for any DNS query given to it, with Lua scripting support (so we can customize what gets logged, return different IPs for different queries, and ignore non-IPv4 IP address queries). The program can also run as a Windows service. The script can only return IPv4 IP addresses or ignore queries, but it’s quite flexible given those limitations.
        Since mmLunacyDNS has Lua support, we now include the full source of my fork of Lua 5.1, “Lunacy”. The reason why I am using an older version of Lua is because this is the version of Lua supported by LuaJIT, and I like having the option of increasing performance with LuaJIT without breaking existing Lua-based configuration files.
        Deadwood logging update: Only note if one can not open cache when verbose_level is 10 or more (since this is mostly harmless). This is a non-fatal error which can be safely ignored. The cache file just keeps copies of previously resolved DNS names around between invocations of Deadwood; if the cache file can’t be read, then DNS resolution might be a bit slower for some names after starting up Deadwood, but everything will be OK.
        I have added the ability to have multiline comments in Deadwood configuration files by using _rem={ at the beginning of a line; this indicates that a comment should continue until a } character is seen. The reason for the unusual syntax is so that we can have multi-line comments in script files which are compatible with Deadwood, Lua, and Python. 

    (2020-07-24) 

maradns-3.5.0007:
This is a stable release of MaraDNS:

        Update name of "ip_blacklist" to be "ip_blocklist". The old name "ip_blacklist" still works (and I have no plans to remove it), but "ip_blocklist" is more up to date.
        Note in some older documents that while "primary" and "replica" are more up to date ways of saying "master" and "slave", the documents will, in the interest of compatibility, retain the "master" and "slave" wording. 

    (2020-07-07) 

maradns-3.5.0006:
This is a stable release of MaraDNS:

        Deadwood configuration files can now have leading space in them. Deadwood no longer uses a subset of Python2 syntax, since Python2 is now post-End of life. 

    (2020-07-01) 

maradns-3.5.0005:
This is a stable release of MaraDNS:

        MaraDNS is now fully supported in Cygwin
        Windows port of MaraDNS no longer includes maradns.exe; we instead tell people how to compile MaraDNS in Cygwin. Note: We continue to fully support Deadwood for Windows, which is a proper Windows service (unlike the old maradns.exe).
        Dockerfile now creates Docker image with working instance of MaraDNS. This is still a work in progress; one currently needs to enter the Docker container to change MaraDNS configuration files.
        Version number fixed when compiling a MaraDNS release. 

    (2020-06-02) 

maradns-3.5.0004:
This is a stable release of MaraDNS:

        maximum_cache_elements no longer needs to include blacklist, root server, upstream server, or synthetic IP elements.
        Documentation updates, mainly for maximum_cache_elements change 

    (2020-04-18) 

maradns-3.5.0003:
This is a stable release of MaraDNS:

        Added support for blacklists as per GitHub issue #69 and GitHub issue #70
        Minimize memory usage of blacklists by allowing the same entry to be used for IPv4 and IPv6 

    (2020-04-16) 

maradns-3.5.0002:
This is a stable release of MaraDNS:

        Documentation and other updates and cleanups.
        Windows port no longer needs to have secret.txt file to run; the Deadwood Windows port now uses the Windows call CryptGenRandom() to get entropy. 

    (2020-02-03) 

maradns-3.5.0001:
This is a stable release of MaraDNS:

        bind2csv2.py updated to run in Python3.
        This is the first “One Source of Truth” release of MaraDNS: All files in the release are derived directly from the Git version of MaraDNS.
        Github history going back to 2014 is now included as part of the source code tarball.
        Scripts to test the Git version of MaraDNS, to make the Windows binaries, and to convert the Git version in to a tarball and Windows zipfile added. 

    (2020-01-25) 

maradns-3.4.02:
This is a stable release of MaraDNS:

        Tests updated to run and pass in CentOS 7
        Fix typo in asktest.c.
        Deadwood: Issue building Deadwood from the GitHub tree in CentOS8 fixed
        Deadwood: Update Windows documents in Deadwood source code tarball 

    (2020-01-16) 

maradns-3.4.01:
This is a stable release of MaraDNS:

        Deadwood updated to 3.4.01 

    (2019-10-24) 

Important: Deadwood 3.4.01 is updated to use the Quad9 upstream DNS servers as the default. If the old behavior of using the ICANN name servers as root servers is desired, add the following lines to one’s dwood3rc file:

root_servers = {}
root_servers["."]="198.41.0.4,"
root_servers["."]+="199.9.14.201,"
root_servers["."]+="192.33.4.12,"
root_servers["."]+="199.7.91.13,"
root_servers["."]+="192.203.230.10,"
root_servers["."]+="192.5.5.241,"
root_servers["."]+="192.112.36.4,"
root_servers["."]+="198.97.190.53,"
root_servers["."]+="192.36.148.17,"
root_servers["."]+="192.58.128.30,"
root_servers["."]+="193.0.14.129,"
root_servers["."]+="199.7.83.42,"
root_servers["."]+="202.12.27.33"

Please note: The above list of IPs is current as of 2019-04-07, and was last changed in October of 2017.

Please go to root-servers.org to get an up-to-date list of root servers.

maradns-3.3.03:
This is a development release of MaraDNS.

        Updated numbering system to give MaraDNS the same version number as Deadwood.
        Deadwood updated to 3.3.03.
        Document how star records work. 

    (2019-09-28)
Comment 11 Norikatsu Shigemura freebsd_committer freebsd_triage 2023-06-14 08:08:08 UTC
I'll handle this PR and work with PR#250021, so I close this PR.

*** This bug has been marked as a duplicate of bug 259921 ***