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

[Albert ARIBAUD]

Hi,

A few inlin comments.
Le Mon, 13 Mar 2017 11:51:44 -0400
Alex Xu  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 
> 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 
> 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,
-- 
Albert.

___
Dnsmasq-discuss mailing list
Dnsmasq-discuss@lists.thekelleys.org.uk
http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss

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

[Alex Xu]

On Mon, 13 Mar 2017 20:13:39 +0100
Albert ARIBAUD  wrote:

> Hi,
> 
> A few inlin comments.
> Le Mon, 13 Mar 2017 11:51:44 -0400
> Alex Xu  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 
> > 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 
> > 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).

___
Dnsmasq-discuss mailing list
Dnsmasq-discuss@lists.thekelleys.org.uk
http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss

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

___
Dnsmasq-discuss mailing list
Dnsmasq-discuss@lists.thekelleys.org.uk
http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss