Hello dns experts.I have been reading paper found on Mastodon [1], called Securing Name Resolution in the IoT: DNS over CoAP [2]. I found caching optimization described interesting and started wondering, why we do not have something similar in normal DNS. The algorithm is described at DNS over CoAP draft [3].
Because big resolvers often provide a way to serve stale data, I think it is common to do refreshes of cache items when they are still in cache. For those cases I think we could use ETag-like behaviour for common record types. I expect most of time records stays the same. If those records are bigger, it uses a lot of data just to receive unmodified reply. Just to check what if it has changed.
I started thinking, what if we used EDNS0 extension sending version at the client and asked the server if that has changed in the mean time. Lets call the extension cache-refresh for example. It might use SOA version number, which I think common authoritative servers use to to mark zone version somehow. But almost any binary id would be sufficient. The server may provide any alternative like timestamp. For a client, it does not matter. It would just store whatever the server used on last reply.
Let me show my idea on example. C is client, S is recursive cache server. C: example.net TXT? with EDNS0, empty cache-refresh option. It does not have it in cache, but indicates it understands refresh protocol.S: example.net TXT "some text" with EDNS0, cache-refresh option contains TTL=0 of example.net TXT. Followed by SOA=2022091312.
Server sends NOERROR response with answer section containing records. Client stores the answer in the cache, TTL in cache-refresh says client should use new response.
Now client after some time wants to refresh these records, so it sends query again.
C: example.net TXT? with EDNS0, cache-refresh option with TTL=0 and SOA=2022091312.
Because we have a cache entry, we want just to check if it has changed. Server can indicate just that no, it has not.
S: NOERROR response with EDNS0, cache-refresh option contains TTL=284 of example.net TXT remaining. Followed by SOA=2022091312.
This should allow to not sending potentially large responses, while being notified soon of a changed records. Suitable for relatively small TTLs like 10 minutes or up to hour. No new verification is needed, no crypto operations just to ensure nothing has changed. It can just provide new TTL from the server cache.
As soon as the record changes, it includes full reply with TTL=0 in cache-refresh. If the record were removed, TTL=0 ensures that is propagated too.
Such mechanism could work well on DNSKEYs, which are often large. It would allow to refresh them often, but keep bytes transferred quite low. I just assume without any proof that majority of similar refreshes happen without really changing the provided value. This would allow to minimize transferred bytes without significantly increasing refresh window.
I think it does not clash even with DNSSEC. There should be some limit how long to allow rrset refreshed this way. One day, up to max one week, might work. It would help if authoritative servers supported this extension also. I think they often know when the record changed their value last. If authoritative did not support this, recursive might just ask first for SOA, then for record to refresh.
What do you think, would such mechanism be useful even on classic DNS? Are there already deployed alternatives? How useful something similar might be? Does such mechanism contain significant drawback, why it would not be a good idea?
Best Regards, Petr Menšík 1. https://ohai.social/@miri64/110819255462045467 2. https://arxiv.org/abs/2207.074863. https://www.ietf.org/archive/id/draft-ietf-core-dns-over-coap-03.html#section-4.3.2
-- Petr Menšík Software Engineer, RHEL Red Hat, https://www.redhat.com/ PGP: DFCF908DB7C87E8E529925BC4931CA5B6C9FC5CB
OpenPGP_0x4931CA5B6C9FC5CB.asc
Description: OpenPGP public key
OpenPGP_signature
Description: OpenPGP digital signature
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
