Local Slave copy of root zone

[Bob McDonald]

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...)

Anyone care to weigh in?

Regards,

Bob

[Tony Finch]

Post by Bob McDonald
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.

[Bob McDonald]

Thank you sir! I'll investigate the newer bind implementations.

Regards.

Bob

Post by Tony Finch

Post by Bob McDonald
I've recently been investigating having a local slave copy of the root

zone

Post by Bob McDonald
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.
--
democracy, participation, and the co-operative principle

[Michał Kępień]

Post by Tony Finch
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.

[Doug Barton]

Post by Bob McDonald
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&view=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-***@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

[Tony Finch]

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.finch <***@dotat.at> http://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-***@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

[Doug Barton]

Post by Tony Finch

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.

* 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.

Post by Tony Finch
* 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.

Post by Tony Finch
* 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. :)

Post by Tony Finch
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-***@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

[Tony Finch]

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.finch <***@dotat.at> http://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-***@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

[Grant Taylor via bind-users]

Post by Tony Finch
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.

[Doug Barton]

Post by Tony Finch
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-***@lists.isc.org
https://lists.isc.o

[Grant Taylor via bind-users]

Post by Doug Barton
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.

Post by Doug Barton
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.

Post by Doug Barton
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.

[Doug Barton]

Post by Grant Taylor via bind-users

Post by Doug Barton
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.

Post by Doug Barton
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.

Post by Doug Barton
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-***@lists.isc.org
https://lists.isc.org/mailman/li