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 1249226 - IPA dnssec-validation not working for AD dnsforwardzone
Summary: IPA dnssec-validation not working for AD dnsforwardzone
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: ipa
Version: 7.2
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: rc
: ---
Assignee: IPA Maintainers
QA Contact: Namita Soman
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2015-07-31 21:49 UTC by Scott Poore
Modified: 2015-11-19 12:04 UTC (History)
5 users (show)

Fixed In Version: ipa-4.2.0-6.el7
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2015-11-19 12:04:52 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2015:2362 0 normal SHIPPED_LIVE ipa bug fix and enhancement update 2015-11-19 10:40:46 UTC

Description Scott Poore 2015-07-31 21:49:18 UTC
Description of problem:

We have tests setting up AD Trust that are failing on some normal DNS Forwarder setups.  It should be noted that these are pre-existing AD servers used in multiple tests for different versions of IPA.  We try to create a dnsforwardzone for the AD Domain on the IPA server like this and see the error:

[root@vm-idm-014 system]# ipa dnsforwardzone-add adtest.qe --forwarder=$AD_IP --forward-policy=only
Server will check DNS forwarder(s).
This may take some time, please wait ...
ipa: WARNING: DNS server $IPA_IP: query 'adtest.qe. SOA': All nameservers failed to answer the query adtest.qe. IN SOA: Server $IPA_IP UDP port 53 anwered SERVFAIL.
  Zone name: adtest.qe.
  Active zone: TRUE
  Zone forwarders: $AD_IP
  Forward policy: only

Then in messages I see:
Aug  1 02:53:00 vm-idm-014 named-pkcs11[16963]: forward zone 'adtest.qe': loaded
Aug  1 02:53:05 vm-idm-014 named-pkcs11[16963]: error (insecurity proof failed) resolving 'adtest.qe/SOA/IN': $AD_IP#53

If I disable dnssec-validation in /etc/named.conf, this does not occur and I can add the forwarder as expected.

Version-Release number of selected component (if applicable):
ipa-server-4.2.0-3.el7.x86_64
bind-pkcs11-9.9.4-27.el7.x86_64


How reproducible:
always at least with this AD DNS server


Steps to Reproduce:
1.  Install IPA Master
2.  Install AD server with DNS
3.  ipa dnsforwardzone-add $AD_DOMAIN --forwarder=$AD_IP --forward-policy=only

Actual results:
Error like above and cannot resolve that domain from IPA server:

[root@vm-idm-014 system]# dig +short @$AD_IP $AD_DOMAIN
$AD_IP

[root@vm-idm-014 system]# dig +short @$IPA_IP $AD_DOMAIN
[root@vm-idm-014 system]# 


Expected results:

I originally thought this should work with zones not supporting DNSSEC but, need clarification.  If not, we may need a better way to disable DNSSEC Validation.

Additional info:

[root@vm-idm-014 system]# dig @$AD_IP $AD_DOMAIN SOA|grep flags
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 2
; EDNS: version: 0, flags:; udp: 4000

[root@vm-idm-014 system]# dig +short @$AD_IP $AD_DOMAIN SOA +edns=0
ad12srv1.adtest.qe. hostmaster.adtest.qe. 2731 900 600 86400 3600

[root@vm-idm-014 system]# dig  @$AD_IP $AD_DOMAIN SOA +edns=0|grep flags
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 2
; EDNS: version: 0, flags:; udp: 4000

From the design page:

http://www.freeipa.org/page/V4/DNSSEC_Support#Detection_if_forwarders_are_DNSSEC_capable

I guess it looks like the AD server does not support DNSSEC because it fails check 3 for forward zones (at least using dig):

check if the record "fwzone IN SOA" @forwarder with EDNS0 has DNSSEC signatures (flags: RD, DO)

    failed: forwarder does not support DNSSEC

Dig results:

[root@vm-idm-014 system]# dig  @$AD_IP $AD_DOMAIN SOA +edns=0|grep flags
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 2
; EDNS: version: 0, flags:; udp: 4000

I don't see the expected DO flag on the AD server.

Comment 2 Jan Cholasta 2015-08-04 15:26:56 UTC
Upstream ticket:
https://fedorahosted.org/freeipa/ticket/5179

Comment 3 Martin Bašti 2015-08-11 10:56:38 UTC
Just for clarification, expecting behavior is to show better warning message ("Please disable DNSSEC validation on all IPA servers if enabled") instead of the current, right?

DNSSEC validation is all or nothing. When it is enabled BIND validates all records. As you use zone that is not available in public internet, chain of trust cannot be validated, thus records are not valid and dropped.
You must always disable DNSSEC validation to work with these zones.

Currently validation must be disabled per each server (there is ticket for bind-dyndb-ldap to allow globally enable/disable validation on all replicas; will not be in 7.2)


If you expect any issues with DNSSEC validation enabled by default, we can change it in RHEL to disabled by default.

Comment 4 Scott Poore 2015-08-12 12:51:05 UTC
Martin,

Yes, a better warning message would definitely help.

It seems like I've also read that there was some plan to add command to set/modify the dnssec-* options in named.conf.  Is that the case or directly editing the file is the intended method of setting the options?

So, one last question (I hope):

Does DNSSEC require all zones and or servers have DNSSEC enabled (and be signed?)?  Or is my problem mostly that my root zone is not?

Thanks,
Scott

Comment 5 Martin Bašti 2015-08-12 13:52:03 UTC
(In reply to Scott Poore from comment #4)
> Martin,
> 
> Yes, a better warning message would definitely help.
> 
> It seems like I've also read that there was some plan to add command to
> set/modify the dnssec-* options in named.conf.  Is that the case or directly
> editing the file is the intended method of setting the options?
> 
It is intended method to setting options directly in named.conf.
This command to modify DNSSEC setting is just nice to have feature.

> So, one last question (I hope):
> 
> Does DNSSEC require all zones and or servers have DNSSEC enabled (and be
> signed?)?  Or is my problem mostly that my root zone is not?
> 
It is not so easy.

It consist of separate issues:
* dnssec support enabled
* dnssec validation enabled
* signed zones
* validation of zones

All DNS servers should have DNSSEC support enabled (this means that the server is able to work with records with dnssec signatures). Without these signatures records cannot be validated.

If dnssec validation is enabled, then server will validate signatures of records. This feature requires to have all DNS server among path with enabled DNSSEC support.


Root zone is signed, public keys are well known.
You do not need to have signed your zones. Every signed zone must have DS record in its parent zones. This means that zone is signed by DNSSEC and server (or client) with enabled DNSSEC validation will check the signatures. If this DS record is not in parent zone, that means the zone is not signed, and only path from root zone to parent zone will be validated.

In case you use zone 'example.test.' and you have enabled DNSSEC validation, this is invalid, because root zone does not contain record 'test.', but DNS server knows that root zone is signed, so when it receives answer from forwarder (for example example.test. A 192.0.2.1) it is handled as attack, and reply is discarded, because DNSSEC validation gave proof that 'test.' zone does not exist.

This should work with for example 'testzone.redhat.com' because '.com' exists in root zone, and redhat is not signed yet.

> Thanks,
> Scott

Comment 7 Scott Poore 2015-08-12 17:01:11 UTC
Ok, so sounds like our AD servers are probably being handled as attack then like your test example.  So we'll need to disable until we get DNSSEC enabled on them.  I'll discuss with my team.

I think the warning is enough to finish this one off.  I don't think we need to disable it by default considering the checks already in place during install.

Thanks,
Scott

Comment 8 Petr Spacek 2015-08-25 08:17:33 UTC
Scott, the only 'proper' solution for you is to use a properly delegated domain instead of made up one.

I.e. you should use domain like adtest.idmqe.lab.bos.redhat.com where the domain is properly delegated from parent idmqe.lab.bos.redhat.com (i.e. the NS record exists in the parent).

In that case the validator will properly detect that the domain is not signed (because there will be no DS record with public key in the parent) and it will work out of the box. Even better, you will not need to add forward zone - the forward zone is just an workaround for missing delegation from parent.


Alternatively it should work (in theory) even without delegation if your parent domain idmqe.lab.bos.redhat.com is not signed (which is not) because the validator will detect that early and do not require security proofs for child domain. In that case you will have to setup forward zone because, again, you will have to workaround the missing delegation.


Do not hesitate to ask me for help when you get to setting up the delegation. Have a nice day!

Comment 11 Scott Poore 2015-08-26 23:25:29 UTC
Verified.

Version ::

ipa-server-4.2.0-8.el7.x86_64

Results ::

[root@vm-idm-001 ~]# grep dnssec-validation /etc/named.conf
	dnssec-validation yes;


[root@vm-idm-001 ~]# ipa dnsforwardzone-add $AD_DOMAIN --forwarder=$AD_IP --forward-policy=only
Server will check DNS forwarder(s).
This may take some time, please wait ...
ipa: WARNING: DNSSEC validation failed: record 'adtest.qe. SOA' failed DNSSEC validation on server 10.65.206.135.
Please verify your DNSSEC configuration or disable DNSSEC validation on all IPA servers.
  Zone name: adtest.qe.
  Active zone: TRUE
  Zone forwarders: 10.65.207.38
  Forward policy: only

Comment 12 errata-xmlrpc 2015-11-19 12:04:52 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/RHBA-2015-2362.html


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