[Dnsmasq-discuss] Don't forward queries if another RR is present
albert.aribaud at free.fr
Mon Mar 13 19:13:39 GMT 2017
A few inlin comments.
Le Mon, 13 Mar 2017 11:51:44 -0400
Alex Xu <alex_y_xu at yahoo.ca> a écrit:
> I tried searching for this topic but only found tangentially related
> 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
> 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 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?
... there would not be a problem, right?
More information about the Dnsmasq-discuss