<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=utf-8">
  </head>
  <body text="#000000" bgcolor="#FFFFFF">
    <div class="moz-cite-prefix">Updates:<br>
      <br>
      1. host(1) cmd preferred behavior realized<br>
      <br>
      I've realized the host(1)-command behavior I want, seemingly (but
      not certain due to these settings) adding 'local=/mydomain.tld/'
      and 'expand-hosts' to my dnsmasq.conf. I suspect one of these
      settings solved the host(1) command "problem" -- but again, I've
      not properly tested the variables.<br>
      <br>
      2. configuring an authoritative dnsmasq nameserver<br>
      <br>
      I'll be looking into running an authoritative server (with SOA
      directive and the like) with settings per this example config:  <a
href="http://lists.thekelleys.org.uk/pipermail/dnsmasq-discuss/2020q3/014153.html">http://lists.thekelleys.org.uk/pipermail/dnsmasq-discuss/2020q3/014153.html</a><br>
      <br>
      3. patching dnsmasq if #2 not currently feasible<br>
      <br>
      If Petr's note below is accurate (and I understand it correctly),
      point #2 (above) will not provide authoritative-server DNS
      service. In such a case, I'd love to see a patch that does.  Pls
      keep in mind I'm currently running at least one DNS config sans
      upstream server connect per: <a
href="http://lists.thekelleys.org.uk/pipermail/dnsmasq-discuss/2020q3/014143.html">http://lists.thekelleys.org.uk/pipermail/dnsmasq-discuss/2020q3/014143.html</a><br>
      <br>
      ~J<br>
      <br>
      <br>
      On 2020-07-07 3:32 AM, Petr Menšík wrote:<br>
    </div>
    <blockquote type="cite"
      cite="mid:a95daa6b-e47c-dc5a-864e-bcbd04f3a1b0@redhat.com">
      <pre wrap="">Hi Johnny,

I think this is related to difference in Dnsmasq internal data model.
Bigger authoritative server handle authoritative responses for a name.
That means once you define some host, even with just single record type,
it would respond NOERROR for the same name for any other record type.

Dnsmasq forwards unhandled records to configured upstream resolver
servers, which may respond with REFUSED. It would respond REFUSED also
to A record, if you asked upstream server instead of your dnsmasq.

While I have seen some use-cases, where this behavior is useful, I think
it should be only optional. Default mode should match other servers -
once a name is defined, it is considered authoritative for the name and
respond for any type of given name NOERROR. It may still omit "zones"
usually required on authoritative servers, but should behave as
mini-zone on any name served. Should require configuration to be able
forward different types to another server, if it is required.

In other words, it might require a lot of work to change this behaviour.
It might help to define authoritative zone using
auth-zone=dnsmasq.example, and provide all names from dnsmasq with
dnsmasq.example suffix. domain=dnsmasq.example might help. dnsmasq would
then answer all requests under this suffix itself and not forward anything.

Simon, would such change be accepted, if I made candidate patch? Are
there documented use-cases, where current behavior is required?

Regards,
Petr

On 7/3/20 8:10 PM, Johnny Utahh wrote:
</pre>
      <blockquote type="cite">
        <pre wrap="">On 2020-07-03 1:07 PM, Johnny Utahh wrote:
</pre>
        <blockquote type="cite">
          <pre wrap="">Two related questions:


1. Support non-error host(1) queries to AAAA and MX records?

Cmdline-session details, with private info (hopefully) redacted:
<a class="moz-txt-link-freetext" href="https://gist.githubusercontent.com/johnnyutahh/0f171e47e6ed861f66a1835150a11e4a/raw">https://gist.githubusercontent.com/johnnyutahh/0f171e47e6ed861f66a1835150a11e4a/raw</a>


Short version:

a. host(1) against my dnsmasq server == 5(REFUSED)
b. host(1) against Cloudflare/GoDaddy == no error

Details:

Ubuntu 20.04's host(1) by default appears to (I think?) query all 3 of
of A, AAAA, and MX records. In my simple,
dnsmasq-served-by-only-the-A-record-is-in-/etc/hosts-config, host(1)
complains about the AAAA and MX looks. When asking Cloudflare (with
GoDaddy as source/authoritative server), host(1) does not complain.

How can I make my dnsmasq server mimic the Cloudflare/GoDaddy response
and make host(1) happy?  (I'd like my users to not complain after a
switchover.)

Does Cloudflare/GoDaddy answer with a blank/empty-string AAAA and MX
record, while dnsmasq simply respond with a "not here"/5(REFUSED)
response?

What is better/best-practice behavior and why?


2. Make dnsmasq, sans upstream DNS, the authoritative DNS for my domains?

The host(1) output from dnsmasq's server shows the reply as
non-authoritative, if I'm reading its output correctly.

Why would dnsmasq not, by default, claim it's the authoritative server
if (in my case) there's no upstream DNS? And how can I make it do so?
</pre>
        </blockquote>
        <pre wrap="">
Clarifying:
</pre>
        <blockquote type="cite">
          <pre wrap="">When asking Cloudflare (with GoDaddy as source/authoritative server),
host(1) does not complain.
</pre>
        </blockquote>
        <pre wrap="">
...even when there is no AAAA nor MX record.


_______________________________________________
Dnsmasq-discuss mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Dnsmasq-discuss@lists.thekelleys.org.uk">Dnsmasq-discuss@lists.thekelleys.org.uk</a>
<a class="moz-txt-link-freetext" href="http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss">http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss</a>

</pre>
      </blockquote>
      <pre wrap="">
</pre>
    </blockquote>
    <br>
    <br>
    <div class="moz-signature">-- <br>
      <i> </i></div>
  </body>
</html>