[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]

The whole reason that no-negcache exists is as a workaround for broken 
upstream servers which fail to find the value of a RR and just return an 
empty reply. That's less of a problem if the broken reply is not cached.

In your case, I think the answer is obvious. If you have broken upstream 
servers, what you have now is preferable to long-term outages from 
cached erroneous negative data. If your upstream servers don't have this 
pathology, (they alomost certainly don't)  don't configure no-negcache. 
It not meant for your situation and shouldn't be used.

Cheers,

Simon.



On 10/07/2025 16:14, Jay Guerette wrote:
> 
> The explicit DNS negative answer is NXDOMAIN and anything else should be 
> considered the will of the domain owner. A NOERROR response, even if 
> empty or unexpected, is a valid response. As many RRs will return an 
> empty response if not explicitly defined I agree that it doesn't make 
> sense to cache them. I disagree that we should discard a non-empty 
> response based on an opinion of it's validity.
> 
> If we can't agree on that premise I think we should have alternative 
> means to handle this. I'm explicitly configuring dnsmasq to cache these 
> RRs. Can we have additional controls around handling of non-empty responses?to 
> Currently ~50% of my household HTTP DNS traffic is for HTTPS records and 
> almost none of it is cached, so I'm open to ideas about improving that 
> situation that isn't just simply blocking them.
> 
> 
> On 7/10/25 9:57 AM, Simon Kelley wrote:
>> 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
>>
>>
>> _______________________________________________
>> 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