Ted Lemon wrote:
On Jan 26, 2018, at 2:27 PM, 神明達哉 <[email protected]
<mailto:[email protected]>> wrote:
It's not clear to me, and either way I believe the draft should be
clearer on these points (see also my latest response to Petr. If the
intent of the draft is to prohibit any user customization, it should
explicitly say so (with, IMO, some more explanation); if the intent is
to allow such customization, I believe we should actually loosen it to
SHOULDs).
There was no clear intent at the beginning when this was an individual
submission, but the discussion on the individual submission and on the
call for adoption seemed to show a fairly strong consensus that looking
up localhost using DNS is a significant security vulnerability, so MUST
is the right language. Of course, I was part of that consensus, so I may
be biased!
i was outside that consensus at the time, and remain so now. the
security aspects aren't paramount and aren't clearly identified. this
change could be made in the style of RFC 1535, referring only to the
operating system API behaviour and not mentioning on-the-wire DNS
protocol behaviour at all. to the extent that it does the latter it
could be a strong recommendation ("SHOULD") and have the same impact.
many operators will ignore this advice no matter how it's phrased, and
nothing bad will happen to them when they ignore it, and that's "not a
MUST" by definition. reasons to ignore include: not wanting to give any
of their customers any reason to call in and say "the internet is down".
the ietf is always at its best when its claims are of the form, "if you
want to do _this_, here's a way to do it interoperably." can that be done?
--
P Vixie
_______________________________________________
DNSOP mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dnsop
