On 13. 09. 24 16:17, Ben Schwartz wrote:
If the A record is useless to a v6-only client, the client can drop it
upon receipt without requiring new signalling between the stub and the
resolver.
For multi-qtype to be the correct solution, I feel all the following
need to be true:
* The client would prefer to save 200 bytes in transit rather than get
a partial answer 20 ms sooner.
Curious question:
Are there public data which show that A and AAAA arrive that far apart?
I would expect that in most cases client will get either cache hit or
miss on both, and there is no reason why one of them should be slower or
faster. At least on DNS protocol level.
* Resolver support for multi-qtypes is mandatory in this context, so
the client can rely on it.
* The client requires direct access to the full flexibility of DNS.
(A limited-purpose gateway will not suffice.)
I would not say mandatory. Client must do some form of detection before
relying on it, and implement a fallback.
There may be situations that meet all of these criteria. If so, it
would be nice to hear a bit about them.
I vaguely remember that Lorenzo Colitti had a complaint in an IETF
session that DoH overhead noticeably increases data consumption on
mobile devices. I guess query coalescing might help with this as well.
Having said that, my main worry is that complexity on server will be
wasted by having zero clients to make use of it. See responses on this
topic in dnssd WG. Beginning of the thread is here:
https://mailarchive.ietf.org/arch/msg/dnssd/hO1QxNPPTPSx8S8vD6mqPKFUYMQ/
IIUC the only people who spoke up were from OpenThread project.
--
Petr Špaček
Internet Systems Consortium
_______________________________________________
DNSOP mailing list -- dnsop@ietf.org
To unsubscribe send an email to dnsop-le...@ietf.org
