I tried searching for this topic but only found tangentially related

If we have "--host-record=example.com,,", then "dig a
example.com" will return as expected. However, "dig aaaa
example.com" will return 2606:2800:220:1:248:1893:25c8:1946. In order
to suppress this behavior, we must specify "--server=/example.com/",
which has the side effect of additionally suppressing requests for
subdomains, i.e. "dig a www.example.com" returns NODATA.

I think this behavior is highly counter-intuitive, but even worse is if
some upstream has RR "example.com IN CNAME otherexample.com". Then,
reportedly with some clients the CNAME may be cached separately and
chased for a subsequent A query, thus resulting in a contradictory
answer. Moreover, I believe this is a violation of RFC 1034 (section
3.6.2), which specifies:

> If a CNAME RR is present at a node, no other data should be
> present; this ensures that the data for a canonical name and its
> aliases cannot be different.  This rule also insures that a cached
> CNAME can be used without checking with an authoritative server for
> other RR types.

In this case, I think we can reasonably interpret the first instance of
"present" as meaning 'loaded in dnsmasq' and the second as 'returned
for any query'. So for the previous example, since an AAAA query
returns a CNAME, A queries must also return CNAME, not any data for

Therefore, I believe this behavior should be changed so that queries
are not forwarded if some RR known to dnsmasq exists for that name,
possibly with some special directive implemented ("add-record"?) for
the existing behavior. I doubt there is anybody relying on this
behavior (possibly even more people expecting the opposite), but some
global directive could also be added to do the right thing (or the
wrong thing, having the right thing as default).

Dnsmasq-discuss mailing list

Reply via email to