SOA record: Difference between revisions
Trailing dot is required in the RNAME unless this is a relative name |
|||
(45 intermediate revisions by 32 users not shown) | |||
Line 1: | Line 1: | ||
{{short description|Type of resource record in the Domain Name System}} |
|||
'''SOA''' means ''Start of Authority'' and is a significant part of a zone file in the domain name system (DNS). A SOA-Record contains important management information about the zone, especially regarding the zone transfer. The SOA-Record is specified in RFC 1035. |
|||
A '''start of authority record''' (abbreviated as '''SOA record''') is a type of [[resource record]] in the [[Domain Name System]] (DNS) containing administrative information about the zone, especially regarding [[DNS zone transfer|zone transfer]]s. The SOA record format is specified in RFC 1035.<ref name="RFC 1035"/> |
|||
== Background == |
== Background == |
||
Normally DNS name servers are set up in clusters. The database within |
Normally DNS name servers are set up in clusters. The database within each cluster is synchronized through zone transfers. The SOA record for a zone contains data to control the zone transfer. This is the serial number and different timespans. |
||
It also contains the |
It also contains the [[email address]] of the responsible person for this zone, as well as the name of the primary master name server. Usually the SOA record is located at the top of the zone. A zone without a SOA record does not conform to the standard required by RFC{{nbsp}}1035. |
||
Usually the SOA-Record is located at the top of the zone. A zone without a SOA-Record does not meet the standard and is therefore not transferable. |
|||
== Structure == |
== Structure == |
||
; NAME: Name of the zone. {{char|@}} is a shortcut to match previous record in [[BIND]] syntax. |
|||
; name |
|||
⚫ | |||
: name of the zone |
|||
⚫ | |||
; IN |
|||
; TTL: Time-to-live |
|||
⚫ | |||
; MNAME: Primary master name server for this zone{{bulleted list |
|||
; SOA |
|||
| [[Dynamic DNS|UPDATE requests]] should be forwarded toward the primary master<ref name="RFC 2136" /> |
|||
⚫ | |||
| [[Dynamic DNS|NOTIFY requests]] propagate outward from the primary master<ref name="RFC 1996" /> |
|||
; Primary |
|||
}} |
|||
: primary master for this zone, practically not very meaningful |
|||
; RNAME: Email address of the administrator responsible for this zone. (As usual, the email address is encoded as a name. The part of the email address before the {{char|@}} becomes the first label of the name; the domain name after the {{char|@}} becomes the rest of the name. In zone-file format, dots in labels are escaped with backslashes; thus the email address <code>john.doe@example.com</code> would be represented in a zone file as <code>john\.doe.example.com.</code>) |
|||
: * it is defining to which server dynamic updates should be sent |
|||
; SERIAL: Serial number for this zone. If a secondary name server slaved to this one observes an increase in this number, the slave will assume that the zone has been updated and initiate a [[DNS zone transfer|zone transfer]]. |
|||
: * it defines to which server no notifies should be sent |
|||
⚫ | |||
; Mail-Address |
|||
⚫ | |||
: mail address of the responsible of this zone. (The <code>@</code> is replaced with a <code>.</code>. Dots before the <code>@</code> are replaced with <code>\.</code>; e.g. <code>john\.doe.example.com</code> for the mail address <code>john.doe@example.com</code>) |
|||
; EXPIRE: Number of seconds after which secondary name servers should stop answering request for this zone if the master does not respond. This value must be bigger than the sum of ''Refresh'' and ''Retry''. Recommendation for small and stable zones:<ref name="RIPE 203"/> {{val|3600000}} seconds ({{val|1000}} hours). |
|||
; Serial Number |
|||
; MINIMUM: Used in calculating the [[time to live#DNS records|time to live]] for purposes of [[negative caching]]. Authoritative name servers take the smaller of the SOA TTL and the SOA MINIMUM to send as the SOA TTL in negative responses. Resolvers use the resulting SOA TTL to understand for how long they are allowed to cache a negative response. Recommendation for small and stable zones:<ref name="RIPE 203"/> {{val|172800}} seconds (2 days). Originally this field had the meaning of a ''minimum'' TTL value for resource records in this zone; it was changed to its current meaning by RFC 2308.<ref name="RFC 2308"/> |
|||
: is increased at every change (common naming scheme: YYYYMMDDVV; is a hint when the zone was updated the last time) |
|||
; Refresh |
|||
: number of seconds after which secondary name servers should request the serial number from the primary name server, to detect zone changes. Recommendation of RIPE for small and stable zones: 86400 ≙ 24 hours<ref name="ripe-203">{{cite web | url=http://www.ripe.net/ripe/docs/ripe-203 | title=Recommendations for DNS SOA Values | quote=These recommendations are aimed at small and stable DNS zones.}}</ref> |
|||
; Retry |
|||
⚫ | |||
; Expire |
|||
⚫ | : |
||
; TTL |
|||
: Time to Live for negative caching (Recommendation of RIPE NCC for small and stable zones: 172800 ≙ 2 days<ref name="ripe-203" />). Originally this field had the meaning of a minimum TTL value for all resource records of this zone and was used in the field if no TTL was specified. This was obsolated by RFC 2308.<ref name="rfc-2308">RFC 2308 – Negative ''Caching of DNS Queries (DNS NCACHE'')</ref> |
|||
== Sample SOA |
== Sample SOA record == |
||
Sample SOA record for example.org, in [[BIND]] syntax. |
|||
<pre> |
|||
@ IN SOA master.example.com. hostmaster. |
|||
example.com. ( |
|||
2017030300 ; serial |
|||
⚫ | |||
1800 ; retry |
|||
604800 ; expire |
|||
600 ) ; ttl |
|||
</pre> |
|||
{{sxhl|2=zone| |
|||
⚫ | |||
$TTL 86400 |
|||
@ IN SOA ns.icann.org. noc.dns.icann.org. ( |
|||
2020080302 ;Serial |
|||
7200 ;Refresh |
|||
⚫ | |||
1209600 ;Expire |
|||
3600 ;Negative response caching TTL |
|||
) |
|||
}} |
|||
== Serial number changes == |
|||
⚫ | |||
⚫ | |||
Several methods have been established for updates to the SERIAL field of a zone's SOA record: |
|||
⚫ | |||
⚫ | |||
⚫ | * The serial number contains the date of the last change (in [[ISO 8601]] basic format) followed by a two-digit counter. For example, the fifth change made on 14 March 2017 (2017-03-14 in [[ISO 8601]]) would have the serial number 2017031405. This method is recommended in RFC 1912.<ref name="RFC 1912"/> |
||
* The serial number is the time of last modification to the zone's data file expressed as the number of seconds since the [[Unix time|UNIX epoch]]. This method is used by default in the [[djbdns]] suite.<ref>{{Cite web |last=Bernstein |first=D.J. |title=How to run a DNS server in place of an existing BIND server |url=https://cr.yp.to/djbdns/run-server-bind.html |access-date=2023-03-13}}</ref> Although it uses a 32-bit counter, it is not susceptible to the [[year 2038 problem]] due to the effect of [[serial number arithmetic]]. |
|||
== References == |
== References == |
||
<references> |
<references> |
||
<ref name="RFC |
<ref name="RFC 1035">{{cite journal |url=https://tools.ietf.org/html/rfc1035#section-3.3.13 |title=RFC 1035 — Domain names - implementation and specification |date=November 1987 |doi=10.17487/RFC1035 |access-date=2017-12-28|last1=Mockapetris |first1=P.V. |journal=Network Working Group}}</ref> |
||
<ref name="RFC 1912">{{cite journal |url=https://tools.ietf.org/html/rfc1912 |title=RFC 1912 — Common DNS Operational and Configuration Errors |date=February 1996 |doi=10.17487/RFC1912 |access-date=2017-12-28|last1=Barr |first1=D. |journal=Network Working Group}}</ref> |
|||
<ref name="RFC 1996">{{cite journal |url=https://tools.ietf.org/html/rfc1996 |title=RFC 1996 — A Mechanism for Prompt Notification of Zone Changes (DNS NOTIFY) |date=August 1996 |doi=10.17487/RFC1996 |access-date=2017-12-28|last1=Vixie |first1=P. |journal=Network Working Group}}</ref> |
|||
<ref name="RFC 2308">{{cite journal |url=https://tools.ietf.org/html/rfc2308 |title=RFC 2308 — Negative Caching of DNS Queries (DNS NCACHE) |date=March 1998 |doi=10.17487/RFC2308 |access-date=2017-12-28|last1=Andrews |first1=M. |doi-access=free |journal=Network Working Group}}</ref> |
|||
<ref name="RFC 2136">{{cite journal |url=https://tools.ietf.org/html/rfc2136 |title=RFC 2136 — Dynamic Updates in the Domain Name System (DNS UPDATE) |date=April 1997 |doi=10.17487/RFC2136 |access-date=2017-12-28|editor-last1=Vixie |editor-first1=P |last1=Thomson |first1=S. |last2=Rekhter |first2=Y. |last3=Bound |first3=J. |last4=Bound |first4=J. |journal=Network Working Group}}</ref> |
|||
<ref name="RIPE 203">{{cite web | url=https://www.ripe.net/publications/docs/ripe-203 |title=RIPE 203 — Recommendations for DNS SOA Values |date=1999-06-07 |access-date=2017-12-28 |quote=These recommendations are aimed at small and stable DNS zones. |journal=Network Working Group}}</ref> |
|||
</references> |
</references> |
||
[[Category: |
[[Category:DNS record types]] |
Latest revision as of 23:57, 1 October 2024
A start of authority record (abbreviated as SOA record) is a type of resource record in the Domain Name System (DNS) containing administrative information about the zone, especially regarding zone transfers. The SOA record format is specified in RFC 1035.[1]
Background
[edit]Normally DNS name servers are set up in clusters. The database within each cluster is synchronized through zone transfers. The SOA record for a zone contains data to control the zone transfer. This is the serial number and different timespans.
It also contains the email address of the responsible person for this zone, as well as the name of the primary master name server. Usually the SOA record is located at the top of the zone. A zone without a SOA record does not conform to the standard required by RFC 1035.
Structure
[edit]- NAME
- Name of the zone. @ is a shortcut to match previous record in BIND syntax.
- CLASS
- Zone class (all but universally IN for internet)
- TYPE
- SOA, abbreviation for start of authority
- TTL
- Time-to-live
- MNAME
- Primary master name server for this zone
- UPDATE requests should be forwarded toward the primary master[2]
- NOTIFY requests propagate outward from the primary master[3]
- RNAME
- Email address of the administrator responsible for this zone. (As usual, the email address is encoded as a name. The part of the email address before the @ becomes the first label of the name; the domain name after the @ becomes the rest of the name. In zone-file format, dots in labels are escaped with backslashes; thus the email address
john.doe@example.com
would be represented in a zone file asjohn\.doe.example.com.
) - SERIAL
- Serial number for this zone. If a secondary name server slaved to this one observes an increase in this number, the slave will assume that the zone has been updated and initiate a zone transfer.
- REFRESH
- Number of seconds after which secondary name servers should query the master for the SOA record, to detect zone changes. Recommendation for small and stable zones:[4] 86400 seconds (24 hours).
- RETRY
- Number of seconds after which secondary name servers should retry to request the serial number from the master if the master does not respond. It must be less than Refresh. Recommendation for small and stable zones:[4] 7200 seconds (2 hours).
- EXPIRE
- Number of seconds after which secondary name servers should stop answering request for this zone if the master does not respond. This value must be bigger than the sum of Refresh and Retry. Recommendation for small and stable zones:[4] 3600000 seconds (1000 hours).
- MINIMUM
- Used in calculating the time to live for purposes of negative caching. Authoritative name servers take the smaller of the SOA TTL and the SOA MINIMUM to send as the SOA TTL in negative responses. Resolvers use the resulting SOA TTL to understand for how long they are allowed to cache a negative response. Recommendation for small and stable zones:[4] 172800 seconds (2 days). Originally this field had the meaning of a minimum TTL value for resource records in this zone; it was changed to its current meaning by RFC 2308.[5]
Sample SOA record
[edit]Sample SOA record for example.org, in BIND syntax.
$TTL 86400
@ IN SOA ns.icann.org. noc.dns.icann.org. (
2020080302 ;Serial
7200 ;Refresh
3600 ;Retry
1209600 ;Expire
3600 ;Negative response caching TTL
)
Serial number changes
[edit]Several methods have been established for updates to the SERIAL field of a zone's SOA record:
- The serial number begins at 1, and is simply incremented at every change.
- The serial number contains the date of the last change (in ISO 8601 basic format) followed by a two-digit counter. For example, the fifth change made on 14 March 2017 (2017-03-14 in ISO 8601) would have the serial number 2017031405. This method is recommended in RFC 1912.[6]
- The serial number is the time of last modification to the zone's data file expressed as the number of seconds since the UNIX epoch. This method is used by default in the djbdns suite.[7] Although it uses a 32-bit counter, it is not susceptible to the year 2038 problem due to the effect of serial number arithmetic.
References
[edit]- ^ Mockapetris, P.V. (November 1987). "RFC 1035 — Domain names - implementation and specification". Network Working Group. doi:10.17487/RFC1035. Retrieved 2017-12-28.
- ^ Thomson, S.; Rekhter, Y.; Bound, J.; Bound, J. (April 1997). Vixie, P (ed.). "RFC 2136 — Dynamic Updates in the Domain Name System (DNS UPDATE)". Network Working Group. doi:10.17487/RFC2136. Retrieved 2017-12-28.
- ^ Vixie, P. (August 1996). "RFC 1996 — A Mechanism for Prompt Notification of Zone Changes (DNS NOTIFY)". Network Working Group. doi:10.17487/RFC1996. Retrieved 2017-12-28.
- ^ a b c d "RIPE 203 — Recommendations for DNS SOA Values". Network Working Group. 1999-06-07. Retrieved 2017-12-28.
These recommendations are aimed at small and stable DNS zones.
- ^ Andrews, M. (March 1998). "RFC 2308 — Negative Caching of DNS Queries (DNS NCACHE)". Network Working Group. doi:10.17487/RFC2308. Retrieved 2017-12-28.
- ^ Barr, D. (February 1996). "RFC 1912 — Common DNS Operational and Configuration Errors". Network Working Group. doi:10.17487/RFC1912. Retrieved 2017-12-28.
- ^ Bernstein, D.J. "How to run a DNS server in place of an existing BIND server". Retrieved 2023-03-13.