[Dnsmasq-discuss] dnsmasq (pihole) caching of HTTPS requested

Petr Menšík pemensik at redhat.com
Tue Jan 31 12:01:04 UTC 2023


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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_0x4931CA5B6C9FC5CB.asc
Type: application/pgp-keys
Size: 4560 bytes
Desc: OpenPGP public key
URL: <http://lists.thekelleys.org.uk/pipermail/dnsmasq-discuss/attachments/20230131/dd40cce3/attachment.key>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_signature
Type: application/pgp-signature
Size: 495 bytes
Desc: OpenPGP digital signature
URL: <http://lists.thekelleys.org.uk/pipermail/dnsmasq-discuss/attachments/20230131/dd40cce3/attachment.sig>


More information about the Dnsmasq-discuss mailing list