Ubuntu – why dig to router is on DNS 53 port

dnsubuntu-12.10

192.168.1.1 is my router NetGear. It has 8.8.8.8 and 8.8.4.4 set as DNS.
from windows:

nslookup google.com 192.168.1.1  // works OK

from ubuntu:

me@ubuntu:/etc/mail# dig @192.168.1.1 google.com +tcp
;; Connection to 192.168.1.1#53(192.168.1.1) for google.com failed: connection refused.

I think this shouldn't go on port 53, right? If yes, what can be the reason to dig translating my DNS query to asking NetGear on wrong port?

I cannot query 8.8.8.8:

dig @8.8.8.8 google.com

; <<>> DiG 9.9.2-P2 <<>> @8.8.8.8 google.com
; (1 server found)
;; global options: +cmd
;; connection timed out; no servers could be reached
root@ubuntuamd:/etc/mail# dig @8.8.8.8 google.com +tcp

however can with +tcp:

dig @8.8.8.8 google.com +tcp

; <<>> DiG 9.9.2-P2 <<>> @8.8.8.8 google.com +tcp
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 59432
;; flags: qr rd ra; QUERY: 1, ANSWER: 16, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512
;; QUESTION SECTION:
;google.com.            IN  A

;; ANSWER SECTION:
google.com.     88  IN  A   46.28.247.93
google.com.     88  IN  A   46.28.247.119
//etc

;; Query time: 33 msec
;; SERVER: 8.8.8.8#53(8.8.8.8)
;; WHEN: Wed May  8 00:20:06 2013
;; MSG SIZE  rcvd: 295

at the end this: here 127.0.1.1 (dnsmasq right?) responds:

 dig  google.com

; <<>> DiG 9.9.2-P2 <<>> google.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 34747
;; flags: qr rd ra; QUERY: 1, ANSWER: 16, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;google.com.            IN  A

;; ANSWER SECTION:
google.com.     300 IN  A   208.117.224.29
//etc

;; Query time: 3 msec
;; SERVER: 127.0.1.1#53(127.0.1.1)
;; WHEN: Wed May  8 00:04:44 2013
;; MSG SIZE  rcvd: 284

nm tool:

me@ubuntu:/etc/mail# nm-tool | tail -n 8   IPv4 Settings:
    Address:         192.168.1.3
    Prefix:          24 (255.255.255.0)
    Gateway:         192.168.1.1

    DNS:             192.168.1.1

Best Answer

Port 53 is indeed the port that a DNS server listens on for requests.

However, by default it's UDP port 53, and TCP port 53 is not often used.

Your dig and nslookup commands use UDP by default, but in your dig command you specified to use TCP with +tcp, and since the router is only listening on UDP, the request fails.

To resolve the issue, query with UDP by removing +tcp from your dig command.

Related Solutions

Windows using the DNS suffix search list on all lookups, even valid FQDNs. How to stop this

Well, I'm no expert, but here's what I found:

This registry entry works for both Windows XP and Windows Vista

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\Software\Policies\Microsoft\Windows NT\DNSClient]
"AppendToMultiLabelName"=dword:00000000

HKLM\Software\Policies\Microsoft\Windows NT\DNSClient\AppendToMultiLabelName
Type = DWORD

Data:

0 (Do not Append Suffix)
1 (Append suffix)

If the registry entry is not present, the default in Windows XP is 1, and 0 in Windows Vista.

Note: This registry changes and its effect apply only to the ping command, they do not apply to the nslookup tool. This is because nslookup contains its own DNS resolver and does not rely on the resolver built into the operating system (DNS Client). The DNS (multi-label) query packets sent by the nslookup tool will append the domains listed in the suffix search order irrespective of the registry key settings mentioned here.

Reference: http://blogs.technet.com/networking/archive/2009/04/16/dns-client-name-resolution-behavior-in-windows-vista-vs-windows-xp.aspx

DNS dig +tcp OK, udp NO

When you do dig @8.8.8.8 wp.pl a request is sent to Google's nameserver. Google's nameserver is not authoritative for the domain wp.pl.(whatever you may have set in your search domains); (The last bit could be a source of trouble; do dig @8.8.8.8 wp.pl. in the future to stop additional searches.), and if it doesn't have a cached record to give you, it will tell you what nameserver is authoritative for that domain; A second request will then be sent to the server Google gives you...

However... For nameservers, you might want to use the nameservers DHCP assigns you; I doubt both 192.168.1.1 and 0.1 were given to you. The lone DNS server I get from DHCP corresponds to my DSL modem/router's gateway, which means having only one resolver in my local configuration is perfect: if I can't reach my gateway, or if my gateway can't talk to whatever DNS servers it gets from its provisioning DHCP server (in which I have no visibility into), then it's unlikely any manual additions I add will provide any additional utility, but likely that it will decrease the performance of DNS queries, and thus, my perceived responsiveness of my Internet activities.

When I use the following tcpdump statement to look at DHCP data:

mini-nevie:~ root# tcpdump -i en1 -nv udp port 67 and udp port 68

the last packet I get from the DCHP server, an ACK(nowledgement) packet contains the configuration parameters for my host:

13:45:15.065227 IP (tos 0x71,ECT(1), ttl 64, id 42740, offset 0, flags [none], proto UDP (17), length 576)
    192.168.2.1.67 > 192.168.2.12.68: BOOTP/DHCP, Reply, length 548, xid 0x3392bc07, Flags [none]
      Your-IP 192.168.2.12
      Client-Ethernet-Address 68:a8:6d:58:5b:f3
      Vendor-rfc1048 Extensions
        Magic Cookie 0x63825363
        DHCP-Message Option 53, length 1: ACK
        Subnet-Mask Option 1, length 4: 255.255.255.0
        Lease-Time Option 51, length 4: 259200
        Default-Gateway Option 3, length 4: 192.168.2.1
        Domain-Name-Server Option 6, length 8: 192.168.2.1,192.168.2.1
        Domain-Name Option 15, length 20: "no-domain-set.aliant"
        Server-ID Option 54, length 4: 192.168.2.1
        Hostname Option 12, length 10: "mini-nevie"

In the "Domain-Name-Server Option 6" field, the DHCP server provides me with 2 IP addresses; in this case, they're identical. They happen to match my gateway, 192.168.2.1. While I've looked all through my DSLmodem's config pages, I cannot see what servers it's using. In my previous service, I did PPOE right on my Mac, and IIRC, the two servers were local resolvers in my province.

My advice is to use the nameserver(s) that are provided to you via DHCP.

Best Answer

Related Solutions

Windows using the DNS suffix search list on all lookups, even valid FQDNs. How to stop this

DNS dig +tcp OK, udp NO

Related Question