Last Call Review of draft-ietf-tls-esni-23
review-ietf-tls-esni-23-dnsdir-lc-gieben-2025-03-07-00

Hello,

I'm the designated reviewer from dnsdir and I've reviewed -23.

I have a bunch of nits and minor questions, but section 10.2 stood out as I had
trouble understanding the DNS bits in there. Though I think that those can be
fairly easy be fixed.

Note that I haven't read (or can't remember) any of the referenced RFCs or I-Ds.

In section 6.1.7 "Authenticating for the Public Name", this repeats the a
public_name should not have any ASCII dots in the wrong places and that all
labels 63 octects.

Nothing is said about the overall length of DNS name? I assume the referenced
RFC 5890 references older DNS RFCs about this? But if so, why call out the
ASCII dots and the label lengths?

At the end of that paragraph other limitations are layed out about the
"numbers" 0-9 and A-F.

    "This avoids public_name... interpreted as IPv4 literals"

Seeing A-F also being mentioned this is "IPv4/IPv6 literals"?  (Then again IPv6
would be weird, because there should dots in public_name).

In section 6.1.8, last paragraph,

    "...comply with any freshness rules (e.g., DNS TTLs)"

Fair, but how does the application get access to those TTLs? AFAIK the normal
resolving stack doesn't not hand out that information.

In section 8.1.1.

    "...provided the server is authoritative for the public name."

What is meant by this? Because in DNS a nameserver is authoritative for a zone
(and thus the names in that zone). Does this mean the DNS name points to this
server (via A or AAAA)?

Section 10.2

nit: "Resource Records" -> RRs (I saw RRs already being used in the document)

    "ECH records"

What are those? Are these the HTTPS record(s), mentioned in the beginning?

Further more,

    "... which is 1:1 with the DNS name that was looked up (modulo DNS
    wildcards)."

As a non-native English speaker, I have trouble understanding the "which is 1:1
with the DNS name".

Then

    "modula DNS wildcards"

Why is this mentioned? Because a DNS server (internally) knows about DNS
wildcards, but a client does not (well with DNSSEC you can figure it out), so
I'm not sure why this is said here, seems not relevant and even a bit wrong?

Nit:

    "Encrypted DNS"

Maybe put the references to the RFCs here again?

Section 10.3

    "... can help mitigate this problem by flushing and DNS or ECHConfig
    state..."

"flushing DNS state" is dropping the HTTPS record information that a client has
and performing a lookup again? Because I don't see how DNS state can be flushed
from, say the local resolving by such client, but I don't think that was meant.

Section 10.10.2

    "... further limit sharing.... different keys using a short TTL"

OK, yes, this will help a bit, put this information is being put in public DNS,
so it's as public as can be... which is the opposite of 'limit sharing'... ?

Section 10.10.6

    "ECH record"

used again.

    "trusted Recursive Resolver"

I'm unaware of a formal definition of "trusted recursive resolver", so you
might trust the resolver, but as this document also explains that sounds a bit
like hoping for the best? Unsure what to make of this. Or is this the Firefox
TRR thing? Which implies DoH/DoT querying?

Cheers,
Miek