02-23-2020 10:10 AM
It seems that login_duo and pam_duo don’t respect our resolv.conf settings - at least not until they try some other methods which time-out.
Our firewalls are not open for external DNS resolvers.
/usr/sbin/login_duo
seems to attempt to reach external resolvers before eventually using our internal DNS after 40 seconds.
pam_duo never succeeds at all with external DNS denied.
To test,
(1) if firewall denies external DNS, time taken for linux 2FA is around 40 seconds
(2) If I punch a hole in the firewall, both start working and the response time 300ms or so.
(3) if I add ■■■■■■■■■■■■■■■■■■■■■■■■ to the hosts file, with external DNS blocked, the time taken is also 40 seconds
Our internal DNS resolves duosecurity.com optimally - typically 1 or 2 ms
Here - with ports opened for external DNS:
[campbell@testhost]~% time sudo /usr/sbin/login_duo -d -f fakeuser
Please enroll at https://■■■■■■■■■■■■■■■■■■■■■■■■■/portal?xxxxxxxx
[4] Aborted Duo login for 'fakeuser': User enrollment required
sudo /usr/sbin/login_duo -d -f fakeuser 0.02s user 0.03s system 14% cpu **0.378 total**
Now with ports blocked for external DNS:
[campbell@testhost]~% time sudo /usr/sbin/login_duo -d -f fakeuser
Please enroll at https://■■■■■■■■■■■■■■■■■■■■■■■■■/portal?xxxxxxxx
[4] Aborted Duo login for 'fakeuser': User enrollment required
sudo /usr/sbin/login_duo -d -f fakeuser 0.02s user 0.05s system 0% cpu **40.505 total**
Note that the https requests to ■■■■■■■■■■■■■■■■■■■■■■■■ are proxied as well - but we don’t see any DNS-over-HTTPS type requests leaving. So it’s purely a native DNS lookup issue.
Solved! Go to Solution.
03-03-2020 01:55 PM
Hi,
My apologies - there is no problem with duo at all. There was an error in the resolver config.
Sorry for wasting your time.
Campbell
03-02-2020 12:31 PM
Hi @campbell,
Thanks for reaching out with your issue. We spent some time looking into this today and have a couple things we’d like you to try out for us.
First, some background:
Duo Unix uses a pretty standard set of C libraries in order to resolve a hostname. If you’re curious you can look at the code here: Github Snippet
On our end this is doing very little more than passing the responsibility onto the OS to figure out what the hostname resolves to. Because of this, we want to have you run a couple tests that will help validate whether the issue lies in the Duo Unix code or with your OS / network configuration.
Test 1:
Resolve with dig.
dig +short <api_host_from_config_goes_here>
Is this command also slow? Does it work at all?
Test 2:
Run using the C library we are using in Duo Unix. Here’s a small snippet of code that you can use to try to reproduce.
#include <sys/types.h>
#include <sys/socket.h>
#include <sys/time.h>
#include <arpa/inet.h>
#include <netdb.h>
#include <poll.h>
#include <signal.h>
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <unistd.h>
#include <fcntl.h>
int main(int argc, char * argv[]) {
if( argc != 2 ) {
printf("Did you provide a hostname?\n");
return 1;
}
struct addrinfo *res = NULL;
struct addrinfo *cur_res = NULL;
struct addrinfo hints;
int error;
memset(&hints, 0, sizeof(hints));
hints.ai_family = PF_UNSPEC;
hints.ai_socktype = SOCK_STREAM;
error = getaddrinfo(
argv[1],
"443",
&hints,
&res
);
if (error != 0) {
printf("error: %s\n", gai_strerror(error));
}
else {
char ipv4[INET_ADDRSTRLEN];
struct sockaddr_in *addr4;
for (; res != NULL; res = res->ai_next) {
if (res->ai_addr->sa_family == AF_INET) {
addr4 = (struct sockaddr_in *) res->ai_addr;
inet_ntop(AF_INET, &addr4->sin_addr, ipv4, INET_ADDRSTRLEN);
printf("Resolved %s to IP: %s\n", argv[1], ipv4);
}
}
}
}
gcc resolution_test.c -o a.out
./a.out <api_host_we_are_testing_here>
What is the output for this command? Did we fail to resolve? Was it slow?
If neither of the steps above are very enlightening just be prepared that we’ll probably move this into an official support ticket so that we can get logs, config files, etc from you.
Let us know if you have any other questions,
Xander
03-03-2020 01:55 PM
Hi,
My apologies - there is no problem with duo at all. There was an error in the resolver config.
Sorry for wasting your time.
Campbell
03-04-2020 05:36 AM
Glad to hear you were able to get it resolved!
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide