| 
									
										
										
										
											2019-08-30 15:58:25 +01:00
										 |  |  | .\" Generated by Mmark Markdown Processer - mmark.miek.nl | 
					
						
							| 
									
										
										
										
											2020-09-14 09:43:13 +00:00
										 |  |  | .TH "COREDNS-RELOAD" 7 "September 2020" "CoreDNS" "CoreDNS Plugins" | 
					
						
							| 
									
										
										
										
											2019-04-06 08:42:40 +01:00
										 |  |  | 
 | 
					
						
							| 
									
										
										
										
											2019-06-24 12:37:27 +01:00
										 |  |  | .SH "NAME" | 
					
						
							| 
									
										
										
										
											2019-04-06 08:42:40 +01:00
										 |  |  | .PP | 
					
						
							|  |  |  | \fIreload\fP - allows automatic reload of a changed Corefile. | 
					
						
							|  |  |  | 
 | 
					
						
							| 
									
										
										
										
											2019-06-24 12:37:27 +01:00
										 |  |  | .SH "DESCRIPTION" | 
					
						
							| 
									
										
										
										
											2019-04-06 08:42:40 +01:00
										 |  |  | .PP | 
					
						
							|  |  |  | This plugin allows automatic reload of a changed \fICorefile\fP. | 
					
						
							|  |  |  | To enable automatic reloading of \fIzone file\fP changes, use the \fB\fCauto\fR plugin. | 
					
						
							|  |  |  | 
 | 
					
						
							|  |  |  | .PP | 
					
						
							|  |  |  | This plugin periodically checks if the Corefile has changed by reading | 
					
						
							|  |  |  | it and calculating its MD5 checksum. If the file has changed, it reloads | 
					
						
							|  |  |  | CoreDNS with the new Corefile. This eliminates the need to send a SIGHUP | 
					
						
							|  |  |  | or SIGUSR1 after changing the Corefile. | 
					
						
							|  |  |  | 
 | 
					
						
							|  |  |  | .PP | 
					
						
							|  |  |  | The reloads are graceful - you should not see any loss of service when the | 
					
						
							|  |  |  | reload happens. Even if the new Corefile has an error, CoreDNS will continue | 
					
						
							|  |  |  | to run the old config and an error message will be printed to the log. But see | 
					
						
							|  |  |  | the Bugs section for failure modes. | 
					
						
							|  |  |  | 
 | 
					
						
							|  |  |  | .PP | 
					
						
							|  |  |  | In some environments (for example, Kubernetes), there may be many CoreDNS | 
					
						
							|  |  |  | instances that started very near the same time and all share a common | 
					
						
							|  |  |  | Corefile. To prevent these all from reloading at the same time, some | 
					
						
							|  |  |  | jitter is added to the reload check interval. This is jitter from the | 
					
						
							|  |  |  | perspective of multiple CoreDNS instances; each instance still checks on a | 
					
						
							|  |  |  | regular interval, but all of these instances will have their reloads spread | 
					
						
							|  |  |  | out across the jitter duration. This isn't strictly necessary given that the | 
					
						
							|  |  |  | reloads are graceful, and can be disabled by setting the jitter to \fB\fC0s\fR. | 
					
						
							|  |  |  | 
 | 
					
						
							|  |  |  | .PP | 
					
						
							|  |  |  | Jitter is re-calculated whenever the Corefile is reloaded. | 
					
						
							|  |  |  | 
 | 
					
						
							|  |  |  | .PP | 
					
						
							|  |  |  | This plugin can only be used once per Server Block. | 
					
						
							|  |  |  | 
 | 
					
						
							| 
									
										
										
										
											2019-06-24 12:37:27 +01:00
										 |  |  | .SH "SYNTAX" | 
					
						
							| 
									
										
										
										
											2019-04-06 08:42:40 +01:00
										 |  |  | .PP | 
					
						
							|  |  |  | .RS | 
					
						
							| 
									
										
										
										
											2018-02-03 19:20:22 +02:00
										 |  |  | 
 | 
					
						
							| 
									
										
										
										
											2019-04-06 08:42:40 +01:00
										 |  |  | .nf | 
					
						
							| 
									
										
										
										
											2018-02-03 19:20:22 +02:00
										 |  |  | reload [INTERVAL] [JITTER] | 
					
						
							| 
									
										
										
										
											2019-04-06 08:42:40 +01:00
										 |  |  | 
 | 
					
						
							| 
									
										
										
										
											2018-02-03 19:20:22 +02:00
										 |  |  | .fi | 
					
						
							| 
									
										
										
										
											2019-04-06 08:42:40 +01:00
										 |  |  | .RE | 
					
						
							|  |  |  | 
 | 
					
						
							| 
									
										
										
										
											2019-09-27 13:30:22 +01:00
										 |  |  | .PP | 
					
						
							|  |  |  | The plugin will check for changes every \fBINTERVAL\fP, subject to +/- the \fBJITTER\fP duration. | 
					
						
							|  |  |  | 
 | 
					
						
							| 
									
										
										
										
											2019-04-06 08:42:40 +01:00
										 |  |  | .IP \(bu 4 | 
					
						
							| 
									
										
										
										
											2019-11-15 15:45:09 +00:00
										 |  |  | \fBINTERVAL\fP and \fBJITTER\fP are Golang durations | 
					
						
							|  |  |  | \[la]https://golang.org/pkg/time/#ParseDuration\[ra]. | 
					
						
							| 
									
										
										
										
											2019-09-27 13:30:22 +01:00
										 |  |  | The default \fBINTERVAL\fP is 30s, default \fBJITTER\fP is 15s, the minimal value for \fBINTERVAL\fP | 
					
						
							|  |  |  | is 2s, and for \fBJITTER\fP it is 1s. If \fBJITTER\fP is more than half of \fBINTERVAL\fP, it will be | 
					
						
							|  |  |  | set to half of \fBINTERVAL\fP | 
					
						
							| 
									
										
										
										
											2019-04-06 08:42:40 +01:00
										 |  |  | 
 | 
					
						
							|  |  |  | 
 | 
					
						
							| 
									
										
										
										
											2019-06-24 12:37:27 +01:00
										 |  |  | .SH "EXAMPLES" | 
					
						
							| 
									
										
										
										
											2019-04-06 08:42:40 +01:00
										 |  |  | .PP | 
					
						
							| 
									
										
										
										
											2018-02-03 19:20:22 +02:00
										 |  |  | Check with the default intervals: | 
					
						
							|  |  |  | 
 | 
					
						
							| 
									
										
										
										
											2019-04-06 08:42:40 +01:00
										 |  |  | .PP | 
					
						
							|  |  |  | .RS | 
					
						
							|  |  |  | 
 | 
					
						
							|  |  |  | .nf | 
					
						
							|  |  |  | \&. { | 
					
						
							| 
									
										
										
										
											2018-02-03 19:20:22 +02:00
										 |  |  |     reload | 
					
						
							|  |  |  |     erratic | 
					
						
							|  |  |  | } | 
					
						
							| 
									
										
										
										
											2019-04-06 08:42:40 +01:00
										 |  |  | 
 | 
					
						
							| 
									
										
										
										
											2018-02-03 19:20:22 +02:00
										 |  |  | .fi | 
					
						
							| 
									
										
										
										
											2019-04-06 08:42:40 +01:00
										 |  |  | .RE | 
					
						
							|  |  |  | 
 | 
					
						
							|  |  |  | .PP | 
					
						
							| 
									
										
										
										
											2018-02-03 19:20:22 +02:00
										 |  |  | Check every 10 seconds (jitter is automatically set to 10 / 2 = 5 in this case): | 
					
						
							|  |  |  | 
 | 
					
						
							| 
									
										
										
										
											2019-04-06 08:42:40 +01:00
										 |  |  | .PP | 
					
						
							|  |  |  | .RS | 
					
						
							|  |  |  | 
 | 
					
						
							|  |  |  | .nf | 
					
						
							|  |  |  | \&. { | 
					
						
							| 
									
										
										
										
											2018-02-03 19:20:22 +02:00
										 |  |  |     reload 10s | 
					
						
							|  |  |  |     erratic | 
					
						
							|  |  |  | } | 
					
						
							| 
									
										
										
										
											2019-04-06 08:42:40 +01:00
										 |  |  | 
 | 
					
						
							| 
									
										
										
										
											2018-02-03 19:20:22 +02:00
										 |  |  | .fi | 
					
						
							| 
									
										
										
										
											2019-04-06 08:42:40 +01:00
										 |  |  | .RE | 
					
						
							|  |  |  | 
 | 
					
						
							| 
									
										
										
										
											2019-06-24 12:37:27 +01:00
										 |  |  | .SH "BUGS" | 
					
						
							| 
									
										
										
										
											2019-04-06 08:42:40 +01:00
										 |  |  | .PP | 
					
						
							|  |  |  | The reload happens without data loss (i.e. DNS queries keep flowing), but there is a corner case | 
					
						
							|  |  |  | where the reload fails, and you loose functionality. Consider the following Corefile: | 
					
						
							| 
									
										
										
										
											2018-02-03 19:20:22 +02:00
										 |  |  | 
 | 
					
						
							| 
									
										
										
										
											2019-04-06 08:42:40 +01:00
										 |  |  | .PP | 
					
						
							|  |  |  | .RS | 
					
						
							|  |  |  | 
 | 
					
						
							|  |  |  | .nf | 
					
						
							|  |  |  | \&. { | 
					
						
							| 
									
										
										
										
											2019-09-27 13:30:22 +01:00
										 |  |  |     health :8080 | 
					
						
							|  |  |  |     whoami | 
					
						
							| 
									
										
										
										
											2018-04-23 12:47:32 +01:00
										 |  |  | } | 
					
						
							| 
									
										
										
										
											2019-04-06 08:42:40 +01:00
										 |  |  | 
 | 
					
						
							| 
									
										
										
										
											2018-04-23 12:47:32 +01:00
										 |  |  | .fi | 
					
						
							| 
									
										
										
										
											2019-04-06 08:42:40 +01:00
										 |  |  | .RE | 
					
						
							|  |  |  | 
 | 
					
						
							|  |  |  | .PP | 
					
						
							|  |  |  | CoreDNS starts and serves health from :8080. Now you change \fB\fC:8080\fR to \fB\fC:443\fR not knowing a process | 
					
						
							|  |  |  | is already listening on that port. The process reloads and performs the following steps: | 
					
						
							|  |  |  | 
 | 
					
						
							|  |  |  | .IP 1\. 4 | 
					
						
							| 
									
										
										
										
											2018-04-23 12:47:32 +01:00
										 |  |  | close the listener on 8080 | 
					
						
							| 
									
										
										
										
											2019-04-06 08:42:40 +01:00
										 |  |  | .IP 2\. 4 | 
					
						
							| 
									
										
										
										
											2018-04-23 12:47:32 +01:00
										 |  |  | reload and parse the config again | 
					
						
							| 
									
										
										
										
											2019-04-06 08:42:40 +01:00
										 |  |  | .IP 3\. 4 | 
					
						
							| 
									
										
										
										
											2018-04-23 12:47:32 +01:00
										 |  |  | fail to start a new listener on 443 | 
					
						
							| 
									
										
										
										
											2019-04-06 08:42:40 +01:00
										 |  |  | .IP 4\. 4 | 
					
						
							| 
									
										
										
										
											2018-04-23 12:47:32 +01:00
										 |  |  | fail loading the new Corefile, abort and keep using the old process | 
					
						
							| 
									
										
										
										
											2019-04-06 08:42:40 +01:00
										 |  |  | 
 | 
					
						
							|  |  |  | 
 | 
					
						
							|  |  |  | .PP | 
					
						
							|  |  |  | After the aborted attempt to reload we are left with the old processes running, but the listener is | 
					
						
							| 
									
										
										
										
											2020-03-31 14:18:39 +00:00
										 |  |  | closed in step 1; so the health endpoint is broken. The same can happen in the prometheus plugin. | 
					
						
							| 
									
										
										
										
											2019-04-06 08:42:40 +01:00
										 |  |  | 
 | 
					
						
							|  |  |  | .PP | 
					
						
							|  |  |  | In general be careful with assigning new port and expecting reload to work fully. | 
					
						
							|  |  |  | 
 | 
					
						
							|  |  |  | .PP | 
					
						
							| 
									
										
										
										
											2019-08-01 14:00:37 +00:00
										 |  |  | In CoreDNS v1.6.0 and earlier any \fB\fCimport\fR statements are not discovered by this plugin. | 
					
						
							|  |  |  | This means if any of these imported files changes the \fIreload\fP plugin is ignorant of that fact. | 
					
						
							|  |  |  | CoreDNS v1.7.0 and later does parse the Corefile and supports detecting changes in imported files. | 
					
						
							| 
									
										
										
										
											2019-04-06 08:42:40 +01:00
										 |  |  | 
 | 
					
						
							| 
									
										
										
										
											2019-06-26 11:18:03 +01:00
										 |  |  | .SH "METRICS" | 
					
						
							|  |  |  | .PP | 
					
						
							| 
									
										
										
										
											2019-10-10 07:45:28 +01:00
										 |  |  | If monitoring is enabled (via the \fIprometheus\fP plugin) then the following metric is exported: | 
					
						
							| 
									
										
										
										
											2019-06-26 11:18:03 +01:00
										 |  |  | 
 | 
					
						
							|  |  |  | .IP \(bu 4 | 
					
						
							| 
									
										
										
										
											2020-03-31 14:18:39 +00:00
										 |  |  | \fB\fCcoredns_reload_failed_total{}\fR - counts the number of failed reload attempts. | 
					
						
							|  |  |  | .IP \(bu 4 | 
					
						
							|  |  |  | \fB\fCcoredns_reload_version_info{hash, value}\fR - record the hash value during reload. | 
					
						
							|  |  |  | 
 | 
					
						
							| 
									
										
										
										
											2019-06-26 11:18:03 +01:00
										 |  |  | 
 | 
					
						
							| 
									
										
										
										
											2020-03-31 14:18:39 +00:00
										 |  |  | .PP | 
					
						
							|  |  |  | Currently the type of \fB\fChash\fR is "md5", the \fB\fCvalue\fR is the returned hash value. | 
					
						
							| 
									
										
										
										
											2019-06-26 11:18:03 +01:00
										 |  |  | 
 | 
					
						
							| 
									
										
										
										
											2019-06-24 12:37:27 +01:00
										 |  |  | .SH "ALSO SEE" | 
					
						
							| 
									
										
										
										
											2019-04-06 08:42:40 +01:00
										 |  |  | .PP | 
					
						
							|  |  |  | See coredns-import(7) and corefile(5). | 
					
						
							|  |  |  | 
 |