Quoting Steve Litt (sl...@troubleshooters.com): > The syntax isn't "stub zone", it's "local zone". They use the "stub > zone" syntax for something else. Thank you for turning me on to Unbound > --- it's twice as easy as Bind9 and djbdns.
You're very welcome. I quote below (in part) the documentation at https://nlnetlabs.nl/documentation/unbound/unbound.conf/ , entry for 'stub zone options': The stub zone can be used to configure authoritative data to be used by the resolver that cannot be accessed using the public internet servers. This is useful for company-local data or private zones. Setup an authoritative server on a different host (or different port). Enter a config entry for unbound with stub-addr: <ip address of host[@port]>. The unbound resolver can then access the data, without referring to the public internet for it. Sounds relevant, but you be the judge. Having never needed to use Unbound for anything but pure recursive-server duty, I've not yet bothered to sort these other features out. I gather that the keyword 'local-zone' has this function: Consider adding server: statements for domain-insecure: and for local-zone: name nodefault for the zone if it is a locally served zone. The insecure clause stops DNSSEC from invalidating the zone. The local zone nodefault (or transparent) clause makes the (reverse-) zone bypass unbound's filtering of RFC1918 zones. But I'd have to read up before understanding what 'filtering of RFC1918 zones' refers to specifically. Me, I like to just keep authoritative and recursive functions totally separate. _______________________________________________ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
