Re: [DNSOP] Question on interpretation of DO and CD

[Mark Andrews]

> On 7 Oct 2021, at 15:49, George Michaelson  wrote:
> 
>> First of all, it is apparent that if a resolver maintains a unified cache in 
>> which it has DNSSEC-aware and DNSSEC-oblivious data, things will definitely 
>> break.  The general wisdom appears to be that you need to maintain two 
>> caches, and only answer DO-set queries with DO-set cache (or go fetch); but 
>> if there's ever been explicit protocol requirement of this, I have forgotten 
>> it.
> 
> Sorry, but I think this is just an over-reach. There is no necessary
> reason for a single information model to break. It is about how you do
> it. The problem of course is transitive links in the tree from one
> state (signed) to the other (unsigned) and back again, and associated
> meta data. Arguably, its one information model, one cache,  but the DO
> bit flagging limits what answers you can tell people and you have to
> reply with SERVFAIL for information you hold, even though you know the
> next query might well be for the same info without DO force.
> 
> It may well be logistically simpler to run two caches, but this
> statement seems to me to be over-stating things.

Very much so.

Eric,
  DNSSEC validation does not work *reliably* if the upstream resolvers
are not *validating*.  Anyone that does a rigorous analysis of the protocol
will tell you this.

DNSSEC will work reasonably well if the upstream are just DNSSEC aware (keep the
RRSIGs with the data they cover, pass through negative proofs required for
the answers) if there is not spoofed traffic, a mix of DNSSEC aware and DNSSEC
oblivious server for the zone, etc.  A validating upstream will block this
badness and only pass through good responses. A non-validating upstream will
cache this garbage.

It will fail abysmally if the upstreams are not DNSSEC aware.  Don’t even
attempt it.

I know many on this list don’t like hearing this, that they would like it
if DNSSEC aware was enough so that intermediate resolvers don’t need to
validate.  They are fooling themselves.  This is where the "just send CD=1"
came from.  The fear that the upstream will have a bad trust anchor or bad
time are just that, fears. If a upstream has a bad clock or bad trust anchors
then everything will be failing and it will get fixed.  Just send DO=1,CD=0
and on the few cases where you get SERVFAIL return with DO=1,CD=1.

Now there are some improvements that could be made to make the protocol
even more robust when there are intermediate resolvers.  Passing the
trust anchors (DS record form) the downstream is using to the upstream
to improve the robustness of the process.  One could also pass the clients
concept of time.

Mark

> G
> 
> ___
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742  INTERNET: ma...@isc.org

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Question on interpretation of DO and CD

[George Michaelson]

> First of all, it is apparent that if a resolver maintains a unified cache in 
> which it has DNSSEC-aware and DNSSEC-oblivious data, things will definitely 
> break.  The general wisdom appears to be that you need to maintain two 
> caches, and only answer DO-set queries with DO-set cache (or go fetch); but 
> if there's ever been explicit protocol requirement of this, I have forgotten 
> it.

Sorry, but I think this is just an over-reach. There is no necessary
reason for a single information model to break. It is about how you do
it. The problem of course is transitive links in the tree from one
state (signed) to the other (unsigned) and back again, and associated
meta data. Arguably, its one information model, one cache,  but the DO
bit flagging limits what answers you can tell people and you have to
reply with SERVFAIL for information you hold, even though you know the
next query might well be for the same info without DO force.

It may well be logistically simpler to run two caches, but this
statement seems to me to be over-stating things.

G

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Question on interpretation of DO and CD

[Andrew Sullivan]

Hi,

Disclaimer: I work for the Internet Society but am speaking for myself.

On Wed, Oct 06, 2021 at 04:47:32PM -0700, Eric Rescorla wrote:

Sorry if these are dumb questions.


They are not dumb questions, unfortunately.


Looking at things from the stub resolver's perspective, if the zone is
signed, then the stub resolver must receive the necessary RRsets or
fail the resolution. So, there needs to be an unambiguous way for the
stub to tell the recursive to deliver them. Am I right so far?


You are right.  The problem is that the protocol is exactly ambiguous enough, 
in my reading, that there isn't a way to ensure that happens.

RFC 6840 attempted to clarify a number of things, but there are IMO two gaps in 
it.

First of all, it is apparent that if a resolver maintains a unified cache in 
which it has DNSSEC-aware and DNSSEC-oblivious data, things will definitely 
break.  The general wisdom appears to be that you need to maintain two caches, 
and only answer DO-set queries with DO-set cache (or go fetch); but if there's 
ever been explicit protocol requirement of this, I have forgotten it.  The 
upshot is that it is entirely possible for a cache to have some but not all the 
DNSSEC data to answer a query, and to respond with what it has, and I know I 
have seen this in the wild.

Much worse is the continued confusion around CD, which 6840 tried pretty hard 
to sort out but that seems to remain a dark corner of the protocol.  The 
reality is that the SHOULD about setting CD in 6840 probably has to be a MUST 
or else stuff will almost certainly break.  For some reason I now don't recall, 
some people wanted to be able to select a policy in which they didn't set CD 
even though it was the only way the validating stub would actually get 
everything it needed.  This is laid out in some detail in Appendix B, but the 
result is still not that satisfying to someone who wants predictable behaviour 
our of the validated resolution system.

Hope that's helpful,

A

--
Andrew Sullivan
a...@anvilwalrusden.com

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Question on interpretation of DO and CD

[Mark Andrews]

You should also note that a validating stub resolver (or anything talking
through a validating resolver) should be prepared to send *both* DO and
DO+CD queries. There are different error conditions / threats that are
mitigated by each of these settings and only by trying the other on error
can you ensure that you have mitigated both.

If the validating resolver is being sent spoofed/erroneous traffic DO
will filter that traffic out of the response stream.  DO+CD works around
bad time/trust-anchors in the validating resolver.

Mark

> On 7 Oct 2021, at 10:47, Eric Rescorla  wrote:
> 
> Hi folks,
> 
> We've been trying to take some measurements of the success of endpoint
> DNSSEC validation and run into some confusion about the implications
> of the DO and CD bits. Sorry if these are dumb questions.
> 
> In the section on stub resolvers RFC 4035 says:
> 
>A validating security-aware stub resolver MUST set the DO bit,
>because otherwise it will not receive the DNSSEC RRs it needs to
>perform signature validation. (S 4.9.1)
> 
> and:
>A validating security-aware stub resolver SHOULD set the CD bit,
>because otherwise the security-aware recursive name server will
>answer the query using the name server's local policy, which may
>prevent the stub resolver from receiving data that would be
>acceptable to the stub resolver's local policy. (S 4.9.2)
> 
> 
> And then in S 5, says:
>When a resolver indicates support for DNSSEC (by setting the DO bit),
>a security-aware name server should attempt to provide the necessary
>DNSKEY, RRSIG, NSEC, and DS RRsets in a response (see Section 3).
> 
> 
> Looking at things from the stub resolver's perspective, if the zone is
> signed, then the stub resolver must receive the necessary RRsets or
> fail the resolution. So, there needs to be an unambiguous way for the
> stub to tell the recursive to deliver them. Am I right so far?
> 
> Reading the above text, I infer that this signal is the DO bit. This
> should cause the recursive to deliver the right RRsets (if available)
> (I note that this text just says "name server" from which I'm
> inferring that it applies to both authoritative and recursive).  Is
> this correct? If so, is the fact that this is "should" and not
> "SHOULD" telling me something"?
> 
> Finally, as I understand it, the function of the CD bit is to tell the
> recursive resolver to return records even it if cannot validate them
> itself. However, it does *not* tell the recursive resolver to send the
> RRsets in the first place, as that's the function of CD.
> 
> 
> Summarizing all this, I have the following table of what the stub
> should expect to receive if the recursive is a validating resolver and
> it asks for an A record (just as an example)
> 
> 
> Bits set Records validRecords invalid
> -
> None A + ???Error
> DO   A + DNSSEC Error
> CD   A + ???  A + ???
> DO + CD  A + DNSSECA + DNSSEC
> 
> Where "A + DNSSEC" means "A + plus the DNSSEC records" and "A + ???"
> means "A + maybe some DSNSSEC records depending on what the recursive
> wants".
> 
> Thanks in advance,
> -Ekr
> ___
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742  INTERNET: ma...@isc.org

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Bailiwick discussion for draft-ietf-dnsop-rfc8499bis

[John Levine]

It appears that Paul Wouters   said:
>The suggestion by Tony Finch:
>
>   * Sibling zones: two zones whose delegations are in the same
> parent zone.
>
>   * Sibling glue: addresses of nameservers that are in a sibling zone.

So far we agree (which when it's Paul and me, is really saying something.)

> Sibling glue is usually the glue that the DNS would require for that
> sibling zone, but in some cases the requirement lies elsewhere, ...

This is where we always go off the rails.  There seem to be two mutually
exclusive interpretations of sibling glue:

1 - it's a small and entirely optional twiddle to speed up or skip
recursing into the sibling zone

b - it's an essential part of the response because it's the only way to
resolve a reference loop.

I've already said my piece about which of these makes sense and which is a cruel
joke, but if we're going to talk about sibling glue at all, we need to decide
which one we mean.

R's,
John

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Question on interpretation of DO and CD

[Michael StJohns]

Hi EKR  -

Your table looks correct and hope.

You may want to take a look at section 5.9 of RFC 6840, as well as 
appendix B as there's some implementation guidance with respect to the 
setting of the CD bit.


Mike


On 10/6/2021 7:47 PM, Eric Rescorla wrote:

Hi folks,

We've been trying to take some measurements of the success of endpoint
DNSSEC validation and run into some confusion about the implications
of the DO and CD bits. Sorry if these are dumb questions.

In the section on stub resolvers RFC 4035 says:

   A validating security-aware stub resolver MUST set the DO bit,
   because otherwise it will not receive the DNSSEC RRs it needs to
   perform signature validation. (S 4.9.1)

and:
   A validating security-aware stub resolver SHOULD set the CD bit,
   because otherwise the security-aware recursive name server will
   answer the query using the name server's local policy, which may
   prevent the stub resolver from receiving data that would be
   acceptable to the stub resolver's local policy. (S 4.9.2)


And then in S 5, says:
   When a resolver indicates support for DNSSEC (by setting the DO bit),
   a security-aware name server should attempt to provide the necessary
   DNSKEY, RRSIG, NSEC, and DS RRsets in a response (see Section 3).


Looking at things from the stub resolver's perspective, if the zone is
signed, then the stub resolver must receive the necessary RRsets or
fail the resolution. So, there needs to be an unambiguous way for the
stub to tell the recursive to deliver them. Am I right so far?

Reading the above text, I infer that this signal is the DO bit. This
should cause the recursive to deliver the right RRsets (if available)
(I note that this text just says "name server" from which I'm
inferring that it applies to both authoritative and recursive). Is
this correct? If so, is the fact that this is "should" and not
"SHOULD" telling me something"?

Finally, as I understand it, the function of the CD bit is to tell the
recursive resolver to return records even it if cannot validate them
itself. However, it does *not* tell the recursive resolver to send the
RRsets in the first place, as that's the function of CD.


Summarizing all this, I have the following table of what the stub
should expect to receive if the recursive is a validating resolver and
it asks for an A record (just as an example)


Bits set         Records valid        Records invalid
-
None             A + ???                        Error
DO               A + DNSSEC                     Error
CD               A + ???                      A + ???
DO + CD          A + DNSSEC                A + DNSSEC

Where "A + DNSSEC" means "A + plus the DNSSEC records" and "A + ???"
means "A + maybe some DSNSSEC records depending on what the recursive
wants".

Thanks in advance,
-Ekr

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop



___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

[DNSOP] Question on interpretation of DO and CD

[Eric Rescorla]

Hi folks,

We've been trying to take some measurements of the success of endpoint
DNSSEC validation and run into some confusion about the implications
of the DO and CD bits. Sorry if these are dumb questions.

In the section on stub resolvers RFC 4035 says:

   A validating security-aware stub resolver MUST set the DO bit,
   because otherwise it will not receive the DNSSEC RRs it needs to
   perform signature validation. (S 4.9.1)

and:
   A validating security-aware stub resolver SHOULD set the CD bit,
   because otherwise the security-aware recursive name server will
   answer the query using the name server's local policy, which may
   prevent the stub resolver from receiving data that would be
   acceptable to the stub resolver's local policy. (S 4.9.2)


And then in S 5, says:
   When a resolver indicates support for DNSSEC (by setting the DO bit),
   a security-aware name server should attempt to provide the necessary
   DNSKEY, RRSIG, NSEC, and DS RRsets in a response (see Section 3).


Looking at things from the stub resolver's perspective, if the zone is
signed, then the stub resolver must receive the necessary RRsets or
fail the resolution. So, there needs to be an unambiguous way for the
stub to tell the recursive to deliver them. Am I right so far?

Reading the above text, I infer that this signal is the DO bit. This
should cause the recursive to deliver the right RRsets (if available)
(I note that this text just says "name server" from which I'm
inferring that it applies to both authoritative and recursive).  Is
this correct? If so, is the fact that this is "should" and not
"SHOULD" telling me something"?

Finally, as I understand it, the function of the CD bit is to tell the
recursive resolver to return records even it if cannot validate them
itself. However, it does *not* tell the recursive resolver to send the
RRsets in the first place, as that's the function of CD.


Summarizing all this, I have the following table of what the stub
should expect to receive if the recursive is a validating resolver and
it asks for an A record (just as an example)


Bits set Records validRecords invalid
-
None A + ???Error
DO   A + DNSSEC Error
CD   A + ???  A + ???
DO + CD  A + DNSSECA + DNSSEC

Where "A + DNSSEC" means "A + plus the DNSSEC records" and "A + ???"
means "A + maybe some DSNSSEC records depending on what the recursive
wants".

Thanks in advance,
-Ekr
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Bailiwick discussion for draft-ietf-dnsop-rfc8499bis

[Brian Dickson]

On Wed, Oct 6, 2021 at 12:05 PM Paul Wouters  wrote:

> On Wed, 6 Oct 2021, Paul Hoffman wrote:
>
> > Greetings again. I think that all of the issues from the WG on
> draft-ietf-dnsop-rfc8499bis have been dealt with, except one significant
> one. Almost a year ago, Tony Finch started a thread about 8499's
> definitions of bailiwick and sibling glue. The thread is
> >   <
> https://mailarchive.ietf.org/arch/msg/dnsop/5bKXkqzCyGE1NuUko9M6wXLD5bI/>
> >   <
> https://mailarchive.ietf.org/arch/msg/dnsop/fAopdUTnVS2mDF71eiGsRdu9zco/>
> >   <
> https://mailarchive.ietf.org/arch/msg/dnsop/PqH_WMhsP5zxRfjKD4gtmf6nw54/>
> >
> > The WG should come to agreement on this so that we can close out the
> document. Please read these messages and comment here about changes you do
> or don't want to be made to the current draft.
>
> The suggestion by Tony Finch:
>
>
>* Sibling zones: two zones whose delegations are in the same
>  parent zone.
>
>* Sibling glue: addresses of nameservers that are in a sibling zone.
>
> I agree with the above part. But the next part I do not agree with:
>
>  Sibling glue is usually the glue that the DNS would require for that
>  sibling zone, but in some cases the requirement lies elsewhere, for
>  example
>
> one.example.NS  nsa.two.example
> one.example.NS  nsb.two.example
> two.example.NS  ns0.two.example
> two.example.NS  ns1.two.example
>
> The DNS protocol does not require sibling glue for the one.example
> nameservers, though glue addresses might be required by .example
> registry policy.
>

It is perhaps worth referencing (informally?) the expired draft (version 05
from 2015):
https://datatracker.ietf.org/doc/html/draft-koch-dns-glue-clarifications-05

I think it may be more appropriate to extract the important behavior
expectations needed for interoperability.
My understanding is as follows:

   - Whatever glue there is in the delegating zone is required (by RFCs?)
   to be served.
   - What glue is accepted or provided (or is required) may differ by
   parent policies or operator practices
   - The glue for sibling zones may or may not be needed for resolution.
   - Resolution may not be possible if glue that should have been present
   is not present
   - In-bailiwick for queries received by a server where the QNAME falls
   below a zone cut is any name at or beneath the parent zone, not the child
   zone. If the example TLD gets a query for foo.example, and the NS for
   foo.example falls under bar.example, both foo and bar are in-bailiwick
   names (at least that is my understanding, which was recently enlarged based
   on previous misunderstandings)

Brian


>
> I find the talk about "in the DNS protocol" and pulling in "registry
> policy" confusing and unneeded.
>
> As a seperate problem in the 2nd references email, I agree that the
> term "in-bailiwick" probably changed meaning from "within this
> delegation or below" to "the data related to this delegation". Eg
> when processing additional records, "in-bailiwick" is interpreted
> as "needed for completing DNS resolution for all NS entries in this
> delegation" and could be RRs from other TLDs and their dependencies.
>
> For example, in this updated meaning, the A record for ns0.nohats.ca
> is "in-bailiwick" to libreswan.org and a resolver could add the A
> record for ns0.nohats.ca (and/or DNSKEY etc) to an answer for NS
> of libreswan.org. This new use of "in-bailiwick" seems more common
> too when thinking of resolver to stub and DNSSEC validation, eg
> with chain-query and tls-dnssec-chain. Possible this dual use let
> to the new term "in-domain" ?
>
> As for the third message quoted, I do not agree that "in-bailiwick is
> a property of a nameserver". I believe it is a term related to the
> NS/A records of the QNAME, not of a nameserver.
>
> Paul
>
> ___
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop
>
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Bailiwick discussion for draft-ietf-dnsop-rfc8499bis

[Paul Wouters]

On Wed, 6 Oct 2021, Paul Hoffman wrote:


Greetings again. I think that all of the issues from the WG on 
draft-ietf-dnsop-rfc8499bis have been dealt with, except one significant one. 
Almost a year ago, Tony Finch started a thread about 8499's definitions of 
bailiwick and sibling glue. The thread is
  
  
  

The WG should come to agreement on this so that we can close out the document. 
Please read these messages and comment here about changes you do or don't want 
to be made to the current draft.


The suggestion by Tony Finch:


  * Sibling zones: two zones whose delegations are in the same
parent zone.

  * Sibling glue: addresses of nameservers that are in a sibling zone.

I agree with the above part. But the next part I do not agree with:

Sibling glue is usually the glue that the DNS would require for that
sibling zone, but in some cases the requirement lies elsewhere, for
example

one.example.NS  nsa.two.example
one.example.NS  nsb.two.example
two.example.NS  ns0.two.example
two.example.NS  ns1.two.example

   The DNS protocol does not require sibling glue for the one.example
   nameservers, though glue addresses might be required by .example
   registry policy.

I find the talk about "in the DNS protocol" and pulling in "registry
policy" confusing and unneeded.

As a seperate problem in the 2nd references email, I agree that the
term "in-bailiwick" probably changed meaning from "within this
delegation or below" to "the data related to this delegation". Eg
when processing additional records, "in-bailiwick" is interpreted
as "needed for completing DNS resolution for all NS entries in this
delegation" and could be RRs from other TLDs and their dependencies.

For example, in this updated meaning, the A record for ns0.nohats.ca
is "in-bailiwick" to libreswan.org and a resolver could add the A
record for ns0.nohats.ca (and/or DNSKEY etc) to an answer for NS
of libreswan.org. This new use of "in-bailiwick" seems more common
too when thinking of resolver to stub and DNSSEC validation, eg
with chain-query and tls-dnssec-chain. Possible this dual use let
to the new term "in-domain" ?

As for the third message quoted, I do not agree that "in-bailiwick is
a property of a nameserver". I believe it is a term related to the
NS/A records of the QNAME, not of a nameserver.

Paul

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Bailiwick discussion for draft-ietf-dnsop-rfc8499bis

[Tim Wicinski]

Paul,

Thanks for bringing this up.  I feel this topic is also relevant to
the draft-ietf-dnsop-glue-is-not-optional draft currently being worked on.
While I am sure folks are aware of this,
this is more of a note that having the definitions clarified will help us
move this other draft forward.

thanks
tim

(and Tony - always thanks!)

On Wed, Oct 6, 2021 at 2:23 PM Paul Hoffman  wrote:

> Greetings again. I think that all of the issues from the WG on
> draft-ietf-dnsop-rfc8499bis have been dealt with, except one significant
> one. Almost a year ago, Tony Finch started a thread about 8499's
> definitions of bailiwick and sibling glue. The thread is
><
> https://mailarchive.ietf.org/arch/msg/dnsop/5bKXkqzCyGE1NuUko9M6wXLD5bI/>
><
> https://mailarchive.ietf.org/arch/msg/dnsop/fAopdUTnVS2mDF71eiGsRdu9zco/>
><
> https://mailarchive.ietf.org/arch/msg/dnsop/PqH_WMhsP5zxRfjKD4gtmf6nw54/>
>
> The WG should come to agreement on this so that we can close out the
> document. Please read these messages and comment here about changes you do
> or don't want to be made to the current draft.
>
> --Paul Hoffman___
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop
>
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

[DNSOP] Bailiwick discussion for draft-ietf-dnsop-rfc8499bis

[Paul Hoffman]

Greetings again. I think that all of the issues from the WG on 
draft-ietf-dnsop-rfc8499bis have been dealt with, except one significant one. 
Almost a year ago, Tony Finch started a thread about 8499's definitions of 
bailiwick and sibling glue. The thread is
   
   
   

The WG should come to agreement on this so that we can close out the document. 
Please read these messages and comment here about changes you do or don't want 
to be made to the current draft.

--Paul Hoffman

smime.p7s
Description: S/MIME cryptographic signature
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] [Ext] Benjamin Kaduk's No Objection on draft-ietf-dnsop-dnssec-iana-cons-04: (with COMMENT)

[Paul Hoffman]

On Oct 5, 2021, at 12:16 PM, Benjamin Kaduk via Datatracker  
wrote:
> --
> COMMENT:
> --
> 
> Thanks to Dan Harkins for the secdir review, and the authors for the
> corresponding updates.
> 
> Section 1
> 
>   DNSSEC is primarily described in [RFC4033], [RFC4034], and [RFC4035].
>   DNSSEC commonly uses two resource records beyond those defined in RFC
>   4034: DS [RFC3658] (which was obsoleted by RFC 4034) and NSEC3
>   [RFC5155].
> 
> I'm a bit confused at how DS is "beyond those defined in RFC 4034" when
> RFC 4034 includes discussion of DS, the record format, etc.

Thank you; no one else noticed this. I've replaced it with:
DNSSEC is primarily described in {{RFC4033}}, {{RFC4034}}, and {{RFC4035}}.
DNSSEC commonly uses another resource record beyond those defined in RFC 4034:
NSEC3 {{RFC5155}}.
DS resrouce records were originally defined in {{RFC3658}}, and that definition
was obsoleted by RFC 4034.


> Section 4
> 
>   In the "Domain Name System Security (DNSSEC) NextSECure3 (NSEC3)
>   Parameters" registry, the registration procedure for "DNSSEC NSEC3
>   Flags", "DNSSEC NSEC3 Hash Algorithms", and "DNSSEC NSEC3PARAM Flags"
>   are changed from "Standards Action" to "RFC Required".
> 
> I note (this is a "comment", after all, right?) that the "flags"
> registries have only 7 values available.  It is not entirely clear to me
> that the IESG would be justified in using an RFC 5742 conflict-review
> response to try to block any frivolous registration attempts made in
> non-IETF-stream RFCs, but maybe we are willing to place confidence in
> the other streams' managers behaving responsibly and otherwise accept
> this risk.

I think so, yes.

> 
> NITS
> 
> Section 2 only talks about "DS or NSEC3 hash algorithms" but the actual
> registry actions also cover the NSEC3{,PARAMS} flags registries.

Good catch. I'll update that sentence to talk about all the registries.

--Paul Hoffman



smime.p7s
Description: S/MIME cryptographic signature
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop