<!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">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>
    </div>
    <div class="moz-cite-prefix"><br>
    </div>
    <div class="moz-cite-prefix">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?</div>
    <p>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.</p>
    <div class="moz-cite-prefix"><br>
    </div>
    <div class="moz-cite-prefix">On 7/10/25 9:57 AM, Simon Kelley wrote:<br>
    </div>
    <blockquote type="cite"
      cite="mid:6f8e7cba-c6ed-43ea-a940-8d877c6e5fd4@thekelleys.org.uk">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-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>