Mark, Mat, Mat wrote: > End users will get confused by this, but then there are plenty of > other possibilities with and without DNS they may get confused about. > I think providing help to them should be dealt with by the OS instead > of bloating DNS. Upon return of any error by DNS (or any other > subsystem) it can show them a useful, platform-dependent message how > to fix it.
Mark Andrews wrote: > Additionally you can detect a DNSSEC failure by asking > queries with and without the CD bit set. > > Most DNSSEC failures can be diagnosed with dig, knowing the > current time and date and access to named.conf for the trust > anchors. There are actually easier to diagnose than most > other DNS failure issues. I agree with both of you, but you are missing the point. The problem space is users that don't know about DNS, and that don't have a local validating resolver. So there is no point of even considering dig. As soon as applications (or local stub resolvers) are validating, that would be the place to generate a "user compatible" error. But in the best case this will take years. In the mean term we are stuck with dummy users, and ISPs that might want to enable validation, but might also be kept off by the cost that unexplainable (or rather unexplained) failures will produce (Helpdesk). Being able to return 'something' in case of validation failures (and only them, not any SERVFAIL!) looks as it were in the interest of the adoption of DNSSEC. Obviously there are parallels to NXDOMAIN rewriting. However, the major difference I see is that NXDOMAIN is a clear message, known by the OSs and applications, that has basically one meaning. SERVFAIL is more like 'didn't work. go figure.' And the good thing is that 'validation error rewriting' could be abandoned again if DNSSEC arrives at the OS/applications. Gilles _______________________________________________ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
