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
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
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.
>
>
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
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
> 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
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
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.
>
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