Timothe Litt 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 
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.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 5159 bytes
Desc: S/MIME Cryptographic Signature
URL: <https://lists.isc.org/pipermail/bind-users/attachments/20130108/cda1dcb2/attachment.bin>

More information about the bind-users mailing list