On 11. 07. 26 15:15, Eric Kinnear wrote:
Name: draft-kinnear-dnsop-globally-relevant
Revision: 00
Title: Globally Relevant HTTPS RRs
I've read all of it and while I understand the technical side, I think,
but I consider this approach problematic. It's a lot of text so I tried
to split it into sections, and I swear this is not AI generated slop :-)
## Assumptions
Are there data available on:
- how often such presumed 'cache flush' occurs?
- how much extra traffic does that generate (compared to not doing cache
flush)?
- what's the cost in terms of latency?
- how widespread such behavior is/where it is implemented?
- is there indication clients are interested in this proposed signal?
## Design choice
I find odd this optimization targets only SVCB and HTTPS.
AFAIK vast majority of NSD/BIND/Knot DNS deployments on this planet
generate 'constant' answers no matter who and when asked. I.e. a
significant portion of DNS answers is 'constant'/observer-independent
and all record types would benefit from "globally-relevant" treatment.
With this in mind, I can imagine this signal can be EDNS option attached
to whole answer message, which might be simply good enough granularity
and provide much better coverage.
Have you considered something like this?
## Important
7. Security Considerations
7.1. Incorrect Use
Clients MUST NOT reuse cached address hints across network changes for
connections that are not authenticated by a security protocol, such as TLS. ...
That sounds waaaaaaaaay beyond scope of this draft. It seems the
underlying assumption is that all clients already MUST drop all caches
all the time, but I don't think it is universally true, or even desired,
especially in data centres and such.
Are there data to back this assumption?
7.4. Downgrade and Upgrade Attacks
This section misses the nasty case:
An attacker can supply a fake value, with long TTL, and with
"globally-relevant" flag. If the underlying assumption is still that
clients normally flushes caches then this new behavior extends the
attack window across network changes.
I also agree with comments raised by Ben Schwarz in the other thread and
will not repeat them here.
## Hard to understand
6. Resolver Behavior
Recursive resolvers
This section contradicts itself - MUST pass vs. SHOULD NOT carry.
MUST pass the "globally-relevant" SvcParamKey through to clients transparently,
without modification....
Such synthesized answers SHOULD NOT carry
I suggest reformulating section to something along the lines of 'MUST
remove flag if the intemediary modifies data, MUST pass the flag if it
does not'.
The section also needs some words on DNSSEC and interaction with it, and
possibly forward reference to 7.3. DNSSEC Considerations. Having said
that, I don't know how DNSSEC could be handled, short of going to EDNS
option/flag :-)
## Terminological nits
5. Server Behavior
An authoritative DNS server SHOULD set the "globally-relevant" SvcParamKey only
when the service binding parameters in the record are consistent across all resolvers and
network paths. This typically applies to globally-deployed services with uniform
configurations.
I would argue this section is for zone managers, not only authoritative
servers. Often it is not 'software' which generates RRs, but even if
they are generated, often it is not the authoritative server software in
charge of generating RRs.
6. Resolver Behavior
Recursive resolvers
Surely recursive resolvers are not the only component in the path. It
can be forwarder, dumb proxy at CPE which provides different transports,
RPZ filtering, or anything else. I suggest reformulating to
'intermediaries' or something like that.
--
Petr Špaček
_______________________________________________
DNSOP mailing list -- [email protected]
To unsubscribe send an email to [email protected]
