Re: nominalism of standards (Re: TCP fallback on timeout)
You're off course right about the long tail of outdated devices. But you should have more trust into what can happen, if only there is sufficient incentive. Look at how long it took for HTTPS to get any meaningful traction. For the longest time, only e-commerce bothered with encryption. Then we had Snowden, Letsencrypt, and the browser-manufacturers/search-engines getting a lot more strict about encryption. And all of a sudden, people either upgraded their ancient software, installed a proxy that hides the limitations from the internet at large, or switched to a cloud provider that ensures modern standards. I'm sure the same would happen if you gave people enough incentive to switch to TCP enabled name servers. Many administrator would probably discover that they already support TCP or could do so with minimal effort. And the rest would use one of the approaches outlined above. As an example for how to provide this incentive, imagine Letsencrypt requiring TCP. Half a year from now, they won't allow new accounts without TCP support. A year from now, they won't sign new domains unless they can be verified by TCP. And two years from now, even certificate renewals require TCP. If this policy was advertised clearly enough, I'd expect the transition to work just fine. The last stragglers are then the same people who wouldn't use Letsencrypt in the first place, as they haven't even made the switch to HTTPS yet. You'll never completely eliminate the long tail. But you shouldn't fear it either. Markus On Apr 28, 2017 16:50, "Paul Vixie via Unbound-users" < unbound-users@unbound.net> wrote: Paul Vixie wrote: > > >> ... > > > > > > i'll go further: i think that's a good clarification of and alteration > > > to the standards. i just don't think it's wise to expect a tcp-only > > > initiator, or a tcp-only responder, to function reliably. (ever.) so the > > > standard is nominal, and should guide other standards, but in this case > > > may give unusable guidance to implementers and operators. > > > let me put that differently and perhaps more understandably: > > > < > be able to put all of the DNS genies back into their bottles. Too many > > implementations have guessed differently when presented with a loose > > specification, and interoperability today is a moving, organic target. > > When I periodically itch to rewrite the specification from scratch, I > > know there are too many things that must be said that also cannot be > > said. It’s as though, in a discussion of the meaning of some bit > > pattern, a modern description of the protocol—written with full > > perspective on all that has been done in the DNS field—would have to > > say, “It could mean x but some implementations will think it means y so > > you must be cautious.”>> > > > http://queue.acm.org/detail.cfm?id=1242499 > > > -- > > P Vixie > >
nominalism of standards (Re: TCP fallback on timeout)
Paul Vixie wrote: >> ... > > i'll go further: i think that's a good clarification of and alteration > to the standards. i just don't think it's wise to expect a tcp-only > initiator, or a tcp-only responder, to function reliably. (ever.) so the > standard is nominal, and should guide other standards, but in this case > may give unusable guidance to implementers and operators. let me put that differently and perhaps more understandably: <> http://queue.acm.org/detail.cfm?id=1242499 -- P Vixie
Re: TCP fallback on timeout
David Conrad wrote: > On Apr 27, 2017, 4:28 PM -0700, Paul Vixie via Unbound-users > , wrote: > >> 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. i'll go further: i think that's a good clarification of and alteration to the standards. i just don't think it's wise to expect a tcp-only initiator, or a tcp-only responder, to function reliably. (ever.) so the standard is nominal, and should guide other standards, but in this case may give unusable guidance to implementers and operators. -- P Vixie
Re: TCP fallback on timeout
On Apr 27, 2017, 4:28 PM -0700, Paul Vixie via Unbound-users , wrote: > 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
Re: TCP fallback on timeout
Havard Eidnes via Unbound-users wrote: >> 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. "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. -- P Vixie
Re: TCP fallback on timeout
> 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
Re: TCP fallback on timeout
On 04/27/2017 07:27 AM, Viktor Dukhovni via Unbound-users wrote: > On Wed, Apr 26, 2017 at 08:14:09PM -0700, Jacob Hoffman-Andrews wrote: > >> 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. Thanks for the info. Another question: For CA queries in general (A, , 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?
Re: TCP fallback on timeout
On Wed, Apr 26, 2017 at 08:14:09PM -0700, Jacob Hoffman-Andrews wrote: > 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. -- Viktor.
TCP fallback on timeout
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
