Re: [DNSOP] What is the purpose of NSEC3 "closest encloser" proofs?

2020-10-08 Thread Nick Johnson
On Fri, Oct 9, 2020 at 1:59 PM Shumon Huque wrote: > On Thu, Oct 8, 2020 at 7:46 PM Nick Johnson 40ethereum@dmarc.ietf.org> wrote: > >> I'm reading RFC 5155, and I'm a bit puzzled by the requirement for >> "closest encloser" proofs to prove nonexi

[DNSOP] What is the purpose of NSEC3 "closest encloser" proofs?

2020-10-08 Thread Nick Johnson
istence? For example, if I want to prove the nonexistence of a.b.c.example, isn't it sufficient to validate an NSEC3 record that covers that name and is one level higher (eg, somehash.b.c.example)? Why do I need to prove the closest-encloser with a secon

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

2019-07-24 Thread Nick Johnson
> current time. > > That last bullet point tells that if the signature's expiration time is > smaller than the TTLs received in the response, the RRset is cached for > at most the duration until the signature expires. > > On 7/24/19 7:50 AM, Nick Johnson wrote: > &

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

2019-07-23 Thread Nick Johnson
rely on it to validate other RRSIGs for the entire 3600 seconds? -Nick Johnson ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Verifying TLD operator authorisation

2019-06-19 Thread Nick Johnson
On Tue, Jun 18, 2019 at 10:15 PM Bjarni RĂșnar Einarsson wrote: > The SOA record for a TLD contains two DNS names which should be > under the control of the NIC: that of the primary master > nameserver, and the e-mail of the responsible administrator > (which includes a domain name). > This seems

Re: [DNSOP] Verifying TLD operator authorisation

2019-06-15 Thread Nick Johnson
On Fri, Jun 14, 2019 at 7:12 PM Shane Kerr wrote: > Nick, > > On 14/06/2019 04.18, Nick Johnson wrote: > > I'm working on a system that needs to authenticate a TLD owner/operator > > in order to take specific actions. We had intended to handle this by > > requir

Re: [DNSOP] Verifying TLD operator authorisation

2019-06-13 Thread Nick Johnson
On Fri, Jun 14, 2019 at 3:02 PM Rubens Kuhl wrote: > > > On 13 Jun 2019, at 23:56, Nick Johnson wrote: > > On Fri, Jun 14, 2019 at 2:51 PM Rubens Kuhl wrote: > >> >> >> On 13 Jun 2019, at 23:18, Nick Johnson < >> nick=40ethereum@dmarc.ietf.o

Re: [DNSOP] Verifying TLD operator authorisation

2019-06-13 Thread Nick Johnson
On Fri, Jun 14, 2019 at 2:51 PM Rubens Kuhl wrote: > > > On 13 Jun 2019, at 23:18, Nick Johnson > wrote: > > I'm working on a system that needs to authenticate a TLD owner/operator in > order to take specific actions. We had intended to handle this by requiring >

Re: [DNSOP] Verifying TLD operator authorisation

2019-06-13 Thread Nick Johnson
On Fri, Jun 14, 2019 at 2:30 PM Joe Abley wrote: > On Jun 13, 2019, at 22:18, Nick Johnson > wrote: > > > I'm working on a system that needs to authenticate a TLD owner/operator > in order to take specific actions. > > Can you give an example of the actions? &g

[DNSOP] Verifying TLD operator authorisation

2019-06-13 Thread Nick Johnson
rary messages using their keys. Are there domains that are globally reserved for the operator across all TLDs? If not, does anyone have any recommendations on an alternative authorisation or authentication mechanism? -Nick Johnson ___ DNSOP mailing list DNSOP

Re: [DNSOP] Enough to break a camel's back?

2018-04-25 Thread Nick Johnson
Just discovered it lacks RFCs 4035 and 5702 as well. So it's definitely on the conservative side. On Wed, Apr 25, 2018 at 2:38 PM Paul Wouters wrote: > On Wed, 25 Apr 2018, Nick Johnson wrote: > > > No, I left out RFCs only referenced by "obsoletes" metadata.

Re: [DNSOP] Enough to break a camel's back?

2018-04-25 Thread Nick Johnson
No, I left out RFCs only referenced by "obsoletes" metadata. On Wed, 25 Apr 2018, 13:11 Paul Wouters, wrote: > > > On Apr 25, 2018, at 06:37, Nick Johnson wrote: > > > So I threw together a quick script > <https://gist.github.com/Arachnid/c51b450b0c80eb2