Re: [Doh] [DNSOP] [Ext] Re: Alternate proposal for transport indication in draft-ietf-dnsop-dns-wireformat-http

[Ben Schwartz <[e-mail]>]

If the stub and forwarder are both on your laptop, why do you need to
truncate?  Local UDP should have extremely large MTU.

On Wed, Apr 4, 2018 at 12:42 PM, Paul Vixie <[e-mail]> wrote:

>
>
> Ted Lemon wrote:
>
>> On Apr 4, 2018, at 11:49 AM, Paul Vixie <[e-mail]
>> <mailto:[e-mail]>> wrote:
>>
>>> this is a far thinner solution than a full-service resolver, which
>>> would require local configuration and monitoring and so on, as well as
>>> topology stability that can't be guaranteed.
>>>
>>
>> For your laptop use case, why wouldn't you just have the thing running
>> on the laptop do truncation if the answer is too long?
>>
>
> that would be low fidelity. i need to run clients whose internet
> experience will not be influenced by middleboxes.
>
> I admit that this is more code, but it's not a lot more code, and
>> what you're doing instead is pretty hacky.
>>
>
> feel free to try it out:
>
> https://github.com/BII-Lab/DNSoverHTTP
>
> or:
>
> https://github.com/BII-Lab/DNSoverHTTPinGO
>
> these are out of date with respect to the current draft, but each works. i
> would like to see a standard that they can conform to, so that i'm safe
> building a larger infrastructure.
>
> The fact that it's not required to implement doesn't mean that it
>> doesn't contribute to the camel problem.
>>
>
> are we at the point where any of us can call anything we see no use for
> part of the camel problem? i'm hoping not, and so i'm going to ignore your
> statement here.
>
> "if you want to do this, here's an interoperable method" is this group's
> meme. it's not "this is the best engineering solution we were able to
> create for the problem we are willing to admit you might have."
>
>
> --
> P Vixie
>
> _______________________________________________
> DNSOP mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dnsop
>