[DNSOP] Re: I-D Action: draft-ietf-dnsop-ns-revalidation-08.txt

[Willem Toorop]

Thanks for the review Duane!




Op 31-01-2025 om 04:39 schreef Shumon Huque:

I have added some minor comments inline below with the individual conversation items "cut out".

On Tue, Jan 28, 2025 at 8:36 PM Wessels, Duane <dwessels=40verisign....@dmarc.ietf.org> wrote:

    >    Additional addresses in authoritative NS RRset responses
    SHOULD be
    >    validated if they are not already authoritatively in cache.  Only
    >    when such additional addresses are DNSSEC verifiable,
    (because the
    >    complete RRset is included, including a verifiable signature
    for the
    >    RRset), such additional addresses can be cached authoritatively
    >    immediately without additional validation queries. DNSSEC
    validation
    >    is enough validation in those cases.  Otherwise, the
    addresses cannot
    >    be assumed to be complete or even authoritatively present in
    the same
    >    zone, and additional validation queries SHOULD be made for these
    >    addresses.

    I suggest rewriting this to talk about the DNSSEC verifiable case
    first
    (no address validation needed) and then say to do the address
    validation.
    As written I find it sort of mixed up, like: "do address
    validation.  except
    sometimes you dont have to.  otherwise you have to".



a rewrite.

Okay, that sounds reasonable. I'll defer to Willem to review this text and propose

Okay, I'll reorder and rewrite to mention it's fine to cache authoritatively when it is DNSSEC verifiable first, and forbidden (MUST NOT) to use to cache otherwise.

    >    Note that there may be outstanding address validation queries
    for the

    >   names of the authoritative NS RRset (from referral address
    validation
    >    queries).

    I don’t think “referral address validation query” is a term previously
    used or defined.



you review and chime in?

Hmm, I'm not fully clear what this paragraph is saying either. Willem - can

It was intended to mean the validating address queries for the names in the non-authoritative, referral, NS RRset. I'll try to clarify by using different wording and referencing the part where those are described

    Even in non-attack situations, it seems that delegation
    revalidation could
    have very significant traffic impacts.  Willem and his colleagues
    performed
    a study for ICANN, looking at consequences of having signed root name
    server data.  One of their conclusions was that revalidation would
    provide
    better security than a signed root priming response.

    The tradeoff is more traffic. If every root priming query today
    resulted
    in an additional 1 NS query and 26 more A/AAAA queries (worst
    case), total
    root zone traffic would grow by 30%.  Of course not all zones have
    that
    property, but some do, and it should probably be documented.



and came about because of that ICANN study. I agree that the draft

of doing it. Willem - let's review and propose some text.

Yes, the glue revalidation section is a relatively new addition to the draft, might need a clearer statement about the traffic amplification implications

Agree, let's add a paragraph on expected traffic increase.

-- Willem

OpenPGP_0xE5F8F8212F77A498_and_old_rev.asc
Description: OpenPGP public key

OpenPGP_signature.asc
Description: OpenPGP digital signature

_______________________________________________
DNSOP mailing list -- dnsop@ietf.org
To unsubscribe send an email to dnsop-le...@ietf.org