[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