[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

[Jay Guerette]

Thanks for the guidance and for your time!


On 7/10/25 11:57 AM, Simon Kelley wrote:
> 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
>
>
> _______________________________________________
> Dnsmasq-discuss mailing list
> Dnsmasq-discuss at lists.thekelleys.org.uk
> https://lists.thekelleys.org.uk/cgi-bin/mailman/listinfo/dnsmasq-discuss

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.thekelleys.org.uk/pipermail/dnsmasq-discuss/attachments/20250711/48716694/attachment.htm>