Files
coredns/plugin/file
Baltasar Blanco 989bf4a9fd plugin/file: resolve each additional section target only once (#8286)
* plugin/file: resolve each additional section target only once

additionalProcessing walked the answer and appended each target's address records without keeping track of the targets it had already resolved. An answer holding several records that point at one target, two MX records differing only in preference for instance, therefore repeated that target's A, AAAA and RRSIGs once per record. SRV, SVCB and HTTPS take the same path and behaved the same way. plugin/backend_lookup.go already skips targets it has seen; the file plugin never did.

Targets are compared in canonical form because SRV targets are not lowercased on insert, so one target can reach additional processing spelled two ways while the zone's tree still matches it case-insensitively. The map is allocated on first use, as additionalProcessing runs for every answer and most carry no target at all.

Fixes #6626

Signed-off-by: baltasarblanco <baltablanco9008@gmail.com>

* plugin/file: move additional section tests to lookup_test.go

The cases exercise additionalProcessing, which lives in lookup.go, so they belong with the rest of the lookup tests. No test logic is changed.

Addresses review feedback.

Signed-off-by: baltasarblanco <baltablanco9008@gmail.com>

---------

Signed-off-by: baltasarblanco <baltablanco9008@gmail.com>
2026-07-24 15:10:04 -07:00
..
2018-09-22 15:12:02 +01:00
2019-08-21 16:08:55 -04:00
2022-03-18 07:11:14 -07:00
2018-07-19 16:23:06 +01:00
2023-04-25 11:25:07 -04:00

file

Name

file - enables serving zone data from an RFC 1035-style master file.

Description

The file plugin is used for an "old-style" DNS server. It serves from a preloaded file that exists on disk contained RFC 1035 styled data. If the zone file contains signatures (i.e., is signed using DNSSEC), correct DNSSEC answers are returned. Only NSEC is supported! If you use this setup you are responsible for re-signing the zonefile.

Syntax

file DBFILE [ZONES...]
  • DBFILE the database file to read and parse. If the path is relative, the path from the root plugin will be prepended to it.
  • ZONES zones it should be authoritative for. If empty, the zones from the configuration block are used.

If you want to round-robin A and AAAA responses look at the loadbalance plugin.

file DBFILE [ZONES... ] {
    reload DURATION
    reload_by_mtime
    fallthrough [ZONES...]
}
  • reload interval to perform a reload of the zone if the SOA version changes. Default is one minute. Value of 0 means to not scan for changes and reload. For example, 30s checks the zonefile every 30 seconds and reloads the zone when serial changes.
  • reload_by_mtime if set, decision to reload the zone will be based on the zone file modification time, instead of change in the SOA serial.
  • fallthrough If zone matches and no record can be generated, pass request to the next plugin. If [ZONES...] is omitted, then fallthrough happens for all zones for which the plugin is authoritative. If specific zones are listed (for example in-addr.arpa and ip6.arpa), then only queries for those zones will be subject to fallthrough.

If you need outgoing zone transfers, take a look at the transfer plugin.

Examples

Load the example.org zone from db.example.org and allow transfers to the internet, but send notifies to 10.240.1.1

example.org {
    file db.example.org
    transfer {
        to * 10.240.1.1
    }
}

Where db.example.org would contain RRSets (https://tools.ietf.org/html/rfc7719#section-4) in the (text) presentation format from RFC 1035:

$ORIGIN example.org.
@	3600 IN	SOA sns.dns.icann.org. noc.dns.icann.org. 2017042745 7200 3600 1209600 3600
	3600 IN NS a.iana-servers.net.
	3600 IN NS b.iana-servers.net.

www     IN A     127.0.0.1
        IN AAAA  ::1

Or use a single zone file for multiple zones:

. {
    file example.org.signed example.org example.net
    transfer example.org example.net {
        to * 10.240.1.1
    }
}

Note that if you have a configuration like the following you may run into a problem of the origin not being correctly recognized:

. {
    file db.example.org
}

We omit the origin for the file db.example.org, so this references the zone in the server block, which, in this case, is the root zone. Any contents of db.example.org will then read with that origin set; this may or may not do what you want. It's better to be explicit here and specify the correct origin. This can be done in two ways:

. {
    file db.example.org example.org
}

Or

example.org {
    file db.example.org
}

See Also

See the loadbalance plugin if you need simple record shuffling. And the transfer plugin for zone transfers. Lastly the root plugin can help you specify the location of the zone files.

See RFC 1035 for more info on how to structure zone files.