[TriLUG] Reverse DNS lookup for some local devices is very slow.

[Aaron Joyner]

On Wed, Sep 19, 2012 at 1:12 PM, Chris Merrill <chris at webperformance.com> wrote:
> On 9/19/2012 11:49 AM, Aaron Joyner wrote:
>> What's your testing methodology?  Are you using nslookup / host / dig
>> / ping / something else?
>
> Our software is Java-based running on Windows7, so the lookup happens through the JVM and Windows
> network stack.  If I add an entry for the device in question to the windows hosts file, the lookup
> in our software is instantaneous, as we would expect.
>
> Running nslookup from Windows responds instantaneously with:
>> C:\Users\Chris>nslookup 10.1.1.191
>> Server:  drusilla.webperformance.com
>> Address:  10.1.1.1
>>
>> *** drusilla.webperformance.com can't find 10.1.1.191: Non-existent domain
>
> Our Linux boxes also respond instantly to host, nslookup, ping and dig:
>> [build at dev1 build]$ host 10.1.1.191
>> Host 191.1.1.10.in-addr.arpa not found: 3(NXDOMAIN)
>> [build at dev1 build]$ nslookup 10.1.1.191
>> Server:         10.1.1.1
>> Address:        10.1.1.1#53
>>
>> ** server can't find 191.1.1.10.in-addr.arpa: NXDOMAIN
>>
>> [build at dev1 build]$ ping 10.1.1.191
>> PING 10.1.1.191 (10.1.1.191) 56(84) bytes of data.
>> 64 bytes from 10.1.1.191: icmp_seq=0 ttl=64 time=95.8 ms
>> 64 bytes from 10.1.1.191: icmp_seq=1 ttl=64 time=86.1 ms
>>
>> --- 10.1.1.191 ping statistics ---
>> 2 packets transmitted, 2 received, 0% packet loss, time 1014ms
>> rtt min/avg/max/mdev = 86.110/90.972/95.834/4.862 ms, pipe 2
>> [build at dev1 build]$ dig 10.1.1.191
>>
>> ; <<>> DiG 9.2.4 <<>> 10.1.1.191
>> ;; global options:  printcmd
>> ;; Got answer:
>> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 19573
>> ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0
>>
>> ;; QUESTION SECTION:
>> ;10.1.1.191.                    IN      A
>>
>> ;; ANSWER SECTION:
>> 10.1.1.191.             0       IN      A       10.1.1.191
>>
>> ;; Query time: 3 msec
>> ;; SERVER: 10.1.1.1#53(10.1.1.1)
>> ;; WHEN: Wed Sep 19 12:53:26 2012
>> ;; MSG SIZE  rcvd: 44
>>
>> [build at dev1 build]$
>
> Lookups of my droid, however, return a proper name association:
>> [build at dev1 build]$ host 10.1.1.109
>> 109.1.1.10.in-addr.arpa domain name pointer android-a6423e93xxxxxxxx.webperforma
>> nce.com.
>> [build at dev1 build]$ nslookup 10.1.1.109
>> Server:         10.1.1.1
>> Address:        10.1.1.1#53
>>
>> 109.1.1.10.in-addr.arpa name = android-a6423e93xxxxxxxx.webperformance.com.
>
> Perhaps the problem is that the local DNS doesn't have a name for the device - so the delay comes
> when the lookup falls to an external DNS?  If that is the case, then I guess the question changes to


Your test query with dig isn't a valid one.  You should try this
command instead $(dig -x 10.1.1.109).  The -x tells dig to convert
10.1.1.109 into the correct reverse-name (109.1.1.10.in-addr.arpa).
Try querying your nameserver for that name, and see if you get an
authoritative response (eg. if the line that says "flags:" contains
"aa").

In particular, I'd be interested in seeing the result of these two
commands on the linux box:

$ time dig +norec -x 10.1.1.109 @<your DNS server>
vs
$ time dig -x 10.1.1.109 @<your DNS server>


> "Why don't these (IOS/OSX) devices get names on our network?".

As to your follow-on question, it would depend on what's doing the
dynamic DNS registrations.  If it's an artifact of Windows, which (I
believe?) will attempt to register itself with the DNS server, that
might explain why the OsX/iOS clients don't get the registrations.
Most sensible operating systems will not try (because most sensible
DNS servers wouldn't accept such an unauthenticated registration).
I'd be surprised if Android does that by default.  Thus, it's more
sensible that it's probably a feature of dnsmasq, which I know
basically nothing about.  If you were doing it with the ISC DHCP
server and BIND, I might could help.  :)

Aaron S. Joyner