The Fallacy of DNS "propagation" - Revision history

Rich at 17:30, 8 October 2011

2011-10-08T17:30:04Z

← Older revision		Revision as of 17:30, 8 October 2011
Line 8:		Line 8:


-	:Now, repeat the following until you remember it: Caching servers (resolvers) pull the data from the authoritative server. The authoritative server does not push (propagate) the data. "Propagation" is a term used by people who don't understand the correct usage of TTL.	+	:Now repeat the following until you remember it: Caching servers (resolvers) pull the data from the authoritative server. The authoritative server does not push (propagate) the data. "Propagation" is a term used by people who don't understand the correct usage of TTL.

Rich at 14:59, 8 October 2011

2011-10-08T14:59:06Z

← Older revision		Revision as of 14:59, 8 October 2011
Line 2:		Line 2:


-	:I was prompted to write this article after working on a cutover with an email provider. Despite my TTL being set to 5 seconds for days, their engineer was insistent that we had to "wait for the DNS changes to propagate" before the mail server would function properly and that it "could take up to a day before the propagation was complete". Even worse, he claimed his team of 20 engineers believed the same thing.	+	:I was prompted to write this article after working on a cutover with an email provider. Despite my TTL being set to 60 seconds for days, their engineer was insistent that we had to "wait for the DNS changes to propagate" before the mail server would function properly and that it "could take up to a day before the propagation was complete". Even worse, he claimed his team of 20 engineers believed the same thing.


Line 8:		Line 8:


-	:Now, repeat the following until you remember it: Caching servers (resolvers) pull the data from the authoritative server. The authoritative server does not push (propagate) the data.	+	:Now, repeat the following until you remember it: Caching servers (resolvers) pull the data from the authoritative server. The authoritative server does not push (propagate) the data. "Propagation" is a term used by people who don't understand the correct usage of TTL.


Line 14:		Line 14:


-	:Besides a DNS name and IP address, clients and caching servers also cache a value called "TTL" or "Time to Live". This value represents the number of seconds that the information is valid for. Once the time has expired, a client or caching server is required to ask your DNS server for new information. Historically the default TTL has been 86400 seconds (one day). In this scenario it can take up to a day for the internet to see your DNS ~~change~~. The correct way to administrate DNS is to set the TTL and negative cache setting to a low value (for example 300 seconds) at least a day prior to your DNS change (or longer if your default TTL is greater than 86400). Doing it this way allows sufficient time for all the clients/resolvers to honor your new 300 second TTL. Now your DNS changes will be recognized in 5 minutes or less. Of course you can use lower values (like 60 seconds) if needed. Remember to increment your zone serial number when reducing your TTL. This is a frequently overlooked step.	+	:Besides a DNS name and IP address, clients and caching servers also cache a value called "TTL" or "Time to Live". This value represents the number of seconds that the information is valid for. Once the time has expired, a client or caching server is required to ask your DNS server for new information. Historically the default TTL has been 86400 seconds (one day). In this scenario it can take up to a day for the internet to see your DNS changes if you don't adjust TTL first. The correct way to administrate DNS is to set the TTL and negative cache setting to a low value (for example 300 seconds) at least a day prior to your DNS change (or longer if your default TTL is greater than 86400). Doing it this way allows sufficient time for all the clients/resolvers to honor your new 300 second TTL. Now your DNS changes will be recognized in 5 minutes or less. Of course you can use lower values (like 60 seconds) if needed. Remember to increment your zone serial number when reducing your TTL. This is a frequently overlooked step.

Rich at 23:16, 7 October 2011

2011-10-07T23:16:43Z

← Older revision		Revision as of 23:16, 7 October 2011
Line 20:		Line 20:


-	:Proper usage of TTL can make cutovers nearly instantaneous. Keep in mind that some socket based applications may do a DNS lookup (gethostbyname) only once and may need to be reset. A properly written program will always perform a gethostbyname prior to each time it opens a socket (~~unless~~ it has a cached list from a previous round-robin DNS reply).	+	:Proper usage of TTL can make cutovers nearly instantaneous. Keep in mind that some socket based applications may do a DNS lookup (gethostbyname) only once and may need to be reset. A properly written program will always perform a gethostbyname prior to each time it opens a socket (except when it has a cached list from a previous round-robin DNS reply).

Rich at 23:16, 7 October 2011

2011-10-07T23:16:03Z

← Older revision		Revision as of 23:16, 7 October 2011
Line 20:		Line 20:


-	:Proper usage of TTL can make cutovers nearly instantaneous. Keep in mind that some socket based applications may do a DNS lookup (gethostbyname) only once and may need to be reset. A properly written program will always perform a gethostbyname prior to each time it opens a socket.	+	:Proper usage of TTL can make cutovers nearly instantaneous. Keep in mind that some socket based applications may do a DNS lookup (gethostbyname) only once and may need to be reset. A properly written program will always perform a gethostbyname prior to each time it opens a socket (unless it has a cached list from a previous round-robin DNS reply).

Rich at 22:20, 7 October 2011

2011-10-07T22:20:44Z

← Older revision		Revision as of 22:20, 7 October 2011
Line 14:		Line 14:


-	:Besides a DNS name and IP address, clients and caching servers also cache a value called "TTL" or "Time to Live". This value represents the number of seconds that the information is valid for. Once the time has expired, a client or caching server is required to ask your DNS server for new information. Historically the default TTL has been 86400 seconds (one day). In this scenario is can take up to a day for the internet to see your DNS change. The correct way to administrate DNS is to set the TTL and negative cache setting to a low value (for example 300 seconds) at least a day prior to your DNS change (or longer if your default TTL is greater than 86400). Doing it this way allows sufficient time for all the clients/resolvers to honor your new 300 second TTL. Now your DNS changes will be recognized in 5 minutes or less. Of course you can use lower values (like 60 seconds) if needed. Remember to increment your zone serial number when reducing your TTL. This is a frequently overlooked step.	+	:Besides a DNS name and IP address, clients and caching servers also cache a value called "TTL" or "Time to Live". This value represents the number of seconds that the information is valid for. Once the time has expired, a client or caching server is required to ask your DNS server for new information. Historically the default TTL has been 86400 seconds (one day). In this scenario it can take up to a day for the internet to see your DNS change. The correct way to administrate DNS is to set the TTL and negative cache setting to a low value (for example 300 seconds) at least a day prior to your DNS change (or longer if your default TTL is greater than 86400). Doing it this way allows sufficient time for all the clients/resolvers to honor your new 300 second TTL. Now your DNS changes will be recognized in 5 minutes or less. Of course you can use lower values (like 60 seconds) if needed. Remember to increment your zone serial number when reducing your TTL. This is a frequently overlooked step.

Rich at 19:56, 7 October 2011

2011-10-07T19:56:33Z

← Older revision		Revision as of 19:56, 7 October 2011
Line 8:		Line 8:


-	:Now, repeat the following until you remember it: ~~Clients and caching~~ servers (resolvers) pull the data from the authoritative server. The authoritative server does not push (propagate) the data.	+	:Now, repeat the following until you remember it: Caching servers (resolvers) pull the data from the authoritative server. The authoritative server does not push (propagate) the data.

Rich at 18:02, 7 October 2011

2011-10-07T18:02:32Z

← Older revision		Revision as of 18:02, 7 October 2011
Line 14:		Line 14:


-	:Besides a DNS name and IP address, clients and caching servers also cache a value called "TTL" or "Time to Live". This value represents the number of seconds that the information is valid for. ~~One~~ the time has expired, a client or caching server is required to ask your DNS server for new information. Historically the default TTL has been 86400 seconds (one day). In this scenario is can take up to a day for the internet to see your DNS change. The correct way to administrate DNS is to set the TTL and negative cache setting to a low value (for example 300 seconds) at least a day prior to your DNS change (or longer if your default TTL is greater than 86400). Doing it this way allows sufficient time for all the clients/resolvers to honor your new 300 second TTL. Now your DNS changes will be recognized in 5 minutes or less. Of course you can use lower values (like 60 seconds) if needed. Remember to increment your zone serial number when reducing your TTL. This is a frequently overlooked step.	+	:Besides a DNS name and IP address, clients and caching servers also cache a value called "TTL" or "Time to Live". This value represents the number of seconds that the information is valid for. Once the time has expired, a client or caching server is required to ask your DNS server for new information. Historically the default TTL has been 86400 seconds (one day). In this scenario is can take up to a day for the internet to see your DNS change. The correct way to administrate DNS is to set the TTL and negative cache setting to a low value (for example 300 seconds) at least a day prior to your DNS change (or longer if your default TTL is greater than 86400). Doing it this way allows sufficient time for all the clients/resolvers to honor your new 300 second TTL. Now your DNS changes will be recognized in 5 minutes or less. Of course you can use lower values (like 60 seconds) if needed. Remember to increment your zone serial number when reducing your TTL. This is a frequently overlooked step.

Rich at 16:15, 7 October 2011

2011-10-07T16:15:04Z

← Older revision		Revision as of 16:15, 7 October 2011
Line 1:		Line 1:
-	:One of the biggest misconceptions among network engineers is the belief that DNS zone changes require time to "propagate" across the internet. The point of this article is to give the reader an understanding of how DNS works and to prevent the further propagation of this "propagation" nonsense (pun intended).	+	:One of the biggest misconceptions among network engineers is the belief that DNS zone changes require some mysterious amount of time to "propagate" across the internet. The point of this article is to give the reader an understanding of how DNS works and to prevent the further propagation of this "propagation" nonsense (pun intended).


-	:I was prompted to write this article after working on a cutover with an email provider. Despite my TTL being set to 5 seconds, their engineer was insistent that we had to "wait for the DNS changes to propagate" before the mail server would function properly and that it "could take up to a day before the propagation was complete". Even worse, he claimed his team of 20 engineers believed the same thing.	+	:I was prompted to write this article after working on a cutover with an email provider. Despite my TTL being set to 5 seconds for days, their engineer was insistent that we had to "wait for the DNS changes to propagate" before the mail server would function properly and that it "could take up to a day before the propagation was complete". Even worse, he claimed his team of 20 engineers believed the same thing.

Rich: Created page with ':One of the biggest misconceptions among network engineers is the belief that DNS zone changes require time to "propagate" across the internet. The point of this article is to gi…'

2011-10-07T16:07:00Z

Created page with ':One of the biggest misconceptions among network engineers is the belief that DNS zone changes require time to "propagate" across the internet. The point of this article is to gi…'

New page

:One of the biggest misconceptions among network engineers is the belief that DNS zone changes require time to "propagate" across the internet. The point of this article is to give the reader an understanding of how DNS works and to prevent the further propagation of this "propagation" nonsense (pun intended).

:I was prompted to write this article after working on a cutover with an email provider. Despite my TTL being set to 5 seconds, their engineer was insistent that we had to "wait for the DNS changes to propagate" before the mail server would function properly and that it "could take up to a day before the propagation was complete". Even worse, he claimed his team of 20 engineers believed the same thing.

:First off, you need to understand that DNS changes do not propagate because DNS is not based on a broadcast/multicast architecture.

:Now, repeat the following until you remember it: Clients and caching servers (resolvers) pull the data from the authoritative server. The authoritative server does not push (propagate) the data.

:Here is another point of clarification. Changes to an authoritative zone file are in fact instantaneous (provided you properly increment the serial number and reload the zone if the server requires it). Of course the first question is "then why does it take time for the rest of the internet to see the change?". This is not due to "propagation" delay, rather its due to clients and caching servers sitting on your old data. And the funny thing is that this is all your fault if you are the DNS administrator.

:Besides a DNS name and IP address, clients and caching servers also cache a value called "TTL" or "Time to Live". This value represents the number of seconds that the information is valid for. One the time has expired, a client or caching server is required to ask your DNS server for new information. Historically the default TTL has been 86400 seconds (one day). In this scenario is can take up to a day for the internet to see your DNS change. The correct way to administrate DNS is to set the TTL and negative cache setting to a low value (for example 300 seconds) at least a day prior to your DNS change (or longer if your default TTL is greater than 86400). Doing it this way allows sufficient time for all the clients/resolvers to honor your new 300 second TTL. Now your DNS changes will be recognized in 5 minutes or less. Of course you can use lower values (like 60 seconds) if needed. Remember to increment your zone serial number when reducing your TTL. This is a frequently overlooked step.

:You can increase your TTL once your changes are complete and you are satisfied with the results. Don't get in a big hurry to do this as your low TTL gives you the flexibility to make changes if there are problems.

:Proper usage of TTL can make cutovers nearly instantaneous. Keep in mind that some socket based applications may do a DNS lookup (gethostbyname) only once and may need to be reset. A properly written program will always perform a gethostbyname prior to each time it opens a socket.

:Now there are a couple of specific scenarios to be aware of. First is a zone transfer between a master authoritative server and a slave. The master server can be configured to notify the slave server of a zone change. This isn't exactly "propagation" but I thought it would be prudent to make mention of it.

:The other scenario is changing your registered nameservers with your domain registrar (or changing to a new registrar). There may be a variable amount of time it will take for your registrar to update the root/TLD servers, and keep in mind the root/TLD servers have a fixed TTL value for your nameservers. This is fairly easy to deal with, simply make your zones identical on the old and new servers (and have the new server serial number be +1 from the old server). Then make sure your old server is running long enough for the cached NS record TTL to expire.

:I hope this helps people have a better understanding how DNS works and encourages people to make correct use of TTL/negative cache values.