Robert Edmonds wrote:
Simon Kelley wrote:
Robert Edmonds wrote:
Robert Edmonds wrote:
so unbound forwarding to 4.2.2.1 works, but unbound forwarding to
dnsmasq which forwards to 4.2.2.1 does not work.  so dnsmasq is not
fully transparent when forwarding between a validating forwarder and a
validating recursive nameserver.
ugh, i meant "DNSSEC-conformant recursive nameserver" here, not
"validating recursive nameserver".  the level3 open recursives (4.2.2.X)
don't perform validation.

A quick query on the dnsmasq configuration in use here: is the
--domain-needed flag set in /etc/dnsmasq.conf? I think that's
causing the problem because the DS query for ".com" hits the filter.
There are already exceptions on this filter for SOA and NS queries,
the DNSSEC era  requires that DS queries are added to that list.

Assuming I've diagnosed this right, removing --domain-needed is a
quick and simple workaround.

from the man page:

   -D, --domain-needed
          Tells dnsmasq to never forward queries for plain names,
          without dots or domain parts, to upstream nameservers. If
          the name is not known from /etc/hosts or DHCP then a "not
          found" answer is returned.

um, i think i know what a "plain name, without dots or domain parts" is,
but dnsmasq is a DNS server and deals with wire-format domain names,
right?  does dnsmasq seriously respond with NXDOMAIN to queries for the
wire-format name "\x03com\x00" (presentation format: "com.") because it
has only a single label?  that is beyond broken.


Some implementations of gethostbyname, given the name "com" or "mycomputer" will attempt to look it up in the DNS with just such a query, thus wasting upstream bandwidth and leaking internal network information. It's sometimes useful to pre-empt that, so there's a configuration option. It's not the default behaviour. NXDOMAIN is wrong here, NODATA would be better, but historically dnsmasq was fielding queries from stub resolvers, so nobody every noticed the difference.

Cheers,

Simon.






--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Reply via email to