ISC can accept patches with the new functionality.

Previous discussion about PTR record updates can be found in mailing list archive:
https://www.redhat.com/archives/freeipa-devel/2013-March/msg00006.html

Current state - why we need a new type:

• With krb5-self and ms-self match-types it is possible to require TSIG/GSSAPI authentication, but it is not possible to use IP address of the signer for additional verification.
  • I.e. in the case where all hosts are allowed to update reverse zone, single compromised host can mess with whole reverse zone.
• With tcp-self match-type it is possible to limit PTR record updates in reverse zone to names matching source IP address of the TCP connection, but request signature is ignored in that case.
  • E.g. any user logged to a machine can send update request and modify PTR record of the machine to arbitrary value.

Proposal

Add new match-types tcp-krb5-self and tcp-ms-self for secure PTR updates.

• Proposed match-types require same valid signature as krb5-self and ms-self, i.e.

  • host/<hostname>@CONFIGURED.REALM
  • <hostname>$@CONFIGURED.REALM

• Source IP address of the TCP connection have to exactly match updated name in the same way as for tcp-self.

• New PTR data sent by client have to match host name in the signature.

Example - an update request allowed by tcp-krb5-self:

update-policy = 'grant EXAMPLE.COM tcp-krb5-self;'
source IP address = 192.0.2.1
Kerberos principal = host/client.example.com@EXAMPLE.COM
update request =
  update add 2.0.192.in-addr.arpa. 3600 IN PTR client.example.com

Request above should be denied if:

• Source IP address doesn't match updated name (property of current tcp-self match-type). I.e. compromised host can mess only with record associated to it's actual IP address.
• Signer's REALM doesn't match realm specified in update policy (property of current krb5-self match-type), i.e. hosts coming via cross-realm trusts are not allowed to update records if realm is not '*'.
• New PTR data doesn't match signer's name, i.e. client.example.com is not allowed to update PTR record associated with it's IP address with data like secureserver.example.com. If we combine requirements above, one compromised host is able to mess only with PTR record associated with it's actual IP address and is not able to create record pointing to a fake name.

Record deletion is a problem, but we tend to allow client to delete all PTR records under name associated with it's IP address.