Google Cloud DNS changing Record Resource update time
up vote
1
down vote
favorite
I am currently trying to map a Compute Engine VM with an ephemeral IP to a hostname using Google Cloud DNS, this operation takes place at the VM startup time. I am doing this through a shell script as it follows:
gcloud dns record-sets transaction start -z=MY_ZONE
gcloud dns record-sets transaction remove --zone MY_ZONE
--name subd.domain.com
--type A "1.2.3.4" #the old external ip for the VM
--ttl 300
gcloud dns record-sets transaction add --zone MY_ZONE
--name subd.domain.com
--type A "5.6.7.8" #the new external ip for the VM
--ttl 300
gcloud dns record-sets transaction execute -z=MY_ZONE
After the script is run I can see the records successfully changed in the Cloud DNS UI, with the "A" RR having the new external IP.
What happens now is that it takes a really long time for these changes to really go live. Accessing the hostname "subd.domain.com" after the change returns an "NXDOMAIN" status lasting a long period of time and only after that it finally maps the domain to the new IP.
This situation raised two questions for me:
#1 Why does the DNS go through the NXDOMAIN phase? Shouldn't those changes act as an Update(due to running this in a transaction) and not as a Remove then Create.
#2 What determines the time for this record update to go live?
shell dns
google-compute-engine 
google-cloud-dns asked Nov 15 at 11:57
Brad
1549
add a comment |
up vote
1
down vote
favorite
I am currently trying to map a Compute Engine VM with an ephemeral IP to a hostname using Google Cloud DNS, this operation takes place at the VM startup time. I am doing this through a shell script as it follows:
gcloud dns record-sets transaction start -z=MY_ZONE
gcloud dns record-sets transaction remove --zone MY_ZONE
--name subd.domain.com
--type A "1.2.3.4" #the old external ip for the VM
--ttl 300
gcloud dns record-sets transaction add --zone MY_ZONE
--name subd.domain.com
--type A "5.6.7.8" #the new external ip for the VM
--ttl 300
gcloud dns record-sets transaction execute -z=MY_ZONE
After the script is run I can see the records successfully changed in the Cloud DNS UI, with the "A" RR having the new external IP.
What happens now is that it takes a really long time for these changes to really go live. Accessing the hostname "subd.domain.com" after the change returns an "NXDOMAIN" status lasting a long period of time and only after that it finally maps the domain to the new IP.
This situation raised two questions for me:
#1 Why does the DNS go through the NXDOMAIN phase? Shouldn't those changes act as an Update(due to running this in a transaction) and not as a Remove then Create.
#2 What determines the time for this record update to go live?
shell dns
google-compute-engine google-cloud-dns asked Nov 15 at 11:57
Brad
1549
1
How do you test if changes really went live, and what is "a long period of time"?
– Dusan Bajic
Nov 15 at 14:08
accesing this console.cloud.google.com/net-services/dns/zones?project=*PROJECT_NAME*, a long period of time in this case is 1-2 hours
– Brad
Nov 15 at 14:28
1
I will offer this suggestion based upon decades of DNS experience. Don't treat DNS as your on-demand database. The DNS ecosystem is not designed to support what you are trying to do. Each link in the chain caches DNS entries. You have no control over this process. In your example your TTL is 300 seconds. It will take as least 5 minutes before the next server above yours expires your entries. A lot of caches ignore your TTL and set it to hours or sometimes even days. You need to design your DNS setup to be "eventually consistent" and not "instantly consistent". Eventually means hours or days.
– John Hanley
Nov 19 at 23:22
@JohnHanley Thank you very much for your response, this I have also come to this conclusion. Could you please consider adding this as an answer?
– Brad
Nov 20 at 12:02
add a comment |
up vote
1
down vote
favorite
up vote
1
down vote
favorite
I am currently trying to map a Compute Engine VM with an ephemeral IP to a hostname using Google Cloud DNS, this operation takes place at the VM startup time. I am doing this through a shell script as it follows:
gcloud dns record-sets transaction start -z=MY_ZONE
gcloud dns record-sets transaction remove --zone MY_ZONE
--name subd.domain.com
--type A "1.2.3.4" #the old external ip for the VM
--ttl 300
gcloud dns record-sets transaction add --zone MY_ZONE
--name subd.domain.com
--type A "5.6.7.8" #the new external ip for the VM
--ttl 300
gcloud dns record-sets transaction execute -z=MY_ZONE
After the script is run I can see the records successfully changed in the Cloud DNS UI, with the "A" RR having the new external IP.
What happens now is that it takes a really long time for these changes to really go live. Accessing the hostname "subd.domain.com" after the change returns an "NXDOMAIN" status lasting a long period of time and only after that it finally maps the domain to the new IP.
This situation raised two questions for me:
#1 Why does the DNS go through the NXDOMAIN phase? Shouldn't those changes act as an Update(due to running this in a transaction) and not as a Remove then Create.
#2 What determines the time for this record update to go live?
shell dns
google-compute-engine google-cloud-dns asked Nov 15 at 11:57
Brad
1549
I am currently trying to map a Compute Engine VM with an ephemeral IP to a hostname using Google Cloud DNS, this operation takes place at the VM startup time. I am doing this through a shell script as it follows:
gcloud dns record-sets transaction start -z=MY_ZONE
gcloud dns record-sets transaction remove --zone MY_ZONE
--name subd.domain.com
--type A "1.2.3.4" #the old external ip for the VM
--ttl 300
gcloud dns record-sets transaction add --zone MY_ZONE
--name subd.domain.com
--type A "5.6.7.8" #the new external ip for the VM
--ttl 300
gcloud dns record-sets transaction execute -z=MY_ZONE
After the script is run I can see the records successfully changed in the Cloud DNS UI, with the "A" RR having the new external IP.
What happens now is that it takes a really long time for these changes to really go live. Accessing the hostname "subd.domain.com" after the change returns an "NXDOMAIN" status lasting a long period of time and only after that it finally maps the domain to the new IP.
This situation raised two questions for me:
#1 Why does the DNS go through the NXDOMAIN phase? Shouldn't those changes act as an Update(due to running this in a transaction) and not as a Remove then Create.
#2 What determines the time for this record update to go live?
shell dns
google-compute-engine google-cloud-dns shell dns
google-compute-engine google-cloud-dns asked Nov 15 at 11:57
Brad
1549
asked Nov 15 at 11:57
Brad
1549
asked Nov 15 at 11:57
Brad
1549
asked Nov 15 at 11:57
Brad
1549
asked Nov 15 at 11:57
Brad
1549
1549
1
How do you test if changes really went live, and what is "a long period of time"?
– Dusan Bajic
Nov 15 at 14:08
accesing this console.cloud.google.com/net-services/dns/zones?project=*PROJECT_NAME*, a long period of time in this case is 1-2 hours
– Brad
Nov 15 at 14:28
1
I will offer this suggestion based upon decades of DNS experience. Don't treat DNS as your on-demand database. The DNS ecosystem is not designed to support what you are trying to do. Each link in the chain caches DNS entries. You have no control over this process. In your example your TTL is 300 seconds. It will take as least 5 minutes before the next server above yours expires your entries. A lot of caches ignore your TTL and set it to hours or sometimes even days. You need to design your DNS setup to be "eventually consistent" and not "instantly consistent". Eventually means hours or days.
– John Hanley
Nov 19 at 23:22
@JohnHanley Thank you very much for your response, this I have also come to this conclusion. Could you please consider adding this as an answer?
– Brad
Nov 20 at 12:02
add a comment |
1
How do you test if changes really went live, and what is "a long period of time"?
– Dusan Bajic
Nov 15 at 14:08
accesing this console.cloud.google.com/net-services/dns/zones?project=*PROJECT_NAME*, a long period of time in this case is 1-2 hours
– Brad
Nov 15 at 14:28
1
I will offer this suggestion based upon decades of DNS experience. Don't treat DNS as your on-demand database. The DNS ecosystem is not designed to support what you are trying to do. Each link in the chain caches DNS entries. You have no control over this process. In your example your TTL is 300 seconds. It will take as least 5 minutes before the next server above yours expires your entries. A lot of caches ignore your TTL and set it to hours or sometimes even days. You need to design your DNS setup to be "eventually consistent" and not "instantly consistent". Eventually means hours or days.
– John Hanley
Nov 19 at 23:22
@JohnHanley Thank you very much for your response, this I have also come to this conclusion. Could you please consider adding this as an answer?
– Brad
Nov 20 at 12:02
1
1
How do you test if changes really went live, and what is "a long period of time"?
– Dusan Bajic
Nov 15 at 14:08
How do you test if changes really went live, and what is "a long period of time"?
– Dusan Bajic
Nov 15 at 14:08
accesing this console.cloud.google.com/net-services/dns/zones?project=*PROJECT_NAME*, a long period of time in this case is 1-2 hours
– Brad
Nov 15 at 14:28
accesing this console.cloud.google.com/net-services/dns/zones?project=*PROJECT_NAME*, a long period of time in this case is 1-2 hours
– Brad
Nov 15 at 14:28
1
1
I will offer this suggestion based upon decades of DNS experience. Don't treat DNS as your on-demand database. The DNS ecosystem is not designed to support what you are trying to do. Each link in the chain caches DNS entries. You have no control over this process. In your example your TTL is 300 seconds. It will take as least 5 minutes before the next server above yours expires your entries. A lot of caches ignore your TTL and set it to hours or sometimes even days. You need to design your DNS setup to be "eventually consistent" and not "instantly consistent". Eventually means hours or days.
– John Hanley
Nov 19 at 23:22
I will offer this suggestion based upon decades of DNS experience. Don't treat DNS as your on-demand database. The DNS ecosystem is not designed to support what you are trying to do. Each link in the chain caches DNS entries. You have no control over this process. In your example your TTL is 300 seconds. It will take as least 5 minutes before the next server above yours expires your entries. A lot of caches ignore your TTL and set it to hours or sometimes even days. You need to design your DNS setup to be "eventually consistent" and not "instantly consistent". Eventually means hours or days.
– John Hanley
Nov 19 at 23:22
@JohnHanley Thank you very much for your response, this I have also come to this conclusion. Could you please consider adding this as an answer?
– Brad
Nov 20 at 12:02
@JohnHanley Thank you very much for your response, this I have also come to this conclusion. Could you please consider adding this as an answer?
– Brad
Nov 20 at 12:02
add a comment |
1 Answer
1
active
oldest
votes
up vote
2
down vote
accepted
I will offer this suggestion based upon decades of DNS experience. Don't treat DNS as your on-demand database. The DNS ecosystem is not designed to support what you are trying to do. Each link in the chain caches DNS entries. You have no control over this process. In your example your TTL is 300 seconds. It will take as least 5 minutes before the next server above yours expires your entries. A lot of caches ignore your TTL and set it to hours or sometimes even days. You need to design your DNS setup to be "eventually consistent" and not "instantly consistent". Eventually means hours or days.
When planning for DNS changes, I plan for minimum of 48 hours for the change to take effect. This means that we maintain services on the old DNS entry while the new DNS entry takes effect.
answered Nov 20 at 18:05
John Hanley
12.1k2527
add a comment |
1 Answer
1
active
oldest
votes
1 Answer
1
active
oldest
votes
active
oldest
votes
active
oldest
votes
up vote
2
down vote
accepted
I will offer this suggestion based upon decades of DNS experience. Don't treat DNS as your on-demand database. The DNS ecosystem is not designed to support what you are trying to do. Each link in the chain caches DNS entries. You have no control over this process. In your example your TTL is 300 seconds. It will take as least 5 minutes before the next server above yours expires your entries. A lot of caches ignore your TTL and set it to hours or sometimes even days. You need to design your DNS setup to be "eventually consistent" and not "instantly consistent". Eventually means hours or days.
When planning for DNS changes, I plan for minimum of 48 hours for the change to take effect. This means that we maintain services on the old DNS entry while the new DNS entry takes effect.
answered Nov 20 at 18:05
John Hanley
12.1k2527
add a comment |
up vote
2
down vote
accepted
I will offer this suggestion based upon decades of DNS experience. Don't treat DNS as your on-demand database. The DNS ecosystem is not designed to support what you are trying to do. Each link in the chain caches DNS entries. You have no control over this process. In your example your TTL is 300 seconds. It will take as least 5 minutes before the next server above yours expires your entries. A lot of caches ignore your TTL and set it to hours or sometimes even days. You need to design your DNS setup to be "eventually consistent" and not "instantly consistent". Eventually means hours or days.
When planning for DNS changes, I plan for minimum of 48 hours for the change to take effect. This means that we maintain services on the old DNS entry while the new DNS entry takes effect.
answered Nov 20 at 18:05
John Hanley
12.1k2527
add a comment |
up vote
2
down vote
accepted
up vote
2
down vote
accepted
I will offer this suggestion based upon decades of DNS experience. Don't treat DNS as your on-demand database. The DNS ecosystem is not designed to support what you are trying to do. Each link in the chain caches DNS entries. You have no control over this process. In your example your TTL is 300 seconds. It will take as least 5 minutes before the next server above yours expires your entries. A lot of caches ignore your TTL and set it to hours or sometimes even days. You need to design your DNS setup to be "eventually consistent" and not "instantly consistent". Eventually means hours or days.
When planning for DNS changes, I plan for minimum of 48 hours for the change to take effect. This means that we maintain services on the old DNS entry while the new DNS entry takes effect.
answered Nov 20 at 18:05
John Hanley
12.1k2527
I will offer this suggestion based upon decades of DNS experience. Don't treat DNS as your on-demand database. The DNS ecosystem is not designed to support what you are trying to do. Each link in the chain caches DNS entries. You have no control over this process. In your example your TTL is 300 seconds. It will take as least 5 minutes before the next server above yours expires your entries. A lot of caches ignore your TTL and set it to hours or sometimes even days. You need to design your DNS setup to be "eventually consistent" and not "instantly consistent". Eventually means hours or days.
When planning for DNS changes, I plan for minimum of 48 hours for the change to take effect. This means that we maintain services on the old DNS entry while the new DNS entry takes effect.
answered Nov 20 at 18:05
John Hanley
12.1k2527
answered Nov 20 at 18:05
John Hanley
12.1k2527
answered Nov 20 at 18:05
John Hanley
12.1k2527
answered Nov 20 at 18:05
John Hanley
12.1k2527
12.1k2527
add a comment |
add a comment |
Thanks for contributing an answer to Stack Overflow!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Some of your past answers have not been well-received, and you're in danger of being blocked from answering.
Please pay close attention to the following guidance:
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53319001%2fgoogle-cloud-dns-changing-record-resource-update-time%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
1
How do you test if changes really went live, and what is "a long period of time"?
– Dusan Bajic
Nov 15 at 14:08
accesing this console.cloud.google.com/net-services/dns/zones?project=*PROJECT_NAME*, a long period of time in this case is 1-2 hours
– Brad
Nov 15 at 14:28
1
I will offer this suggestion based upon decades of DNS experience. Don't treat DNS as your on-demand database. The DNS ecosystem is not designed to support what you are trying to do. Each link in the chain caches DNS entries. You have no control over this process. In your example your TTL is 300 seconds. It will take as least 5 minutes before the next server above yours expires your entries. A lot of caches ignore your TTL and set it to hours or sometimes even days. You need to design your DNS setup to be "eventually consistent" and not "instantly consistent". Eventually means hours or days.
– John Hanley
Nov 19 at 23:22
@JohnHanley Thank you very much for your response, this I have also come to this conclusion. Could you please consider adding this as an answer?
– Brad
Nov 20 at 12:02