Bug 640944 - wrong error message
Summary: wrong error message
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: c-ares
Version: 6.1
Hardware: All
OS: Linux
low
medium
Target Milestone: rc
: ---
Assignee: Jakub Hrozek
QA Contact: Petr Sklenar
URL:
Whiteboard:
Depends On:
Blocks: 750334
TreeView+ depends on / blocked
 
Reported: 2010-10-07 10:00 UTC by Karel Volný
Modified: 2012-06-20 14:27 UTC (History)
3 users (show)

Fixed In Version: c-ares-1.7.0-6.el6
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2012-06-20 14:27:40 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)
A fixed version of the test program (4.48 KB, text/x-csrc)
2011-08-10 14:43 UTC, Jakub Hrozek
no flags Details


Links
System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2012:0922 0 normal SHIPPED_LIVE c-ares bug fix update 2012-06-19 20:46:10 UTC

Description Karel Volný 2010-10-07 10:00:28 UTC
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)

Comment 2 Karel Volný 2010-10-07 10:13:02 UTC
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

Comment 3 RHEL Program Management 2011-01-07 15:42:12 UTC
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.

Comment 5 Jakub Hrozek 2011-06-13 13:19:21 UTC
> 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

Comment 6 Jakub Hrozek 2011-06-13 13:21:37 UTC
(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.

Comment 7 Karel Volný 2011-06-28 14:23:11 UTC
(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

Comment 8 RHEL Program Management 2011-07-06 00:25:54 UTC
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.

Comment 9 Jakub Hrozek 2011-08-10 14:42:19 UTC
(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!

Comment 10 Jakub Hrozek 2011-08-10 14:43:29 UTC
Created attachment 517634 [details]
A fixed version of the test program

Comment 15 errata-xmlrpc 2012-06-20 14:27:40 UTC
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


Note You need to log in before you can comment on or make changes to this bug.