Skip site navigation (1)Skip section navigation (2)

  
 
  

home | help 
COREDNS-FILE(7) 		 CoreDNS Plugins		 COREDNS-FILE(7)

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
		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  sec-
	 onds and reloads the zone when serial changes.

     *	 fallthrough  If  zone	matches and no record can be generated, pass re-
	 quest to the next plugin.  If [ZONES...] is omitted,  then  fallthrough
	 happens  for  all  zones for which the plugin is authoritative. If spe-
	 cific 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
     <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 <https://www.rfc-editor.org/rfc/rfc1035.txt> for more info on
     how to structure zone files.

CoreDNS 			   March 2026			 COREDNS-FILE(7)

Want to link to this manual page? Use this URL:
<https://man.freebsd.org/cgi/man.cgi?query=coredns-file&sektion=7&manpath=FreeBSD+Ports+15.1.quarterly>

home | help