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). _______________________________________________ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss