Bug 177607 - named.conf comment to slave root suggests potentially dangerous BIND configuration
Summary: named.conf comment to slave root suggests potentially dangerous BIND configur...
Status: Closed Overcome By Events
Alias: None
Product: Base System
Classification: Unclassified
Component: conf (show other bugs)
Version: 9.1-RELEASE
Hardware: Any Any
: Normal Affects Only Me
Assignee: freebsd-bugs mailing list
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2013-04-03 12:40 UTC by Mark Knight
Modified: 2019-10-31 09:27 UTC (History)
2 users (show)

See Also:


Attachments
file.diff (446 bytes, patch)
2013-04-03 12:40 UTC, Mark Knight
no flags Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Mark Knight 2013-04-03 12:40:00 UTC
	
	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.
Comment 1 Maxim Konovalov 2013-04-03 13:03:04 UTC
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
Comment 2 Maxim Konovalov 2013-04-03 13:05:14 UTC
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
Comment 3 Mark Knight 2013-04-03 13:37:02 UTC
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
Comment 4 Maxim Konovalov 2013-04-03 15:00:20 UTC
>  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
Comment 5 Mark Knight 2013-04-03 15:51:35 UTC
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.
Comment 6 vali gholami 2017-11-26 20:43:55 UTC
MARKED AS SPAM
Comment 7 Eitan Adler freebsd_committer freebsd_triage 2018-05-20 23:52:59 UTC
For bugs matching the following conditions:
- Status == In Progress
- Assignee == "bugs@FreeBSD.org"
- Last Modified Year <= 2017

Do
- Set Status to "Open"
Comment 8 Eugene Grosbein freebsd_committer 2019-10-31 09:27:01 UTC
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.