5. How it works

This is a short description of how RFC2136 (update) messages are processed by PowerDNS.

  1. The RFC2136 message is received. If it is TSIG signed, the TSIG is validated against the tsigkeys table. If it is not valid, Refused is returned to the requestor.

  2. A check is performed on the zone to see if it is a valid zone. ServFail is returned when not valid.

  3. The experimental-rfc2136 setting is checked. Refused is returned when the setting is 'no'.

  4. If the ALLOW-2136-FROM has a value (from both domainmetadata and the configuration file), a check on the value is performed. If the requestor (sender of the update message) does not match the values in ALLOW-2136-FROM, Refused is returned.

  5. If the message is TSIG signed, the TSIG keyname is compared with the TSIG keyname in domainmetadata. If they do not match, a Refused is send. The TSIG-ALLOW-2136 domainmetadata setting is used to find which key belongs to the domain.

  6. The backends are queried to find the backend for the given domain.

  7. If the domain is a slave domain, the forward-2136 option and domainmetadata settings are checked. If forwarding to a master is enabled, the message is forward to the master. If that fails, the next master is tried until all masters are tried. If all masters fail, ServFail is returned. If a master succeeds, the result from that master is returned.

  8. A check is performed to make sure all updates/prerequisites are for the given zone. NotZone is returned if this is not the case.

  9. The transaction with the backend is started.

  10. The prerequisite checks are performed (section 3.2 of RFC2136). If a check fails, the corresponding RCode is returned. No further processing will happen.

  11. Per record in the update message, a the prescan checks are performed. If the prescan fails, the corresponding RCode is returned. If the prescan for the record is correct, the actual update/delete/modify of the record is performed. If the update fails (for whatever reason), ServFail is returned. After changes to the records have been applied, the ordername and auth flag are set to make sure DNSSEC remains working. The cache for that record is purged.

  12. If there are records updated and the SOA record was not modified, the SOA serial is updated. See Section 3, “SOA Serial Updates”. The cache for this record is purged.

  13. The transaction with the backend is committed. If this fails, ServFail is returned.

  14. NoError is returned.