nslookup: connection timed out; no servers could be reached
 

I have 2 servers:

xmail1 192.168.1.21
xmail2 192.168.1.22

THE PROBLEM:

[root@xmail1 ~]# nslookup 64.81.79.2
;; connection timed out; no servers could be reached

[root@xmail2 ~]# nslookup 64.81.79.2
Server: 64.81.79.2
Address: 64.81.79.2#53

Non-authoritative answer:
2.79.81.64.in-addr.arpa name = dns.sfo1.speakeasy.net.

Authoritative answers can be found from:


Logging in and sendmail are slow as a result. I can ssh and ping to local machines from xmail1, and sendmail successfully sends slowly, but it's really gummed up because of the DNS issue here.

Here are a few configs I've tried for xmail1 that have failed and xmail2's which works:

[root@xmail1 ~]# cat /etc/sysconfig/network-scripts/ifcfg-eth0
DEVICE=eth0
BOOTPROTO=none
BROADCAST=192.168.1.255
HWADDR=00:30:48:59:A1:F8
IPADDR=192.168.1.21
NETMASK=255.255.255.0
NETWORK=192.168.1.0
ONBOOT=yes
TYPE=Ethernet
USERCTL=no
PEERDNS=yes
GATEWAY=192.168.1.1
IPV6INIT=no

[root@xmail1 ~]# cat /etc/sysconfig/network-scripts/ifcfg-eth0
# Broadcom Corporation NetXtreme BCM5704 Gigabit Ethernet
DEVICE=eth0
BOOTPROTO=none
BROADCAST=192.168.1.255
HWADDR=00:30:48:59:a1:f8
IPADDR=192.168.1.21
NETMASK=255.255.255.0
NETWORK=192.168.1.0
ONBOOT=yes
GATEWAY=192.168.1.1
TYPE=Ethernet

[root@xmail1 ~]# cat /etc/sysconfig/network-scripts/ifcfg-eth0
# Broadcom Corporation NetXtreme BCM5704 Gigabit Ethernet
DEVICE=eth0
BOOTPROTO=none
BROADCAST=192.168.1.255
HWADDR=00:30:48:59:a1:f8
IPADDR=192.168.1.21
NETMASK=255.255.255.0
NETWORK=192.168.1.0
ONBOOT=yes
GATEWAY=192.168.1.1
TYPE=Ethernet
PEERDNS=no

[root@xmail2 ~]# cat /etc/sysconfig/network-scripts/ifcfg-eth0
DEVICE=eth0
BOOTPROTO=none
BROADCAST=192.168.1.255
HWADDR=00:12:3F:ED:08:5A
IPADDR=192.168.1.22
NETMASK=255.255.255.0
NETWORK=192.168.1.0
ONBOOT=yes
TYPE=Ethernet
USERCTL=no
PEERDNS=yes
GATEWAY=192.168.1.1
IPV6INIT=no

RESOLV.CONF:

[root@xmail1 ~]# cat /etc/resolv.conf
search glocap.com
nameserver 64.81.79.2
nameserver 216.231.41.2

[root@xmail2 ~]# cat /etc/resolv.conf
search glocap.com
#nameserver 192.168.1.20
nameserver 64.81.79.2 #speakeasy
nameserver 216.231.41.2 #speakeasy
# nameserver 209.17.66.100
# nameserver 209.17.66.79

ROUTE:

[root@xmail1 ~]# route
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
192.168.1.0 * 255.255.255.0 U 0 0 0 eth0
link-local * 255.255.0.0 U 0 0 0 eth0
default 192.168.1.1 0.0.0.0 UG 0 0 0 eth0

[root@xmail2 ~]# route
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
192.168.1.0 * 255.255.255.0 U 0 0 0 eth0
169.254.0.0 * 255.255.0.0 U 0 0 0 eth0
default 192.168.1.1 0.0.0.0 UG 0 0 0 eth0

Note: the last line (gateway) of xmail1's 'route' command loads very slowly, I think it might be related.

Thanks so much for any response!

Kimball

It sounds as though xmail1 cannot reach any DNS server in its list. Since xmail2 can, and it appears to be on the same subnet, is there a restriction on the firewall that is allowing DNS traffic (UDP port 53) only to xmail2?

To verify this, can xmail1 ping any machine off the local net (using address, not DNS name)? If not, there may be a blanket prohibition on its address, and/or the firewall (router) may not be doing NAT for it. If ping reports a reply, then you almost certainly have a DNS issue.

(BTW, if you ask xmail1 to report its route table via it should not take a long time to report back. I am speculating that the delay is an attempt by the route command to do the inverse lookup of the IP addresses.)

easy way to check if its a firewall issue would be to as root from the command line issue:

# iptables -F

this will clear your firewall rules (they'll be restored on reboot) and if your network works as expected then you know its a firewall issue.

... presuming, of course, that the firewall is actually a un*x box. It might be a router/firewall, in which case, this won't work.

Trying to ping www.google.com by IP address:

[root@xmail1 ~]# ping 74.125.19.104
PING 74.125.19.104 (74.125.19.104) 56(84) bytes of data.
<hangs>

route -n did indeed return immediately, thank you!

How do I verify/address the 'blanket prohibition' and 'not doing NAT' possibilities, respectively? I'm pretty sure my firewall setup doesn't distinguish by machine, I have at least 7 boxes on the subnet working and 2 that are not, including 3 email relays with the same firewall rules as xmail1. thank you so much for your help!

If you have separate firewall rules on each machine and no firewall-type device between your local net and the Internet, then check on the machines that do not work, like this:

List the INPUT chain on a non-working machine This will give you a list of all the rules that are applied (in order) to an arriving packet. Review this list to see if UDP packets with this machine's IP address and source-port 53 and dest-port 53 or 1024-65535 will be accepted, and revise as necessary.

List the OUTPUT chain similarly, and verify that UDP packets with this machine's IP address and source-port 53 and dest-port 1024-65535 are permitted.

These rules should allow DNS traffic through a single machine's firewall. If you have a common machine between the Internet and the non-working machines, you also need to check that its FORWARD chain will allow the UDP packets to transit that box.

The reason for the asymmetry between INPUT and OUTPUT is that (I assume) your box is running a recent version of BIND, which uses non-privileged (high-numbered) source ports; older DNS implementation still can use source-port 53 in their messages, so you will need to accept them, too.

From my firewall machine, between the subnet and the Internet:

[root@trusty ~]# iptables -nvL INPUT
Chain INPUT (policy DROP 135K packets, 7287K bytes)
pkts bytes target prot opt in out source destination
298K 24M FIREWALL all -- * * 0.0.0.0/0 0.0.0.0/0
[root@trusty ~]# iptables -nvL OUTPUT
Chain OUTPUT (policy ACCEPT 210K packets, 28M bytes)
pkts bytes target prot opt in out source destination
[root@trusty ~]# iptables -nvL FORWARD
Chain FORWARD (policy DROP 36736 packets, 5764K bytes)
pkts bytes target prot opt in out source destination
201M 78G FIREWALL all -- * * 0.0.0.0/0 0.0.0.0/0

[root@xmail1 ~]# iptables -nvL INPUT
Chain INPUT (policy ACCEPT 255 packets, 19819 bytes)
pkts bytes target prot opt in out source destination
[root@xmail1 ~]# iptables -nvL OUTPUT
Chain OUTPUT (policy ACCEPT 5406 packets, 519K bytes)
pkts bytes target prot opt in out source destination
[root@xmail1 ~]# iptables -nvL FORWARD
Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination

[root@xmail2 ~]# iptables -nvL INPUT
Chain INPUT (policy ACCEPT 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination
[root@xmail2 ~]# iptables -nvL OUTPUT
Chain OUTPUT (policy ACCEPT 17 packets, 1876 bytes)
pkts bytes target prot opt in out source destination
[root@xmail2 ~]# iptables -nvL FORWARD
Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination

I'm investigating these lines I found in /var/log/messages from a few days ago:

Jun 12 20:11:16 xmail1 system-config-network[2108]: mkdir ///etc/cipe
Jun 12 20:11:16 xmail1 system-config-network[2108]: ln //etc/sysconfig/network-scripts//ifcfg-eth0 //etc/sysconfig/networking/devices//ifcfg-eth0
Jun 12 20:11:16 xmail1 system-config-network[2108]: Linking eth0 to devices and putting it in profile default.
Jun 12 20:11:16 xmail1 system-config-network[2108]: ln //etc/sysconfig/networking/devices//ifcfg-eth0 //etc/sysconfig/networking/profiles//default/ifcfg-eth0
Jun 12 20:11:17 xmail1 system-config-network[2108]: ln //etc/sysconfig/network-scripts//ifcfg-eth1 //etc/sysconfig/networking/devices//ifcfg-eth1
Jun 12 20:11:17 xmail1 system-config-network[2108]: Linking eth1 to devices and putting it in profile default.
Jun 12 20:11:17 xmail1 system-config-network[2108]: ln //etc/sysconfig/networking/devices//ifcfg-eth1 //etc/sysconfig/networking/profiles//default/ifcfg-eth1
Jun 12 20:11:17 xmail1 system-config-network[2108]: ln //etc/hosts //etc/sysconfig/networking/profiles//default/hosts
Jun 12 20:11:17 xmail1 system-config-network[2108]: ln //etc/resolv.conf //etc/sysconfig/networking/profiles//default/resolv.conf
Jun 12 20:11:57 xmail1 system-config-network[2108]: chmod 0644 //etc/sysconfig/networking/devices/ifcfg-eth0
Jun 12 20:11:57 xmail1 system-config-network[2108]: chmod 0644 //etc/sysconfig/networking/devices/ifcfg-eth1
Jun 12 20:14:02 xmail1 shutdown[2235]: shutting down for system reboot
Jun 12 20:14:02 xmail1 init: Switching to runlevel: 6
Jun 12 20:14:03 xmail1 restorecond: Will not restore a file with more than one hard link (/etc/resolv.conf) Invalid argument
Jun 12 20:14:03 xmail1 avahi-daemon[2028]: Got SIGTERM, quitting.
Jun 12 20:14:03 xmail1 avahi-daemon[2028]: Leaving mDNS multicast group on interface eth0.IPv4 with address 192.168.1.21.

...

Jun 13 16:59:55 xmail1 avahi-daemon[1979]: Withdrawing address record for 192.168.1.21 on eth0.
Jun 13 16:59:55 xmail1 avahi-daemon[1979]: Leaving mDNS multicast group on interface eth0.IPv4 with address 192.168.1.21.
Jun 13 16:59:55 xmail1 avahi-daemon[1979]: Interface eth0.IPv4 no longer relevant for mDNS.
Jun 13 16:59:55 xmail1 avahi-daemon[1979]: Withdrawing address record for fe80::230:48ff:fe59:a1f8 on eth0.
Jun 13 16:59:56 xmail1 kernel: IPv6 over IPv4 tunneling driver
Jun 13 16:59:56 xmail1 kernel: sit0: Disabled Privacy Extensions
Jun 13 16:59:56 xmail1 kernel: ADDRCONF(NETDEV_UP): eth0: link is not ready
Jun 13 16:59:59 xmail1 kernel: tg3: eth0: Link is up at 1000 Mbps, full duplex.
Jun 13 16:59:59 xmail1 kernel: tg3: eth0: Flow control is on for TX and on for RX.
Jun 13 16:59:59 xmail1 kernel: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready
Jun 13 17:00:00 xmail1 avahi-daemon[1979]: Registering new address record for fe80::230:48ff:fe59:a1f8 on eth0.*.
Jun 13 17:00:00 xmail1 avahi-daemon[1979]: Joining mDNS multicast group on interface eth0.IPv4 with address 192.168.1.21.
Jun 13 17:00:00 xmail1 avahi-daemon[1979]: New relevant interface eth0.IPv4 for mDNS.
Jun 13 17:00:00 xmail1 avahi-daemon[1979]: Registering new address record for 192.168.1.21 on eth0.IPv4.
Jun 13 17:18:46 xmail1 yum-updatesd-helper: error getting update info: Cannot retrieve repository metadata (repomd.xml) for repository: fedora. Please verify its path and try again
Jun 13 18:03:14 xmail1 avahi-daemon[1979]: Withdrawing address record for 192.168.1.21 on eth0.
Jun 13 18:03:14 xmail1 avahi-daemon[1979]: Leaving mDNS multicast group on interface eth0.IPv4 with address 192.168.1.21.
Jun 13 18:03:14 xmail1 avahi-daemon[1979]: Interface eth0.IPv4 no longer relevant for mDNS.
Jun 13 18:03:14 xmail1 avahi-daemon[1979]: Withdrawing address record for fe80::230:48ff:fe59:a1f8 on eth0.
Jun 13 18:03:15 xmail1 kernel: ADDRCONF(NETDEV_UP): eth0: link is not ready
Jun 13 18:03:17 xmail1 kernel: tg3: eth0: Link is up at 1000 Mbps, full duplex.
Jun 13 18:03:17 xmail1 kernel: tg3: eth0: Flow control is on for TX and on for RX.
Jun 13 18:03:17 xmail1 kernel: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready
Jun 13 18:03:18 xmail1 avahi-daemon[1979]: Registering new address record for fe80::230:48ff:fe59:a1f8 on eth0.*.
Jun 13 18:03:19 xmail1 avahi-daemon[1979]: Joining mDNS multicast group on interface eth0.IPv4 with address 192.168.1.21.
Jun 13 18:03:19 xmail1 avahi-daemon[1979]: New relevant interface eth0.IPv4 for mDNS.
Jun 13 18:03:19 xmail1 avahi-daemon[1979]: Registering new address record for 192.168.1.21 on eth0.IPv4.
Jun 13 18:09:55 xmail1 avahi-daemon[1979]: Withdrawing address record for 192.168.1.21 on eth0.
Jun 13 18:09:55 xmail1 avahi-daemon[1979]: Leaving mDNS multicast group on interface eth0.IPv4 with address 192.168.1.21.
Jun 13 18:09:55 xmail1 avahi-daemon[1979]: Interface eth0.IPv4 no longer relevant for mDNS.
Jun 13 18:09:55 xmail1 avahi-daemon[1979]: Withdrawing address record for fe80::230:48ff:fe59:a1f8 on eth0.
Jun 13 18:09:56 xmail1 kernel: ADDRCONF(NETDEV_UP): eth0: link is not ready
Jun 13 18:09:59 xmail1 kernel: tg3: eth0: Link is up at 1000 Mbps, full duplex.
Jun 13 18:09:59 xmail1 kernel: tg3: eth0: Flow control is on for TX and on for RX.
Jun 13 18:09:59 xmail1 kernel: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready
Jun 13 18:10:00 xmail1 avahi-daemon[1979]: Joining mDNS multicast group on interface eth0.IPv4 with address 192.168.1.21.
Jun 13 18:10:00 xmail1 avahi-daemon[1979]: New relevant interface eth0.IPv4 for mDNS.
Jun 13 18:10:00 xmail1 avahi-daemon[1979]: Registering new address record for 192.168.1.21 on eth0.IPv4.
Jun 13 18:10:00 xmail1 avahi-daemon[1979]: Registering new address record for fe80::230:48ff:fe59:a1f8 on eth0.*.

...

Jun 13 18:26:10 xmail1 restorecond: Will not restore a file with more than one hard link (/etc/resolv.conf) Invalid argument

Perhaps SELinux is involved? See below, regarding resolv.conf and restorecond error in /var/logs/messages:

http://www.fedoraforum.org/forum/arc.../t-159533.html

Perhaps avahi-daemon is also involved?

While interesting, the log messages do not, by themselves, indicate anything wrong. They do, however, indicate that you are running a multicast DNS scheme to provide DNS service to some number of your machines.

The original problem you reported was that some of your servers could not resolve the address 64.81.79.2, which is off your local net. Subsequent posts indicate that you have effectively no firewalling between the offending machine and the Internet. It seems to me that it might be time to actually do a packet trace on (for example) xmail1 to find out what in the world it is doing when you ask it to resolve that address. There should be no problem in its resolution, but there definitely is.

The tool you need is tcpdump, and the thing you want to look for is UDP packets with either source- or destination-port 53. I think it will be very informative to find out where that machine is actually sending such packets, because they clearly are not going where they should.

Some tcpdump output that might be helpful:

...

13:31:00.110143 IP 192.168.1.21.ssh > 192.168.1.1.39540: P 663016090:663016282(192) ack 2620139830 win 90 <nop,nop,timestamp 1894415 228009203>
13:31:00.110230 IP 192.168.1.1.39540 > 192.168.1.21.ssh: . ack 192 win 22444 <nop,nop,timestamp 228009212 1894415>
13:31:00.110633 IP 192.168.1.21.32798 > 64.81.79.2.domain: 39250+ PTR? 1.1.168.192.in-addr.arpa. (42)
13:31:05.110224 IP 192.168.1.21.32799 > 216.231.41.2.domain: 39250+ PTR? 1.1.168.192.in-addr.arpa. (42)
13:31:10.110215 IP 192.168.1.21.32798 > 64.81.79.2.domain: 39250+ PTR? 1.1.168.192.in-addr.arpa. (42)
13:31:15.110212 IP 192.168.1.21.32799 > 216.231.41.2.domain: 39250+ PTR? 1.1.168.192.in-addr.arpa. (42)
13:31:20.110282 IP 192.168.1.21.32799 > 64.81.79.2.domain: 28995+ PTR? 21.1.168.192.in-addr.arpa. (43)
13:31:25.110236 IP 192.168.1.21.32800 > 216.231.41.2.domain: 28995+ PTR? 21.1.168.192.in-addr.arpa. (43)
13:31:30.110212 IP 192.168.1.21.32799 > 64.81.79.2.domain: 28995+ PTR? 21.1.168.192.in-addr.arpa. (43)
13:31:35.110217 IP 192.168.1.21.32800 > 216.231.41.2.domain: 28995+ PTR? 21.1.168.192.in-addr.arpa. (43)
13:31:40.110196 arp who-has 192.168.1.1 tell 192.168.1.21
13:31:40.110305 arp reply 192.168.1.1 is-at 00:30:48:59:dd:dc (oui Unknown)

...

[root@xmail1 var]# less tcplog.txt | grep UDP
13:33:51.904148 IP 192.168.1.25.netbios-dgm > 192.168.1.255.netbios-dgm: NBT UDP PACKET(138)
13:33:51.904418 IP 192.168.1.25.netbios-dgm > 192.168.1.255.netbios-dgm: NBT UDP PACKET(138)
13:35:51.150368 IP 192.168.1.25.netbios-dgm > 192.168.1.255.netbios-dgm: NBT UDP PACKET(138)
13:38:48.078832 IP 192.168.1.25.netbios-ns > 192.168.1.255.netbios-ns: NBT UDP PACKET(137): QUERY; REQUEST; BROADCAST
13:38:48.828701 IP 192.168.1.25.netbios-ns > 192.168.1.255.netbios-ns: NBT UDP PACKET(137): QUERY; REQUEST; BROADCAST
13:38:49.578715 IP 192.168.1.25.netbios-ns > 192.168.1.255.netbios-ns: NBT UDP PACKET(137): QUERY; REQUEST; BROADCAST
13:40:57.531666 IP 192.168.1.25.netbios-ns > 192.168.1.255.netbios-ns: NBT UDP PACKET(137): QUERY; REQUEST; BROADCAST
13:40:58.281135 IP 192.168.1.25.netbios-ns > 192.168.1.255.netbios-ns: NBT UDP PACKET(137): QUERY; REQUEST; BROADCAST

...

[root@xmail1 var]# less tcplog.txt | grep 64.81.79.2
13:31:00.110633 IP 192.168.1.21.32798 > 64.81.79.2.domain: 39250+ PTR? 1.1.168.192.in-addr.arpa. (42)
13:31:10.110215 IP 192.168.1.21.32798 > 64.81.79.2.domain: 39250+ PTR? 1.1.168.192.in-addr.arpa. (42)
13:31:20.110282 IP 192.168.1.21.32799 > 64.81.79.2.domain: 28995+ PTR? 21.1.168.192.in-addr.arpa. (43)
13:31:30.110212 IP 192.168.1.21.32799 > 64.81.79.2.domain: 28995+ PTR? 21.1.168.192.in-addr.arpa. (43)
13:31:40.110357 IP 192.168.1.21.32800 > 64.81.79.2.domain: 12659+ PTR? 2.79.81.64.in-addr.arpa. (41)
13:31:50.110211 IP 192.168.1.21.32800 > 64.81.79.2.domain: 12659+ PTR? 2.79.81.64.in-addr.arpa. (41)
13:31:55.366859 IP 192.168.1.21.32802 > 64.81.79.2.domain: 28429+ PTR? 2.79.81.64.in-addr.arpa. (41)
13:32:00.110344 IP 192.168.1.21.32804 > 64.81.79.2.domain: 33628+ PTR? 2.41.231.216.in-addr.arpa. (43)

...

[root@xmail1 var]# less tcplog.txt | grep 216.231.41.2
13:31:05.110224 IP 192.168.1.21.32799 > 216.231.41.2.domain: 39250+ PTR? 1.1.168.192.in-addr.arpa. (42)
13:31:15.110212 IP 192.168.1.21.32799 > 216.231.41.2.domain: 39250+ PTR? 1.1.168.192.in-addr.arpa. (42)
13:31:25.110236 IP 192.168.1.21.32800 > 216.231.41.2.domain: 28995+ PTR? 21.1.168.192.in-addr.arpa. (43)
13:31:35.110217 IP 192.168.1.21.32800 > 216.231.41.2.domain: 28995+ PTR? 21.1.168.192.in-addr.arpa. (43)
13:31:45.110219 IP 192.168.1.21.32801 > 216.231.41.2.domain: 12659+ PTR? 2.79.81.64.in-addr.arpa. (41)
13:31:55.110213 IP 192.168.1.21.32801 > 216.231.41.2.domain: 12659+ PTR? 2.79.81.64.in-addr.arpa. (41)
13:31:56.366784 IP 192.168.1.21.32803 > 216.231.41.2.domain: 28429+ PTR? 2.79.81.64.in-addr.arpa. (41)
13:32:02.366824 IP 192.168.1.21.32803 > 216.231.41.2.domain: 28429+ PTR? 2.79.81.64.in-addr.arpa. (41)
13:32:05.110218 IP 192.168.1.21.32805 > 216.231.41.2.domain: 33628+ PTR? 2.41.231.216.in-addr.arpa. (43)

...

Should I grep for something in particular? thanks so much!

Rather than 'grep'ping for stuff after the fact, it is probably better to get tcpdump to filter the traffic for you right away. Here is a command that I think will provide some instructive data: This command will record only UDP packets either coming from or going to port 53, the DNS port.
On my machine, this produces a result like this:

Thanks, I ran 'nslookup 64.79.81.2' and 'ping www.google.com' with no results, and then ran 'nslookup 216.231.41.2' and got this:

[root@xmail1 ~]# tail -f /var/tcplog.txt
18:42:07.719876 IP (tos 0x0, ttl 64, id 49257, offset 0, flags [DF], proto UDP (17), length 71) 192.168.1.21.32871 > 64.81.79.2.53: 451+ PTR? 19.1.168.192.in-addr.arpa. (43)
18:42:12.719215 IP (tos 0x0, ttl 64, id 54257, offset 0, flags [DF], proto UDP (17), length 71) 192.168.1.21.32872 > 216.231.41.2.53: 451+ PTR? 19.1.168.192.in-addr.arpa. (43)
18:42:17.719207 IP (tos 0x0, ttl 64, id 49258, offset 0, flags [DF], proto UDP (17), length 71) 192.168.1.21.32871 > 64.81.79.2.53: 451+ PTR? 19.1.168.192.in-addr.arpa. (43)
18:42:22.719210 IP (tos 0x0, ttl 64, id 54258, offset 0, flags [DF], proto UDP (17), length 71) 192.168.1.21.32872 > 216.231.41.2.53: 451+ PTR? 19.1.168.192.in-addr.arpa. (43)
18:45:17.143869 IP (tos 0x0, ttl 64, id 42073, offset 0, flags [DF], proto UDP (17), length 71) 192.168.1.21.32872 > 64.81.79.2.53: 59727+ PTR? 19.1.168.192.in-addr.arpa. (43)
18:45:22.143234 IP (tos 0x0, ttl 64, id 47073, offset 0, flags [DF], proto UDP (17), length 71) 192.168.1.21.32875 > 216.231.41.2.53: 59727+ PTR? 19.1.168.192.in-addr.arpa. (43)
18:45:27.143206 IP (tos 0x0, ttl 64, id 42074, offset 0, flags [DF], proto UDP (17), length 71) 192.168.1.21.32872 > 64.81.79.2.53: 59727+ PTR? 19.1.168.192.in-addr.arpa. (43)
18:45:32.143207 IP (tos 0x0, ttl 64, id 47074, offset 0, flags [DF], proto UDP (17), length 71) 192.168.1.21.32875 > 216.231.41.2.53: 59727+ PTR? 19.1.168.192.in-addr.arpa. (43)
18:46:02.741892 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto UDP (17), length 69) 192.168.1.21.32875 > 64.81.79.2.53: 4116+ PTR? 2.79.81.64.in-addr.arpa. (41)
18:46:03.741814 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto UDP (17), length 69) 192.168.1.21.32876 > 216.231.41.2.53: 4116+ PTR? 2.79.81.64.in-addr.arpa. (41)
18:46:08.741822 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto UDP (17), length 69) 192.168.1.21.32875 > 64.81.79.2.53: 4116+ PTR? 2.79.81.64.in-addr.arpa. (41)
18:46:09.741847 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto UDP (17), length 69) 192.168.1.21.32876 > 216.231.41.2.53: 4116+ PTR? 2.79.81.64.in-addr.arpa. (41)
18:46:14.741880 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto UDP (17), length 69) 192.168.1.21.32875 > 64.81.79.2.53: 4116+ PTR? 2.79.81.64.in-addr.arpa. (41)
18:46:15.741907 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto UDP (17), length 69) 192.168.1.21.32876 > 216.231.41.2.53: 4116+ PTR? 2.79.81.64.in-addr.arpa. (41)
18:47:07.028418 IP (tos 0x0, ttl 64, id 20886, offset 0, flags [DF], proto UDP (17), length 60) 192.168.1.21.32876 > 64.81.79.2.53: 22006+ A? www.google.com. (32)
18:47:12.028237 IP (tos 0x0, ttl 64, id 25886, offset 0, flags [DF], proto UDP (17), length 60) 192.168.1.21.32877 > 216.231.41.2.53: 22006+ A? www.google.com. (32)
18:47:17.028214 IP (tos 0x0, ttl 64, id 20887, offset 0, flags [DF], proto UDP (17), length 60) 192.168.1.21.32876 > 64.81.79.2.53: 22006+ A? www.google.com. (32)
18:47:22.028209 IP (tos 0x0, ttl 64, id 25887, offset 0, flags [DF], proto UDP (17), length 60) 192.168.1.21.32877 > 216.231.41.2.53: 22006+ A? www.google.com. (32)
18:47:27.028268 IP (tos 0x0, ttl 64, id 40886, offset 0, flags [DF], proto UDP (17), length 71) 192.168.1.21.32877 > 64.81.79.2.53: 26241+ A? www.google.com.glocap.com. (43)
18:47:32.028220 IP (tos 0x0, ttl 64, id 45886, offset 0, flags [DF], proto UDP (17), length 71) 192.168.1.21.32878 > 216.231.41.2.53: 26241+ A? www.google.com.glocap.com. (43)
18:47:37.028216 IP (tos 0x0, ttl 64, id 40887, offset 0, flags [DF], proto UDP (17), length 71) 192.168.1.21.32877 > 64.81.79.2.53: 26241+ A? www.google.com.glocap.com. (43)
18:47:42.028216 IP (tos 0x0, ttl 64, id 45887, offset 0, flags [DF], proto UDP (17), length 71) 192.168.1.21.32878 > 216.231.41.2.53: 26241+ A? www.google.com.glocap.com. (43)
18:50:49.798302 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto UDP (17), length 71) 192.168.1.21.32878 > 64.81.79.2.53: 39588+ PTR? 2.41.231.216.in-addr.arpa. (43)
18:50:50.798225 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto UDP (17), length 71) 192.168.1.21.32880 > 216.231.41.2.53: 39588+ PTR

I just don't know how to read this yet..

Well, that is pretty definitive: it says that your machine 192.168.1.21 is trying to reach quite a few servers, and getting replies from none of them. For reference, here is the resolution I get from my systems:
64.81.79.2 ==> dns.sfo1.speakeasy.net
216.231.41.2 ==> ns-legacy.speakeasy.net

The reason that you are not getting any answer is that your query is for resolution of an IP address 192.168.1.19. No self-respecting public DNS server is going to answer to that, for two reasons: first, it won't know the answer, and second, the request is for a Private Networking address. That address is almost certainly assigned to one of the machines on your local net, and is probably the address of a DNS server. I am betting that your xmail1 machine somehow thinks that it ought to be asking for that nameserver, rather than the ones you reported in your resolv.conf. Is there more than one such file? I have read about some GUI tools that keep system configuration in other places, and overwrite (or link to other files) the default stuff I am familiar with on Fedora systems.

And if you repeat the tcpdump experiment on xmail2 (that works), how does it compare?