On 27. 01. 20 16:08, Hugo Salgado wrote:
Dear DNSOPers, as an operator I tend to have this need to couple
an answer for a query to an auth server, with the actual "SOA zone
version" used. So I think it'll be valuable to have an EDNS option
for it.
Here I'm proposing it with this new draft. The '
On 10. 05. 21 10:19, Petr Špaček wrote:
I think the proper solution should be a real multi-query option, which
incidentally provides a superset of RRSERIAL capabilities.
If multi-queries require the records being in sync (if from the same
zone), I really dislike the implications of them being
Hi all,
As a follow-up to the presentation by Wes Hardaker at the IETF 110 DNSOP
meeting, we want to start a call for adoption of
draft-hardaker-dnsop-nsec3-guidance on the mailing list.
With the presentation at the DNSOP meeting on IETF 110, there was a
sufficient general support in the (vi
On Mon, 10 May 2021 at 00:42, Joe Abley wrote:
>
> On May 9, 2021, at 19:27, Paul Hoffman wrote:
>
> > If I'm wrong about this being as good as it can be, there must be an item
> > delimiter that is better than a comma. I am not thinking creatively enough
> > to figure out what might be better
Hi Dick,
On 5/9/21 2:01 PM, Dick Franks wrote:
> Pre-processing of '\\,' into the RFC1035 standard '\,' is
> superficially attractive, but also fraught with danger.
>
> A parser could have some fun with this one:
>
> $ORIGIN example.com
> @ SVCB 1 foo
> key6="\032\001\013\184\000\000
On May 10, 2021, at 05:42, Pieter Lexis wrote:
>> On 5/9/21 2:01 PM, Dick Franks wrote:
>> Pre-processing of '\\,' into the RFC1035 standard '\,' is
>> superficially attractive, but also fraught with danger.
>>
>> A parser could have some fun with this one:
>>
>>$ORIGIN example.com
>>@
On Mon, 10 May 2021 at 00:28, Paul Hoffman wrote:
>
> On May 9, 2021, at 11:26 AM, Paul Wouters wrote:
> > This is all pretty terrible. I agree with Tim that we should not inflict
> > this onto the users. Or perhaps we can already pre-allocate some CVE
> > numbers for the security issues this w
Hi Dick,
On 5/10/21 1:02 PM, Dick Franks wrote:
> My objection is narrowly focussed on the escape mechanism, nothing
> more. Changing the delimiter is neither necessary nor relevant.
>
> I am happy to contribute the necessary words.
If you have the words to fix this issue that would need to cha
I support the adoption of this document as a starting point for NSEC3 guidance.
It will be useful for people who help operators when those operators ask "why
didn't you tell us what were good choices for the values?".
--Paul Hoffman
smime.p7s
Description: S/MIME cryptographic signature
Hi Joe,
On 5/10/21 1:42 AM, Joe Abley wrote:
> On May 9, 2021, at 19:27, Paul Hoffman wrote:
>
>> If I'm wrong about this being as good as it can be, there must be an item
>> delimiter that is better than a comma. I am not thinking creatively enough
>> to figure out what might be better than a
Hi Pieter,
On 10 May 2021, at 11:23, Pieter Lexis wrote:
> You then invite the following issues:
>
> Clients need to match the tuple (ownername + prio + target) and get all
> data from all matched rrsets, whereas now you get all that data in one
> piece of rdata.
Inviting that issue is also a
The IESG has received a request from the Domain Name System Operations WG
(dnsop) to consider the following document: - 'YANG Types for DNS Classes and
Resource Record Types'
as Proposed Standard
The IESG plans to make a decision in the next few weeks, and solicits final
comments on this acti
Hello everyone. Thanks for the comments, I just uploaded an unchanged
version (just to revive it) at:
https://datatracker.ietf.org/doc/draft-salgado-dnsop-RRSERIAL/
I agree RRSERIAL doesn't have much relevance in zones that don't give
serial versioning a meaning to its content. We can add a para
Hi Vladimir,
On 10 May 2021, at 04:32, Vladimír Čunát wrote:
> On 10. 05. 21 10:19, Petr Špaček wrote:
>> I think the proper solution should be a real multi-query option, which
>> incidentally provides a superset of RRSERIAL capabilities.
>
> If multi-queries require the records being in sync
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
I agree with what Hugo said
I would also like to point out that this draft spirit is aiming to be a
debugging tool to be used by humans and not in between servers. If we start
introducing all these new use cases in-between servers (like authoritativ
Hi Ben,
On 10 May 2021, at 12:56, Ben Schwartz wrote:
> I don't support breaking the SvcParams into separate RRs across the RRSet.
> This would be an extremely inefficient encoding in wire format,
I think that assertion may well be worth challenging, and...
> and would conflict with the usua
Benno Overeinder wrote:
>
> https://datatracker.ietf.org/doc/draft-hardaker-dnsop-nsec3-guidance/.
Yes, this is a helpful document that should be adopted by dnsop. I'm happy
to review etc.
Tony.
--
f.anthony.n.finchhttps://dotat.at/
Biscay: Southwest 3 to 5 increasing 5 to 7. Rough, occasio
I support the adoption of the document.
Yours,
Daniel
On Mon, May 10, 2021 at 1:21 PM Tony Finch wrote:
> Benno Overeinder wrote:
> >
> > https://datatracker.ietf.org/doc/draft-hardaker-dnsop-nsec3-guidance/.
>
> Yes, this is a helpful document that should be adopted by dnsop. I'm happy
> to re
I like the document, but the section on validators recommends not to
follow requirements from RFC 5155, so I don't expect that best-practice
track is sufficient. And I do think we need a similar update to 5155,
be it in this document or a separate one.
I'd also expect something on limits acce
On Mon, 2021-05-10 at 10:55 +0200, Benno Overeinder wrote:
> The draft is available here:
> https://datatracker.ietf.org/doc/draft-hardaker-dnsop-nsec3-guidance/.
>
> Please review this draft to see if you think it is suitable for adoption
> by DNSOP, and comments to the list, clearly stating yo
I guess I support the document but would like it to say
“Please do not use NSEC3 but if you have to use NSEC3 use it use these settings”
The document should point how trivial it is to expose most names in NSEC3
signed zone using Graphics cards and dictionaries.
Olafur
> On May 10, 2021, at
On Mon, 2021-05-10 at 16:43 +0200, Pieter Lexis wrote:
> Hi Dick,
>
> On 5/10/21 1:02 PM, Dick Franks wrote:
> > My objection is narrowly focussed on the escape mechanism, nothing
> > more. Changing the delimiter is neither necessary nor relevant.
> >
> > I am happy to contribute the necessary w
On Mon, May 10, 2021 at 12:07 PM Peter van Dijk
wrote:
> On Mon, 2021-05-10 at 10:55 +0200, Benno Overeinder wrote:
> > The draft is available here:
> > https://datatracker.ietf.org/doc/draft-hardaker-dnsop-nsec3-guidance/.
> >
> > Please review this draft to see if you think it is suitable for a
On Mon, 2021-05-10 at 12:37 -0400, Hugo Salgado wrote:
> Hello everyone. Thanks for the comments, I just uploaded an unchanged
> version (just to revive it) at:
> https://datatracker.ietf.org/doc/draft-salgado-dnsop-RRSERIAL/
Thanks Hugo, that is useful.
In section 3.2, 'the resource record of
On Mon, 10 May 2021, Olafur Gudmundsson wrote:
I guess I support the document but would like it to say
“Please do not use NSEC3 but if you have to use NSEC3 use it use these settings”
The document should point how trivial it is to expose most names in NSEC3
signed zone using Graphics cards an
On Mon, 10 May 2021, Joe Abley wrote:
$ORIGIN example.com
@ SVCB 1 foo
key6="\032\001\013\184\000\000\000\000\000\000\000\000,\000"
; a.k.a. ipv6hint=2001:db8::5c5c:2c00
A zone owner/editor would never even think of typing in IP addresses
like that.
Right, but an attacker
Peter van Dijk wrote:
>
> Also in section 3.2, I do not think responding with the option should
> be limited to NOERROR. Specifically, I'd very much also want it to work
> for NXDOMAIN,
Isn't the SOA record usually present in a negative response?
> and I can imagine some cases of it being useful
On Mon, 2021-05-10 at 22:09 +0100, Tony Finch wrote:
> Peter van Dijk wrote:
> > Also in section 3.2, I do not think responding with the option should
> > be limited to NOERROR. Specifically, I'd very much also want it to work
> > for NXDOMAIN,
>
> Isn't the SOA record usually present in a negati
On Mon, 10 May 2021, Ben Schwartz wrote:
It would also require a dramatic rewrite of a specification that is now widely
deployed.
The IETF is not a rubber-stamp factory for corporate proposals though.
The tendency for corporation to bring up something at the IETF that is
"too far gone" for m
> On 11 May 2021, at 02:56, Ben Schwartz
> wrote:
>
> I don't support breaking the SvcParams into separate RRs across the RRSet.
> This would be an extremely inefficient encoding in wire format, and would
> conflict with the usual understanding of resource records as independently
> meani
On May 10, 2021, at 9:56 AM, Ben Schwartz
wrote:
>
> I don't support breaking the SvcParams into separate RRs across the RRSet.
> This would be an extremely inefficient encoding in wire format, and would
> conflict with the usual understanding of resource records as independently
> meaningfu
Hiya,
Without commenting on the rest of the discussion (though
I do agree with those who made the point that optimising
for those writing zone files here is better than for
those parsing zone files)...
On 10/05/2021 17:56, Ben Schwartz wrote:
It would also require a dramatic rewrite of a
speci
> On 11 May 2021, at 08:46, Paul Hoffman wrote:
>
> On May 10, 2021, at 9:56 AM, Ben Schwartz
> wrote:
>>
>> I don't support breaking the SvcParams into separate RRs across the RRSet.
>> This would be an extremely inefficient encoding in wire format, and would
>> conflict with the usual
On May 10, 2021, at 4:14 PM, Mark Andrews wrote:
> Actually, the process problem is that record format keeps changing AFTER the
> code point has been assigned and the record format THEORETICALLY been FIXED.
Mark makes an excellent point, one that people in the DNS world routinely
forget.
--Pa
On Mon, May 10, 2021 at 9:58 AM Ben Schwartz wrote:
> I don't support breaking the SvcParams into separate RRs across the
> RRSet. This would be an extremely inefficient encoding in wire format, and
> would conflict with the usual understanding of resource records as
> independently meaningful a
> On 11 May 2021, at 09:20, Paul Hoffman wrote:
>
> On May 10, 2021, at 4:14 PM, Mark Andrews wrote:
>> Actually, the process problem is that record format keeps changing AFTER the
>> code point has been assigned and the record format THEORETICALLY been FIXED.
>
> Mark makes an excellent poi
On Mon, 10 May 2021, Benno Overeinder wrote:
Now we will start a period of two weeks for the call for adoption of
draft-hardaker-dnsop-nsec3-guidance on the mailing list.
The draft is available here:
https://datatracker.ietf.org/doc/draft-hardaker-dnsop-nsec3-guidance/.
Please review this d
37 matches
Mail list logo
