Bug 767725

Summary: GSS-TSIG DNS updates should update reverse entries as well
Product: Red Hat Enterprise Linux 6 Reporter: Dmitri Pal <dpal>
Component: ipaAssignee: Rob Crittenden <rcritten>
Status: CLOSED ERRATA QA Contact: IDM QE LIST <seceng-idm-qe-list>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 6.3CC: jgalipea, ksiddiqu, mkosek
Target Milestone: rc   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: ipa-2.2.0-3.el6 Doc Type: Bug Fix
Doc Text:
Cause: When an IPA server is configured with a DNS support, DNS zone dynamic update policy allows IPA clients to update a relevant DNS forward record if the client IP address changes. However, for security reasons, clients cannot be allowed to update also their reverse records, because then they would be able to change any record in the reverse zone. Consequence: Reverse record is not updated automatically when client IP address changes. Change: IPA dns zone can be configured to allow automatic updates of client reverse records when the forward record is updated with the new IP address. Result: Both forward and reverse records for a client machine can be updated when client IP address changes.
Story Points: ---
Clone Of: Environment:
Last Closed: 2012-06-20 13:28:17 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On: 767494    
Bug Blocks:    

Description Dmitri Pal 2011-12-14 18:36:57 UTC
This bug is created as a clone of upstream ticket:
https://fedorahosted.org/freeipa/ticket/2176

Moved to FreeIPA from https://fedorahosted.org/sssd/ticket/1089

Customers have requested on the mailing lists that updating DNS entries with SSSD should also update the reverse entry in DNS. For security reasons, we cannot have SSSD do this with GSS-TSIG (because it would require giving each client the capability to update any reverse entry in the domain).

Our recommended solution would be to add a plugin to the BIND LDAP driver to allow it to set the reverse entry automatically whenever the forward entry is updated.

Comment 1 Martin Kosek 2012-02-24 09:10:01 UTC
Fixed upstream:
master: 1c898e388b4777e0dfd0dd7577bbb4971e308605
ipa-2-2: 40063c08e567287fd86e10405ccf5c9418bceabb

Comment 3 Martin Kosek 2012-04-19 19:26:38 UTC
    Technical note added. If any revisions are required, please edit the "Technical Notes" field
    accordingly. All revisions will be proofread by the Engineering Content Services team.
    
    New Contents:
Cause: When an IPA server is configured with a DNS support, DNS zone dynamic update policy allows IPA clients to update a relevant DNS forward record if the client IP address changes. However, for security reasons, clients cannot be allowed to update also their reverse records, because then they would be able to change any record in the reverse zone.
Consequence: Reverse record is not updated automatically when client IP address changes.
Change: IPA dns zone can be configured to allow automatic updates of client reverse records when the forward record is updated with the new IP address.
Result: Both forward and reverse records for a client machine can be updated when client IP address changes.

Comment 4 Kaleem 2012-05-04 10:26:14 UTC
Verified.

ipa version:
===========
[root@ipa63server ~]# rpm -q ipa-server bind-dyndb-ldap
ipa-server-2.2.0-12.el6.x86_64
bind-dyndb-ldap-1.1.0-0.8.b1.el6.x86_64
[root@ipa63server ~]#

Following steps used for verification:

On Server side:
===============
(1)Add a PTR record in reverse zone for existing A record in forward zone.

  ipa dnsrecord-add 201.65.10.in-addr.arpa. 163 --ptr-rec ipa63client1.testrelm.com.

(2)Add synchronization flag for forward and reverse zone records in Forward zone.
   
  [root@ipa63server ~]# ipa dnszone-mod testrelm.com --allow-sync-ptr=1
  Zone name: testrelm.com
  Authoritative nameserver: ipa63server.testrelm.com.
  Administrator e-mail address: hostmaster.testrelm.com.
  SOA serial: 2012050252
  SOA refresh: 3600
  SOA retry: 900
  SOA expire: 1209600
  SOA minimum: 3600
  Active zone: TRUE
  Allow query: any;
  Allow transfer: none;
  Allow PTR sync: TRUE
  [root@ipa63server ~]#

(3)Verify that both forward and reverse records are present.

   [root@ipa63server ~]# ipa dnsrecord-find testrelm.com client;ipa dnsrecord-find 201.65.10.in-addr.arpa. client
  Record name: ipa63client1
  A record: 10.65.201.161
  SSHFP record: 2 1 5A8C58F842A807DBCC2A92396AE50492A92EADCC, 1 1 4A6DEF9594E86160F62D09923B3C8517784BF9C4
----------------------------
Number of entries returned 1
----------------------------
  Record name: 163
  PTR record: ipa63client1.testrelm.com.
----------------------------
Number of entries returned 1
----------------------------
[root@ipa63server ~]#

On Client side:
===============
(4)Get kerberos tkt for client machine's principal.

   /usr/bin/kinit -k -t /etc/krb5.keytab host/`hostname`

(5)Run nsupdate to send dns update request to modify A record

   [root@ipa63client1 ~]# cat nsupdate.txt 
   zone testrelm.com
   update delete ipa63client1.testrelm.com IN A
   send
   update add ipa63client1.testrelm.com 1200 IN A 10.65.201.161
   send
   [root@ipa63client1 ~]#

   nsupdate -g nsupdate.txt

On Server side:
===============
(6)Verify that both forward and reverse records have been changed.

[root@ipa63server ~]# ipa dnsrecord-find testrelm.com client;ipa dnsrecord-find 201.65.10.in-addr.arpa. client
  Record name: ipa63client1
  A record: 10.65.201.161
  SSHFP record: 2 1 5A8C58F842A807DBCC2A92396AE50492A92EADCC, 1 1 4A6DEF9594E86160F62D09923B3C8517784BF9C4
----------------------------
Number of entries returned 1
----------------------------
  Record name: 161
  PTR record: ipa63client1.testrelm.com.
----------------------------
Number of entries returned 1
----------------------------
[root@ipa63server ~]#

Comment 7 errata-xmlrpc 2012-06-20 13:28:17 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.

http://rhn.redhat.com/errata/RHBA-2012-0819.html