I have set up a DNS-server on SLES10 (currently bind 9.6) on a multi-homed server. This server can be queried from all internal networks and delivers answers for all internal networks. We have two separate DNS "master" zones. Each of these zones is being served by a number of authoritative Windows-DNS-servers.

Now my linux-server is a secondary DNS server for one of these zones (private internal zone) and acting as forwarder for the other zone (public internal zone).

Until recently this setup worked without problems. Now I get - upon querying the public internal zone (e.g. by the host command on a linux client) the error-message

;; Truncated, retrying in TCP mode

a wireshark-dump revealed the cause of this: The first query goes out in UDP mode, the answer does not fit into UDP (due to the longish list of authoritative NS), then it is retried in TCP mode, delivering the right answer.

Now the question: Can I configure my bind to query the forwarders in TCP mode without trying UDP first?

Update: Trying my hand on ASCII-art...

+--------------+   +--------------+   +-----------------+
| W2K8R2 DNS   |   | SLES 10 DNS  |   | W2K8R2 DNS      |
| Zone private +---+ All internal +---+ Zone public     |
| internal 2x  |   |   Zones      |   | internal 30+ x  |
+--------------+   +-+----------+-+   +-----------------+
                     |          |
                  +--+---+   +--+---+
                  |Client|   |Client|
                  +------+   +------+
  • a small diagram of this would be useful - I'm struggling to figure out which server is which from your description.
    – Alnitak
    Jan 10, 2012 at 10:39
  • somewhat better, although it's still unclear between exactly which hosts you're running this host command, and what query is being sent.
    – Alnitak
    Jan 10, 2012 at 21:05
  • The clients request via SLES10 the entries from zone public internal. The zone private internal does not suffer - as there are only 2 NS entries there.
    – Nils
    Jan 10, 2012 at 21:20
  • and the clients are just plain stub resolvers?
    – Alnitak
    Jan 10, 2012 at 21:24
  • suggest you add minimal-responses: yes to the BIND config on SLES 10 - it may reduce the response sizes. In any event, most normal queries won't exceed the 512 byte limit.
    – Alnitak
    Jan 10, 2012 at 21:27

2 Answers 2


First, I would not call that an error, just an informational message.

Second, DNS servers will always answer UDP queries (BIND at least, I cannot find options to disable UDP) and clients will always (?) try to send a UDP query first (for example there are no options in resolv.conf to change that nor in the JVM) - if they fit in a UDP packet (requests usually do)

If you have a specific use case, you can specify to use TCP, e.g. in shell script use 'dig +tcp' or 'host -T' for resolution, and you can use system calls 'sethostent/gethostbyname/endhostent' (see man page) to force TCP in other cases.

If you really want to try and block UDP, the only option I can see is with an iptable rule, but I am not sure that that set up would work. I expect that DNS resolution would simply fail.

  • there's nominally a performance benefit from knowing a priori that the UDP query will fail, and trying over TCP first. See RFC 5966 for some discussion of that.
    – Alnitak
    Jan 10, 2012 at 12:51
  • @Alnitak and I would like to get that benefit.
    – Nils
    Jan 10, 2012 at 20:38
  • 1
    @Nils so we need to figure out why EDNS apparently isn't working...
    – Alnitak
    Jan 10, 2012 at 20:39
  • I have no special use case - the clients will use their resolver library - but each request and each answer will go over the network twice - I don`t like that.
    – Nils
    Jan 10, 2012 at 20:51
  • @Nils, the issue is that the client decide UDP/TCP, but the server known the size of the answer. Jan 11, 2012 at 10:44

Your BIND server should be using EDNS (see RFC 6891) to allow UDP packets longer than 512 bytes.

options {
    edns-udp-size 4096;
    max-udp-size 4096;

This should permit your large NS set to be retrieved over UDP, without requiring the overhead of a TCP connection for other smaller queries.

Note however that these are actually the default values. If EDNS isn't being used, either something is blocking it, or the servers receiving the EDNS options aren't supporting it.

Also, note that host doesn't support EDNS. It's perfectly possible that your forwarder -> server queries are already using EDNS, and you just can't see it when you try with your local client.

Try dig +bufsize=4096 @server hostname A instead of using host.

  • Who should be using this? Propably both my server and my forwarders from zone "public internal"?
    – Nils
    Jan 10, 2012 at 20:49
  • What is the sense of sending the complete list of NS in the answer anyway?
    – Nils
    Jan 10, 2012 at 20:52
  • @Nils the DNS protocol requires that the complete set of entries matching the same (QNAME, QTYPE and QCLASS) tuple are indivisible (aka an "RRset")
    – Alnitak
    Jan 10, 2012 at 20:56
  • can you please point me to the RFC regarding this RRset?
    – Nils
    Jan 10, 2012 at 21:27
  • 1
    Actaully host uses the standard resolver library, and on my workstation it supports EDNS0. To test if the requests specifies EDNS0, run 'tcpdump -x port 53' and the hex dump should contain (towards the end, in the additional section) the sequence 0029 1000 0000 8000 0000, which is the binary representation of the OPT RR. Jan 11, 2012 at 12:00

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.