Re: Local Slave copy of root zone
On 08/21/2018 08:53 AM, Grant Taylor via bind-users wrote: On 08/20/2018 11:06 PM, Doug Barton wrote: But that doesn't mean that slaving a zone, any zone, including the root, is "dangerous." If slaving zones is dangerous, the DNS is way more fragile than it already is. Sorry, poor chose of words. The last time I read the RFC discussing slaving the root zone stressed that it should only be done for localhost and / or a special config that could only impact the single host if (implying when) there was a problem, thus limiting the scope of negative impact. I combined that and the potential unvalidated zone transfer allowing ""corruption and called it "dangerous". I don't think there is anything dangerous about slave zone transfers at all. I've been doing them for the better part of 20 years. I think the ""danger, if any, is the fact that the discussion was around the root zone and the potential impact of the blast radius if things went wrong. Namely all client machines that used the DNS server in question. The DNSSEC validation errors that Tony references are self-healing, in that if the validating resolver stops validating things, the operator is hopefully going to notice that, and take steps to fix it. Sadly, the small user base that I've had, has been more likely to not tell me about problems and live with things or change things to use other servers without providing that desired ~> needed feedback loop. I am certainly open to the new mirror zone software doing awesome things, don't get me wrong. But don't call something "dangerous" that lots of people have already been using successfully for over 15 years. Sorry for the poor choice of words. Fair enough, no harm in challenging assumptions, etc. I have never said that slaving the root is for everyone, and you've illustrated some good reasons why. ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Local Slave copy of root zone
On 08/20/2018 11:06 PM, Doug Barton wrote: But that doesn't mean that slaving a zone, any zone, including the root, is "dangerous." If slaving zones is dangerous, the DNS is way more fragile than it already is. Sorry, poor chose of words. The last time I read the RFC discussing slaving the root zone stressed that it should only be done for localhost and / or a special config that could only impact the single host if (implying when) there was a problem, thus limiting the scope of negative impact. I combined that and the potential unvalidated zone transfer allowing ""corruption and called it "dangerous". I don't think there is anything dangerous about slave zone transfers at all. I've been doing them for the better part of 20 years. I think the ""danger, if any, is the fact that the discussion was around the root zone and the potential impact of the blast radius if things went wrong. Namely all client machines that used the DNS server in question. The DNSSEC validation errors that Tony references are self-healing, in that if the validating resolver stops validating things, the operator is hopefully going to notice that, and take steps to fix it. Sadly, the small user base that I've had, has been more likely to not tell me about problems and live with things or change things to use other servers without providing that desired ~> needed feedback loop. I am certainly open to the new mirror zone software doing awesome things, don't get me wrong. But don't call something "dangerous" that lots of people have already been using successfully for over 15 years. Sorry for the poor choice of words. -- Grant. . . . unix || die smime.p7s Description: S/MIME Cryptographic Signature ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Local Slave copy of root zone
On 08/20/2018 09:00 AM, Grant Taylor via bind-users wrote: On 08/20/2018 05:23 AM, Tony Finch wrote: If the local root zone gets corrupted somehow (maliciously or otherwise) the usual setup cannot detect a problem, but it'll cause DNSSEC validation failures downstream. The normal resolver / validator algorithm is more robust. The new mirror zone code validates the root zone before installing it, which at least allows it to detect a problem; I have not examined it closely enough to see how hard it tries to recover by xfering the zone from a different root server, or if it just falls back to normal resolution. Thank you for that explanation. It explains why it's potentially dangerous to blindly slave the root zone for general use by clients on a local recursive resolver. No, it doesn't do that at all. It may be true that the new mirror zone code does awesome things to make sure that the slaved zone is identical to the master's, I don't know, I haven't seen it. But that doesn't mean that slaving a zone, any zone, including the root, is "dangerous." If slaving zones is dangerous, the DNS is way more fragile than it already is. The DNSSEC validation errors that Tony references are self-healing, in that if the validating resolver stops validating things, the operator is hopefully going to notice that, and take steps to fix it. And I have always said that you should not be slaving the root unless you already have a good mechanism for making sure that said slaving isn't failing. (In other words, don't go into this, or any other configuration blind.) I am certainly open to the new mirror zone software doing awesome things, don't get me wrong. But don't call something "dangerous" that lots of people have already been using successfully for over 15 years. ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Local Slave copy of root zone
On 08/20/2018 05:23 AM, Tony Finch wrote: If the local root zone gets corrupted somehow (maliciously or otherwise) the usual setup cannot detect a problem, but it'll cause DNSSEC validation failures downstream. The normal resolver / validator algorithm is more robust. The new mirror zone code validates the root zone before installing it, which at least allows it to detect a problem; I have not examined it closely enough to see how hard it tries to recover by xfering the zone from a different root server, or if it just falls back to normal resolution. Thank you for that explanation. It explains why it's potentially dangerous to blindly slave the root zone for general use by clients on a local recursive resolver. -- Grant. . . . unix || die smime.p7s Description: S/MIME Cryptographic Signature ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Local Slave copy of root zone
Doug Barton wrote: > > How, specifically, is DNSSEC affected by the validating resolver having a > local copy of the root zone? If the local root zone gets corrupted somehow (maliciously or otherwise) the usual setup cannot detect a problem, but it'll cause DNSSEC validation failures downstream. The normal resolver / validator algorithm is more robust. The new mirror zone code validates the root zone before installing it, which at least allows it to detect a problem; I have not examined it closely enough to see how hard it tries to recover by xfering the zone from a different root server, or if it just falls back to normal resolution. Tony. -- f.anthony.n.finchhttp://dotat.at/ Hebrides, Bailey, Fair Isle, Faeroes, Southeast Iceland: Westerly, backing southerly later, 4 or 5, occasionally 6 later in Fair Isle. Moderate, occasionally slight. Showers then rain. Good, becoming moderate or poor. ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Local Slave copy of root zone
On 2018-08-15 10:43, Tony Finch wrote: Doug Barton wrote: Slaving the root and ARPA zones is a small benefit to performance for a busy resolver, [...] This technique is particularly useful for folks in bad/expensive network conditions. While the current anycast networks of root servers is much better than it was "in the old days," the more data you have locally the more resilient you are to DDOS against those targets. I should probably have said that it isn't just RFC 8198: * synth-from-dnssec (RFC 8198) synthesizes negative answers, so in most cases you don't need to talk to the authorities to find out that the answer is no; this is on by default If you're slaving the zone on the resolver, that resolver is authoritative for the zone, so it doesn't need to query another server to prove that the answer is no. * prefetch (https://tools.ietf.org/html/draft-wkumari-dnsop-hammer [1]) means your users won't suffer the latency of talking to the authorities when a popular name expires from the cache; this is on by default If you're slaving the zone, there is no cache to expire. * stale-answer-enable / max-stale-ttl (https://tools.ietf.org/html/draft-ietf-dnsop-serve-stale) means you can still function for a while if you can't reach the authorities This is a terrible idea, so not having it is a good thing. :) These are all general-purpose features, not at all specific to the root. I think a local root was clearly a good idea before DNSSEC; since 2010 I have been less comfortable with it. How, specifically, is DNSSEC affected by the validating resolver having a local copy of the root zone? Doug ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Local Slave copy of root zone
> BIND 9.14 will have an improved local root implementation (called a > "mirror" zone) which validates the zone so you don't blindly serve bogus > data. The feature is available now in the 9.13 dev branch; I have not > tried mirroring the arpa zones - the docs suggest that isn't a supported > config for mirror zones. The catch is that, as of current master, you would have to configure trusted-keys/managed-keys for each zone you would like to mirror. In other words, the chain of trust from the root is currently not established automatically when a mirror zone is validated. This might change in the future, but since the root zone is the primary use case and a default trust anchor for the root zone is installed implicitly, I would not hold my breath for it. -- Best regards, Michał Kępień ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Local Slave copy of root zone
Doug Barton wrote: > > Slaving the root and ARPA zones is a small benefit to performance for a busy > resolver, [...] > This technique is particularly useful for folks in bad/expensive network > conditions. While the current anycast networks of root servers is much better > than it was "in the old days," the more data you have locally the more > resilient you are to DDOS against those targets. I should probably have said that it isn't just RFC 8198: * synth-from-dnssec (RFC 8198) synthesizes negative answers, so in most cases you don't need to talk to the authorities to find out that the answer is no; this is on by default * prefetch (https://tools.ietf.org/html/draft-wkumari-dnsop-hammer [1]) means your users won't suffer the latency of talking to the authorities when a popular name expires from the cache; this is on by default * stale-answer-enable / max-stale-ttl (https://tools.ietf.org/html/draft-ietf-dnsop-serve-stale) means you can still function for a while if you can't reach the authorities These are all general-purpose features, not at all specific to the root. I think a local root was clearly a good idea before DNSSEC; since 2010 I have been less comfortable with it. [1] contains possibly my favourite ack ever Tony. -- f.anthony.n.finchhttp://dotat.at/ Sole, Lundy, Fastnet: Southwest veering west, 4 or 5, increasing 6 for a time. Moderate or rough, occasionally slight later. Rain then showers. Moderate or poor, becoming good. ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Local Slave copy of root zone
On 08/15/2018 09:11 AM, Bob McDonald wrote: I've recently been investigating having a local slave copy of the root zone on a caching/forwarder type server. I've even put the local slave copy of the root zone into a separate view accessed via a different loopback address. (An limited example of this exists on the ISC site) My question is this. Is there any benefit to also hosting local slave copies of arpa., in-addr.arpa., and ip6.arpa.? Although FreeBSD now comes with unbound as it's default DNS software, installing bind yields an example named.conf which floats the concept of the local slave copies of the above zones. (That is what led me down this path...) I'm responsible for the slave zone configuration in the FreeBSD named.conf. At least, I wrote the original version of it, and maintained it for many years. The version located here looks essentially as I left it: https://svnweb.freebsd.org/ports/head/dns/bind913/files/named.conf.in?revision=470832=markup Slaving the root and ARPA zones is a small benefit to performance for a busy resolver, and as long as you maintain a watch on your logs to make sure that slaving the zone does not fail, you're golden. I understand the reasoning behind maintaining these zones in a separate view, accessible only locally, but don't see any value in it. A resolver is going to cache the answers it gets anyway. This technique is particularly useful for folks in bad/expensive network conditions. While the current anycast networks of root servers is much better than it was "in the old days," the more data you have locally the more resilient you are to DDOS against those targets. In regards to production readiness, I've used it in heavy production at numerous sites, as have thousands of FreeBSD users. hope this helps, Doug ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Local Slave copy of root zone
Thank you sir! I'll investigate the newer bind implementations. Regards. Bob On Wed, Aug 15, 2018 at 12:41 PM Tony Finch wrote: > Bob McDonald wrote: > > > I've recently been investigating having a local slave copy of the root > zone > > on a caching/forwarder type server. > > I do this on my toy server for various strange reasons, and although it > has worked OK I'm not confident it's really solid enough for production. > > If you are running BIND 9.12 then its RFC 8198 implementation removes a > lot of the benefits of having a local root (and it also works for the arpa > zones). > > BIND 9.14 will have an improved local root implementation (called a > "mirror" zone) which validates the zone so you don't blindly serve bogus > data. The feature is available now in the 9.13 dev branch; I have not > tried mirroring the arpa zones - the docs suggest that isn't a supported > config for mirror zones. > > Tony. > -- > f.anthony.n.finchhttp://dotat.at/ > democracy, participation, and the co-operative principle > ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Local Slave copy of root zone
Bob McDonald wrote: > I've recently been investigating having a local slave copy of the root zone > on a caching/forwarder type server. I do this on my toy server for various strange reasons, and although it has worked OK I'm not confident it's really solid enough for production. If you are running BIND 9.12 then its RFC 8198 implementation removes a lot of the benefits of having a local root (and it also works for the arpa zones). BIND 9.14 will have an improved local root implementation (called a "mirror" zone) which validates the zone so you don't blindly serve bogus data. The feature is available now in the 9.13 dev branch; I have not tried mirroring the arpa zones - the docs suggest that isn't a supported config for mirror zones. Tony. -- f.anthony.n.finchhttp://dotat.at/ democracy, participation, and the co-operative principle ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
