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

[Alex Xu]

On Mon, 13 Mar 2017 20:13:39 +0100
Albert ARIBAUD <albert.aribaud at free.fr> wrote:

> Hi,
> 
> 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
> > 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 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?
> 
> 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).