litt at acm.org
Tue Jan 8 13:19:56 UTC 2013
> 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
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
DNSSEC is another area where issues need to be forwarded to the source,
not the victim.
That's my 3 cents.
ACM Distinguished Engineer
This communication may not represent the ACM or my employer's views,
if any, on the matters discussed.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 5159 bytes
Desc: S/MIME Cryptographic Signature
More information about the bind-users