1. Should ISC change the default logging for lame servers to disabled?
Well, since you asked: the lame server logging goes back to when the internet was a small, collegial place and one wrote a quick note to a friend to fix these issues. And people who accidentally had a lame server were embarrassed. Those days, sadly, are gone.
The current logging only tells the victim why a query failed; it's pretty much useless unless troubleshooting a persistent, impactful problem. And at that point, it's easy enough to turn on for the duration. So I'd vote for disabled - and the ability to enable for resolution of queries to specific domains/nameservers via rndc for troubleshooting.
What I think would be more useful is if named actually reported the issues to where they'd do some good. Perhaps a DNS extension "I got an invalid message from you" - so it shows up in the log of the server (and administrator) with the problem. (I'd worry about denial of service, though if the server is in fact lame, it's not providing service - at least to that zone . Abuse of the reporting mechanism is the main risk, and avoiding it would take some careful engineering.)
Or, perhaps logged to a 'troubled' list of nameservers like the email RBL blacklists. People don't like being on 'bad citizen' lists, so if that list sent the whois registered technical contact for the domain an e-mail once a week in addition to making the list public... maybe some shame would work. But it's probably a dream. And there'd be a lot of fingers pointed at client firewalls...
Since choice 2 is out-of-band, it would be a lot easier to put in place - if someone (ISC?) volunteered to host the list...
In general, logging is most useful when the data goes to someone who can do something about it. Logging at the victim is useful for isolating a problem - but if no-one is actually troubleshooting (and won't), it's largely wasted.
DNSSEC is another area where issues need to be forwarded to the source, not the victim.
That's my 3 cents. -- Timothe Litt ACM Distinguished Engineer -------------------------- This communication may not represent the ACM or my employer's views, if any, on the matters discussed.
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
