Re: [Fed-Talk] nslookup/host and traceroute?
Re: [Fed-Talk] nslookup/host and traceroute?
- Subject: Re: [Fed-Talk] nslookup/host and traceroute?
- From: "Traynor, Paul I" <email@hidden>
- Date: Wed, 19 Nov 2014 18:18:43 +0000
- Thread-topic: [Fed-Talk] nslookup/host and traceroute?
So... simply put, NSLOOKUP always explicitly queries a DNS server (either the default assigned in TCPIP, or one specified on the command line), ignoring any defined order of host lookup defined for the OS. Other commands follow the OS-order of lookups
-----Original Message-----
From: fed-talk-bounces+paul.i.traynor=email@hidden [mailto:fed-talk-bounces+paul.i.traynor=email@hidden] On Behalf Of Levine, Jason (NIH/NCI) [E]
Sent: Wednesday, November 19, 2014 12:00 PM
To: Campbell, Paul Madison (ARC-TH)[ASRC RESEARCH & TECHNOLOGY SOLUTIONS]
Cc: email@hidden
Subject: Re: [Fed-Talk] nslookup/host and traceroute?
So operating under two presumptions, I think I’m able to demonstrate that traceroute is NOT susceptible to the same alternate DNS resolving as nslookup and host. Those presumptions:
1. I’ve always understood that on OS X, ping uses the underlying OS DNS resolution mechanisms (specifically, the system getaddrinfo() call, which calls into the OS-level name resolution process).
2. I’ve always noticed that changes to /etc/hosts aren’t reflected when using tools like nslookup and host but ARE reflected by ping, so that’s my test for the two different behaviors.
With that, I added a host to my /etc/hosts file (127.0.1.1 jasonhost) and then did:
1. host jasonhost —> host not found
2. nslookup jasonhost —> servfail, not found 3. ping jasonhost —> successfully resolves it to 127.0.1.1 and tries to ping it 4. traceroute jasonhost —> successfully resolves it to 127.0.1.1 and tries to traceroute to it
So with that, I believe that the man page is accurate in NOT including the same notice.
Jason
Jason Levine, email@hidden<mailto:email@hidden>
NCI CCR Acting Associate Director for IT and Clinical Informatics NCI CCR Pediatric Oncology Branch
(240) 276-5557
On Nov 19, 2014, at 12:31 PM, Campbell, Paul Madison (ARC-TH)[ASRC RESEARCH & TECHNOLOGY SOLUTIONS] <email@hidden<mailto:email@hidden>> wrote:
Hey All,
I am tracking down a VPN issue and I believe traceroute may be lying to me. The man pages for nslookup and host both say this:
Mac OS X NOTICE
The nslookup command does not use the host name and address resolution
or the DNS query routing mechanisms used by other processes running on
Mac OS X. The results of name or address queries printed by nslookup
may differ from those found by other processes that use the Mac OS X
native name and address resolution mechanisms. The results of DNS
queries may also differ from queries that use the Mac OS X DNS routing
library.
The man page for traceroute doesn’t say that, but it is from the same generation of tools and it wouldn’t be the first time a man page omitted something. Anyone know if traceroute is susceptible to the same alternate DNS resolving and then tracing?
The bonus question is: if that is the case, how can you run a traceroute using the actual system resolver that’s used by Safari?
Paul
--
Paul Campbell | Senior Macintosh System Administrator ASRC Federal Research and Technology Solutions NASA Ames Research Center Moffett Field, CA 94035 email@hidden<mailto:email@hidden>
W: 650.604.4014 | F: 650.604.3323
ASRC Federal | Customer-Focused. Operationally Excellent.
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Fed-talk mailing list (email@hidden<mailto:email@hidden>)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Fed-talk mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Fed-talk mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden