RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 1319404 - Authoritative vs. recursive DNS server
Summary: Authoritative vs. recursive DNS server
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: doc-Linux_Domain_Identity_Management_Guide
Version: 7.2
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: rc
: ---
Assignee: Aneta Šteflová Petrová
QA Contact: Namita Soman
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2016-03-19 15:55 UTC by Luc de Louw
Modified: 2019-03-06 01:10 UTC (History)
4 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2016-06-10 11:54:59 UTC
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)

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.
Note You need to log in before you can comment on or make changes to this bug.