Re: AW: Problems with (unsigned) forward zones, dnssec-validation auto and validate-except on BIND 9.16 and 9.17
On 27. 01. 22 16:05, Gehrkens.IT GmbH | Heiko Wundram wrote: Hello Tony, The other things that can cause the behaviour you observed are synth-from- dnssec and qname-minimization. thanks for the heads up concerning synth-from-dnssec; I thought the default was "no", but that seems to have changed somewhere between 9.14 and 9.16... FTR it was introduced in 9.12.0, later disabled by default in 9.15.6, and reenabled by default in 9.17.21. -- Petr Špaček @ Internet Systems Consortium ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
AW: Problems with (unsigned) forward zones, dnssec-validation auto and validate-except on BIND 9.16 and 9.17
Hello Tony, > The other things that can cause the behaviour you observed are synth-from- > dnssec and qname-minimization. thanks for the heads up concerning synth-from-dnssec; I thought the default was "no", but that seems to have changed somewhere between 9.14 and 9.16... I've just changed that and let's see whether that changes the behaviour. At least, from the documentation it sounds like it should have the same effect. qname-minimization is set to relaxed, so that shouldn't have an effect, and at least all Windows AD DNS-servers I know can cope with normalized/minimized queries. > It might make sense to forward the whole of .lan and .local to your Windows > resolvers, assuming you have one set of servers that knows the whole > namespace. As the AD domains aren't part of a singular forest, there is no "global" lan or local zone, alas. I'm also only able to access other forwarders (rather: firewalls connected via VPN to the resolver), not the nameservers of the disjointed forests themselves, which is the main point why setting up an aggregate .lan/.local-zone is rather difficult, as I can't even put in proper glue if I were to synthesize a corresponding zone. But I'll try with synth-from-dnssec, that should do the trick. Thanks! --- Heiko. smime.p7s Description: S/MIME cryptographic signature ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Problems with (unsigned) forward zones, dnssec-validation auto and validate-except on BIND 9.16 and 9.17
Gehrkens.IT GmbH | Heiko Wundram wrote: > > From what I gather, this behaviour sounds almost like what RFC 8020 proposes > (NXDOMAIN cut), but at least according to the corresponding ticket, that > isn't implemented in BIND. The other things that can cause the behaviour you observed are synth-from-dnssec and qname-minimization. It might make sense to forward the whole of .lan and .local to your Windows resolvers, assuming you have one set of servers that knows the whole namespace. Tony. -- f.anthony.n.finchhttps://dotat.at/ Bailey: Northwest 5 or 6, backing southwest 6 to gale 8, perhaps severe gale 9 later. Very rough, becoming rough for a time. Showers, rain later. Good, becoming moderate or poor later. ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Problems with (unsigned) forward zones, dnssec-validation auto and validate-except on BIND 9.16 and 9.17
Dear list, I'm currently setting up a resolver using bind (tested with both 9.16 and 9.17), which uses multiple views to expose forwarded zones (under .lan and .local, old Windows-AD zones which I don't control and can't change.) under some of their views. All of the views have dnssec-validation auto (set as a global option), and the forwarding zones are configured as "type forward; forward only;" in each specific view using an import from a single configuration file which contains all forward zone specifications and also a "validate-except" clause which lists all of the forwarded zones. Generally, this works: in the views that should resolve the internal forwarded zone names, I can resolve them, and BIND also skips DNSsec validation for those zones. Now comes the but: if I resolve a zone name in .lan or .local which is not forwarded I get an NXDOMAIN with "ad" as I would expect (coming from the roots which authoritatively don't know e.g. .local), but the cached entry for the authoritative NXDOMAIN seems to block future resolution of all forwarded zones under this pseudo-TLD. When the resolved records under the forwarded .lan or .local zone time out, I get an NXDOMAIN for any record that I try to resolve in a zone that should be reachable through forward, with "authority" for the result pointing to the roots. It seems that this also kills the connectivity of the forward zone completely (i.e., the zone is removed from BIND in some way or another): I need to restart bind to make the forward-zones resolvable again, clearing the resolver cache does not seem to help to get them to resolve again. >From what I gather, this behaviour sounds almost like what RFC 8020 proposes (NXDOMAIN cut), but at least according to the corresponding ticket, that isn't implemented in BIND. BIND 9.11 (which comes with Debian Buster) did not have this behaviour with this configuration (for BIND 9.11, I did not use validate-except but periodic rndc nta for the injected forward zones, but using that with BIND 9.16/.17 gives the same result as above), but after updating BIND to the version in bullseye (which comes with 9.16), I see this behaviour, and it seems that this only happens when DNSsec validation is on. Turning it off makes the forward zones work correctly. I do not want to turn off DNSsec validation completely, and neither do I want to "validate-except" lan and local (which does not help anyway, as I currently don't have a .lan/.local zone file set up and would rather not have to manage one, as the forwarders aren't the NS records for the zones I'm looking up anyway, so it'd be rather difficult to make a proper glue entry for the forwarded zones without additional network magic). Thanks for any hints on where I might look; I tried to follow the actual resolver code, but that gave me no immediate cause for the change, and I also found no entries in the bugtracker. Heiko. smime.p7s Description: S/MIME cryptographic signature ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
