David Conrad wrote on 2019-02-12 15:10:
You missed my point. The IETF declared NATs heretical and as a
result, a zillion people did it in a zillion different ways, creating
a huge mess.
i remember this. and i agree. had IAB said "this specification is
inadequate, let's get firewall traversal working before we publish",
rather than "it is heretical and must not be done", a lot of pain and
waste would have been avoided.
... Lots of people are implementing sending/receiving DNS
queries/responses over HTTPS.
since i did it myself (https://github.com/BII-Lab/DNSoverHTTP) years
before DoH was thought of, i can scarcely disagree.
DoH simply codifies one way of doing it so that network managers,
software developers, etc., have a chance to develop management
systems for it.
really? "simply"? i don't think it's that simple. here's the part of RFC
8484 that i would have expected to cause a "discuss" event in IESG
before allowing publication:
<<Two primary use cases were considered during this protocol's
development. These use cases are preventing on-path devices from
interfering with DNS operations, ...>>
that's not a simple thing. IESG should have said, "that part is
problematic, please make this protocol optional for the network
operators and controllable their on-path devices."
by putting that text in and leaving it in, this becomes a political
project not a technical one. IESG had the ability to say, please find a
better way to solve this problem, that disenfranchises nobody.
as it happens, nothing stops a web browser or other such client from
using DoT, and it's possible that the right answer was to say, DoT will
answer every technical need that this RFC describes, but none of its
political needs, and we don't want to be in the politics business.
to validate whether RFC 8484's goal is political, let's ponder whether
the document would have been perfectly unhurt by the non-enumeration of
this use case. i think yes. so, why mention it?
i'd like the same level of freedom when it comes to how DNS is
served.
Then force the folks on your network to install a cert so you can
filter out DoH. Contrary to your assertion, I doubt netflow will let
you discriminate between good and evil. You have to have visibility
to do that.
i have embedded devices which don't let me install certs inside them,
and i don't think i'm alone. the general name for what you're describing
is "web application firewall" and it simply breaks anything that won't
cooperate -- which is the policy i'm going to need, if any so-called
"public DNS" server shares a DoH responder address with any other
service i care about. this remains to be seen. the market will help decide.
i'm surprised and fascinated by your vision of what my security needs
are -- even though you have misstated them here -- but you're wrong on
the facts, and the economics. if you are willing to spend the serious
effort it would take to fully engage with the lived experience of modern
CISO's, then we should take that topic up 1x1.
--
P Vixie
_______________________________________________
DNSOP mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dnsop
