The comment in the default named.conf encourages users to slave the root but does not provide an example configuration that prevent a name server being used as an amplifier in DDOS attacks. Users who adopt this configuration by uncommenting the supplied entries are likely to receive abuse reports or be unwitting participants in a DDOS attack. Fix: Consider applying a patch such as enclosed below to the default configuration file to help users avoid this misconfiguration if they uncomment the relevant slave zone configurations. How-To-Repeat: Uncomment zone "." entry and then run dig -t ns @x.x.x.x . from the Internet.
Hello, [...] > >Description: > > The comment in the default named.conf encourages users to slave the root but does not provide > an example configuration that prevent a name server being used as an amplifier in DDOS attacks. > Users who adopt this configuration by uncommenting the supplied entries are likely to receive > abuse reports or be unwitting participants in a DDOS attack. > >How-To-Repeat: > Uncomment zone "." entry and then run dig -t ns @x.x.x.x . from the Internet. With the "listen-on { 127.0.0.1; };" at the line 22 it won't hurt anybody. If you are going to change this setting than you have more work to secure your named server. -- Maxim Konovalov
Just for the record, mail to the submitter bounces: ----- Transcript of session follows ----- 550 5.1.2 <markk@lnigma.org>... Host unknown (Name server: lnigma.org: host not found) -- Maxim Konovalov
Sorry, typo in my mail address - should be markk@knigma.org. In the proposed patch - allow-query { localnets; }; would be better than localhost. I still think it better to make this example more robust. Best regards, Mark
> Sorry, typo in my mail address - should be markk@knigma.org. > > In the proposed patch - allow-query { localnets; }; would be better than > localhost. I still think it better to make this example more robust. > I corrected your address in the Reply-To header. I still think that our named.conf is not a BIND security guide. But this is just my opinion and I leave the PR. Still, don't understand why the PR has Severity serious and Priority high if we are speaking about the commented out example (even uncommented it won't hurt anybody) in the daemon that doesn't run by default. -- Maxim Konovalov
Thanks for fixing up the Repy-To. I stupidly uncommented these lines on a box *assuming* it was safe. Once upon a time responding to root DNS queries wouldn't have been considered a bad thing. However today I received an abuse@ report to thank me for my error. The comment above the stanza doesn't mention the amplifier threat (although it does mention general caution) and appears to offer a good suggestion for improving resilience and reducing net traffic that's "ready to run". Clearly it isn't. My rationale was that it's a quick and easy fix and given the recent attacks it was worth giving this a high priority in the name of pro-active security. It's a potential security issue and is therefore serious. Apologies if I've exaggerated the threat.
MARKED AS SPAM
For bugs matching the following conditions: - Status == In Progress - Assignee == "bugs@FreeBSD.org" - Last Modified Year <= 2017 Do - Set Status to "Open"
ISC BIND is not part of FreeBSD base system anymore in any supported branch. Default configuration is not affected. Default named.conf file is not right place for comprehensive BIND security guide. Closing this PR that has not gain much attention for 6 years.