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

[Simon Kelley]

On 31/01/2023 12:01, Petr Menšík wrote:
> 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.

There's actually already code to cache arbitrary-length RRs. It was 
built for DNSKEY and DS records in the DNSSEC campaign, but it's 
subsequently been used to cache SRV records. Expanding the SRV caching 
code to cache from an arbitrary list is a reasonable thing to do. The 
list of cached RRS could default to SRV and SVCB, but allowing 
configuration of an arbitrary list would be easy and useful.
> 
> 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 that, I prefer my suggestion because it's a smaller behaviour change 
without explicit configuration.
> 
> 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?

That's a fairly big change to the cache code.


Simon.

> 
> 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
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> Dnsmasq-discuss mailing list
>>>> Dnsmasq-discuss at lists.thekelleys.org.uk
>>>> https://lists.thekelleys.org.uk/cgi-bin/mailman/listinfo/dnsmasq-discuss