Bug 1319404

Summary:	Authoritative vs. recursive DNS server
Product:	Red Hat Enterprise Linux 7	Reporter:	Luc de Louw <ldelouw>
Component:	doc-Linux_Domain_Identity_Management_Guide	Assignee:	Aneta Šteflová Petrová <apetrova>
Status:	CLOSED CURRENTRELEASE	QA Contact:	Namita Soman <nsoman>
Severity:	unspecified	Docs Contact:
Priority:	unspecified
Version:	7.2	CC:	pspacek, pvoborni, rcritten, rhel-docs
Target Milestone:	rc	Keywords:	Documentation, EasyFix
Target Release:	---
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2016-06-10 11:54:59 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description Luc de Louw 2016-03-19 15:55:22 UTC

Description of problem:
ipa-server-install should set allow-recursion in /etc/named.conf to none or at least limit it to the subnet.

Further, ipa-client-install should be able to set a pair of recursive DNS

Version-Release number of selected component (if applicable):
4.x

How reproducible:
Always


Actual results:
The authoritative DNS server in IPA also acts as recursive DNS


Expected results:
Authoritative DNS servers should not act as recursive DNS


Additional info:

Actually,  BZ #713798 should be reverted as this can lead to DNS Amplification Attacks, see https://www.us-cert.gov/ncas/alerts/TA13-088A and other problems.

Further, authoritative DNS answers are not cached, thus creating unnecessary load on the IPA server(s).

Recommended practice is to have pair of separate recursive DNS servers. It would be great to have a way having the IP addresses be configured by ipa-client-install, which means this information needs to be stored in IPA.

RHEL7 provides the unbound package which is an excellent DNS specialized for recursive DNS queries.

Comment 2 Petr Spacek 2016-03-21 12:46:38 UTC

Yes, IPA default is not the recommended value.

Pros and cons are mentioned here:
https://bugzilla.redhat.com/show_bug.cgi?id=713798#c2

We need to decide if assumption 'setting allow-recurse any is an acceptable compromise to make things work out of the box without affecting security too much' still holds.

Comment 3 Petr Vobornik 2016-04-08 08:49:31 UTC

from idm triage:  mkosek: we should at least document (in admonition) that people runing FreeiPA DNS in public network should change the default to prevent DNS amplification attacks

For more info contact pspacek.

Comment 5 Luc de Louw 2016-04-08 08:57:43 UTC

(In reply to Petr Vobornik from comment #3)
> from idm triage:  mkosek: we should at least document (in admonition) that
> people runing FreeiPA DNS in public network should change the default to
> prevent DNS amplification attacks
> 
> For more info contact pspacek.

Since authoritative answers are not cached, this creates IMHO unnecessary load on the IPA servers. Means that in large environments this can cause performance issues.

Comment 6 Petr Spacek 2016-04-08 09:17:41 UTC

(In reply to Luc de Louw from comment #5)
> Since authoritative answers are not cached, this creates IMHO unnecessary
> load on the IPA servers. Means that in large environments this can cause
> performance issues.

Technically this is not correct. Our authoritative server (BIND) has all the data in memory so the lookup is faster than going through a intermediate recursor (which needs to re-fetch the data from authoritative from time to time).

Comment 7 Petr Spacek 2016-04-08 09:25:10 UTC

Aneta, please add following note somwhere near DNS deployment considerations:

IdM-integrated DNS server by default allows all clients to issue recursive queries to the DNS server. When IdM-DNS server is deployed in a network with untrusted clients it is necessary to change DNS server's configuration to prevent DNS amplification attacks. For further information please see https://www.us-cert.gov/ncas/alerts/TA13-088A .

Thanks!

Comment 9 Aneta Šteflová Petrová 2016-06-03 11:05:54 UTC

I added the "Preventing DNS Amplification Attacks" section that explains the problem and documents how to prevent the risk.

Comment 11 Aneta Šteflová Petrová 2016-06-10 11:54:59 UTC

Published in an asynchronous update.