>>>>> "Stephane" == Stephane Bortzmeyer <bortzmeyer@xxxxxx> writes:
Stephane> But suggesting ORNS (Open Recursive Name Servers) for
Stephane> the solution to this issue is, indeed, a bad idea (do
Stephane> note I did not say the N word), for the reasons
Stephane> explained in draft-ietf-dnsop-reflectors-are-evil-04.txt
Stephane> (reflections attack).
Hmm. All I get is that suggesting open recursive nameservers has the
harm that it creates reflection attacks. The current text of section
4 to me says that you SHOULD NOT offer recursive name service by
default and the generic recommendation is that you should not offer
recursive name service to other clients than those you need. However
if I've evaluated the harm caused by the attack, evaluated the costs
of other solutions and concluded that the best tradeoff is running an
open recursive nameserver, I can do so. That seems like a balanced
and reasonable approach.
If you intend the draft to same something else, you have some work to
do.
Stephane> There are other solutions to this issue and lists have
Stephane> already been given in this thread *and* in the I-D we
Stephane> discuss. These solutions are TSIG, local caching
Stephane> resolvers and VPN. May be there is an editorial problem
Stephane> if they are not well explained but the I-D does
Stephane> completely cover the issue of romaing users.
People have explained why the cost/benefit tradeoff may not favor
these solutions. tsig is not realistic in the current software
implementation space; it has promise for the future. VPN is very
complicated and probably not worth it if all you want is more reliable
nameservice. (I do understand the man-in-the-middle and transparent
proxy issues). Caching resolvers are problematic for deployment
complexity reasons .
_______________________________________________
Ietf@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ietf