Mark,
Thanks for the email.
My first reaction is that it adds a lot of additional records to the zone. If
I understand correctly, one XHASH for every NSEC/NSEC3, plus an RRSIG for each
XHASH. You didn't really say how (or if) XHASH could be used on an unsigned
zone.
My second reaction is th
A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Domain Name System Operations WG of the IETF.
Title : A Common Operational Problem in DNS Servers - Failure
To Respond.
Authors : M. Andrews
I've been watching actively but quietly. Stellar work! Congratulations!
Steve Crocker
On Fri, Jul 20, 2018 at 2:40 PM, Tim Wicinski wrote:
>
> All
>
> Thanks for a pretty productive week and thanks for
> breaking in our new chair slowly.
>
> Rough Minutes have been uploaded:
>
> https://datat
All
Thanks for a pretty productive week and thanks for
breaking in our new chair slowly.
Rough Minutes have been uploaded:
https://datatracker.ietf.org/doc/minutes-102-dnsop/
And I apologize - I took notes of the last topic on Thursday but have
somehow lost them. I will listen to the audio and
perfect!
Mark Andrews wrote:
Rather than having a full zone hash this can be done as a chain
of hashes (XHASH).
The XHASH would include all records at a signed name (where a signed
name is NOT an NSEC3 name) up until the next signed name (where a
signed name is NOT a NSEC3 name) in DNSSEC order
All
The WG Last Call for draft-ietf-dnsop-dns-capture-format and the chairs
feel we have enough consensus to move this forward.
HOWEVER, two things did come up with some reviews that happened in the
last few days:
- The packet format has a version number, but the draft does not document
or expl
That's a great feedback Jonathan! Thanks
Manu
On Fri, Jul 20, 2018 at 6:40 AM Jonathan Reed wrote:
>
> On Tue, 17 Jul 2018, manu tman wrote:
>
> > I'd like to see this standardized too.
> > Side note: I would also be interested to get a return of experience from
> people operating qname minimiz
All
Thanks for all the comments on this draft. The Call for Adoption is ending
today but it seems that there is consensus to adopt this work in DNSOP and
support this work. The chairs thank everyone for the feedback.
Authors should upload a new version with the
draft-ietf-dnsop-multi-provider-
Tim Wicinski has requested publication of draft-ietf-dnsop-kskroll-sentinel-15
as Proposed Standard on behalf of the DNSOP working group.
Please verify the document's state at
https://datatracker.ietf.org/doc/draft-ietf-dnsop-kskroll-sentinel/
___
DNS
The DNSOP WG has placed draft-song-atr-large-resp in state
Candidate for WG Adoption (entered by Tim Wicinski)
The document is available at
https://datatracker.ietf.org/doc/draft-song-atr-large-resp/
Comment:
We don't know if theWG is ready to adopt this, but marking this down so the
chairs do
The DNSOP WG has placed draft-wessels-dns-zone-digest in state
Candidate for WG Adoption (entered by Tim Wicinski)
The document is available at
https://datatracker.ietf.org/doc/draft-wessels-dns-zone-digest/
___
DNSOP mailing list
DNSOP@ietf.org
https
The DNSOP WG has placed draft-kh-dnsop-7706bis in state
Candidate for WG Adoption (entered by Tim Wicinski)
The document is available at
https://datatracker.ietf.org/doc/draft-kh-dnsop-7706bis/
Comment:
Needs some more review before we adopt. but still.
[ Top-post ]
Thank you to Ólafur and Dave for their comments -- I know that the
discussion on the draft has been long and the draft is filled with
minutia, but we'd dearly love more feedback, positive or negative.
W
On Thu, Jul 19, 2018 at 11:42 PM Dave Lawrence wrote:
>
> Warren Kumari writes
Jonathan
That's *exactly* the type of operational issues that I am interesting in
documenting.
(That doesn't mean the other chairs or the working group feel the same way,
in fact they probably won't!
Tim
On Fri, Jul 20, 2018 at 9:40 AM, Jonathan Reed <
jreed=40akamai@dmarc.ietf.org> wrote:
The same zone NSEC3 signed with a.example.com in OPTOUT range
example.com SOA
example.com NS ns.example.com
example.com DNSKEY …
example.com NSEC3PARAM 1 0 0 -
example.com XHASH …
3QNILC4QRC2P5CRN7JGVB5S3BPG0SHUV.example.com 1 1 0 - NSEC3 1 1 0 -
> On 20 Jul 2018, at 10:37 pm, George Michaelson wrote:
>
> The intent (to me at least) is to be able to use exterior fetch, *not*
> DNS, to source this as a file. curl. wget. ncftp. rsync.
Nothing in this proposal stops these transport mechanisms.
> the "thing" is a file object. It almost ce
On Tue, 17 Jul 2018, manu tman wrote:
I'd like to see this standardized too.
Side note: I would also be interested to get a return of experience from people
operating qname minimization at scale,
I suspect you're looking for feedback from recursive operators, but I'd
like to share our exper
The intent (to me at least) is to be able to use exterior fetch, *not*
DNS, to source this as a file. curl. wget. ncftp. rsync.
the "thing" is a file object. It almost certainly is in near-canonical
sort order already. Its a stream of characters, probably in
bind-normal form.
If you can compute t
Rather than having a full zone hash this can be done as a chain
of hashes (XHASH).
The XHASH would include all records at a signed name (where a signed
name is NOT an NSEC3 name) up until the next signed name (where a
signed name is NOT a NSEC3 name) in DNSSEC order similar to ZONEMD.
If there is
19 matches
Mail list logo
