Bug 740894 - Recursion disabled and bogos
Recursion disabled and bogos
Status: CLOSED ERRATA
Product: Fedora
Classification: Fedora
Component: bind (Show other bugs)
19
Unspecified Unspecified
unspecified Severity high
: ---
: ---
Assigned To: Tomáš Hozza
Fedora Extras Quality Assurance
:
: 929336 (view as bug list)
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2011-09-23 13:02 EDT by Renich Bon Ciric
Modified: 2013-06-03 04:54 EDT (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2013-06-03 04:54:23 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Renich Bon Ciric 2011-09-23 13:02:30 EDT
Hello,

I've recently became aware of these documents:

http://www.team-cymru.org/Services/Resolvers/
http://www.us-cert.gov/reading_room/DNS-recursion033006.pdf
http://www.cymru.com/Documents/secure-bind-template.html
http://www.team-cymru.org/Services/Bogons/dns.html

Since I've been contacted by switch.ch; regarding my DNS configuration. I think much of these docs should be implemented in the Fedora's default Bind installation; even, though, we use DNSSEC and all.

Anyway, this is a security issue and should be attended in some way, IMHO.
Comment 1 Adam Tkac 2011-09-30 05:48:09 EDT
In my opinion our default named.conf configuration is secure enough.

1. named listens only on 127.0.0.1:53 and ::1:53
2. DNSSEC validation is enabled
3. queries are accepted only from localhost

This is enough for small or medium servers which aren't exposed on the Internet.

If the server is exposed on the Internet you are right our default configuration is not sufficient. However configuration of big server needs experienced admin and fine-tuning of various options and I would rather keep default named.conf clean and readable.

What is your opinion about this?
Comment 2 Renich Bon Ciric 2011-09-30 18:44:45 EDT
(In reply to comment #1)
> In my opinion our default named.conf configuration is secure enough.
> 
> 1. named listens only on 127.0.0.1:53 and ::1:53
> 2. DNSSEC validation is enabled
> 3. queries are accepted only from localhost
> 
> This is enough for small or medium servers which aren't exposed on the
> Internet.
>
> If the server is exposed on the Internet you are right our default
> configuration is not sufficient. However configuration of big server needs
> experienced admin and fine-tuning of various options and I would rather keep
> default named.conf clean and readable.
> 
> What is your opinion about this?

Thank you for replying.

I partly agree with you. If the configuration is to be local, IMHO, there is no need for DNSSEC. Specially if queries are accepted from localhost only; which would convert it into a caching only installation.

Usually, newbies, would just remove the localhost constraints configured in the server and start using it. These servers would be, immediately, exposed if they allow recursion. Switch.ch has complained. CloudSigma has, already, complained about this and I am sure this is the case for most of the ISPs that allow full control of your server.

I think we could help prevent this a little if we offer a mid-point configuration; with remote and local views; disabling recursion for remotes.

A small/medium company would, definitely, benefit from an internet-ready configuration so they could start using it immediately.

I think we could offer a much better configuration; as I mentioned you earlier. 

I'd like to offer a simple example, if I may, for you to evaluate. If not in substituting the original configuration, offering an example in /usr/share/docs/bind-X/named.conf.example or something like that.

I'll get back to you with this example today or tomorrow.

Some examples of improvement would be:

- setting up a local and remote views by default; with recursion disabled for remotes.

- using the /etc/dhcp directory to store master and slave configurations there (include /etc/named/{master,slave}.zones) so we keep the main config clean.

- some script to renew/regenerate the host key (and automatic inclusion o fit too.

- set up a blackhole.

I'd like you to consider this and, also, ask you to look at mandriva's configuration; which, IMHO, would be a good place to start. Also, the references I, already, pointed you at.

I say all this with respect for what mainstream offers and what Fedora offers. I  am just looking for an opportunity to improve.

I could help you with these; if I may ;=)
Comment 3 Fedora End Of Life 2013-04-03 09:46:30 EDT
This bug appears to have been reported against 'rawhide' during the Fedora 19 development cycle.
Changing version to '19'.

(As we did not run this process for some time, it could affect also pre-Fedora 19 development
cycle bugs. We are very sorry. It will help us with cleanup during Fedora 19 End Of Life. Thank you.)

More information and reason for this action is here:
https://fedoraproject.org/wiki/BugZappers/HouseKeeping/Fedora19
Comment 4 Fedora Admin XMLRPC Client 2013-04-25 07:37:35 EDT
This package has changed ownership in the Fedora Package Database.  Reassigning to the new owner of this component.
Comment 5 Tomáš Hozza 2013-05-02 05:39:08 EDT
Hi.

I agree with Adam about that our default named.conf is secure and simple
enough. I would rather include some Warning message in it to prevent people
from configuring their bind instance as a public recursive server.

I think something like mentioned in Bug #952311 comment #1 would do the
right job.
Comment 6 Tomáš Hozza 2013-05-03 05:41:30 EDT
*** Bug 929336 has been marked as a duplicate of this bug. ***
Comment 7 Renich Bon Ciric 2013-05-03 12:02:04 EDT
(In reply to comment #5)
> Hi.
> 
> I agree with Adam about that our default named.conf is secure and simple
> enough. I would rather include some Warning message in it to prevent people
> from configuring their bind instance as a public recursive server.
> 
> I think something like mentioned in Bug #952311 comment #1 would do the
> right job.

Yeah, that seems helpful. Can we provide sample configs like black-hole and stuff like that?

Here's a sample:

https://github.com/renich/fedora-configs/blob/bind/etc/named.conf

This one required to mount /dev/null into the chroot. Not really aware of how this works with systemd and containers though... 

I checked out the /usr/libexec/setup-named-chroot.sh and couldn't find /dev/null anywhere... but systemd mounts it anyway so... 

I mention all this because, back in SysV, I had to modify the init file (or was it /etc/sysconfig/named?) in order to add /ev/null.

So, those are my two cents. I believe a more complete configuration for bind will help users get around it's configuration. 

Maybe if examples are provided or a README.Fedora? I dunno; it's up to you.

Thank you for the attention.
Comment 8 Tomáš Hozza 2013-05-13 04:07:51 EDT
(In reply to comment #7)
> (In reply to comment #5)
> > Hi.
> > 
> > I agree with Adam about that our default named.conf is secure and simple
> > enough. I would rather include some Warning message in it to prevent people
> > from configuring their bind instance as a public recursive server.
> > 
> > I think something like mentioned in Bug #952311 comment #1 would do the
> > right job.
> 
> Yeah, that seems helpful. Can we provide sample configs like black-hole and
> stuff like that?
> 
> Here's a sample:
> 
> https://github.com/renich/fedora-configs/blob/bind/etc/named.conf
> 
> This one required to mount /dev/null into the chroot. Not really aware of
> how this works with systemd and containers though... 
> 
> I checked out the /usr/libexec/setup-named-chroot.sh and couldn't find
> /dev/null anywhere... but systemd mounts it anyway so... 
> 
> I mention all this because, back in SysV, I had to modify the init file (or
> was it /etc/sysconfig/named?) in order to add /ev/null.
> 
> So, those are my two cents. I believe a more complete configuration for bind
> will help users get around it's configuration. 
> 
> Maybe if examples are provided or a README.Fedora? I dunno; it's up to you.
> 
> Thank you for the attention.

I appreciate your ideas and passion to improve our bind configurations. However
we already provide a "sample" configuration located in /usr/share/doc/bind-9.9.x/sample/etc/named.conf
with a lot of comments and some samples how to do things. I would rather not complicate
thing and let bind users/admins choose what fits best their needs. I think It is
better to read BIND Administrator's Reference Manual and understand possible options
than just use some sample and complicated configuration out-of-the-box.

Thank you for your understanding.
Comment 9 Fedora Update System 2013-05-13 07:46:22 EDT
bind-9.9.3-0.6.rc2.fc19 has been submitted as an update for Fedora 19.
https://admin.fedoraproject.org/updates/bind-9.9.3-0.6.rc2.fc19
Comment 10 Renich Bon Ciric 2013-05-13 19:41:05 EDT
I understand. Thank you for your patience.

It's just that I hate Mandriva/Mageia users that claim that their configuration is 'just ready' while ours isn't... 

Feel free to close the bug (or let koji/bodhi do it, hehe). 

Thanks!
Comment 11 Fedora Update System 2013-05-24 16:14:11 EDT
bind-9.9.3-0.6.rc2.fc19, dhcp-4.2.5-12.fc19, bind-dyndb-ldap-3.2-1.fc19, dnsperf-2.0.0.0-6.fc19 has been pushed to the Fedora 19 stable repository.  If problems still persist, please make note of it in this bug report.

Note You need to log in before you can comment on or make changes to this bug.