<!DOCTYPE html>
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<div class="moz-cite-prefix"><br>
</div>
<div class="moz-cite-prefix">Thanks for the guidance and for your
time!</div>
<div class="moz-cite-prefix"><br>
</div>
<div class="moz-cite-prefix"><br>
</div>
<div class="moz-cite-prefix">On 7/10/25 11:57 AM, Simon Kelley
wrote:<br>
</div>
<blockquote type="cite"
cite="mid:e4fc442e-8edd-4e2d-8f37-e4f4c6b81d49@thekelleys.org.uk">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.
<br>
<br>
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.
<br>
<br>
Cheers,
<br>
<br>
Simon.
<br>
<br>
<br>
<br>
On 10/07/2025 16:14, Jay Guerette wrote:
<br>
<blockquote type="cite">
<br>
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.
<br>
<br>
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.
<br>
<br>
<br>
On 7/10/25 9:57 AM, Simon Kelley wrote:
<br>
<blockquote type="cite">It depends what the _query_ is.
<br>
<br>
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.
<br>
<br>
The answer to an HTTPS query is no HTTPS record: that's a
negative answer.
<br>
<br>
Simon.
<br>
On 7/10/25 14:09, Jay Guerette wrote:
<br>
<blockquote type="cite">
<br>
The CNAME response is not a negative response.
<br>
<br>
A negative response is an empty response; for example: dig
-t HTTPS foo.com
<br>
<br>
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.
<br>
<br>
<br>
On 7/10/25 6:43 AM, Simon Kelley wrote:
<br>
<blockquote type="cite">
<br>
<br>
On 7/9/25 05:19, Jay Guerette wrote:
<br>
<blockquote type="cite">Running dnsmasq 2.90 on Fedora 42.
<br>
<br>
To reproduce:
<br>
- verify caching is active and working
<br>
- add cache-rr=HTTPS to your conf
<br>
- verify no-negcache is NOT active in your conf
<br>
- reload or restart dnsmasq
<br>
- do _two_ digs for ietf.org: dig -t HTTPS @127.0.0.1
<a class="moz-txt-link-abbreviated" href="http://www.ietf.org">www.ietf.org</a>
<br>
- verify the 2nd IN HTTPS response is served from cache
<br>
- do _two_ digs to example.com: dig -t HTTPS @127.0.0.1
<a class="moz-txt-link-abbreviated" href="http://www.example.com">www.example.com</a>
<br>
- verify the 2nd IN CNAME response is served from cache
<br>
- enable no-negcache in your conf
<br>
- reload or restart dnsmasq
<br>
- do _two_ digs for ietf.org: dig -t HTTPS @127.0.0.1
<a class="moz-txt-link-abbreviated" href="http://www.ietf.org">www.ietf.org</a>
<br>
- verify the 2nd IN HTTPS response is served from cache
<br>
- do _two_ digs to example.com: dig -t HTTPS @127.0.0.1
<a class="moz-txt-link-abbreviated" href="http://www.example.com">www.example.com</a>
<br>
- observe the 2nd IN CNAME response is *NOT* served from
cache
<br>
<br>
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.
<br>
<br>
I don't think that a CNAME response to an HTTPS request
is a negative response and expect that it would be
cached.
<br>
<br>
</blockquote>
<br>
I think this is correct behaviour.
<br>
<br>
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.
<br>
<br>
You can think of the answer as being
<br>
<br>
CNAME:www.example.com -> <NO ANSWER>
<br>
<br>
It's telling you that there's no HTTPS data for
<a class="moz-txt-link-abbreviated" href="http://www.example.com">www.example.com</a>, and that's definitely a negative
response.
<br>
<br>
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 <a class="moz-txt-link-abbreviated" href="http://www.ietf.org">www.ietf.org</a> has an HTTPS
records and <a class="moz-txt-link-abbreviated" href="http://www.example.com">www.example.com</a> doesn't. The presence of
CNAMEs is irrelevant.
<br>
<br>
<br>
Cheers,
<br>
Simon.
<br>
<br>
<blockquote type="cite">
<br>
<br>
_______________________________________________
<br>
Dnsmasq-discuss mailing list
<br>
<a class="moz-txt-link-abbreviated" href="mailto:Dnsmasq-discuss@lists.thekelleys.org.uk">Dnsmasq-discuss@lists.thekelleys.org.uk</a>
<br>
<a class="moz-txt-link-freetext" href="https://lists.thekelleys.org.uk/cgi-bin/mailman/listinfo/dnsmasq">https://lists.thekelleys.org.uk/cgi-bin/mailman/listinfo/dnsmasq</a>-
discuss
<br>
</blockquote>
<br>
<br>
_______________________________________________
<br>
Dnsmasq-discuss mailing list
<br>
<a class="moz-txt-link-abbreviated" href="mailto:Dnsmasq-discuss@lists.thekelleys.org.uk">Dnsmasq-discuss@lists.thekelleys.org.uk</a>
<br>
<a class="moz-txt-link-freetext" href="https://lists.thekelleys.org.uk/cgi-bin/mailman/listinfo/dnsmasq">https://lists.thekelleys.org.uk/cgi-bin/mailman/listinfo/dnsmasq</a>-
discuss
<br>
</blockquote>
<br>
<br>
<br>
_______________________________________________
<br>
Dnsmasq-discuss mailing list
<br>
<a class="moz-txt-link-abbreviated" href="mailto:Dnsmasq-discuss@lists.thekelleys.org.uk">Dnsmasq-discuss@lists.thekelleys.org.uk</a>
<br>
<a class="moz-txt-link-freetext" href="https://lists.thekelleys.org.uk/cgi-bin/mailman/listinfo/dnsmasq-discuss">https://lists.thekelleys.org.uk/cgi-bin/mailman/listinfo/dnsmasq-discuss</a>
<br>
</blockquote>
<br>
<br>
_______________________________________________
<br>
Dnsmasq-discuss mailing list
<br>
<a class="moz-txt-link-abbreviated" href="mailto:Dnsmasq-discuss@lists.thekelleys.org.uk">Dnsmasq-discuss@lists.thekelleys.org.uk</a>
<br>
<a class="moz-txt-link-freetext" href="https://lists.thekelleys.org.uk/cgi-bin/mailman/listinfo/dnsmasq-discuss">https://lists.thekelleys.org.uk/cgi-bin/mailman/listinfo/dnsmasq-discuss</a>
<br>
</blockquote>
<br>
<br>
<br>
_______________________________________________
<br>
Dnsmasq-discuss mailing list
<br>
<a class="moz-txt-link-abbreviated" href="mailto:Dnsmasq-discuss@lists.thekelleys.org.uk">Dnsmasq-discuss@lists.thekelleys.org.uk</a>
<br>
<a class="moz-txt-link-freetext" href="https://lists.thekelleys.org.uk/cgi-bin/mailman/listinfo/dnsmasq-discuss">https://lists.thekelleys.org.uk/cgi-bin/mailman/listinfo/dnsmasq-discuss</a>
<br>
</blockquote>
<br>
<br>
_______________________________________________
<br>
Dnsmasq-discuss mailing list
<br>
<a class="moz-txt-link-abbreviated" href="mailto:Dnsmasq-discuss@lists.thekelleys.org.uk">Dnsmasq-discuss@lists.thekelleys.org.uk</a>
<br>
<a class="moz-txt-link-freetext" href="https://lists.thekelleys.org.uk/cgi-bin/mailman/listinfo/dnsmasq-discuss">https://lists.thekelleys.org.uk/cgi-bin/mailman/listinfo/dnsmasq-discuss</a>
<br>
</blockquote>
<p><br>
</p>
</body>
</html>