So I have adjusted the configuration on my workstation's name server to
include the global root servers (for robustness) as well as a local
stealth slave (for low latency). Here's a count of queries directed at the
root zone and the servers chosen to handle them. I wonder how different it
would be
Paul Vixie p...@redbarn.org wrote:
I thought the idea of validating the zone transfer before putting the zone
live was interesting.
this is something deliberately left out of the dnssec design, because it
doesn't obviate validation by query initiators of the underlying data.
Right, but
Tony Finch mailto:d...@dotat.at
Wednesday, November 12, 2014 7:13 AM
Paul Vixie p...@redbarn.org wrote:
With normal DNSSEC validation, resolvers have a way to recover from data
corruption. With this local root zone proposal they do not.
i seem to have missed a step. why?
If a validating
Paul Vixie p...@redbarn.org wrote:
that's either an argument for listing multiple servers, the first being
on the loopback, the other(s) being real global root name servers;
That would probably work.
or, instead of telling bind9 forward only, tell it forward first.
That would not work: you
Paul Vixie p...@redbarn.org wrote:
um. type forward is a possible zone type in bind9. we do it when we
deliver DNS RBL policy zones. i was not talking about the kind of
forwarding used for recursive service.
Yes, I know that. type forward does not work if the server you are
forwarding to is
Greetings again. Based on some great input from Evan Hunt, we have updated our
draft. The algorithm is both simpler and easier to configure. In fact, we have
examples of how to configure BIND and Unbound/NSD to match the new spec.
We'll be talking about the new draft in today's meeting.
--Paul
This sounded good until Note that using this configuration will cause the
recursive resolver to fail if the local root zone server fails. Could I
use forward first instead of static-stub so that it would fall back to
the normal root servers if the local root server could not get zone
transfers or
On Tue, Nov 11, 2014 at 2:15 PM, Evan Hunt e...@isc.org wrote:
This sounded good until Note that using this configuration will cause
the
recursive resolver to fail if the local root zone server fails. Could I
use forward first instead of static-stub so that it would fall back
to
the
Paul Hoffman paul.hoff...@vpnc.org wrote:
Greetings again. Based on some great input from Evan Hunt, we have
updated our draft. The algorithm is both simpler and easier to
configure. In fact, we have examples of how to configure BIND and
Unbound/NSD to match the new spec.
I have been running
On Tue, Nov 11, 2014 at 02:43:02PM -0500, Bob Harold wrote:
Thanks, but what about the case where the zone transfers are refused and
the root zone expires? My server is still running, but cannot answer for
the root zone. That's a case where I want it to fail over to the real
roots.
If the
Tony Finch mailto:d...@dotat.at
Tuesday, November 11, 2014 1:07 PM
...
I thought the idea of validating the zone transfer before putting the zone
live was interesting.
this is something deliberately left out of the dnssec design, because it
doesn't obviate validation by query initiators
11 matches
Mail list logo
