weird named problem

Code:
12:56:55.703491 IP (tos 0x0, ttl 52, id 47253, offset 0, flags [none], proto UDP (17), length 562) 192.5.5.241.53 > 212.71.19.98.63785: [udp sum ok] 62199- q: A? opensourcecms.com. 0/13/16 ns: com. NS I.GTLD-SERVERS.NET., com. NS J.GTLD-SERVERS.NET., com. NS D.GTLD-SERVERS.NET., com. NS A.GTLD-SERVERS.NET., com. NS G.GTLD-SERVERS.NET., com. NS C.GTLD-SERVERS.NET., com. NS B.GTLD-SERVERS.NET., com. NS E.GTLD-SERVERS.NET., com. NS K.GTLD-SERVERS.NET., com. NS M.GTLD-SERVERS.NET., com. NS H.GTLD-SERVERS.NET., com. NS L.GTLD-SERVERS.NET., com. NS F.GTLD-SERVERS.NET. ar: A.GTLD-SERVERS.NET. A 192.5.6.30, B.GTLD-SERVERS.NET. A 192.33.14.30, C.GTLD-SERVERS.NET. A 192.26.92.30, D.GTLD-SERVERS.NET. A 192.31.80.30, E.GTLD-SERVERS.NET. A 192.12.94.30, F.GTLD-SERVERS.NET. A 192.35.51.30, G.GTLD-SERVERS.NET. A 192.42.93.30, H.GTLD-SERVERS.NET. A 192.54.112.30, I.GTLD-SERVERS.NET. A 192.43.172.30, J.GTLD-SERVERS.NET. A 192.48.79.30, K.GTLD-SERVERS.NET. A 192.52.178.30, L.GTLD-SERVERS.NET. A 192.41.162.30, M.GTLD-SERVERS.NET. A 192.55.83.30, A.GTLD-SERVERS.NET. AAAA 2001:503:a83e::2:30, B.GTLD-SERVERS.NET. AAAA 2001:503:231d::2:30, . OPT UDPsize=4096 OK (534)
12:56:55.705170 IP (tos 0x0, ttl 64, id 13489, offset 0, flags [none], proto UDP (17), length 74, bad cksum 0 (->4100)!) 212.71.19.98.62397 > 192.42.93.30.53: [bad udp cksum 7c1d!] 15843% [1au] A? opensourcecms.com. ar: . OPT UDPsize=4096 OK (46)
12:56:55.877602 IP (tos 0x0, ttl 52, id 0, offset 0, flags [DF], proto UDP (17), length 142) 192.42.93.30.53 > 212.71.19.98.62397: [udp sum ok] 15843- q: A? opensourcecms.com. 0/2/3 ns: opensourcecms.com. NS ns1.opensourcecms.com., opensourcecms.com. NS ns2.opensourcecms.com. ar: ns1.opensourcecms.com. A 174.36.28.226, ns2.opensourcecms.com. A 174.36.29.58, . OPT UDPsize=512 OK (114)
 
Ofloo said:
different gtld-servers.net different result?

Nah, every .com server gives you the same reply:

Code:
opensourcecms.com.	172800	IN	NS	ns1.opensourcecms.com.
opensourcecms.com.	172800	IN	NS	ns2.opensourcecms.com.

That's all they need to give to you, and that's all they do. It goes wrong in the next stage, when you query "some" nameserver to give you the A record for the nameservers you got from the .com servers.

Unfortunately, dig doesn't print the IP address of the DNS server producing the final lookups, whether they succeed or fail. I have no idea why some lookups work and others fail.

The UDP checksum errors are cause for worry though, you should never see those.

You could look into OpenDNS (https://www.opendns.com/start/device/bind) for testing purposes. Use their DNS servers as forwarders in named.conf and see if these problems persist.
 
DutchDaemon said:
You could look into OpenDNS (https://www.opendns.com/start/device/bind) for testing purposes. Use their DNS servers as forwarders in named.conf and see if these problems persist.

Do not use OpenDNS server, use your ISP's forward server. OpenDNS may be good for your desktop but not good for servers. They break few things and good luck getting anti spam RBL working with them. Many slashdot geeks consider OpenDNS as a scam - see http://news.slashdot.org/comments.pl?sid=1120359&cid=26771895. I won't use them on desktop too...
 
I suggested OpenDNS for testing purposes only. Just to get the problem diagnosed. It is certainly not a serious option, and indeed, it breaks RBLs.
 
from the moment the forwarders are set the problem is gone, i could use my isp however i don't like to do so cause they have content filters in place ordered by government, in order to filter specific sites.

But isn't there a way to fix this, i would assume one should be able to run dns like this?

any suggestions what could cause the UDP checksum errors ?
 
Instead of setting OpenDNS as forwarders, you could set them as 2nd and 3rd resolver behind 127.0.0.1 in /etc/resolv.conf. That way they will only kick in when localhost can't resolve a host. I'm not sure about the ckecksum errors. I know most network cards have tcp checksum offloading (which may show up in tcpdump/wireshark as 'checksum errors' -- harmless), but I'm not sure whether they do udp checksum offloading producing the same type of error. If you have a different NIC laying around, you could try that.
 
i did ifconfig re0 -txcsum -rxcsum

result:

Code:
narf# tcpdump -vv -s 0 -pnli re0 proto UDP and port 53
tcpdump: listening on re0, link-type EN10MB (Ethernet), capture size 65535 bytes
17:51:59.148724 IP (tos 0x0, ttl 64, id 7163, offset 0, flags [none], proto UDP (17), length 74) 212.71.19.98.60138 > 192.41.162.30.53: [udp sum ok] 49721% [1au] A? opensourcecms.com. ar: . OPT UDPsize=4096 OK (46)
17:51:59.257627 IP (tos 0x0, ttl 52, id 0, offset 0, flags [DF], proto UDP (17), length 142) 192.41.162.30.53 > 212.71.19.98.60138: [udp sum ok] 49721- q: A? opensourcecms.com. 0/2/3 ns: opensourcecms.com. NS ns1.opensourcecms.com., opensourcecms.com. NS ns2.opensourcecms.com. ar: ns1.opensourcecms.com. A 174.36.28.226, ns2.opensourcecms.com. A 174.36.29.58, . OPT UDPsize=512 OK (114)

I will test a different NIC however after running the ifconfig command i didn't see any udp checksum errors anymore.. not in these queries and not in any other however this doesn't solve the problem.
 
I'm still intrigued by the findings of posts 20/21 above. If you can correlate failed DNS lookups in one console with a tcpdump on that 102 address in another console, you really should try to find out why it even uses that address. I see you have your domain set as domain/search in /etc/resolv.conf. Any chance there's something going on in that zone file (e.g. records pointing to that 102 address)?
 
of course there is records in zone files pointing to that address but those are just A records, .. there is no search or domain that would suggest otherwise in resolv.conf there used to be, however I've removed those.

I think it is really strange that this server is doing a dns query on 98 because I can't see why it would still do that.

except for it being a slave server, and this server has the same dns problem it doesn't resolve opensourcecms.com either

and now the dns ofcourse only shows the above in previous post only it doesn't show the 102 anymore except for other look ups but that might be because some processes might have the name server cached.
 
[solved]

I finally found out what the problem was, .. blackhole { bogusnets; }; contained IP range of root servers.

And it works now however the udp checksums still appear.
 
Back
Top