Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

cares would not use the second dns when the first dns return F.ROOT-SERVER.NET #226

Closed
llluiop opened this issue Oct 10, 2018 · 5 comments
Closed

Comments

@llluiop
Copy link

llluiop commented Oct 10, 2018

I have two dns server set, the first is 10.201.128.1, second is 8.8.8.8, the first dnsserver just return top root server see wireshark:
2
1

in this situation, i can get the right address and cares would not use the second dns to resolving, i have debug the source code in 1.14,it did so.

can you fix the issue please.

@bradh352
Copy link
Member

  1. Is this a regression from a prior c-ares version? If so, what version did it work correctly on and what version are you testing on (e.g. official 1.14.0 release, git master, etc)?
  2. Does this work as you'd expect with some other DNS resolver? If so, which one?

@llluiop
Copy link
Author

llluiop commented Oct 11, 2018

1.it is not a regression , i have tested on 1.14, 1.13 and master
2.it would work when i use libcurl default dns resolver, see below, you can see it would use the second dns server:
3

3.you can simulate the situation by adding this code in ares_parse_a_reply.c:
int ares_parse_a_reply(const unsigned char *abuf, int alen, struct hostent **host, struct ares_addrttl *addrttls, int *naddrttls) { char* a = abuf; a[7] = 0; //set Answer RRs to 0 unsigned int qdcount, ancount;

it will set "Answer RRs" to 0, then you can see this issue

@llluiop
Copy link
Author

llluiop commented Oct 15, 2018

@bradh352 hi,can you help me with this issue ,thanks a lot

@bradh352
Copy link
Member

Is this still present? I'm pretty sure based on the description of this issue, it was recently resolved. c-ares would previously stop on ARES_ENODATA on search, but now will continue. Its possible there is another area that needs a bypass however.

@bradh352
Copy link
Member

closing due to lack of reply, assuming bug is fixed

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants