10

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|
                  +------+   +------+
Nils
  • 7,657
  • 3
  • 31
  • 71
  • a small diagram of this would be useful - I'm struggling to figure out which server is which from your description. – Alnitak Jan 10 '12 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 '12 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 '12 at 21:20
  • and the clients are just plain stub resolvers? – Alnitak Jan 10 '12 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 '12 at 21:27

2 Answers2

9

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.

Dan Andreatta
  • 5,384
  • 2
  • 23
  • 14
  • 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 '12 at 12:51
  • @Alnitak and I would like to get that benefit. – Nils Jan 10 '12 at 20:38
  • 1
    @Nils so we need to figure out why EDNS apparently isn't working... – Alnitak Jan 10 '12 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 '12 at 20:51
  • @Nils, the issue is that the client decide UDP/TCP, but the server known the size of the answer. – Dan Andreatta Jan 11 '12 at 10:44
  • GNU libc has a (non documented) option for forcing TCP for DNS resolution: its `use-vc` (in res_init.c). It can be set with `options use-vc` in resolv.conf or in the environment: `RES_OPTIONS="set-vc"`. – ysdx Feb 10 '15 at 17:02
4

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.

Community
  • 1
Alnitak
  • 20,901
  • 3
  • 48
  • 81
  • Who should be using this? Propably both my server and my forwarders from zone "public internal"? – Nils Jan 10 '12 at 20:49
  • What is the sense of sending the complete list of NS in the answer anyway? – Nils Jan 10 '12 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 '12 at 20:56
  • can you please point me to the RFC regarding this RRset? – Nils Jan 10 '12 at 21:27
  • I can't quote chapter and verse, it might be in RFC 1034 / 5 somewhere. If you search for "RRset indivisible" on Google you'll find stuff in RFC 5507 about it, although that's not where it's actually specified. – Alnitak Jan 10 '12 at 21:29
  • 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. – Dan Andreatta Jan 11 '12 at 12:00
  • @DanAndreatta On what OS? On MacOS X, the standard resolver library _does_ support EDNS0, but only when told to by setting `RES_USE_EDNS0` in the `_res.options` structure. – Alnitak Jan 11 '12 at 12:10
  • The question says Linux for the machine running `host`, requiring `option edns0` to be in `resolv.conf`. – JdeBP Jan 19 '12 at 19:11
  • @gidoBOSSftw5731 I've rejected your edit because at this point the so-called "flag day" change to recommended EDNS buffer sizes to avoid fragmentation are simply advisory, and have not been encoded in any DNS-related RFC. – Alnitak Feb 03 '21 at 12:31