Re: [DNSOP] Acceptance processing in draft-ietf-regext-dnsoperator-to-rrr-protocol-04 section 3.4

2018-05-16 Thread Matthew Pounsett
On 16 May 2018 at 14:51, Viktor Dukhovni  wrote:

>
>
>
> I can make a list...  Should it go in this draft, or should I work with
> Patrick Wallstrom to flesh out that draft?  Will this draft reference
> the other one?
>
> General DNSSEC hygeine is out of scope for this draft, so better that you
work with Patrick.  The draft already references
draft-wallstrom-dnsop-dns-delegation-requirements in the bootstrapping
section.
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop


Re: [DNSOP] Acceptance processing in draft-ietf-regext-dnsoperator-to-rrr-protocol-04 section 3.4

2018-05-16 Thread Viktor Dukhovni


> On May 16, 2018, at 2:38 PM, Jacques Latour  wrote:
> 
> The intent of the document at bootstrap is for the parent to perform 
> sufficient tests to ensure they are conformable in bootstrapping the chain of 
> trust, I agree with you that these tests and other could be performed by the 
> parent to ensure the child/DNS Operator is "well behaved" and/or has "good 
> DNSSEC hygiene".
> 
> I think defining the criteria for good DNSSEC hygiene is not in scope for 
> this document, but this document could certainly reference something like 
> https://tools.ietf.org/html/draft-wallstrom-dnsop-dns-delegation-requirements-03
>   with your details in section 8 "DNSSEC Requirements".
> 
> Also, I'm thinking at registration time to check immediately if the newly 
> domain is suitable for DNSSEC bootstrapping, meaning the domain has a proper 
> CDS or CDNSKEY and has good hygiene and all, so that when we publish the zone 
> file with that new domain the DS record is included right away.  Any issues 
> with that?

I am not a stickler for the means, so long as we achieve the same ends.
That is, provided the DNSSEC hygiene is somehow taken into account at
registration time, if this document points at some other document, that
may be OK.  My concern is only that not enough of the DANE-impacting
hygiene requirements may yet be written down.

I can make a list...  Should it go in this draft, or should I work with
Patrick Wallstrom to flesh out that draft?  Will this draft reference
the other one?

-- 
Viktor.

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


Re: [DNSOP] Acceptance processing in draft-ietf-regext-dnsoperator-to-rrr-protocol-04 section 3.4

2018-05-16 Thread Jacques Latour
The intent of the document at bootstrap is for the parent to perform sufficient 
tests to ensure they are conformable in bootstrapping the chain of trust, I 
agree with you that these tests and other could be performed by the parent to 
ensure the child/DNS Operator is "well behaved" and/or has "good DNSSEC 
hygiene".

I think defining the criteria for good DNSSEC hygiene is not in scope for this 
document, but this document could certainly reference something like 
https://tools.ietf.org/html/draft-wallstrom-dnsop-dns-delegation-requirements-03
  with your details in section 8 "DNSSEC Requirements".

Also, I'm thinking at registration time to check immediately if the newly 
domain is suitable for DNSSEC bootstrapping, meaning the domain has a proper 
CDS or CDNSKEY and has good hygiene and all, so that when we publish the zone 
file with that new domain the DS record is included right away.  Any issues 
with that?


 

-Original Message-
From: DNSOP <dnsop-boun...@ietf.org> On Behalf Of Viktor Dukhovni
Sent: May 15, 2018 4:11 PM
To: dnsop <dnsop@ietf.org>
Subject: Re: [DNSOP] Acceptance processing in 
draft-ietf-regext-dnsoperator-to-rrr-protocol-04 section 3.4



> On May 15, 2018, at 3:57 PM, John Levine <jo...@taugh.com> wrote:
> 
> I think it's a swell idea to offer people DNSSEC testing services but
> it's hopeless to conflate it with key rotation.

I completely agree with you on key rotation, once the zone has already
been operating signed.  But the document also covers enrollment:

   This document describes a simple protocol that allows a third party
   DNS operator to: establish the initial chain of trust (bootstrap
---
   DNSSEC) for a delegation; update DS records for a delegation; and,
   
   remove DS records from a secure delegation.  The DNS operator may do
   these things in a trusted manner, without involving the Registrant
   for each operation.  This same protocol can be used by Registrants to
   maintain their own domains if they wish.

It is at the time of initial enrollment that I'd like to propose greater
due diligence.

-- 
Viktor.

___
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] Acceptance processing in draft-ietf-regext-dnsoperator-to-rrr-protocol-04 section 3.4

2018-05-15 Thread Viktor Dukhovni


> On May 15, 2018, at 3:57 PM, John Levine  wrote:
> 
> I think it's a swell idea to offer people DNSSEC testing services but
> it's hopeless to conflate it with key rotation.

I completely agree with you on key rotation, once the zone has already
been operating signed.  But the document also covers enrollment:

   This document describes a simple protocol that allows a third party
   DNS operator to: establish the initial chain of trust (bootstrap
---
   DNSSEC) for a delegation; update DS records for a delegation; and,
   
   remove DS records from a secure delegation.  The DNS operator may do
   these things in a trusted manner, without involving the Registrant
   for each operation.  This same protocol can be used by Registrants to
   maintain their own domains if they wish.

It is at the time of initial enrollment that I'd like to propose greater
due diligence.

-- 
Viktor.

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


Re: [DNSOP] Acceptance processing in draft-ietf-regext-dnsoperator-to-rrr-protocol-04 section 3.4

2018-05-15 Thread John Levine
In article <8e5d5d6c-6893-473d-a2fe-dcb0b46e7...@dukhovni.org> you write:
>Some of the more subtle, but still very important failure modes
>are not obvious unless *tested*.  It is would be a disservice to
>the ecosystem to blindly turn on only partly working DNSSEC which
>is actually broken in important ways.

I think it's a swell idea to offer people DNSSEC testing services but
it's hopeless to conflate it with key rotation.

R's,
John

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


Re: [DNSOP] Acceptance processing in draft-ietf-regext-dnsoperator-to-rrr-protocol-04 section 3.4

2018-05-15 Thread Viktor Dukhovni


> On May 15, 2018, at 2:29 PM, John Levine  wrote:
> 
> I think you will find that attempts to legislate against being stupid
> do not generally turn out well.  It makes sense to check for mistakes
> that might screw up the upper level name server like an invalid
> algorithm number, but if they want to shoot themselves in the foot,
> there's not much we can do about that.
> 
> There's no way to make a list of every possible stupid thing that
> someone might do, so I wouldn't try.

Some of the more subtle, but still very important failure modes
are not obvious unless *tested*.  It is would be a disservice to
the ecosystem to blindly turn on only partly working DNSSEC which
is actually broken in important ways.

Section 3.4 says:

   The Registration Entity, upon receiving a signal or detecting through
   polling that the child desires to have its delegation updated, SHOULD
   run a series of tests to ensure that updating the parent zone will
   not create or exacerbate any problems with the child zone.  The basic
   tests SHOULD include: [...]

And while we can't enumerate all possible breakage, there are clear
mistakes that are comparatively common now, and which would become
much more prevalent if enrollment is made easier with no due care to
ensure that we're not adding to the problems.

   * Incomplete NSEC chains that break denial of existence of
 the TLSA records of any explicit (or implicit zone apex)
 MX hosts.

   * SOA signatures that are invalid (typically modified after signing)

   * RRtype-based query filtering that drops TLSA/CAA/... queries.

   * ... and a few more ...

The above are not made-up hypotheticals, they are actually observed in
sufficient numbers to establish a pattern of likely failure modes that
need to be tested.  I have around ~200 samples that provide strong evidence
of the most common failure modes.

We can perhaps quibble over which failures might be ignored, but it
would be irresponsible and counter-productive to ignore them all.

-- 
-- 
Viktor.

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


Re: [DNSOP] Acceptance processing in draft-ietf-regext-dnsoperator-to-rrr-protocol-04 section 3.4

2018-05-15 Thread John Levine
In article <1d06889c-770f-4f92-bf06-a76338aeb...@dukhovni.org> you write:
>For example, nazwa.pl has recently signed a bunch of domains with lame
>wildcard NS records under the zone apex.  This breaks denial of existence
>for all child domains, including TLSA lookups, and therefore breaks email
>delivery to the newly signed domains.

I think you will find that attempts to legislate against being stupid
do not generally turn out well.  It makes sense to check for mistakes
that might screw up the upper level name server like an invalid
algorithm number, but if they want to shoot themselves in the foot,
there's not much we can do about that.

There's no way to make a list of every possible stupid thing that
someone might do, so I wouldn't try.

R's,
John

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


Re: [DNSOP] Acceptance processing in draft-ietf-regext-dnsoperator-to-rrr-protocol-04 section 3.4

2018-05-15 Thread Viktor Dukhovni


> On Apr 28, 2018, at 1:28 AM, Viktor Dukhovni  wrote:
> 
> So at this point I think we understand each other, and the issue comes down 
> to whether it is appropriate for the registry to automatically turn on DS 
> records for the first time for a domain which is substantively operationally 
> deficient at the time its CDS records are encountered.
> 
> I think that garbage-in/garbage-out is not only a disservice to the domain's 
> owner, but more importantly it poisons the ecosystem for everyone else.
> 
> If turning on DNSSEC validation in your resolver stops email delivery to a 
> bunch of domains, or breaks all access to the domain's data, whom exactly is 
> the registry helping by enabling DNSSEC for a substantially broken domain.
> 
> Think of this as anti-pollution environmental regulation.

I see a new version -05, with (so far) the Section 3.4 acceptance text
unchanged. I strongly feel broken DNSSEC adoption is much worse than no
DNSSEC adoption, it not only has operational impact on the target domain,
but also creates strong disincentives to enabling validation in resolvers.

Therefore, if at all possible, broken implementations should not have their
DS records published, and all reasonable effort should be made to detect
known forms of breakage before inflicting such breakage on the world at
large.

For example, nazwa.pl has recently signed a bunch of domains with lame
wildcard NS records under the zone apex.  This breaks denial of existence
for all child domains, including TLSA lookups, and therefore breaks email
delivery to the newly signed domains.  This is easily detected, and such
detection should be part of acceptance criteria for having DS records
published.  Yes, some domains will introduce breakage after the fact,
but we can and should avoid it at inception.

$ grep nazwa broken | ... | xargs -n1 unbound-host -D -t tlsa
validation failure <_25._tcp.andyandmag.pl. TLSA IN>: nodata proof failed from 
85.128.129.10
validation failure <_25._tcp.fruty.pl. TLSA IN>: nodata proof failed from 
85.128.128.10
validation failure <_25._tcp.funit.com.pl. TLSA IN>: nodata proof failed from 
195.238.185.146
validation failure <_25._tcp.informica.org. TLSA IN>: nodata proof failed from 
195.238.185.146
validation failure <_25._tcp.vitacard.pl. TLSA IN>: nodata proof failed from 
85.128.129.10
validation failure <_25._tcp.sjedrzejewski.pl. TLSA IN>: nodata proof failed 
from 85.128.129.10
validation failure <_25._tcp.centrumuslugszklarskich.com. TLSA IN>: nodata 
proof failed from 85.128.129.10
validation failure <_25._tcp.ts3priv.pl. TLSA IN>: nodata proof failed from 
195.238.185.146

-- 
Viktor.

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


Re: [DNSOP] Acceptance processing in draft-ietf-regext-dnsoperator-to-rrr-protocol-04 section 3.4

2018-04-27 Thread Viktor Dukhovni


> On Apr 27, 2018, at 3:23 PM, Matthew Pounsett  wrote:
> 
>> If the registry operator is going to automatically upgrade previously 
>> insecure delegations to DNSSEC, then due diligence to make sure that this is 
>> not going to cause outages is advisable.  Once a domain is signed, TLSA and 
>> CAA lookups must succeed, or the domain may no longer receive email from 
>> DANE-enabled sending MTAs, or be able to obtain certificates from their CA, 
>> ...
>> 
>> So I rather strongly feel that appropriate quality checks should be in 
>> place, to protect both the registrant and the registry (dealing with fallout 
>> from outages is best avoided).
> 
> Except that those are standard DNSSEC operations best practices, not even 
> limited to CDS use, let alone a REST protocol designed for signalling that 
> CDS should be scanned.  Perhaps others can speak up about the applicability 
> here, but I feel rather strongly that general operations best practices 
> shouldn't be defined in a document limited to one corner case.  That risks 
> the advice case either not being applied elsewhere, because it's not in a 
> general operations document and therefore not seen, or worse contradicting 
> what goes into a general operations document.
> 
> The security checks in this draft are there to help ensure that the parent 
> can trust the update request.  I believe going further than that is out of 
> scope.

So at this point I think we understand each other, and the issue comes down to 
whether it is appropriate for the registry to automatically turn on DS records 
for the first time for a domain which is substantively operationally deficient 
at the time its CDS records are encountered.

I think that garbage-in/garbage-out is not only a disservice to the domain's 
owner, but more importantly it poisons the ecosystem for everyone else.

If turning on DNSSEC validation in your resolver stops email delivery to a 
bunch of domains, or breaks all access to the domain's data, whom exactly is 
the registry helping by enabling DNSSEC for a substantially broken domain.

Think of this as anti-pollution environmental regulation.

-- 
Viktor.

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


Re: [DNSOP] Acceptance processing in draft-ietf-regext-dnsoperator-to-rrr-protocol-04 section 3.4

2018-04-27 Thread Matthew Pounsett
On 14 April 2018 at 17:05, Viktor Dukhovni  wrote:

>
>
> > On Apr 14, 2018, at 4:26 PM, Matthew Pounsett 
> wrote:
> >
> > These are getting into name server quality checks, and not security
> checks, which is the point of the acceptance testing.  I don't agree that
> these should be part of this document.
>
> If the registry operator is going to automatically upgrade previously
> insecure delegations to DNSSEC, then due diligence to make sure that this
> is not going to cause outages is advisable.  Once a domain is signed, TLSA
> and CAA lookups must succeed, or the domain may no longer receive email
> from DANE-enabled sending MTAs, or be able to obtain certificates from
> their CA, ...
>
> So I rather strongly feel that appropriate quality checks should be in
> place, to protect both the registrant and the registry (dealing with
> fallout from outages is best avoided).
>

Except that those are standard DNSSEC operations best practices, not even
limited to CDS use, let alone a REST protocol designed for signalling that
CDS should be scanned.  Perhaps others can speak up about the applicability
here, but I feel rather strongly that general operations best practices
shouldn't be defined in a document limited to one corner case.  That risks
the advice case either not being applied elsewhere, because it's not in a
general operations document and therefore not seen, or worse contradicting
what goes into a general operations document.

The security checks in this draft are there to help ensure that the parent
can trust the update request.  I believe going further than that is out of
scope.

I think if you want there to be guidance that parents should check on the
quality of the child operations that should
1) come from DNSOP, not REGEX, and
2) be in a document about general DNSSEC operations.

We currently ref out to draft-wallstrom-dnsop-dns-delegation-requirements
in that section (we're hoping that draft continues to go somewhere so we
don't have to import too much of its text directly, although it has been
expired for a year now).  You might want to submit some text there.. or
angle for something that updates (or is a -ter for) RFC6781.


> >
> > While this is probably a reasonable thing to do, a registration
> mechanism documented in REGEXT is not the place to do this.  I think if
> DNSOP wants such advice in a standard there should be a BCP document out of
> DNSOP that defines it.
>
> Yes, this is a point for discussion.  Still I think it would be bad to,
> for example, introduce more domains with 512-bit RSA keys, or perhaps even
> accept 1024-bit RSA
> keys.  There are many domains with 1536-bit KSKs and 1280-bit ZSKs, these
> are I
> think well chosen, though ECDSA P-256 (algorithm 13) is looking
> increasingly like
> an even better choice at present.
>
> Given that 1024-bit RSA is considered past its use-by these days, perhaps
> limiting
> automated upgrades to DNSSEC only to stronger keys is a good idea???
>

But again, that's a general operations issue, and not one limited to this
signalling mechanism.


>
> >>   o Check that if the zone uses NSEC3 the NSEC3PARAM iteration
> count is
> >> at most 150 (regardless of RSA key size).  Larger iteration
> counts
> >> are both inefficient and fragile in the face of algorithm
> rollovers.
> >> The optimal value is 0 (performs one round of SHA1, which is
> enough to
> >> deter casual zone walking).  The most popular value is 1, which
> is
> >> very likely because it is slightly unclear whether 0 means no
> hash
> >> or (as is the case) just one initial hash.  So hats off to the
> >> operations that chose 1, they understand that the count should
> be
> >> low, and are careful to avoid edge cases.
> >
> > Again, I think this is out of scope of a document standardizing a
> registration mechanism.  Besides which, there are operators out there who
> deliberately have a low iteration count because they don't care about zone
> walking, and are only using NSEC3 for the opt-out capability.
>
> Here you misunderstood my point, I am suggesting a MAXIMUM of 150 and
> recommending
> 0 or 1, precisely because opt-out is mostly all that NSEC3 is useful for,
> but one
> or two rounds of SHA deter "casual" zone walking.
>

Yes, for some reason I got your intent backwards.  I still think it's out
of scope though... an iteration count higher than 150 does not constitute a
trustworthiness problem for the parent.
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop


Re: [DNSOP] Acceptance processing in draft-ietf-regext-dnsoperator-to-rrr-protocol-04 section 3.4

2018-04-14 Thread Viktor Dukhovni


> On Apr 14, 2018, at 4:26 PM, Matthew Pounsett  wrote:
> 
> These are getting into name server quality checks, and not security checks, 
> which is the point of the acceptance testing.  I don't agree that these 
> should be part of this document.

If the registry operator is going to automatically upgrade previously insecure 
delegations to DNSSEC, then due diligence to make sure that this is not going 
to cause outages is advisable.  Once a domain is signed, TLSA and CAA lookups 
must succeed, or the domain may no longer receive email from DANE-enabled 
sending MTAs, or be able to obtain certificates from their CA, ...

So I rather strongly feel that appropriate quality checks should be in place, 
to protect both the registrant and the registry (dealing with fallout from 
outages is best avoided).

>>   o Check that if the zone uses RSA, the KSK and ZSK are at least 1280
>> bits and at most 2048 bits.  This may be controversial, but for new
>> deployments RSA <= 1024 bits is widely considered too weak, and RSA
>> with more than 2048 bits creates signatures that are often too large
>> for reliable UDP transport.
> 
> While this is probably a reasonable thing to do, a registration mechanism 
> documented in REGEXT is not the place to do this.  I think if DNSOP wants 
> such advice in a standard there should be a BCP document out of DNSOP that 
> defines it.

Yes, this is a point for discussion.  Still I think it would be bad to, for 
example, introduce more domains with 512-bit RSA keys, or perhaps even accept 
1024-bit RSA
keys.  There are many domains with 1536-bit KSKs and 1280-bit ZSKs, these are I
think well chosen, though ECDSA P-256 (algorithm 13) is looking increasingly 
like
an even better choice at present.

Given that 1024-bit RSA is considered past its use-by these days, perhaps 
limiting
automated upgrades to DNSSEC only to stronger keys is a good idea???

>>   o Check that if the zone uses NSEC3 the NSEC3PARAM iteration count is
>> at most 150 (regardless of RSA key size).  Larger iteration counts
>> are both inefficient and fragile in the face of algorithm rollovers.
>> The optimal value is 0 (performs one round of SHA1, which is enough 
>> to
>> deter casual zone walking).  The most popular value is 1, which is
>> very likely because it is slightly unclear whether 0 means no hash
>> or (as is the case) just one initial hash.  So hats off to the
>> operations that chose 1, they understand that the count should be
>> low, and are careful to avoid edge cases.
> 
> Again, I think this is out of scope of a document standardizing a 
> registration mechanism.  Besides which, there are operators out there who 
> deliberately have a low iteration count because they don't care about zone 
> walking, and are only using NSEC3 for the opt-out capability.

Here you misunderstood my point, I am suggesting a MAXIMUM of 150 and 
recommending
0 or 1, precisely because opt-out is mostly all that NSEC3 is useful for, but 
one
or two rounds of SHA deter "casual" zone walking.

You may not have seen my posts to dns-operations and this list about the issues
with iteration counts that exceed 150.  The tl;dr version is don't do that.
Catching mistakes at registration time is our best opportunity to maintain the
hygiene of the ecosystem.

-- 
Viktor.

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


Re: [DNSOP] Acceptance processing in draft-ietf-regext-dnsoperator-to-rrr-protocol-04 section 3.4

2018-04-14 Thread Matthew Pounsett
On 14 April 2018 at 12:54, Viktor Dukhovni  wrote:

>
> A number of checks are listed in:
>
>   https://tools.ietf.org/html/draft-ietf-regext-dnsoperator-
> to-rrr-protocol-04#section-3.4
>
> that are intended to make sure a domain is ready for DNSSEC.
>
> As I've been the DNSSEC and DANE implementations at now ~5.8 million
> domains, I'd like to suggest some additional checks:
>

Thanks for the review Viktor. We haven't had many DNS people respond to the
draft.. I've been considering mentioning it in DNSOP, but was going to wait
until several pending changes are in the doc and -05 is out (hopefully in
the next week or two, time permitting).


>
>  o  ensuring that the SOA record RRset is correctly signed, unlike:
>
>   http://dnsviz.net/d/_25._tcp.mx1.techtrack.gov/dnssec/
>
> which is always incremented by 1 *after* the zone is signed!
>

I believe this is already covered by the first point: "checks that the
child zone is is properly signed as per the Registration Entity and parent
DNSSEC policies".  Although, we could add some example RRsets that should
be examined for correct signatures.


>  o  ensuring the NS RRset at the zone apex matches the glue RRs
> at the parent zone


>  o  Verifying that TLSA lookups are NOT blocked and denial of
> existence works by querying for:
>
>_25._tcp..example.net. IN TLSA ?
>
> and verifying the NXDomain, NODATA, or (very rarely) wildcard
> TLSA records against the implied DNSKEYs.  The nonce can be some
> random hex string of 8 or more bytes, that is unlikely to be an
> actual name in the zone.
>
>   o Do the above for all IPv4 and IPv6 addresses of all the
> nameservers,
> as some misconfigured firewalls block unexpected RR types for just
> IPv4 or just IPv6.
>
>   o A similar probe for CAA records is likely appropriate, Let's
> Encrypt
> runs into CAA lookup issues for a non-negligible fraction of
> domains.
>

These are getting into name server quality checks, and not security checks,
which is the point of the acceptance testing.  I don't agree that these
should be part of this document.


>
>   o Check that if the zone uses RSA, the KSK and ZSK are at least 1280
> bits and at most 2048 bits.  This may be controversial, but for new
> deployments RSA <= 1024 bits is widely considered too weak, and RSA
> with more than 2048 bits creates signatures that are often too
> large
> for reliable UDP transport.
>

While this is probably a reasonable thing to do, a registration mechanism
documented in REGEXT is not the place to do this.  I think if DNSOP wants
such advice in a standard there should be a BCP document out of DNSOP that
defines it.


>
>   o Check that if the zone uses NSEC3 the NSEC3PARAM iteration count is
> at most 150 (regardless of RSA key size).  Larger iteration counts
> are both inefficient and fragile in the face of algorithm
> rollovers.
> The optimal value is 0 (performs one round of SHA1, which is
> enough to
> deter casual zone walking).  The most popular value is 1, which is
> very likely because it is slightly unclear whether 0 means no hash
> or (as is the case) just one initial hash.  So hats off to the
> operations that chose 1, they understand that the count should be
> low, and are careful to avoid edge cases.
>

Again, I think this is out of scope of a document standardizing a
registration mechanism.  Besides which, there are operators out there who
deliberately have a low iteration count because they don't care about zone
walking, and are only using NSEC3 for the opt-out capability.
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop