[Dnsmasq-discuss] When HTTPS is added to rr-types of --cache-rr and --nonegcache is active non-HTTPS responses to HTTPS queries are not cached

[Simon Kelley]

It depends what the _query_ is.

If the query is for CNAME, then it's not an empty response, and it 
should be cache. In this case, the query is for an HTTPS record and the 
answer is a CNAME, but there's no answer for the target of the CNAME, so 
it's a negative response.

The answer to an HTTPS query is no HTTPS record: that's a negative answer.

Simon.
On 7/10/25 14:09, Jay Guerette wrote:
> 
> The CNAME response is not a negative response.
> 
> A negative response is an empty response; for example: dig -t HTTPS foo.com
> 
> It may not be the response you're hoping for or expecting but it is a 
> positive response configured by the domain owner and thus I think it 
> should be cached.
> 
> 
> On 7/10/25 6:43 AM, Simon Kelley wrote:
>>
>>
>> On 7/9/25 05:19, Jay Guerette wrote:
>>> Running dnsmasq 2.90 on Fedora 42.
>>>
>>> To reproduce:
>>> - verify caching is active and working
>>> - add cache-rr=HTTPS to your conf
>>> - verify no-negcache is NOT active in your conf
>>> - reload or restart dnsmasq
>>> - do _two_ digs for ietf.org: dig -t HTTPS @127.0.0.1 www.ietf.org
>>> - verify the 2nd IN HTTPS response is served from cache
>>> - do _two_ digs to example.com: dig -t HTTPS @127.0.0.1 www.example.com
>>> - verify the 2nd IN CNAME response is  served from cache
>>> - enable no-negcache in your conf
>>> - reload or restart dnsmasq
>>> - do _two_ digs for ietf.org: dig -t HTTPS @127.0.0.1 www.ietf.org
>>> - verify the 2nd IN HTTPS response is served from cache
>>> - do _two_ digs to example.com: dig -t HTTPS @127.0.0.1 www.example.com
>>> - observe the 2nd IN CNAME response is *NOT* served from cache
>>>
>>> Firefox is requesting an HTTPS record for every host name and almost 
>>> all return IN CNAME instead of IN HTTPS so almost none are cached.
>>>
>>> I don't think that a CNAME response to an HTTPS request is a negative 
>>> response and expect that it would be cached.
>>>
>>
>> I think this is correct behaviour.
>>
>> The thing to understand here is that the CNAME chain doesn't end in a 
>> answer to the original question. This is therefore a negative response.
>>
>> You can think of the answer as being
>>
>> CNAME:www.example.com -> <NO ANSWER>
>>
>> It's telling you that there's no HTTPS data for www.example.com, and 
>> that's definitely a negative response.
>>
>> There are two differences here between your example.com and ietf.org 
>> tests. You are concentrating on the CNAME, but the difference that 
>> means the ietf.org gets cached and example.com doesn't is that 
>> www.ietf.org has an HTTPS records and www.example.com doesn't. The 
>> presence of CNAMEs is irrelevant.
>>
>>
>> Cheers,
>> Simon.
>>
>>>
>>>
>>> _______________________________________________
>>> Dnsmasq-discuss mailing list
>>> Dnsmasq-discuss at lists.thekelleys.org.uk
>>> https://lists.thekelleys.org.uk/cgi-bin/mailman/listinfo/dnsmasq-discuss
>>
>>
>> _______________________________________________
>> Dnsmasq-discuss mailing list
>> Dnsmasq-discuss at lists.thekelleys.org.uk
>> https://lists.thekelleys.org.uk/cgi-bin/mailman/listinfo/dnsmasq-discuss
> 
> 
> 
> _______________________________________________
> Dnsmasq-discuss mailing list
> Dnsmasq-discuss at lists.thekelleys.org.uk
> https://lists.thekelleys.org.uk/cgi-bin/mailman/listinfo/dnsmasq-discuss