Linux - NetworkingThis forum is for any issue related to networks or networking.
Routing, network cards, OSI, etc. Anything is fair game.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
For some reason, I'm having really strange problems trying to do lookups on the main one. If I do:
host google.com 204.255.24.254
it times out. If I force it to use tcp with the -u option, it works fine. Also all queries on the secondary server (204.255.24.251) work fine using both TCP and UDP.
Also, I have OSX on one of my computers, and I can't figure out how to tell if it's using TCP or UDP (it doesn't say in the verbose output like the linux one does, but it does work on both DNS servers without forcing TCP, but it could be choosing TCP automatically).
What I don't get is that, since TCP uses UDP for transport, how can the TCP connection work but the UDP one not work?
you do not mention your distro so pls do if you need to reply.
In a Mandriva I have
/etc/resolv.conf which you can view and its contents must be of the form
nameserver (your primary dns eg 204.255.24.254)
nameserver 204.255.24.251
2) I also have a /etc/resolvconf folder which has another resolv.conf file that should duplicate your primary and secondary dns numbers...plus has some other files including (for me) and file called eth0 with the same numbers as I use a modem/router
3) but you can also have a look at /etc/sysconfig/network-scripts
4) also I tweaked my ethernet card setting by using a /etc/rc.local addition (using root powers to edit) by adding this line
/sbin/ifconfig eth0 mtu 1492.....where 1492 is the number recommended by my ISP....yours may differ
in a terminal type su to get into root mode and type
ifconfig.....to see what your current mtu is.....plus you may notice transmission errors or receiving errors....ideally you should have none
5) another way of looking at your stats without root powers is to open a terminal and type
netstat -i (I for interfaces)
anyhow check them them out if you have time and report if you see errors please
I just tested this and I am able to resolve google.com off those 2 name severs using UDP.
Quote:
What I don't get is that, since TCP uses UDP for transport, how can the TCP connection work but the UDP one not work?
I think you are confused here. UDP, and TCP are separate protocols, and neither one relies on the other.
With DNS there are only 2 times TCP is generally used. The first is zone transfers, and the second is if the packet size of the response is greater than 512 bytes.
Other than that UDP is generally used for resolution, but TCP can also be used.
You can resolve google.com using TCP on 204.255.24.254, so that shows that recursion is working properly on the server, and removes the possibility of of a misconfigured acl.
I would start by checking to make sure there are no firewalls on the client as well as any router/firewall on your network that may be blocking the traffic.
I am using Debian, I've tried this both on my system (using the previous version) and my friend's system (using the most current stable version). Note that the newer version uses a different switch to force TCP (-T), and doesn't say which it's using (although I'd guess it works the same way based on when it does and doesn't work).
Another problem I have is that, usually between midnight and 1 AM, I can't get a response from either nameserver using any protocol, and this happens a few times a week. From what I've heard, there's actually only 1 nameserver, and they do something in the router to make it look like 2.
I can't traceroute either one, it stops after 3 hops and times out up to 30. I can ping both (even when they're not responding to DNS at all).
First, using the default (UDP):
~$ host -d google.com 204.255.24.254
;; res_send()
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 17326
;; flags: rd; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0
;; google.com, type = A, class = IN
;; Querying server (# 1) udp address = 204.255.24.254
204.255.24.254 recvfrom: Connection timed out
;; Querying server (# 1) udp address = 204.255.24.254
204.255.24.254 recvfrom: Connection timed out
;; res_send failed
Nameserver host.warwick.net not responding
google.com A record not found at host.warwick.net, try again
Now, forcing TCP with the u option:
~$ host -du google.com 204.255.24.254
;; res_send()
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 17333
;; flags: rd; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0
;; google.com, type = A, class = IN
;; Querying server (# 1) tcp address = 204.255.24.254
;; connected to 204.255.24.254
;; got answer, 212 bytes:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 17333
;; flags: qr rd ra; QUERY: 1, ANSWER: 3, AUTHORITY: 4, ADDITIONAL: 4
;; google.com, type = A, class = IN
google.com. 1m35s IN A 64.233.187.99
google.com. 1m35s IN A 72.14.207.99
google.com. 1m35s IN A 64.233.167.99
google.com. 1d12h26m23s IN NS ns4.google.com.
google.com. 1d12h26m23s IN NS ns1.google.com.
google.com. 1d12h26m23s IN NS ns2.google.com.
google.com. 1d12h26m23s IN NS ns3.google.com.
ns1.google.com. 2d14h25m53s IN A 216.239.32.10
ns2.google.com. 2d14h25m53s IN A 216.239.34.10
ns3.google.com. 2d14h25m53s IN A 216.239.36.10
ns4.google.com. 2d14h25m53s IN A 216.239.38.10
;; Query done, 3 answers, status: no error
google.com A 64.233.187.99
google.com A 72.14.207.99
google.com A 64.233.167.99
On OSX with the default option (should be UDP, but doesn't specify):
;; ANSWER SECTION:
google.com. 300 IN A 64.233.167.99
google.com. 300 IN A 64.233.187.99
google.com. 300 IN A 72.14.207.99
;; AUTHORITY SECTION:
google.com. 130781 IN NS ns1.google.com.
google.com. 130781 IN NS ns2.google.com.
google.com. 130781 IN NS ns3.google.com.
google.com. 130781 IN NS ns4.google.com.
;; ADDITIONAL SECTION:
ns1.google.com. 224351 IN A 216.239.32.10
ns2.google.com. 224351 IN A 216.239.34.10
ns3.google.com. 224351 IN A 216.239.36.10
ns4.google.com. 224351 IN A 216.239.38.10
Received 212 bytes from 204.255.24.254#53 in 36 ms
Trying "google.com"
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 4563
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0
;; QUESTION SECTION:
;google.com. IN AAAA
;; AUTHORITY SECTION:
google.com. 300 IN SOA ns1.google.com. dns-admin.google.com. 2007083100 7200 1800 1209600 300
Received 78 bytes from 204.255.24.254#53 in 28 ms
Trying "google.com"
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 20883
;; flags: qr rd ra; QUERY: 1, ANSWER: 4, AUTHORITY: 4, ADDITIONAL: 4
;; QUESTION SECTION:
;google.com. IN MX
;; ANSWER SECTION:
google.com. 5750 IN MX 10 smtp4.google.com.
google.com. 5750 IN MX 10 smtp1.google.com.
google.com. 5750 IN MX 10 smtp2.google.com.
google.com. 5750 IN MX 10 smtp3.google.com.
;; AUTHORITY SECTION:
google.com. 130781 IN NS ns3.google.com.
google.com. 130781 IN NS ns4.google.com.
google.com. 130781 IN NS ns1.google.com.
google.com. 130781 IN NS ns2.google.com.
;; ADDITIONAL SECTION:
ns1.google.com. 224351 IN A 216.239.32.10
ns2.google.com. 224351 IN A 216.239.34.10
ns3.google.com. 224351 IN A 216.239.36.10
ns4.google.com. 224351 IN A 216.239.38.10
Received 252 bytes from 204.255.24.254#53 in 16 ms
----
There are no routers or firewalls on my end, that box is connected directly to the DSL modem.
I don't think my ISP would be able to recommend an MTU. If I call tech support, I get some call center in North Dakota, and the only information they can access about the ISP's actual network is to reset passwords and change account information (address, etc.), they don't actually have access to the network or any technical information about it.
-----
# netstat -i
Kernel Interface table
Iface MTU Met RX-OK RX-ERR RX-DRP RX-OVR TX-OK TX-ERR TX-DRP TX-OVR Flg
eth0 1500 0 653675264 0 0 0713707131 0 0 0 BMRU
eth0: 1500 0 - no statistics available - BMRU
lo 16436 0 1293160 0 0 0 1293160 0 0 0 LRU
I tried an alternate one, but whenever it didn't find a URL (and even sometimes when it did), it would redirect to a page with ads and popups. I think it was even redirecting some sites to phishing sites. I was losing outgoing email because it was returning crazy results. I don't trust the "alternative" "free" "ad-supported" ones, but I may try to find one from another ISP (like Roadrunner or Earthlink).
That OpenDNS one says they block adult sites and stuff, so they're obviously screwing with the results. While my ISP's is down sometimes (actually annoyingly often), at least it doesn't do that.
It sounds like your ISP's DNS servers may be having problems from what you said. Trying another DNS server regardless of if they messing with the results helps prove this. As long as you can get a constant response using either protocol with them helps rule out anything that could be on your machine.
There are 2 Verizon servers that can be used that don't(as far as I know) alter the results of your queries.
4.2.2.1 and 4.2.2.2
If their servers are having problems all you can really do is call their tech support, run your own DNS server, or use publicly available ones.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.