If I do an nslookup on youtube.com, no problem, if I do one with www.youtube.com, failure. See details below.

[~] nslookup youtube.com



Non-authoritative answer:

Name: youtube.com


Name: youtube.com


Name: youtube.com


[~] nslookup www.youtube.com

;; Truncated, retrying in TCP mode.

;; Connection to for www.youtube.com failed: connection refused.

If I do the same from a Windows machine its fine, its when I do it from a Mac workstation that I get the issue.

I have rebooted, both server and workstation, I did a changeip, but nothing is working.

Any recommendations?

2 Answers 2


Just turn IPv6 off, it should work then :)

  • www.youtube.com isn't advertising any IPv6 addresses, how would this help?
    – sysadmin1138
    Apr 4, 2011 at 14:21
  • I went to system preferences, Network, and turned off ipv6 and everything works now!!! Thank you I had given up. This is so uncool, I cannot raise the grade on this answer since I dont have enough reputation. This is THE CORRECT ANSWER, ignore the other one. Note I did this on the Mac Mini server. Apr 5, 2011 at 4:36

For some reason the osx workstation is issuing UDP dns requests and the reply was too big to fit into a UDP packet (hence it was truncated). The dns resolver on the osx machine is turning around and trying to issue the same request using tcp (which it should have in the first place). THEN something is preventing the osx machine from contacting the dns server using a tcp socket on port 53. Do a tcpdump and watch for icmp messages, specifically "Administratively blocked" messages which generally are hawked back from a fw or nacl when it blocks a connection.

That would be a start. Also, run dig instead of nslookup.

  • dig results in exactly the same result for the www.youtube.com case. Mar 17, 2011 at 23:29
  • Oh yeah, if I do a dig +ignore www.youtube.com, it works fine as well. I think it is a UDP packet size issue, but how do I get to the bottom of it :( Mar 17, 2011 at 23:41
  • Keep in mind that Directory Services doesn't use the same code dig and nslookup do, which is the ISC standard way of doing it (that doesn't mean it's the best way, just that that's how it works with ISC's BIND utilities everywhere.) It's probably doing something similar, but not absolutely certain. As to the TCP failure, the OP's router is handling DNS (see the address it's querying: and doesn't support TCP DNS. The fix for that is to override DNS in Control Panel > Internet & Wireless > Network.
    – geekosaur
    Mar 17, 2011 at 23:47
  • I had the same problem - firewall rules for DNS were allowing UDP but not TCP, and enabling 53/tcp in the firewall fixed the problem - IPv6 was already disabled - nothing to do with that at all in my case.
    – Screwtape
    Nov 3, 2017 at 12:28

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .