From Fedora Project Wiki

Testcase FreeIPA v3 DNS persistent search

Persistent search feature notifies DNS server about each change in central LDAP database immediately. Each change in DNS data should be visible to clients immediately. Waiting for cache time-out (on DNS server side) is not necessary in FreeIPA 3.0. This feature is enabled by default in FreeIPA 3.0 installs.

Following text assumes FreeIPA installed in DNS domain "lab.example". This domain is configured and filled with default records created during the installation with --setup-dns parameter. Please amend DNS names and IP addresses appropriately to your situation.

Parameters mentioned further in this text are located in file /etc/named.conf in section ipa. Following example shows only psearch parameter, other lines were omitted:

dynamic-db "ipa" {
        arg "psearch yes";
}

Adding a new zone

A new zone is added using the ipa dnszone-add command. Here is an example for domain name "new.test", DNS server name is "vm-148.lab.example.". (Period at the end of name is intentional.)

$ ipa dnszone-add new.test --name-server=vm-148.lab.example. --admin-email=hostmaster.new.test
 Zone name: new.test
 Authoritative nameserver: vm-148.lab.example.
 Administrator e-mail address: hostmaster.new.test.
 SOA serial: 1346759454
# snip


The new zone should be resolvable from client immediately:

$ dig @vm-148.lab.example. -t SOA new.test.
  ;; QUESTION SECTION:
  ;new.test.			IN	SOA
 
  ;; ANSWER SECTION:
  new.test.		86400	IN	SOA	vm-148.lab.example. hostmaster.new.test. 1346758308 3600 900 1209600 3600
 
  ;; AUTHORITY SECTION:
 new.test.		86400	IN	NS	vm-148.lab.example.
 
  ;; ADDITIONAL SECTION:
 vm-148.lab.example. 1200 IN	A	192.168.10.148

Without persistent search user has to wait up to zone_refresh seconds before resolving the zone. This parameter is also in "ipa" section in /etc/named.conf. (In older installs it was 30 seconds by default.)

Adding and managing a record

Now add an arbitrary record to the new zone:

$ ipa dnsrecord-add new.test. txt1 "--txt-data=First value"
  Record name: txt1
  TXT record: First value


The new record will be resolvable immediately. This case disregards persistent search, because there is no negative cache on the DNS server.

$ dig @vm-148.lab.example. -t TXT txt1.new.test.
  ;; QUESTION SECTION:
  ;txt1.new.test.			IN	TXT
  
  ;; ANSWER SECTION:
  txt1.new.test.		86400	IN	TXT	"First" "value"


Now we will change "txt1" record's value. --txt-rec parameter specifies an old value and --txt-data specifies a new value.

$ ipa dnsrecord-mod new.test. txt1 "--txt-rec=First value" "--txt-data=Second value" 
  Record name: txt1
  TXT record: Second value


New DNS query from client will return latest value immediately:

$ dig @vm-148.lab.example. -t TXT txt1.new.test.
  ;; ANSWER SECTION:
  txt1.new.test.		86400	IN	TXT	"Second" "value"

In deployments without persistent search DNS server will return old value until internal cache expires. Default time to live is 120 seconds and it can be changed with cache_ttl parameter in named.conf.


SOA serial number auto-increment

Each DNS zone contains "serial number" which has to be incremented after each change. FreeIPA 3.0 increments serial number automatically after each change in LDAP DB by default. This behaviour can be changed with serial_autoincrement parameter in named.conf. (This feature is closely related to persistent search. Persistent search is required for serial auto-increment to work.)

Now query the actual SOA serial number value:

$ dig @vm-148.lab.example. +multiline -t SOA new.test.
  ;; ANSWER SECTION:
  new.test.		86400 IN SOA vm-148.lab.example. hostmaster.new.test. (
				1346760629 ; serial
				3600       ; refresh (1 hour)
				900        ; retry (15 minutes)
				1209600    ; expire (2 weeks)
				3600       ; minimum (1 hour)
				)

SOA serial number should be incremented automatically after any change in DNS zone. Try to add/modify/delete any record in a zone and re-query the SOA record. It should contain new serial value. New value has to be higher than the old one.