Ted Lemon wrote:
On Apr 4, 2018, at 11:49 AM, Paul Vixie <p...@redbarn.org
<mailto:p...@redbarn.org>> 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
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
