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