LinuxQuestions.org
Latest LQ Deal: Latest LQ Deals
Home Forums Tutorials Articles Register
Go Back   LinuxQuestions.org > Forums > Linux Forums > Linux - Networking
User Name
Password
Linux - Networking This forum is for any issue related to networks or networking.
Routing, network cards, OSI, etc. Anything is fair game.

Notices


Reply
  Search this Thread
Old 08-31-2007, 06:14 PM   #1
FlyingMoose
LQ Newbie
 
Registered: Mar 2003
Posts: 19

Rep: Reputation: 0
Really strange DNS problems...


My ISP has a primary and a secondary DNS server.

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?

Thanks.
 
Old 08-31-2007, 06:51 PM   #2
aus9
LQ 5k Club
 
Registered: Oct 2003
Location: Western Australia
Distribution: Icewm
Posts: 5,842

Rep: Reputation: Disabled
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
 
Old 08-31-2007, 07:05 PM   #3
aus9
LQ 5k Club
 
Registered: Oct 2003
Location: Western Australia
Distribution: Icewm
Posts: 5,842

Rep: Reputation: Disabled
btw I never use mac try a forum...this looks nice?

http://www.macfixitforums.com/
 
Old 08-31-2007, 10:23 PM   #4
fur
Member
 
Registered: Dec 2003
Distribution: Debian, FreeBSD
Posts: 310

Rep: Reputation: 35
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.
 
Old 09-03-2007, 02:09 PM   #5
FlyingMoose
LQ Newbie
 
Registered: Mar 2003
Posts: 19

Original Poster
Rep: Reputation: 0
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):

$ host -d google.com 204.255.24.254
Trying "google.com"
Using domain server:
Name: 204.255.24.254
Address: 204.255.24.254#53
Aliases:

;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 36819
;; flags: qr rd ra; QUERY: 1, ANSWER: 3, AUTHORITY: 4, ADDITIONAL: 4

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

;; 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.

No local iptables:

~# iptables --list
Chain INPUT (policy ACCEPT)
target prot opt source destination

Chain FORWARD (policy ACCEPT)
target prot opt source destination

Chain OUTPUT (policy ACCEPT)
target prot opt source destination

Resolv.conf:

~# cat /etc/resolv.conf
-snip-
nameserver 204.255.24.251
nameserver 204.255.24.254

----

I have no resolvconf directory on the server.

----

~# ifconfig
eth0 Link encap:Ethernet HWaddr 00:01:03:E2:FF:67
inet addr:216.6.149.28 Bcast:216.6.149.255 Mask:255.255.255.0
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:653674366 errors:0 dropped:0 overruns:0 frame:0
TX packets:713706225 errors:0 dropped:0 overruns:0 carrier:1777
collisions:3979052 txqueuelen:100
RX bytes:3833617118 (3.5 GiB) TX bytes:1973839130 (1.8 GiB)
Interrupt:29 Base address:0xec80

eth0:0 Link encap:Ethernet HWaddr 00:01:03:E2:FF:67
inet addr:216.6.149.29 Bcast:216.6.149.255 Mask:255.255.255.0
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
Interrupt:29 Base address:0xec80

lo Link encap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0
UP LOOPBACK RUNNING MTU:16436 Metric:1
RX packets:1293156 errors:0 dropped:0 overruns:0 frame:0
TX packets:1293156 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:645517031 (615.6 MiB) TX bytes:645517031 (615.6 MiB)


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
 
Old 09-03-2007, 03:52 PM   #6
fur
Member
 
Registered: Dec 2003
Distribution: Debian, FreeBSD
Posts: 310

Rep: Reputation: 35
Try using some alternate DNS servers and see if you have the same problems.


From http://www.opendns.com
208.67.222.222
208.67.220.220
 
Old 09-03-2007, 04:07 PM   #7
FlyingMoose
LQ Newbie
 
Registered: Mar 2003
Posts: 19

Original Poster
Rep: Reputation: 0
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.
 
Old 09-03-2007, 07:20 PM   #8
fur
Member
 
Registered: Dec 2003
Distribution: Debian, FreeBSD
Posts: 310

Rep: Reputation: 35
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.
 
Old 09-03-2007, 07:32 PM   #9
FlyingMoose
LQ Newbie
 
Registered: Mar 2003
Posts: 19

Original Poster
Rep: Reputation: 0
I may just switch ISP's. Their so-called 1024K connection is sometimes less than 100K.
 
  


Reply



Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is Off
HTML code is Off



Similar Threads
Thread Thread Starter Forum Replies Last Post
strange DNS problem? cyrwyn Linux - Networking 4 06-22-2007 11:29 AM
Strange DNS issue! Atif_Khan Linux - General 2 01-27-2007 07:49 AM
strange DNS vadirajcs Linux - Wireless Networking 3 07-27-2006 06:03 AM
Strange DNS Issue helt2 Linux - Networking 7 01-13-2004 03:36 PM
Strange dns problem jekyl Linux - Networking 1 01-15-2003 12:49 PM

LinuxQuestions.org > Forums > Linux Forums > Linux - Networking

All times are GMT -5. The time now is 10:19 AM.

Main Menu
Advertisement
My LQ
Write for LQ
LinuxQuestions.org is looking for people interested in writing Editorials, Articles, Reviews, and more. If you'd like to contribute content, let us know.
Main Menu
Syndicate
RSS1  Latest Threads
RSS1  LQ News
Twitter: @linuxquestions
Open Source Consulting | Domain Registration