[DNSOP] Can an RRSET remain valid past the expiration timestamp on its signing RRSIG?

Suppose I receive a response containing an RRSET with records with ttl=3600, signed with an RRSIG that has an expiration timestamp 60 seconds from now. After validating the signature, can I cache the RRSET for 3600 seconds, or only for 60 seconds? If the former, and the RRSET is a DNSKEY, can I

Re: [DNSOP] some 2015-era thoughts about RFC 7706 -bis

Small couple of comments in a top-reply... I think the concept of having the root zone integrated into the RDNS is something that Paul correctly indicates as something RDNS practices have moved away from. I happen to agree that doing so is a mistake, with particular reasoning: - When integrated

[DNSOP] some 2015-era thoughts about RFC 7706 -bis

at the one-hour DNSOP meeting in montreal on monday evening, the authors of RFC 7706 described some of the use case questions they were hoping to answer in their -bis document, and one of them hit squarely on a topic i spoke about frequently between 2005 and 2015. i've attached a copy of the

[DNSOP] TIMEOUT resource record RDATA format revisited

DNSOP, It’s exciting to see some implementation experience in bind 9 by Mark Andrews for TIMEOUT records and during this process several issues have come up with the current use of RDATA as the method to match represented records. Thanks Mark for all the work and feedback so far! 1.

[DNSOP] More on NPN RR's

Hi DNSOP,For those interested in finding more about our proposed pattern-based DNSSEC signature/ validation augment, please check out our NPN draft --(https://www.ietf.org/internet-drafts/draft-woodworth-npn-00.txt)Best regards  John___ DNSOP mailing

Re: [DNSOP] Fwd: HTTPSSVC record draft

I was too late to join the virtual queue in the dnsop meeting (fighting with the Meetecho UI), so I'll send a mail to the list: Slide 5 of the presentation (Alias form) basically covers the ANAME case, but still relies on the client to chase the target. The ANAME record is flexible where the

Re: [DNSOP] a CDN perspective on ANAME challenges

On 7/23/19 2:33 PM, Ben Schwartz wrote: > > > On Tue, Jul 23, 2019 at 4:39 AM Matthijs Mekking > wrote: > > Hi Erik, > > On 7/22/19 9:31 PM, Erik Nygren wrote: > > Reading the draft again, I think a challenge with the structure > relative >

Re: [DNSOP] proposal: Covert in-band zone data

On Mon, 22 Jul 2019 at 14:00, Dan Mahoney wrote: > On NOTE: > > Moving to the DNS-vendor standard answers of "just use DDNS" or "put it in > an IPAM" add additional complexity, and additional attack surfaces. DNS > servers have a tenuous relationship with database backends, and I spend > enough

[DNSOP] Review of draft-ietf-dnsop-no-response-issue-13

I promised a new review of this document a long time ago. Apologies for taking so long to get around to it. This is a huge improvement over previous versions. I'd like to thank the authors for such an extensive cleanup. I sill have a few style suggestions (and grammar nits), which I think

Re: [DNSOP] a CDN perspective on ANAME challenges

Hi Erik, On 7/22/19 9:31 PM, Erik Nygren wrote: > Reading the draft again, I think a challenge with the structure relative > to the CDN > use-case is that requirements on how and where sibling record resolution > is done are derived from the target of the ANAME, not from the > authoritative

Re: [DNSOP] I-D Action: draft-ietf-dnsop-aname-04.txt

Hi Petr, On 7/22/19 10:21 PM, Petr Špaček wrote: > Hello, > > this is an attempt to review draft-ietf-dnsop-aname-04 with fresh eyes - Thanks. > I've managed to forget the old versions ;-) Very wise :) Comments below: > On 08. 07. 19 22:05, internet-dra...@ietf.org wrote: >> Filename

Re: [DNSOP] draft-hoffman-dns-terminology-ter-01.txt - some comments

Rob, i should have more clearly stated that I also consider this draft and generally agreements on commonly used terms very helpful. Paul, thanks for writing it. BR, Normen > On 23. Jul 2019, at 02:55, Rob Sayre wrote: > > > > On Mon, Jul 22, 2019 at 5:38 PM Normen Kowalewski