Re: nominalism of standards (Re: TCP fallback on timeout)

2017-04-28 Thread 顧孟勤
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

nominalism of standards (Re: TCP fallback on timeout)

2017-04-28 Thread Paul Vixie via Unbound-users
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

Re: TCP fallback on timeout

2017-04-28 Thread Paul Vixie via Unbound-users
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. > >

Re: TCP fallback on timeout

2017-04-28 Thread David Conrad via Unbound-users
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

Re: TCP fallback on timeout

2017-04-27 Thread Paul Vixie via Unbound-users
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

Re: TCP fallback on timeout

2017-04-27 Thread Havard Eidnes via Unbound-users
> 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

Re: TCP fallback on timeout

2017-04-27 Thread Jacob Hoffman-Andrews via Unbound-users
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

Re: TCP fallback on timeout

2017-04-27 Thread Viktor Dukhovni via Unbound-users
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. >

TCP fallback on timeout

2017-04-26 Thread Jacob Hoffman-Andrews via Unbound-users
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