I'm trying to understand Unbound's TCP fallback better. Is it expected
that Unbound will fall back to TCP when UDP queries timeout, or only if
it receives a truncated ANSWER?
Specifically, I'm trying to make CAA queries, and finding that, when
querying a certain DNS provider (NetRegistry), UDP queries time out but
TCP queries succeed. Specifically, if I set tcp-upstream: yes, I can get
a response, but if I set tcp-upstream: no (the default), I get timeouts
from Unbound, and I never see it fall back to TCP.
I'm considering running two Unbound instances: one with tcp-upstream:
yes, and one with tcp-upstream: no, and having my application implement
fallback between the two. That is, if a query to the first instance
times out, query the second instance. Is that a reasonable approach?
Thanks,
Jacob
I'm trying to understand Unbound's TCP fallback better. Is it expected
that Unbound will fall back to TCP when UDP queries timeout, or only if
it receives a truncated ANSWER?
Only when truncated as you observed.
Specifically, I'm trying to make CAA queries, and finding that, when
querying a certain DNS provider (NetRegistry), UDP queries time out but
TCP queries succeed.
That provider has a misconfigured (often Arbor Networks) firewall
in front of their nameservers, and the firewall is dropping queries
for all but a set of "standard" RRtypes. Ofen in my experience
(when the firewall is Arbor Networks) IPv6 UDP queries also work,
when the nameservers have IPv6 addresses. In other words, the
filtering is in place only for UDP+IPv4.
The right thing to do is to not implement work-arounds for the
problem on the client end. Instead, let operational errors lead
to failure, but notify the operator so they remediate the issue.
This will fix lookup issues for CAA, CDS, TLSA, SMIMEA, OPENPGPKEY,
whether the resolver is unbound, BIND, ...
If you email me a small list of problem domains (served by the
problem nameservers), I can get the ball rolling, open a new
entry under:
https://github.com/dns-violations/dns-violations
and notify the errant provider.
Thanks for the info.
Another question: For CA queries in general (A, AAAA, TXT, CAA), Let's
Encrypt has gotten feedback that using TCP to query authoritative
resolvers is more secure and less likely to be spoofed. Unfortunately,
DNS servers aren't required to support TCP. This is another reason why
we've been considering running to recursive resolvers, one with
tcp-upstream: yes, and one with tcp-upstream: no. The idea would be that
the CA software (Boulder) would first attempt to query the tcp-upstream:
yes instance, and fall back to the tcp-upstream: no instance on errors.
In your opinion, is this a reasonable setup, and does it meaningfully
increase protections against spoofing?
Unfortunately, DNS servers aren't required to support TCP.
IMHO, that is an all too commonly held misconception. Publishing name
servers need to support TCP as well. I'm pretty sure section 4.2 of
RFC 1035 mandates it. It doesn't use the formal requirements keywords
because it predates the RFC which defined their use in this document
series.
Regards,
- Håvard
"mandate" and "required" would be stronger words than the context could
sustain.
in practical terms, there are and have always been and will always be
authority name servers who never set TC=1 on UDP, and which do not
support TCP, either by design or because of firewalls. these name
servers work just fine, and that "works just fine" attribute has first
mover advantage: any client that uses only TCP will get no service from
those name servers, and the client not the server will be found "at
fault" for the nonfunction, and so the client will be "fixed" rather
than the server.
so in effect, TCP is not required, and will never be required. the
installed base and its long tail matter more than the wording of 1035.
https://tools.ietf.org/html/rfc7766, proposed standard updates 1035 and 1123:
" This document therefore updates the core DNS protocol specifications
such that support for TCP is henceforth a REQUIRED part of a full DNS
protocol implementation."
Yes, I know about the "installed base" argument and usually agree with it. However, Internet standards evolve and, when it makes sense, the Internet follows suit. In this case, I think the benefits of TCP support given DNSSEC, privacy, spoof protection, etc., will be sufficient to move the needle over time.
Regards,
-drc