Bug#630637: Bug#629290: unbound: Forwarding doesn't work if the target nameserver is broken
Simon Kelley wrote: > Robert Edmonds wrote: > > i disagree. the existence of an option that pre-empts queries for > > one-label qnames (and the comment at the top of the example config file > > encouraging one to turn it on) harms interoperability. > > There should be a warning, certainly. What do you think about moving to > returning NODATA? I really don't want stuff existing downstream caching > the idea that the whole .com domain doesn't exist. well, NODATA is better than NXDOMAIN. > > i'd recommend deprecating and removing the domain-needed option > > altogether but if you're not going to do that i'd at least make the > > filtering logic conditional. from looking at the source it appears > > qtype=NS is exempted from the filter, maybe you could invert the logic > > and make it apply only to qtype=A and perhaps qtype=. > > > I'm tempted by the A/ only solution, the alternative is to add DS to > the list of RRtypes exempted. Any others I've not thought of? DNSKEY, SOA, TXT, MX, certainly others... -- Robert Edmonds edmo...@debian.org -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#630637: Bug#629290: unbound: Forwarding doesn't work if the target nameserver is broken
Robert Edmonds wrote: > Simon Kelley wrote: >> 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. > > hm, so? a heuristic based solely on the number of labels in the qname > is a rather blunt tool here. far better to fix the misconfigured client > than to guess at what the stub resolver might have meant. No argument, but sometimes easier to implement the fix in the DNS forwarder than to alter many clients which may be heterogeneous and/or not under the admin's control. Pragmatism. Dnsmasq supplies a tool which is useful, but not perfect. > >> 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. > > i disagree. the existence of an option that pre-empts queries for > one-label qnames (and the comment at the top of the example config file > encouraging one to turn it on) harms interoperability. There should be a warning, certainly. What do you think about moving to returning NODATA? I really don't want stuff existing downstream caching the idea that the whole .com domain doesn't exist. > > i'd recommend deprecating and removing the domain-needed option > altogether but if you're not going to do that i'd at least make the > filtering logic conditional. from looking at the source it appears > qtype=NS is exempted from the filter, maybe you could invert the logic > and make it apply only to qtype=A and perhaps qtype=. > I'm tempted by the A/ only solution, the alternative is to add DS to the list of RRtypes exempted. Any others I've not thought of? Cheers, Simon. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#630637: Bug#629290: unbound: Forwarding doesn't work if the target nameserver is broken
Simon Kelley wrote: > 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. hm, so? a heuristic based solely on the number of labels in the qname is a rather blunt tool here. far better to fix the misconfigured client than to guess at what the stub resolver might have meant. > 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. i disagree. the existence of an option that pre-empts queries for one-label qnames (and the comment at the top of the example config file encouraging one to turn it on) harms interoperability. i'd recommend deprecating and removing the domain-needed option altogether but if you're not going to do that i'd at least make the filtering logic conditional. from looking at the source it appears qtype=NS is exempted from the filter, maybe you could invert the logic and make it apply only to qtype=A and perhaps qtype=. -- Robert Edmonds edmo...@debian.org -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#630637: Bug#629290: unbound: Forwarding doesn't work if the target nameserver is broken
Robert Edmonds wrote: ok, now that i look in the dnsmasq debian changelog i see this option started defaulting to disabled in 2006. still... Probably best not to look at "filterwin2k" then. Not the finest hour. Simon. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#630637: Bug#629290: unbound: Forwarding doesn't work if the target nameserver is broken
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
Bug#630637: Bug#629290: unbound: Forwarding doesn't work if the target nameserver is broken
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. ok, now that i look in the dnsmasq debian changelog i see this option started defaulting to disabled in 2006. still... -- Robert Edmonds edmo...@debian.org -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#630637: Bug#629290: unbound: Forwarding doesn't work if the target nameserver is broken
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. -- Robert Edmonds edmo...@debian.org -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#630637: Bug#629290: unbound: Forwarding doesn't work if the target nameserver is broken
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. Cheers, Simon. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
