Hi Duane
On Mon, Oct 29, 2018 at 10:26:42PM +, Wessels, Duane wrote:
> Mukund,
>
> Thanks for the comments. I have incorporated most of them. I will follow up
> below on items I did not incorporate.
>
> > On Oct 29, 2018, at 8:55 AM, Mukund Sivaraman wrote:
> >
> > After a reading, despi
On Mon, 29 Oct 2018, Wessels, Duane wrote:
What if we signed root-servers.net and allowed people to AXFR that
zone along with the root zone. Would there be any need to do any
checksumming? It seems a much simpler solution to protecting the unsigned
glue records then a new checksum method.
Firs
On Mon, 29 Oct 2018, Wessels, Duane wrote:
The feedback I have received regarding this point has been mixed. I have
some folks saying "make it work with stable zones now, figure out dynamic
zones later" and others saying "have to support incremental updates now."
This is why the authors prop
i hope we can make rollover happen every 18 to 30 months. often enough
that its contribution of chaos is lost in the noise margin of normal
chaos. often enough that we never forget how to do it.
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.o
as usual, billions arithmetic got me. 0.001 * 2,300,000,000 is 2,300,000
so thats a few dodgers stadiums more than I said...
-G
On Tue, Oct 30, 2018 at 10:41 AM George Michaelson wrote:
>
> There is a tension between assumed privacy ("this is my resolver, what
> I run is my business, how I run i
There is a tension between assumed privacy ("this is my resolver, what
I run is my business, how I run it is my business") of entities
running resolvers, and customers ("this is my DNS query. what I ask is
my business") and providers of infrastructure ("this is my liability:
the consequences of not
I had advocated early and frequent rollovers for precisely the reason: keep
doing it until it’s easy, so we’re in strong agreement.
Yes, this one actually went smoothly but there was some tension. Aside
from any specific improvement, reducing the tension and sense of drama is
mainly what I had in
Hi Steve,
There will always be the potential for tension between the desire to perform
measurement and the need for privacy. In this case it seems to me that a
well-intentioned and competent authority, supported by a well-intentioned and
occasionally-coherent community has a plausible and sensi
I won't be in Bangkok, so I won't be able to participate. In my view,
there were two specific problems that dominated the rollover problem. The
first was the inability to determine the configuration of querying
resolver. The second was the in ability to notify resolver operators if it
was eviden
Mukund,
Thanks for the comments. I have incorporated most of them. I will follow up
below on items I did not incorporate.
> On Oct 29, 2018, at 8:55 AM, Mukund Sivaraman wrote:
>
> After a reading, despite what is said in Section 5, I'd like to see such
> a scheme to be generally useful for l
Hi all,
I have read draft-wessels-dns-zone-digest-04.
General Summary
I find this document to be generally well-written, clear and unambiguous.
I think being able to embed a checksum in a zone, which can be authenticated
using DNSSEC, is generally useful. I think describing the construction an
I have new drafts ready and will submit them on when the submission
block is lifted.
Copies including diffs are at:
https://www.dropbox.com/sh/cwtztpjzauri3i3/AABbexI4p6sC50z-DEVh1tx9a?dl=0
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
--
Dave Crocker
Brandenburg InternetWorking
> On Oct 25, 2018, at 1:44 PM, Paul Wouters wrote:
>
>
>
>> Subject: Re: [DNSOP] I-D Action: draft-wessels-dns-zone-digest-04.txt
>
> Duane,
>
> It seems this document is really aiming at the root zone, even though
> there is some text about making it sort of general.
Hi Paul,
Certainly t
Dave Lawrence writes:
> Count me as another, for that very reason. When I first saw Paul's
> message I thought, "oh that's a shame" but figured it to be fairly
> set. If there's flexibility for making the meeting happen earlier in
> the week, I'd be interested.
Following up to my own message, si
Joe Abley writes:
> I'm sure I'm not the only person planning to fly out from Bangkok on
> Friday morning, given that there are no working group meetings
> scheduled on that day.
Count me as another, for that very reason. When I first saw Paul's
message I thought, "oh that's a shame" but figured
After a reading, despite what is said in Section 5, I'd like to see such
a scheme to be generally useful for larger zones and zones with high
rates of updates. There are some kinds of zones in common use which can
benefit from better performance. So I recommend working on an
incremental scheme now
Am 29.10.18 um 14:49 schrieb Petr Špaček:
> Well, AXFR is not strictly necessary.
>
> E.g. implementation of RFC 7706-like feature in Knot Resolver pulls zone
> file from a HTTPS URL so it can reuse any CDN you like (or not).
Well, good point!
unbound behave similar.
So it would be simply som
On 28. 10. 18 18:20, A. Schulze wrote:
> Am 28.10.18 um 18:14 schrieb Paul Vixie:
>> there is no need to make production AXFR queries for the root zone from
>> "real" root servers any more.
>
> I agree to separate production and AXFR services.
> A formal statement of ICANN *which is not limited t
I hear a use-case for draft-wessels-dns-zone-digest
On 28/10/2018, 18:55, "DNSOP on behalf of Evan Hunt" wrote:
On Sun, Oct 28, 2018 at 11:05:17AM -0600, Grant Taylor wrote:
> Does root zone local mirroring require that the zone comes from the
> lettered root servers themselves? O
19 matches
Mail list logo
