Automatic PTR record synchronization¶

Bind-dyndb-ldap offers an option to automatically synchronize PTR records when A/AAAA records are changed.

Quick Configuration for FreeIPA¶

This chapter shows how to enable PTR record synchronization via FreeIPA‘s command line interface. Everything can be done directly in LDAP, see next chapter for all the gory details.

Enable dynamic updates for forward zone.

$ ipa dnszone-mod example.com. --dynamic-update=TRUE
$ ipa dnszone-mod example.com. --update-policy='grant EXAMPLE.COM krb5-self * A; grant EXAMPLE.COM krb5-self * AAAA; grant EXAMPLE.COM krb5-self * SSHFP;'

Enable PTR record synchronization in forward zone:

$ ipa dnszone-mod example.com. --allow-sync-ptr=TRUE

Enable dynamic updates in reverse zone:

$ ipa dnszone-mod 2.0.192.in-addr.arpa. --dynamic-update=TRUE

How It Works - Requirements¶

This synchronization is done only if all following conditions are fulfilled:

Forward and reverse zones are hosted on the same server inside the same bind-dyndb-ldap instance.
- Both zones are managed by bind-dyndb-ldap driver declared in the one dynamic-db section of /etc/named.conf.
A/AAAA record is modified via DNS Dynamic Update.
- Changes made directly in LDAP database don’t trigger PTR record synchronization. This also applies to FreeIPA‘s user interfaces and APIs.
Dynamic Update is enabled for forward and also reverse zone.
- Bind-dyndb-ldap has special boolean option which enables or disables dynamic updates. This option can be configured on two places (ordered by descending priority):
  1. per-zone via idnsAllowDynUpdate attribute in zone object
    - FreeIPA CLI equivalent is ipa dnszone-mod --dynamic-update=TRUE
  2. per-server for all zones via dyn_update option in /etc/named.conf
- Update policy (2) has to allow A or AAAA record update in forward zone at least. Update policy in reverse zone doesn’t matter.
  - FreeIPA’s default update policy for forward zones is:
    grant EXAMPLE.COM krb5-self * A; grant EXAMPLE.COM krb5-self * AAAA; grant EXAMPLE.COM krb5-self * SSHFP;
    where EXAMPLE.COM is your Kerberos REALM.
PTR record synchronization is enabled for forward zone.
- Bind-dyndb-ldap has special boolean option for controlling this feature. It can be configured on three places (ordered by descending priority):
  1. per-zone via idnsAllowSyncPTR attribute in the zone object
    - FreeIPA CLI equivalent is ipa dnszone-mod --allow-sync-ptr=TRUE
  2. for all zones globally: via idnsAllowSyncPTR attribute in global configuration object
    - the configuration object is usually the same object as specified by the base option in /etc/named.conf
    - FreeIPA CLI equivalent is ipa dnsconfig-mod --allow-sync-ptr=TRUE
  3. per-server for all zones via sync_ptr option in /etc/named.conf
- This configuration option is ignored for reverse zones.
Existing values in A/AAAA and PTR records matches. For example:
- Update adds record example.com. A 192.0.2.1 => PTR record 1.2.0.192.in-addr.arpa. has to not exist.
- Update deletes record example.com. A 192.0.2.1 => PTR record 1.2.0.192.in-addr.arpa. has to have value example.com.

Error reporting¶

SERVFAIL is returned to the client if the A/AAAA update succeeded and PTR record synchronization is enabled but the synchronization was unsuccessful.

Versions <= 3.1 had very poor error reporting. Newer versions log detailed error messages to usual places (as configured in /etc/named.conf).

Security considerations¶

This feature, when enabled, has some impact to security of DNS dynamic updates.

IP addresses in A/AAAA records sent by clients are not checked in any way. As a result, an client can create PTR record which points to client’s name even if the client do not hold the particular IP address.

Overall impact depends on update policy applied to forward zone. You should carefully think about your update policy and interaction with checks done by bind-dyndb-ldap.

Known problems¶

Ticket	Summary	Resolution	Fixed in version
#33	update PTR records when A/AAAA records are updated in safe way
#112	[RFE] Implement secure PTR synchronization to BIND9
#39	Enable/disable the PTR synchronization.	fixed	1.1.0a1
#43	Hold bind and plugin global settings in LDAP	fixed	1.1.0b1
#104	Investigate memory leaks in plugin 1.1.0-0.9.b1.el6_3.1.x86_64	fixed	2.0
#110	Potential crash during startup/reload if global configuration options are set	fixed	2.6
#113	PTR record synchronization can deadlock if connection count <= 2 (only plugin versions < 3.0)	fixed
#115	PTR record synchronization deletes all data under reverse name	fixed	3.2
#118	PTR record synchronization doesn’t work with IPv6 addresses	fixed	3.3
#155	PTR record synchronization for A/AAAA record tuple can fail mysteriously	fixed	8.0

Alternative: Client-side PTR record synchronization¶

Another option is to do PTR synchronization directly from clients. This method requires a client which is able to update A and PTR records separately. (Of course, you can prepare hand made script or something similar.)

See discussion about this possibility.

Configuration example¶

Configure reverse zone with update policy tcp-self.

$ ipa dnszone-mod 2.0.192.in-addr.arpa --dynamic-update=TRUE
$ ipa dnszone-mod 2.0.192.in-addr.arpa --update-policy='grant * tcp-self *;'

Now the client has to do dynamic update over TCP, note the -v parameter.

$ nsupdate -v
debug
update delete 1.2.0.192.in-addr.arpa. 1200 IN PTR
update add 1.2.0.192.in-addr.arpa. 1200 IN PTR client1.example.com.
send