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 1056202 - [RFE] Support DNS root zone
Summary: [RFE] Support DNS root zone
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: ipa
Version: 7.0
Hardware: Unspecified
OS: Unspecified
medium
low
Target Milestone: rc
: ---
Assignee: Martin Kosek
QA Contact: Namita Soman
URL:
Whiteboard:
Depends On:
Blocks: 1064025 1113520
TreeView+ depends on / blocked
 
Reported: 2014-01-21 16:59 UTC by Chinmay Paradkar
Modified: 2019-04-16 14:07 UTC (History)
13 users (show)

Fixed In Version: ipa-4.1.0-6.el7
Doc Type: Enhancement
Doc Text:
Clone Of:
Environment:
Last Closed: 2015-03-05 10:10:14 UTC
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHSA-2015:0442 0 normal SHIPPED_LIVE Moderate: ipa security, bug fix, and enhancement update 2015-03-05 14:50:39 UTC

Description Chinmay Paradkar 2014-01-21 16:59:45 UTC 
Description of problem:

In BETA testing RHEL7 and the IPA/IdM, it is discovered that root hints are enabled when --setup-dns is specified. On isolated and secure networks, this is a security configuration finding (specifically DISA STIG finding).

Suggested solution:
A way to fix this with IPA/IdM would be to add an option in the webui DNS configuration to disable root hints as well as an ipa dnsconfig-mod option.
Comment 2 Martin Kosek 2014-01-22 08:20:43 UTC 
I see 2 ways to fix this request:

1) Fix ipa and bind-dyndb-ldap to allow LDAP definition if the root zone ".". Currently, when I created it in LDAP by bypassing IPA validation, bind-dyndb-ldap refused to serve it:

# ipa dnszone-add test. --name-server=a --ip-address=198.41.0.4 --admin-email root.`hostname`.
  Zone name: test.
  Authoritative nameserver: a
  Administrator e-mail address: root.vm-236.example.com.
  SOA serial: 1390377720
  SOA refresh: 3600
  SOA retry: 900
  SOA expire: 1209600
  SOA minimum: 3600
  BIND update policy: grant EXAMPLE.COM krb5-self * A; grant EXAMPLE.COM
                      krb5-self * AAAA; grant EXAMPLE.COM krb5-self * SSHFP;
  Active zone: TRUE
  Dynamic update: FALSE
  Allow query: any;
  Allow transfer: none;

# ldapmodify -h `hostname` -Y GSSAPI -ZZ
SASL/GSSAPI authentication started
SASL username: admin.ENG.BRQ.REDHAT.COM
SASL SSF: 56
SASL data security layer installed.
dn: idnsname=test.,cn=dns,dc=example,dc=com
changetype: modrdn
newrdn: idnsname=.
deleteoldrdn: 1

modifying rdn of entry "idnsname=test.,cn=dns,dc=example,dc=com"

# ipa dnszone-show .
  Zone name: .
  Authoritative nameserver: a
  Administrator e-mail address: root.vm-236.example.com.
  SOA serial: 1390377724
  SOA refresh: 3600
  SOA retry: 900
  SOA expire: 1209600
  SOA minimum: 3600
  Active zone: TRUE
  Allow query: any;
  Allow transfer: none;

# ipa dnsrecord-find .
  Record name: @
  NS record: a

  Record name: _kerberos
  TXT record: EXAMPLE.COM

  Record name: a
  A record: 198.41.0.4
----------------------------
Number of entries returned 3
----------------------------


The LDAP entry looks correct, howerver bind-dyndb-ldap refused to load it:
Jan 22 09:05:57 vm-236.example.com named[21522]: failed to convert dn idnsname=a,idnsname=.,cn=dns,dc=idm,dc=lab,dc=eng,dc=brq,dc=redhat,dc=com to DNS name: empty label
Jan 22 09:05:57 vm-236.example.com named[21522]: update_record (psearch) failed, dn 'idnsname=a,idnsname=.,cn=dns,dc=idm,dc=lab,dc=eng,dc=brq,dc=redhat,dc=com' change type 0x0. Records can be outdated, run `rndc reload`: empty label
Jan 22 09:05:57 vm-236.example.com named[21522]: failed to convert dn idnsname=_kerberos,idnsname=.,cn=dns,dc=idm,dc=lab,dc=eng,dc=brq,dc=redhat,dc=com to DNS name: empty label
Jan 22 09:05:57 vm-236.example.com named[21522]: update_record (psearch) failed, dn 'idnsname=_kerberos,idnsname=.,cn=dns,dc=idm,dc=lab,dc=eng,dc=brq,dc=redhat,dc=com' change type 0x0. Records can be outdated, run `rndc reload`: empty label

Petr, do you think this is something that could be fixed in bind-dyndb-ldap? As we discussed before, there should be theoretically no obstacle on defining a root zone in LDAP. Or would we need also need to have a new attribute for zone type which would be then set to "hint"?


2) Disable the root hint in local /etc/named.conf. However, when I commented following sections:

        #forward first;
        #forwarders {
        #       10.0.0.1;
        #};

...

#zone "." IN {
#       type hint;
#       file "named.ca";
#};

I still got the root hint when testing it:

# dig -t ns .
...
j.root-servers.net.	604705	IN	A	192.58.128.30
j.root-servers.net.	604705	IN	AAAA	2001:503:c27::2:30
e.root-servers.net.	604705	IN	A	192.203.230.10
...

Is this something compiled in named/dig?
Comment 3 Petr Spacek 2014-01-22 10:35:18 UTC 
(In reply to Martin Kosek from comment #2)
> I see 2 ways to fix this request:
> 
> 1) Fix ipa and bind-dyndb-ldap to allow LDAP definition if the root zone
> ".". Currently, when I created it in LDAP by bypassing IPA validation,
> bind-dyndb-ldap refused to serve it:
[...]
> The LDAP entry looks correct, howerver bind-dyndb-ldap refused to load it:
> Jan 22 09:05:57 vm-236.example.com named[21522]: failed to convert dn
> idnsname=a,idnsname=.,cn=dns,dc=idm,dc=lab,dc=eng,dc=brq,dc=redhat,dc=com to
> DNS name: empty label
[...]

> Petr, do you think this is something that could be fixed in bind-dyndb-ldap?
Yes I do, we can hack it around if it's necessary.

> As we discussed before, there should be theoretically no obstacle on
> defining a root zone in LDAP. Or would we need also need to have a new
> attribute for zone type which would be then set to "hint"?
It depends on the requirements from the field. It is not possible to just 'disable' root hints. Some hints have to be always present so DNS resolver know where to start. 

We have two possibilities:
1) Add support for 'hint's in LDAP: In practice it means that user has to create 'master' root zone on some internal server and then add IP addresses of this internal server to LDAP.

2) Amend zone parser so it will accept root name and use 'master' zone in LDAP as root. This mitigates requirement for another server from variant (1).

The difference between 'hint' and 'master' zones are described at:
ftp://ftp.isc.org/isc/bind9/9.9.4/doc/arm/Bv9ARM.ch06.html#id2592749

Note that 'hint' is not a real zone:
https://lists.isc.org/pipermail/bind-users/2006-January/061082.html

> 2) Disable the root hint in local /etc/named.conf. However, when I commented
> following sections:
> 
>         #forward first;
>         #forwarders {
>         #       10.0.0.1;
>         #};
> 
> ...
> 
> #zone "." IN {
> #       type hint;
> #       file "named.ca";
> #};

Note that in any case we would comment out hints in named.conf. This file is parsed before bind-dyndb-ldap is loaded.

> 
> I still got the root hint when testing it:
> 
> # dig -t ns .
> ...
> j.root-servers.net.	604705	IN	A	192.58.128.30
> j.root-servers.net.	604705	IN	AAAA	2001:503:c27::2:30
> e.root-servers.net.	604705	IN	A	192.203.230.10
> ...
> 
> Is this something compiled in named/dig?
Yes, root hints for 'IN' DNS class are compiled to named - DNS resolver can't work without them.


I'm curious what is the solution in case with plain BIND? Can we reach the requestor and ask him?
Comment 4 Martin Kosek 2014-01-22 11:04:56 UTC 
(In reply to Petr Spacek from comment #3)
> (In reply to Martin Kosek from comment #2)
...
> > As we discussed before, there should be theoretically no obstacle on
> > defining a root zone in LDAP. Or would we need also need to have a new
> > attribute for zone type which would be then set to "hint"?
> It depends on the requirements from the field. It is not possible to just
> 'disable' root hints. Some hints have to be always present so DNS resolver
> know where to start. 

Can we override them? I.e. have a '.' zone in LDAP which would contain alternative root hints?

BTW by "attribute in LDAP" in my answer above I meant an attribute to specify the zone type, i.e. something like "idnstype" supporting "master" or "hint" value. Does that make sense?

> 
> We have two possibilities:
> 1) Add support for 'hint's in LDAP: In practice it means that user has to
> create 'master' root zone on some internal server and then add IP addresses
> of this internal server to LDAP.

How the DNS clients are then supposed to be configured? Given than root hints are being compiled in, they would not even ask their default resolver for it, right?

> ...
> I'm curious what is the solution in case with plain BIND? Can we reach the
> requestor and ask him?

Good question. Chinmay, can you please ask customer what was their configuration of BIND and host machines (i.e. DNS clients) to allow them disable or replace the default root zone hints? Understanding what worked for them before could give us some hint what exactly do they want.
Comment 5 Petr Spacek 2014-01-22 11:55:56 UTC 
(In reply to Martin Kosek from comment #4)
> (In reply to Petr Spacek from comment #3)
> > (In reply to Martin Kosek from comment #2)
> ...
> > > As we discussed before, there should be theoretically no obstacle on
> > > defining a root zone in LDAP. Or would we need also need to have a new
> > > attribute for zone type which would be then set to "hint"?
> > It depends on the requirements from the field. It is not possible to just
> > 'disable' root hints. Some hints have to be always present so DNS resolver
> > know where to start. 
> 
> Can we override them? I.e. have a '.' zone in LDAP which would contain
> alternative root hints?
Yes we can try it, that is what I proposed as variant (1) in comment #3. I'm not sure how to force BIND to ignore built-in hints, it will be a delicate operation. May be that root hints will always be loaded first and then replaced by hints from LDAP later. 

Should I dig into it right now?

Anyway, after some thinking I propose to use 'master' root zone instead of 'hints' zone. Master root zone has to be somewhere in any case, so why not use IPA? I guess that internal wiring in BIND will be simpler in this case.

> BTW by "attribute in LDAP" in my answer above I meant an attribute to
> specify the zone type, i.e. something like "idnstype" supporting "master" or
> "hint" value. Does that make sense?
I would create new object class for hint zones because hints will have different set of allowed attribures. Another advantage would be that older versions of bind-dyndb-ldap would not be confused by 'hint' zones. Again, I propose normal 'master' zones instead of 'hint' zone.

> > We have two possibilities:
> > 1) Add support for 'hint's in LDAP: In practice it means that user has to
> > create 'master' root zone on some internal server and then add IP addresses
> > of this internal server to LDAP.
> 
> How the DNS clients are then supposed to be configured? Given than root
> hints are being compiled in, they would not even ask their default resolver
> for it, right?
Well, we have to distinguish so-called 'stub resolver' and 'recursive/full resolver'. These articles explain the difference quite nicely:
http://www.zytrax.com/books/dns/apa/resolver.html
https://lists.isc.org/pipermail/bind-users/2009-November/078203.html

Usually, an application uses stub resolver on local machine. This stub resolver simply forwards the query to configured name server configured in /etc/resolv.conf. The name server runs recursive resolver (e.g. inside BIND or unbound process) and this *recursive resolver uses hints*.

As a result, you have to configure hints "only" on all internal name servers. Normal clients will use whatever is configured on internal servers.

> > ...
> > I'm curious what is the solution in case with plain BIND? Can we reach the
> > requestor and ask him?
> 
> Good question. Chinmay, can you please ask customer what was their
> configuration of BIND and host machines (i.e. DNS clients) to allow them
> disable or replace the default root zone hints? Understanding what worked
> for them before could give us some hint what exactly do they want.

I'm wondering "what is the benefit"? Clients can't get any answer from Internet if they are in isolated environment so I don't see a real value in this exercise. It could be even useful to let original hints in place and log attempts to reach server Internet server on routers or something like that. That would uncover worms and some other suspicious activity in the internal network.
Comment 11 Martin Kosek 2014-01-31 08:40:09 UTC 
Upstream ticket:
https://fedorahosted.org/freeipa/ticket/4149
Comment 14 Petr Spacek 2014-06-26 06:25:54 UTC 
This is now implemented upstream by git commits bff6d68ac200ea1ab543b090ab2763e2437a48ce, 1c9b7ec800b0cbdba6032ec4fd1d41cff6ce5e6d
Comment 15 Martin Kosek 2014-06-26 07:54:57 UTC 
Commits mentioned in Comment 14 are in bind-dyndb-ldap. FreeIPA part (https://fedorahosted.org/freeipa/ticket/4149), i.e. allowing "." DNS zone, is not completed yet. Moving back to ASSIGNED.
Comment 17 Petr Spacek 2014-07-18 12:18:29 UTC 
I have modified bug title to reflect current implementation. It allows you to serve DNS root zone (".") from IPA server. It is not directly related to root "hints".
Comment 18 Petr Spacek 2014-09-08 10:32:07 UTC 
bind-dyndb-ldap 5.2 fully supports root zone and all known bugs were fixed.
Comment 19 Petr Viktorin (pviktori) 2014-09-25 14:41:54 UTC 
upstream added webui and ipa command to disable root hints
ipa-4-1:
https://fedorahosted.org/freeipa/changeset/c32b89d892f11da1aa4cc3f5c340e78ab189d8fd
https://fedorahosted.org/freeipa/changeset/72e0b339539a780d895ef1eddab1d84008c2708f
https://fedorahosted.org/freeipa/changeset/18460d629bd26e5f32c19abebe20568f53b7b58e
https://fedorahosted.org/freeipa/changeset/637a082713ec5002aae149d9e65368907367a3b6
https://fedorahosted.org/freeipa/changeset/bf61689069a5f6215063beec3fc91873e4b6e091
https://fedorahosted.org/freeipa/changeset/c675808c43adf5db8673258596f9b43a9a21ed07
https://fedorahosted.org/freeipa/changeset/b7e3a990369d85dfd12165891cf9142d669a0259
master:
https://fedorahosted.org/freeipa/changeset/f846e0d1efa222181f79c930a73e4c9940141bef
https://fedorahosted.org/freeipa/changeset/94743a3f2635a52ecb6d9628e6e330399a192fb8
https://fedorahosted.org/freeipa/changeset/7bc17bb8528f3dbeaf70822ee952e67bd7cf08f5
https://fedorahosted.org/freeipa/changeset/7e24e241ba18dddba6cc217b1108c4874647c8de
https://fedorahosted.org/freeipa/changeset/239adf9de40748caa9e1522c9cd04aedd5516c75
https://fedorahosted.org/freeipa/changeset/23620a40255c8f3963ce8ca012c34f340b2f780b
https://fedorahosted.org/freeipa/changeset/bc2eaa145637e1947449ee53548243ab22059805
Comment 20 Martin Kosek 2014-09-26 08:28:14 UTC 
dns help page fixed:

master:
https://fedorahosted.org/freeipa/changeset/3f8cfdab269490e4935db7d296c3fc7f2fa552f5
ipa-4-1:
https://fedorahosted.org/freeipa/changeset/0f2eb65f008777ebdee9b35f5f69bada66066484
Comment 22 Martin Kosek 2014-10-01 14:56:24 UTC 
Upstream ticket:
https://fedorahosted.org/freeipa/ticket/4573
Comment 23 Martin Kosek 2014-10-06 14:00:17 UTC 
== USE CASE & LIMITATION ==

This RFE allows an administrator to create and manage root zone "." on IdM Server. Any DNS queries sent to the IdM DNS server will then use this configured zone instead of the public one, as pointed to by default DNS root hints available in BIND package (/var/named/named.ca) or other DNS resolvers.

This will make the new root zone effective on all IdM clients that use standard glibc DNS queries and that do not use own recursive resolver like BIND or unbound. Clients using own recursive resolver would need to have updated their root hints to point at IdM DNS servers to have the new root zone applied.
Comment 24 Petr Vobornik 2014-10-20 10:10:53 UTC 
upstream, Web UI added force option to skip DNS check while modifying idnssoamname attribute of dns zone and while adding new NS record:

master:
https://fedorahosted.org/freeipa/changeset/741c31c2b428cf979db6a9d7cd91f88e5f247fb4
ipa-4-1:
https://fedorahosted.org/freeipa/changeset/502bf5671306b873c36e12bc88139bb5a42f8657
Comment 25 Martin Kosek 2014-10-24 13:10:23 UTC 
Regression caused by this RFE found, affects ipa-server-install and --zone-mgr option:

https://fedorahosted.org/freeipa/ticket/4663

I will link this ticket to this bug.
Comment 26 Martin Kosek 2014-10-24 13:16:05 UTC 
Moving to ASSIGNED until 4663 is fixed.
Comment 27 Petr Viktorin (pviktori) 2014-10-27 14:59:07 UTC 
4663 fixed upstream
master:
https://fedorahosted.org/freeipa/changeset/e971fad5c1235bb755e58d131f8183f1646770e6
ipa-4-1:
https://fedorahosted.org/freeipa/changeset/75cdc50ba91a94682eac11f99995746be283f668
Comment 29 Martin Kosek 2014-11-12 09:14:00 UTC 
Minor regression was found in the installation, see

https://fedorahosted.org/freeipa/ticket/4707

Moving back to ASSIGNED.
Comment 30 Jan Cholasta 2014-11-13 10:38:14 UTC 
Fixed upstream
master:
https://fedorahosted.org/freeipa/changeset/a7162e7766150aa7577a42747a4d583a425f7271
ipa-4-1:
https://fedorahosted.org/freeipa/changeset/3ab75d70412921bf2362edefd6c9411cff7df92d
Comment 31 Petr Spacek 2015-01-29 15:43:30 UTC 
Steps to verify:
- install IPA server
- add DNS root zone "." to it
- add NS records for existing zones to the root zone to configure proper delegation.
E.g. if IPA server had zone example.net. configured prior adding the root zone then please run:
$ ipa dnsrecord-add . example.net --ns-rec=name.of.the.ipa.server.test.
(repeat this for all non-root zones)

- add some other records to the root zone
- verify that all records you added are visible and resolvable (including dig)
Comment 32 Xiyang Dong 2015-01-29 18:00:44 UTC 
Verified on ipa-server-4.1.0-15.el7.x86_64:

[root@mgmt9 ~]# ipa dnszone-add .
  Zone name: .
  Active zone: TRUE
  Authoritative nameserver: mgmt9.testrelm.test.
  Administrator e-mail address: hostmaster
  SOA serial: 1422547064
  SOA refresh: 3600
  SOA retry: 900
  SOA expire: 1209600
  SOA minimum: 3600
  BIND update policy: grant TESTRELM.TEST krb5-self * A; grant TESTRELM.TEST krb5-self * AAAA; grant TESTRELM.TEST krb5-self * SSHFP;
  Dynamic update: FALSE
  Allow query: any;
  Allow transfer: none;

[root@mgmt9 ~]# ipa dnszone-find
  Zone name: .
  Active zone: TRUE
  Authoritative nameserver: mgmt9.testrelm.test.
  Administrator e-mail address: hostmaster
  SOA serial: 1422553403
  SOA refresh: 3600
  SOA retry: 900
  SOA expire: 1209600
  SOA minimum: 3600
  Allow query: any;
  Allow transfer: none;

  Zone name: 4.16.10.in-addr.arpa.
  Active zone: TRUE
  Authoritative nameserver: mgmt9.testrelm.test.
  Administrator e-mail address: hostmaster.testrelm.test.
  SOA serial: 1422549642
  SOA refresh: 3600
  SOA retry: 900
  SOA expire: 1209600
  SOA minimum: 3600
  Allow query: any;
  Allow transfer: none;

  Zone name: testrelm.test.
  Active zone: TRUE
  Authoritative nameserver: mgmt9.testrelm.test.
  Administrator e-mail address: hostmaster.testrelm.test.
  SOA serial: 1422549642
  SOA refresh: 3600
  SOA retry: 900
  SOA expire: 1209600
  SOA minimum: 3600
  Allow query: any;
  Allow transfer: none;
----------------------------
Number of entries returned 3
----------------------------


[root@mgmt9 ~]# ipa dnsrecord-add . testrelm.test --ns-rec=mgmt9.testrelm.test.
  Record name: testrelm.test
  NS record: mgmt9.testrelm.test.
[root@mgmt9 ~]# ipa dnsrecord-add . 4.16.10.in-addr.arpa --ns-rec=mgmt9.testrelm.test.
  Record name: 4.16.10.in-addr.arpa
  NS record: mgmt9.testrelm.test.
[root@mgmt9 ~]# ipa dnsrecord-add . test_txt_record --txt-rec=ABC
  Record name: test_txt_record
  TXT record: ABC

[root@mgmt9 ~]# ipa dnsrecord-find .
  Record name: @
  NS record: mgmt9.testrelm.test., cloud-qe-19.testrelm.test.

  Record name: 4.16.10.in-addr.arpa
  NS record: mgmt9.testrelm.test.

  Record name: testrelm.test
  NS record: mgmt9.testrelm.test.

  Record name: test_txt_record
  TXT record: ABC
----------------------------
Number of entries returned 4
----------------------------

[root@mgmt9 ~]# dig -t ns 4.16.10.in-addr.arpa. |grep mgmt9.testrelm.test.
4.16.10.in-addr.arpa.	86400	IN	NS	mgmt9.testrelm.test.
mgmt9.testrelm.test.	1200	IN	A	10.16.4.19
[root@mgmt9 ~]# dig -t ns testrelm.test. |grep mgmt9.testrelm.test.
testrelm.test.		86400	IN	NS	mgmt9.testrelm.test.
mgmt9.testrelm.test.	1200	IN	A	10.16.4.19
[root@mgmt9 ~]# dig -t txt test_txt_record. |grep ABC
test_txt_record.	86400	IN	TXT	"ABC"
Comment 34 errata-xmlrpc 2015-03-05 10:10:14 UTC 
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://rhn.redhat.com/errata/RHSA-2015-0442.html
Note You need to log in before you can comment on or make changes to this bug.