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=AAAA. > I'm tempted by the A/AAAA 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
