DNS::hostByAddress can be slow #68

Closed
karlr42 opened this Issue Jan 18, 2013 · 5 comments

Comments

Projects
None yet
3 participants
Contributor

karlr42 commented Jan 18, 2013

I've found that for some domains, resolving takes on the order of 5 seconds in my environment. This is evident using HTTPSClientSession and I've put together a minimal test case here:

https://gist.github.com/4566844

From my testing it looks like the issue is IPv6 related and is down to the AI_ADDRCONFIG flag passed to the getaddrinfo system call by DNS::hostByAddress. If I remove that flag and recompile the library(I'm using 1.4.6 downloaded from the main site) and then try my test case, resolution takes the normal(<1 sec) amount of time. I have also replicated the problem and made a small test case using just C and directly calling getaddrinfo. : https://gist.github.com/4566462

My setup is:
Ubuntu 12.10 64-bit
Configured Poco(1.4.6) with --no-tests --no-samples --omit=Data/OBDC,Data/MySQL
My ifconfig is : https://gist.github.com/4566285 and the interface connected to the outside world is eth1.

I think the issue is down to the fact the domain in question has no AAAA records but my local machine has an assigned IPv6 address. So getaddrinfo, following the AI_ADDRCONFIG flag, makes a request an AAAA record, which timesout, and then makes a request for an A record, thus causing the delay. Or there is some other peculiarity with the DNS records for this site and others I've tried(myjoyonline.com, for example), I'm not sure.

So maybe this isn't necessarily a bug on your side, but I thought I would bring it to your attention anyway- this issue doesn't seem to affect any other application I use in this environment. I have patched Net::DNS::hostByAddress locally for now to remove the AI_ADDRCONFIG flag and my application(a proxy server making lots of DNS requests) is a lot faster now.

Owner

obiltschnig commented Jan 18, 2013

Interesting observation. I remember that I've put in AI_ADDRCONFIG for some specific reason, but I cannot remember what it was.
Will have to dig it out.

Günter

Günter Obiltschnig
Applied Informatics Software Engineering GmbH
A-9182 Maria Elend | Maria Elend 96/4 | www.appinf.com
P: +43 4253 32596 M: +43 676 5166737 F: +43 4253 32096

Company Registration: FN 276491 f | Landesgericht Klagenfurt
Managing Director: DI Günter Obiltschnig

On 18.01.2013, at 19:48, karlr42 wrote:

I've found that for some domains, resolving takes on the order of 5 seconds in my environment. This is evident using HTTPSClientSession and I've put together a minimal test case here:

https://gist.github.com/4566844

From my testing it looks like the issue is IPv6 related and is down to the AI_ADDRCONFIG flag passed to the getaddrinfo system call by DNS::hostByAddress. If I remove that flag and recompile the library(I'm using 1.4.6 downloaded from the main site) and then try my test case, resolution takes the normal(<1 sec) amount of time. I have also replicated the problem and made a small test case using just C and directly calling getaddrinfo. : https://gist.github.com/4566462

My setup is:
Ubuntu 12.10 64-bit
Configured Poco(1.4.6) with --no-tests --no-samples --omit=Data/OBDC,Data/MySQL
My ifconfig is : https://gist.github.com/4566285 and the interface connected to the outside world is eth1.

I think the issue is down to the fact the domain in question has no AAAA records but my local machine has an assigned IPv6 address. So getaddrinfo, following the AI_ADDRCONFIG flag, makes a request an AAAA record, which timesout, and then makes a request for an A record, thus causing the delay. Or there is some other peculiarity with the DNS records for this site and others I've tried(myjoyonline.com, for example), I'm not sure.

So maybe this isn't necessarily a bug on your side, but I thought I would bring it to your attention anyway- this issue doesn't seem to affect any other application I use in this environment. I have patched Net::DNS::hostByAddress locally for now to remove the AI_ADDRCONFIG flag and my application(a proxy server making lots of DNS requests) is a lot faster now.


Reply to this email directly or view it on GitHub.

Owner

aleks-f commented Jan 25, 2013

Maybe expose it in hostByName() and hostByAddress(), with default AI_CANONNAME | AI_ADDRCONFIG ?

On another note, FYI apparently something has changed in appinf DNS and test fails now. Not a big deal, just little bit annoying.

Owner

aleks-f commented Jan 25, 2013

apparently something has changed in appinf DNS and test fails now

There was 1 failure: 
 1: N7CppUnit10TestCallerI7DNSTestEE.testHostByName
    "he1.name() == "dnstest.appinf.com" || he1.name() == "aliastest.appinf.com""
    in "src/DNSTest.cpp", line 64
Owner

obiltschnig commented Jan 25, 2013

I fixed the DNS records for dnstest and aliastest and the test should work again soon (after the change propagates through).

Günter

Günter Obiltschnig
Applied Informatics Software Engineering GmbH
A-9182 Maria Elend | Maria Elend 96/4 | www.appinf.com
P: +43 4253 32596 M: +43 676 5166737 F: +43 4253 32096

Company Registration: FN 276491 f | Landesgericht Klagenfurt
Managing Director: DI Günter Obiltschnig

On 25.01.2013, at 06:43, Aleksandar Fabijanic wrote:

apparently something has changed in appinf DNS and test fails now

There was 1 failure:
1: N7CppUnit10TestCallerI7DNSTestEE.testHostByName
"he1.name() == "dnstest.appinf.com" || he1.name() == "aliastest.appinf.com""
in "src/DNSTest.cpp", line 64


Reply to this email directly or view it on GitHub.

aleks-f was assigned Feb 2, 2013

@aleks-f aleks-f added a commit that referenced this issue Mar 24, 2013

@aleks-f aleks-f GH #68: DNS::hostByAddress can be slow
GH #68: DNS::hostByAddress can be slow - added parameters in the
interface to pass hint flags to hostByAddress() and hostByName() calls
22b658a
Owner

aleks-f commented Mar 24, 2013

I could not reproduce this problem with my DNS, Windows 8, VS 2012. Flags can now be passed by user, if not explicitly passed, defaulting to AI_CANONNAME | AI_ADDRCONFIG. Will be in 1.5.2

aleks-f closed this Mar 24, 2013

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