Bug 136013

Summary: [resolver] Resolver wrong diagnostics
Product: Base System Reporter: Libor Forst <forst>
Component: kernAssignee: freebsd-bugs (Nobody) <bugs>
Status: Open ---    
Severity: Affects Only Me    
Priority: Normal    
Version: 7.1-RELEASE   
Hardware: Any   
OS: Any   

Description Libor Forst 2009-06-24 20:30:04 UTC
	The res_searchN() function makes a decision about loop continuation
    after returning from the res_querydomainN() call based on two pieces
    of information: res->res_h_errno and hp->rcode. However, if the query
    was made for both A and AAAA RRs, the hp address points just to the
    first res_target structure, but the res->res_h_errno will be set by
    the result of the second query. Thus, res->res_h_errno and hp->rcode
    can be inconsistent.

Fix: 

1. Both pieces of information (h_errno and rcode) must be consistent.
       I.e. the rcode should be saved e.g. into res_state structure (as
       a new res_rcode member?).
    2. The question is, whether the result (h_errno+rcode) should really
       be defined as "last query result". Why the responses NXDomain (A)
       and ServFail (AAAA) bring a different behavior than the case of
       ServFail (A) and NXDomain (AAAA)? Maybe the final result selection
       should not follow "the last" response but "the most relevant" one.
How-To-Repeat: 	At least two-domains search-list, query for a name without dots,
    the first (A) response should be NXDomain, the second (AAAA) should
    be ServFail. In this situation, the first res_querydomainN() call
    (for the NAME.DOMAIN1) returns with res->res_h_errno == TRY_AGAIN
    (according to the second query) but hp->rcode == NXDomain (because
    hp reflects the first res_target). As such, the second domain will
    not be tried (in spite of that in all three other combinations of
    results, the domain is tried).
Comment 1 Eitan Adler freebsd_committer freebsd_triage 2017-12-31 07:59:14 UTC
For bugs matching the following criteria:

Status: In Progress Changed: (is less than) 2014-06-01

Reset to default assignee and clear in-progress tags.

Mail being skipped