COREDNS-FILE(7)

πŸ“¦
version 1.15.0 Β· 3 versions
, in opensuse-leap 16.0

🌸 NAME 🌸

okay so bestie, welcome to COREDNS-FILE(7), one of the CoreDNS plugins pages πŸ’– and this one's about file β€” it enables serving zone data from an RFC 1035-style master file. that's it, that's the vibe ✨


πŸŽ€ DESCRIPTION πŸŽ€

so the file plugin? it's for an "old-style" DNS server, and honestly it ate πŸ’… it serves from a preloaded file that exists on disk containing RFC 1035 styled data.

if the zone file contains signatures (i.e., it's signed using DNSSEC), correct DNSSEC answers are returned πŸ”₯ but heads up: only NSEC is supported! so if you're running this setup, you are responsible for re-signing the zonefile. no cap, that part's on you 🫢


✨ 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 🌈

the SOA record's owner name must match the zone being loaded, like the universe will simply not allow otherwise πŸ’€ names without a final dot are relative to the current origin; for example test in a zone loaded as test. becomes test.test., not test.. use @ (when the current origin matches the zone) or the zone's absolute name for the SOA owner ⭐

a mismatched SOA causes loading to fail; an invalid reload leaves the last successfully loaded zone in service. so it's giving graceful, but it is also giving rejected πŸ™ˆ

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 DURATION β€” 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. lowkey iconic behavior fr fr
  • 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 πŸ’–

🌸 example the first

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://www.rfc-editor.org/info/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

πŸ¦‹ example the second

or use a single zone file for multiple zones, with relative owner names and no fixed $ORIGIN:

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

for example, db.shared can contain:

@   3600 IN SOA sns.dns.icann.org. noc.dns.icann.org. 2017042745 7200 3600 1209600 3600
@   3600 IN NS a.iana-servers.net.
www 3600 IN A 127.0.0.1

each configured zone is used as the initial origin when parsing this file, so @ is its apex πŸŽ€ signed zones require signatures for the actual owner names and must be signed separately. periodt.

🧚 the origin problem (a cautionary tale)

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. a file with an SOA for example.org. will be rejected because it does not match the configured root zone, even if the file sets $ORIGIN example.org. 😭 (yes, even then. tragic.)

specify the correct zone in one of 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 (https://www.rfc-editor.org/info/rfc1035/) for more info on how to structure zone files πŸ“š


ok that's the whole page bestie, go forth and serve zones responsibly πŸ’…βœ¨

this has been COREDNS-FILE(7) from the CoreDNS plugins, brought to you by CoreDNS, dated October 2026 β€” mwah, love u, bye πŸŽ€πŸ’–

πŸ“¦ where this page comes from