Murray Kucherawy has entered the following ballot position for
draft-ietf-dnsop-extended-error-14: Yes
When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)
Please refer to h
I made some twiddles to my dbound-in-dns library and updated the I-D to
match.
Code: https://github.com/jrlevine/bound
I-D: https://datatracker.ietf.org/doc/draft-levine-dbound-dns/
I added some more records to the DNS zone so now I believe that by careful
abuse of DNS wildcards, in most case
Having read through the draft, and twice through the emails, I think the
draft has the right balance in using the parent and child NS RRsets
properly.
I think the "extra" query for the child NS, sent once per parent TTL, is a
savings over the older method of sending the NS records as "additional
d
(as a chair)
I enjoyed reading the thread on dns-operations, and as a chair,
both Benno and we like where this is going.
(consider this a gentle nudge working group this is relevant to
our interests)
thanks Shumon/Ralph/Paul
tim
On Fri, Apr 10, 2020 at 9:46 AM Shumon Huque wrote:
> Hi fol
Hi folks,
Paul Vixie, Ralph Dolmans, and I have submitted this I-D for
consideration:
https://tools.ietf.org/html/draft-huque-dnsop-ns-revalidation-01
I mentioned it on the dns-operati...@dns-oarc.net mailing
list last week, where the topic came up in another thread,
and there has already bee
On Thu, Apr 9, 2020 at 6:10 PM Benjamin Kaduk wrote:
> >
> > Sure (the short summary is that the adversary can just trivially
> enumerate
> > the zone by querying the provider that employs NSEC). Will add some text.
>
> Oh! I was misreading this sentence -- I thought that the loss of
> protectio
