I got to work with the app owners today debugging this problem. One way to get the DNS server to return the list of root servers is to do a non-recursive (+norec) query for a non-existent domain. Turns out this particular app does non-recursive queries. The app itself does a single Windows system call for DNS, and then Windows does the rest (probably with the res_search() equivalent as Mark Andrews alluded to).
So, why would the DNS server return NXDomain for a non-recursive query? I think Kevin Darcy got this right with the negative caching. The app owners, as part of debugging, would use nslookup for their SRV records. Nslookup does recursion by default. BIND then caches the negative responses from the nslookup queries for max-ncache-ttl default of 3 hours. The app works fine if it gets only NXDomain or only NoError. If the first DNS server queried returns NXDomain, Windows appends the search suffix and tries that same DNS server again. This usually works. If the first DNS server queried returns NoError, Windows tries the other DNS servers listed. As long as they all return NoError, Windows will then append the search suffix and try the first DNS server again. However, if the secondary or tertiary returns NXDomain, Windows just gets confused, quits DNS queries and the app breaks. The app owners think this is a problem with Windows (2003 and 2008). The negative caching is just exacerbating the problem. > 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 > >> On 5/29/2014 2:40 PM, Jiann-Ming Su wrote: >> > What could cause BIND to respond with reply code 0x8083 (no such name) > vs 0 >> x8080 (no error)? >> > >> > I have an app doing srv queries without the domain name appended. One > time >> , server will respond with no such name (flags 0x8083) which causes the app > t >> o query again with domain name appended. Another time, the DNS server > respon >> ds with no error (flags 0x8080) which causes the app to query again without > t >> he domain suffix appended. >> > >> > I may very well be debugging an application problem, but I'm > curious as to >> why BIND would respond with different codes. Thanks for any insights. >> > >> > _______________________________________________ >> > Please visit https://lists.isc.org/mailman/listinfo/bind-users to > unsubscri >> be from this list >> > >> > bind-users mailing list >> > bind-users@lists.isc.org >> > https://lists.isc.org/mailman/listinfo/bind-users >> > >> > >> > >> > >> >> _______________________________________________ >> 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 > -- > Mark Andrews, ISC > 1 Seymour St., Dundas Valley, NSW 2117, Australia > PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org > > _______________________________________________ > 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 > _______________________________________________ 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
