]> granicus.if.org Git - pdns/commitdiff
dnsupdate: Use automatic numbering for documentation
authorAki Tuomi <cmouse@cmouse.fi>
Tue, 2 Aug 2016 21:34:47 +0000 (00:34 +0300)
committerAki Tuomi <cmouse@cmouse.fi>
Sat, 3 Sep 2016 21:26:36 +0000 (00:26 +0300)
docs/markdown/authoritative/dnsupdate.md

index 1d6be3f03ed5432af0bddb413cecc3cfcfe19ea9..e123d0a3c2104d237bb7d8894e244d942e259d9f 100644 (file)
@@ -234,16 +234,16 @@ Restart PowerDNS and you should be ready to go!
 This is a short description of how DNS update messages are processed by PowerDNS.
 
 1.  The DNS update 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 **dnsupdate** setting is checked. Refused is returned when the setting is 'no'.
-4.  If the **ALLOW-DNSUPDATE-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-DNSUPDATE-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-DNSUPDATE 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-dnsupdate** 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 [SOA Serial Updates](#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.
+1.  A check is performed on the zone to see if it is a valid zone. ServFail is returned when not valid.
+1.  The **dnsupdate** setting is checked. Refused is returned when the setting is 'no'.
+1.  If the **ALLOW-DNSUPDATE-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-DNSUPDATE-FROM**, Refused is returned.
+1.  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-DNSUPDATE domainmetadata setting is used to find which key belongs to the domain.
+1.  The backends are queried to find the backend for the given domain.
+1.  If the domain is a slave domain, the **forward-dnsupdate** 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.
+1.  A check is performed to make sure all updates/prerequisites are for the given zone. NotZone is returned if this is not the case.
+1.  The transaction with the backend is started.
+1. The prerequisite checks are performed (section 3.2 of RFC2136). If a check fails, the corresponding RCode is returned. No further processing will happen.
+1. 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.
+1. If there are records updated and the SOA record was not modified, the SOA serial is updated. See [SOA Serial Updates](#soa-serial-updates). The cache for this record is purged.
+1. The transaction with the backend is committed. If this fails, ServFail is returned.
+1. NoError is returned.