[dns-operations] too many round robin RR's / tcp and lookup errors?

[Patrick, Robert (CONTR)]

Is the mobile device submitting DNS queries without EDNS enabled in options, and/or is the mobile device forwarding DNS queries through a server which performs recursion without EDNS enabled?

"the hostname in question was using round robin DNS, and had enough records that the response size was over 512 bytes, thus the truncate bit was set and the resolver is supposed to retry over TCP.  So we had them drop enough records to get the response under 512 bytes and the problem went away."

Betting on truncated responses to be retried via TCP should be a last resort, given that EDNS enables larger than 512 bytes within a UDP packet.  Firewall admins occasionally forget to open TCP for port 53.  Many (wrongly) believe DNS only uses UDP 53 for queries, thinking that TCP 53 is for zone transfers.

Trusting the firewall to track EDNS negotiation (e.g. "client auto" in newer Cisco ASA versions) initiated via client query puts a lot of faith in the firewall to get DNS right, rather than in your DNS server.

While EDNS is necessary for DNSSEC, EDNS is a separate feature and useful for any scenario where DNS packet size may increase above 512 bytes.  Best practices would seem to indicate any product shipping today should operate with EDNS enabled, but don't under-estimate embedded or mobile devices potentially lagging behind in this regard.

UDP packets for DNS using EDNS can exceed 512 bytes in size, allowing queries and responses to be processed immediately, without having to failback to TCP (and relying upon the client and/or firewalls in the path to allow queries via TCP).

Also, if any firewalls in the path are set to discard fragments, large EDNS responses that exceed a single packet may still run into problems.

For troubleshooting, I'm not sure if the latest version of dig supports an option to query without EDNS, but drill (from ldns package) can be used to generate queries without EDNS.

--/--

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.dns-oarc.net/pipermail/dns-operations/attachments/20120916/39b947ba/attachment.html>