In message <20131128000148.ga20...@mycre.ws>, Robert Edmonds writes:
> David Conrad wrote:
> > Ed,
> >
> > On Nov 27, 2013, at 6:00 AM, Edward Lewis wrote:
> > > My excuse is - operators limit "the effort expended in fighting
> > > entropy." Imagine an average operations environment operating a
David Conrad wrote:
> Ed,
>
> On Nov 27, 2013, at 6:00 AM, Edward Lewis wrote:
> > My excuse is - operators limit "the effort expended in fighting entropy."
> > Imagine an average operations environment operating as most environments go.
> > ...
> > Eventually one day something breaks and then.
In message <20131127221711.9f444ae4...@rock.dv.isc.org>, Mark Andrews writes:
>
> In message <20131127212453.gb5...@x28.adm.denic.de>, Peter Koch writes:
> > On Wed, Nov 27, 2013 at 08:48:05AM -0500, Edward Lewis wrote:
> >
> > > It should be:
> > >
> > > There MUST be an RRSIG for each RRset u
In message <20131127212453.gb5...@x28.adm.denic.de>, Peter Koch writes:
> On Wed, Nov 27, 2013 at 08:48:05AM -0500, Edward Lewis wrote:
>
> > It should be:
> >
> > There MUST be an RRSIG for each RRset using at least one DNSKEY of
> > each algorithm in the zone apex DNSKEY RRset that is also in
On Wed, Nov 27, 2013 at 08:48:05AM -0500, Edward Lewis wrote:
> It should be:
>
> There MUST be an RRSIG for each RRset using at least one DNSKEY of
> each algorithm in the zone apex DNSKEY RRset that is also in the DS RRset.
> The apex DNSKEY RRset
> itself MUST be signed by each algorithm app
Hi Jim,
At 01:35 27-11-2013, Jim Reid wrote:
So what? The root zone file is freely available to anyone who wants
it. AXFR from a root server is not the only mechanism to get a copy.
And as Joe just said, it's not necessarily a Good Thing for
resolving servers to keep a local copy of the root zo
Ed,
On Nov 27, 2013, at 6:00 AM, Edward Lewis wrote:
> My excuse is - operators limit "the effort expended in fighting entropy."
> Imagine an average operations environment operating as most environments go.
> ...
> Eventually one day something breaks and then... ...include here "the
> on
My excuse is - operators limit "the effort expended in fighting entropy."
Imagine an average operations environment operating as most environments go.
One admin comes in a decides they can do a better job. And the admin does,
stellar talent.
Then the said stellar admin decides to move on care
On Nov 27, 2013, at 4:46, Peter Palfrader wrote:
>
> Are there any guesstimates or even hard data what percentage of
> resolvers, if any, will consider zones bogus if the algorithm rollover
> is handled in the more liberal style as a regular double-signature KSK
> rollover?
This is a good questi
On Wed, Nov 27, 2013 at 09:35:26AM +, Jim Reid wrote:
>
> BTW, you quoted Section 2.7 of RFC2870. That BCP is over 13 years old.
And about to be obsoleted, I believe.
Best,
A
--
Andrew Sullivan
a...@anvilwalrusden.com
___
dns-operations mailing
Hi,
On 11/27/2013 10:46 AM, Peter Palfrader wrote:
> Hi,
>
> I'm planning a dnssec algorithm rollover for a couple of my zones.
>
> RFC6781 suggests an approach in section 4.1.4 that involves first
> signing the zone with a ZSK of the new algorithm, and only when all
> previous RRSIGs have expir
Hi,
I'm planning a dnssec algorithm rollover for a couple of my zones.
RFC6781 suggests an approach in section 4.1.4 that involves first
signing the zone with a ZSK of the new algorithm, and only when all
previous RRSIGs have expired to introduce the ZSK and KSK to the
DNSKEY RRset.
I started ex
On 27 Nov 2013, at 08:10, SM wrote:
> Some root servers allow AXFR; some do not allow AXFR.
So what? The root zone file is freely available to anyone who wants it. AXFR
from a root server is not the only mechanism to get a copy. And as Joe just
said, it's not necessarily a Good Thing for resol
Hi Damian,
At 18:17 26-11-2013, Damian Menscher wrote:
Back to solving the problem of traffic at the roots, I've always
been curious why recursive resolvers don't just AXFR the root zone
file and cache the list of TLDs. Yes,
From some RFC:
"Root servers SHOULD NOT answer AXFR, or other zon
14 matches
Mail list logo