Re: [Dnsmasq-discuss] Don't forward queries if another RR is present
> 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 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. ___ 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
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
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
