The discussion had covered the failure mode problem. There is substantial agreement that it's better for a stub that issues a query for localhost to fail than to succeed. You seem to disagree.
You haven't stated a reason for disagreeing—instead you've vigorously asserted that this is true. It's fine for you to do this, but if you were to get your way, that would be exactly the bad outcome I want to avoid. So if there really is a problem here, it would be good for you to make it clear. Your stated desire to preserve flexibility makes sense to me, but it doesn't contradict the reason already given for *not *providing that flexibility. Is there some *other* reason why this is important to you, or is that it? On Sep 7, 2017 8:06 PM, "Mark Andrews" <ma...@isc.org> wrote: > > In message <bfaecdaf-8f4b-4c8d-ab7e-1615bd54e...@fugue.com>, Ted Lemon > writes: > > > > On Sep 7, 2017, at 12:59 AM, Mark Andrews <ma...@isc.org> wrote: > > > I shouldn't BE FORCED to hard code special LOCALHOST rules into DNS > > > tools. Lookups should "just work" like they did before the root > > > zone was signed. > > > > Because...? > > Because there are things you can do with localhost as a DNS zone > that you can't do with /etc/hosts, NIS, etc. as they are limited > to addresses only. > > Localhost should work just like home.arpa. The tools we use shouldn't > need special knowledge. Special knowledge means EVERYTHING needs > to be tested to see if it works with localhost as well and regular > names. That testing will get missed. If it doesn't get missed it > costs more money. Workarounds for different behavior increases the > probability of bugs being introduced as there will be seperate code > paths. > > If I want to add a local trust anchor for localhost I will then > need additional code to disable the workaround for the fact the > root doesn't have a insecure delegation. > > Mark > -- > Mark Andrews, ISC > 1 Seymour St., Dundas Valley, NSW 2117, Australia > PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org >
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
