On 19. 01. 23 11:57, Simon Kelley wrote:
Addendum.

I just looked at the latest draft (11) rather than draft zero whixh was linked here. That makes it clear that the additional processing is optional, so simply caching SVCB recpords might be a usable option.


Opinions? I'm basing this on a 10 minute skim of the draft, does anyone have more information?

Simon.

Yes, I also think we can just cache the record as any good recursive server. Additional records may or may not be stored to cache too, but that is clearly optional. If they are, similar restrictions to CNAME processing should be done. I think we should rely on clients be able to ask them.

I think dnsmasq should be modified to cache any reasonably short response, no matter what record type it contains. It is not necessary to cache PGP keys, but HTTPS and SVCB might be queried before each connection. It makes sense to cache those. I think type of record should be made separate cache field instead of encoding it in flags field. Only loggers should be taught to provide descriptions for common types and just simplified for more unusual types. Current code has it quite entangled into the logic and is difficult to add just selected new records. I agree that HTTPS RR would be the best candidate now. Ideally dnsmasq should be able to collect record query types per some period and cache most queried types, whatever it is. But sure, that would require non-trivial logic updates.

I think we should cache HTTPS response and just that record response. Rely on clients to ask additional records until we implement logic to store those related records as well. And for cases where some clients cannot handle well what they should, allow runtime cache disabling for selected record types, including HTTPS. New option --skip-cache-rr=https maybe?

Or we could modify cache to store separate records for ANSWER and ADDITIONAL sections. If we can respond a query with multiple records of different types and into multiple sections, that would solve the problem, right? We do not do iterative queries, so we just need to answer with all records our upstream has included. That might help also with CNAME or DNAME following, right?

Just my 2 cents.

Cheers,
Petr


On 19/01/2023 00:20, Dan Schaper via Dnsmasq-discuss wrote:
HTTPS is a valid resource record type. It's currently in draft status but it's used in the wild rather frequently.

https://developer.mozilla.org/en-US/docs/Glossary/https_rr

https://blog.cloudflare.com/speeding-up-https-and-http-3-negotiation-with-dns/

Best,
Dan


--
Petr Menšík
Software Engineer, RHEL
Red Hat, http://www.redhat.com/
PGP: DFCF908DB7C87E8E529925BC4931CA5B6C9FC5CB

Attachment: OpenPGP_0x4931CA5B6C9FC5CB.asc
Description: OpenPGP public key

Attachment: OpenPGP_signature
Description: OpenPGP digital signature

_______________________________________________
Dnsmasq-discuss mailing list
Dnsmasq-discuss@lists.thekelleys.org.uk
https://lists.thekelleys.org.uk/cgi-bin/mailman/listinfo/dnsmasq-discuss

Reply via email to