Looking through the traces of the NXDomain vs NoError responses. The NoError response includes the list of the Internet root servers. This would definitely be a valid response for a "." query. I wonder if I've run into a bug with this particular version of BIND where it ignores or changes the actual query with a "." lookup. Hence the NoError response with the full list of root servers.
> On Thursday, May 29, 2014 6:53 PM, Jiann-Ming Su <su_...@yahoo.com> wrote: > > > > > > > >> On Thursday, May 29, 2014 6:32 PM, Mark Andrews <ma...@isc.org> > wrote: >> > >> In message <53879683.2080...@chrysler.com>, Kevin Darcy writes: >>> Why the different RCODES? See RFC 2308. Short version: the >> "NODATA" >>> response occurs when the QNAME exists, but no records match QTYPE. It >>> will also occur if the QNAME is merely a "branch" to > something >> further >>> down in the hierarchy (a so-called "empty non-terminal"), > and >> owns no >>> records of its own. >>> >>> I'm not sure why NODATA would inhibit search-suffixing, but I just > >>> confirmed on a Linux platform that it does. Weird. >>> >>> - Kevin >> >> Actually is it perfectly logical and fixes a long standing security >> bug. A name should refer to a single node in the DNS not multiple >> nodes depending upon the query type. A search should always end >> on the same node independent of query type. >> >> What is broken is putting a bare SRV prefix into res_search. >> res_search was not designed for that type of searching and doing >> so introduces the sort of security errors talked about in RFC 1535. >> > > Mark, > > Thanks again for your insights. The troublesome app is the same one you > responded to me about back in February when I was asking about recursion and > auth responses. While it does appear the app may not be following best > practices in its DNS queries, do you have insights as to why BIND would > respond > NoError on one query and NXDomain on another? > > I'm reading through RFC 1535 now and will forward that along to the > application owners. > _______________________________________________ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
