[Dnsmasq-discuss] Don't forward queries if another RR is present

[Alex Xu]

I tried searching for this topic but only found tangentially related
topics.

If we have "--host-record=example.com,127.0.0.1,", then "dig a
example.com" will return 127.0.0.1 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

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
example.com.

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).

[Albert ARIBAUD]

Hi,

A few inlin comments.
Le Mon, 13 Mar 2017 11:51:44 -0400

Post by Alex Xu
I tried searching for this topic but only found tangentially related
topics.
If we have "--host-record=example.com,127.0.0.1,", then "dig a
example.com" will return 127.0.0.1 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

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 example.com.
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).

Am I right in thinking that the issue here is due to the host-record
specifies an IPv4 and without an IPv6?

IOW, with...

host-record=example.com,127.0.0.1,::1

... there would not be a problem, right?

Amicalement,

[Alex Xu]

On Mon, 13 Mar 2017 20:13:39 +0100

Post by Albert ARIBAUD
Hi,
A few inlin comments.
Le Mon, 13 Mar 2017 11:51:44 -0400

Post by Alex Xu
I tried searching for this topic but only found tangentially related
topics.
If we have "--host-record=example.com,127.0.0.1,", then "dig a
example.com" will return 127.0.0.1 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

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 example.com.
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).

Am I right in thinking that the issue here is due to the host-record
specifies an IPv4 and without an IPv6?
IOW, with...
host-record=example.com,127.0.0.1,::1
... there would not be a problem, right?
Amicalement,

then if we do "dig mx example.com" we could have the same problem (irl
example.com doesn't have MX, but some other domain).

[Josh Soref]

Post by Albert ARIBAUD
Am I right in thinking that the issue here is due to the host-record
specifies an IPv4 and without an IPv6?
IOW, with...
host-record=example.com,127.0.0.1,::1
... there would not be a problem, right?

Sounds right.

FWIW, I've been hitting this problem a lot. I'm glad someone raised it.

I hit it because of RFC 6555 - Happy Eyeballs.

My personal preference is for dnsmasq to realize that since it has an
A or AAAA or anything else, it isn't legal to return a CNAME and thus,
if it gets a CNAME from a recursive, it should drop it.

I'd be willing to look into writing a patch for this if there was an
indication that this was likely to be accepted.