Greetings again. My motivation here is kinda trivial, but I've heard it is a
common complaint. When writing a about DNSSEC, I need to reference the RFC. But
it's three RFCs (4033, 4034, and 4035), and possibly another (6840). It would
be awfully nice to refer to "DNSSEC" with a single reference
Sounds good to me.
Even better if we would clarify DNSSEC is not an optional part of DNS, but I
don’t think you are volunteering for that discussion 😀
Sent using a virtual keyboard on a phone
> On Mar 10, 2022, at 13:54, Paul Hoffman wrote:
>
> Greetings again. My motivation here is kinda tr
I like this idea also. Warren may have some ideas but could also be
something to do in one of the area WGs.
Grinding paperwork is a necessary evil.
tim
On Thu, Mar 10, 2022 at 2:05 PM Paul Wouters wrote:
> Sounds good to me.
>
> Even better if we would clarify DNSSEC is not an optional part
On 10/03/2022 19:04, Paul Wouters wrote:
Sounds good to me.
Something analogous to bcp195 could be a good plan, esp
as signature algorithms, rsa key sizes and maybe ksk/zsk
handling change over time.
Not sure if it'd be better part of such a document but also
be no harm to try document good/
Sounds like a good plan to me.
-Bill
> On Mar 10, 2022, at 7:55 PM, Paul Hoffman wrote:
>
> Greetings again. My motivation here is kinda trivial, but I've heard it is a
> common complaint. When writing a about DNSSEC, I need to reference the RFC.
> But it's three RFCs (
Hi,
+10 to aggregating current documentation into one place.
On 3/10/22 12:04 PM, Paul Wouters wrote:
Even better if we would clarify DNSSEC is not an optional part of DNS,
but I don’t think you are volunteering for that discussion 😀
Eh ... I'm more interested in aggregating current documenta
On Thu, Mar 10, 2022 at 2:59 PM Grant Taylor
wrote:
> Aside: Maybe it's just me, but I feel like there is more perceived
> value in clarifying existing documentation, in the hopes that others
> will be more likely to adopt current best practices, than there is in
> updating things. Dare I say it
Good idea, and I volunteer to assist if you'd like. Some stuff that may be good
to consider including:
- Negative Trust Anchors - https://datatracker.ietf.org/doc/rfc7646/
- In case of DNSSEC validation failures, don't switch resolvers -
https://datatracker.ietf.org/doc/draft-livingood-dnsop-dont
On 3/10/22 1:16 PM, Colm MacCárthaigh wrote:
I think a single BCP doc is a good idea, but here I'd actually go
much further and argue for a significant section in the BCP that
acknowledges that it is also a best current practice not to enable
DNSSEC. That is objectively the most common practice
Paul-san,
> In the big picture, I think it would be good for the DNS to be able
> to refer to DNSSEC more easily. Thoughts?
I think it can be said for RFC 1034 and 1035, too.
But it's much more difficult than DNSSEC.
My friend Takashi Takizawa maintains this horrible figure.
DNS RFCs - ttkzw'
10 matches
Mail list logo
