Description of problem: If a domain is not found, c-ares reports "error from ares: DNS server returned answer with no data". This message is misleading, it should have been 'Domain name not found' as reported on another system. Version-Release number of selected component (if applicable): c-ares-1.7.0-5.el6.x86_64 How reproducible: alway Steps to Reproduce: 1. try to resolve nonexistant domain with c-ares Actual results: error from ares: DNS server returned answer with no data Expected results: error from ares: Domain name not found Additional info: tcpdump capture is like this: 11:43:49.732858 IP6 localhost6.localdomain6.33732 > localhost6.localdomain6.domain: 10177+ AAAA? nonsense-DzeYVAxm. (35) 11:43:50.737978 IP6 localhost6.localdomain6.domain > localhost6.localdomain6.33732: 10177 NXDomain 0/1/0 (110)
now I have found another example ... c-ares says: error from ares: Timeout while contacting DNS servers but from tcpdump output: 06:04:34.431851 IP6 localhost6.localdomain6.53027 > localhost6.localdomain6.domain: 23482+ AAAA? nonsense-rqCviUv6.... (59) 06:04:43.816300 IP6 localhost6.localdomain6.53027 > localhost6.localdomain6.domain: 23482+ AAAA? nonsense-rqCviUv6..... (59) 06:04:56.327858 IP6 localhost6.localdomain6.53027 > localhost6.localdomain6.domain: 23482+ AAAA? nonsense-.... (59) 06:04:59.427666 IP6 localhost6.localdomain6.domain > localhost6.localdomain6.53027: 23482 ServFail 0/0/0 (59) - there is ServFail response, not timeout
This request was evaluated by Red Hat Product Management for inclusion in the current release of Red Hat Enterprise Linux. Because the affected component is not scheduled to be updated in the current release, Red Hat is unfortunately unable to address this request at this time. Red Hat invites you to ask your support representative to propose this request, if appropriate and relevant, in the next release of Red Hat Enterprise Linux. If you would like it considered as an exception in the current release, please ask your support representative.
> Steps to Reproduce: > 1. try to resolve nonexistant domain with c-ares > > Actual results: > error from ares: DNS server returned answer with no data > > Expected results: > error from ares: Domain name not found > > Additional info: > tcpdump capture is like this: > > 11:43:49.732858 IP6 localhost6.localdomain6.33732 > > localhost6.localdomain6.domain: 10177+ AAAA? nonsense-DzeYVAxm. (35) > 11:43:50.737978 IP6 localhost6.localdomain6.domain > > localhost6.localdomain6.33732: 10177 NXDomain 0/1/0 (110) The root cause is that ares returns ARES_ENOTFOUND when there is no answer at all and ARES_ENODATA when a DNS lookup returns, but with no relevant data (NXDomain). I agree that ENOTFOUND might me more appropriate, but upstream is reluctant[1] to change the code and prefers to amend the ares_gethostbyname() documentation so that it lists ARES_ENODATA as an expected return code. I don't think we should carry a distribution patch for this issue (other than fixing the man pages, too) and diverge too much from upstream. Clients can check for ENODATA return code easily (we do that in SSSD already with no problems). [1] http://c-ares.haxx.se/mail/c-ares-archive-2011-06/0013.shtml
(In reply to comment #2) > now I have found another example ... > > c-ares says: > > error from ares: Timeout while contacting DNS servers > > but from tcpdump output: > > 06:04:34.431851 IP6 localhost6.localdomain6.53027 > > localhost6.localdomain6.domain: 23482+ AAAA? nonsense-rqCviUv6.... (59) > 06:04:43.816300 IP6 localhost6.localdomain6.53027 > > localhost6.localdomain6.domain: 23482+ AAAA? nonsense-rqCviUv6..... (59) > 06:04:56.327858 IP6 localhost6.localdomain6.53027 > > localhost6.localdomain6.domain: 23482+ AAAA? nonsense-.... (59) > 06:04:59.427666 IP6 localhost6.localdomain6.domain > > localhost6.localdomain6.53027: 23482 ServFail 0/0/0 (59) > > - there is ServFail response, not timeout Can you be more specific about your environment? I'd like to reproduce this issue to see if there is a bug.
(In reply to comment #6) > (In reply to comment #2) > > now I have found another example ... > > > > c-ares says: > > > > error from ares: Timeout while contacting DNS servers > > > > but from tcpdump output: > > > > 06:04:34.431851 IP6 localhost6.localdomain6.53027 > > > localhost6.localdomain6.domain: 23482+ AAAA? nonsense-rqCviUv6.... (59) > > 06:04:43.816300 IP6 localhost6.localdomain6.53027 > > > localhost6.localdomain6.domain: 23482+ AAAA? nonsense-rqCviUv6..... (59) > > 06:04:56.327858 IP6 localhost6.localdomain6.53027 > > > localhost6.localdomain6.domain: 23482+ AAAA? nonsense-.... (59) > > 06:04:59.427666 IP6 localhost6.localdomain6.domain > > > localhost6.localdomain6.53027: 23482 ServFail 0/0/0 (59) > > > > - there is ServFail response, not timeout > > Can you be more specific about your environment? I'd like to reproduce this > issue to see if there is a bug. this is standard Beaker setup ... just run the test like: bkr workflow-simple --family=RedHatEnterpriseLinux6 --task=/CoreOS/c-ares/Regression/bz560116-IPv6-in-resolvconf I've found that the setup done by the test is insufficient for BIND to behave as intended, so ServFail is appropriate in this environment, however, you can see that c-ares gets the reply, thus the "timeout" message is not appropriate
(In reply to comment #7) > (In reply to comment #6) > > (In reply to comment #2) > > > now I have found another example ... > > > > > > c-ares says: > > > > > > error from ares: Timeout while contacting DNS servers > > > > > > but from tcpdump output: > > > > > > 06:04:34.431851 IP6 localhost6.localdomain6.53027 > > > > localhost6.localdomain6.domain: 23482+ AAAA? nonsense-rqCviUv6.... (59) > > > 06:04:43.816300 IP6 localhost6.localdomain6.53027 > > > > localhost6.localdomain6.domain: 23482+ AAAA? nonsense-rqCviUv6..... (59) > > > 06:04:56.327858 IP6 localhost6.localdomain6.53027 > > > > localhost6.localdomain6.domain: 23482+ AAAA? nonsense-.... (59) > > > 06:04:59.427666 IP6 localhost6.localdomain6.domain > > > > localhost6.localdomain6.53027: 23482 ServFail 0/0/0 (59) > > > > > > - there is ServFail response, not timeout > > > > Can you be more specific about your environment? I'd like to reproduce this > > issue to see if there is a bug. > > this is standard Beaker setup ... just run the test like: > > bkr workflow-simple --family=RedHatEnterpriseLinux6 > --task=/CoreOS/c-ares/Regression/bz560116-IPv6-in-resolvconf > > I've found that the setup done by the test is insufficient for BIND to behave > as intended, so ServFail is appropriate in this environment, however, you can > see that c-ares gets the reply, thus the "timeout" message is not appropriate Karel, I was playing with different timeout options today and realized why the test was failing - the test C program I gave you was missing one option to treat SRVFAIL responses as dig does. I'm attaching a fixed version. Can you commit it to the CVS test repository? However, to test NXDomain response, you should also amend your test a little. I would suggest creating a dummy zone (forward is enough) and 1) testing that a known hostname from that domain resolves fine 2) testing that an unknown hostname yields NXDomain. The bottom line is that the only real bug is the manpage one. Thank you for reporting it!
Created attachment 517634 [details] A fixed version of the test program
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. http://rhn.redhat.com/errata/RHBA-2012-0922.html