DNS resolving to old IP address after one week The 2019 Stack Overflow Developer Survey Results Are In Unicorn Meta Zoo #1: Why another podcast? Announcing the arrival of Valued Associate #679: Cesar Manara Come Celebrate our 10 Year Anniversary!Route53 only for wildcard subdomainSome DNS servers in the world giving wrong IP address for our domain?Sender address rejected: Domain not found - after Route 53 (Amazon AWS) changesSubdomains not resolving in AWS Route 53Windows 2016 DNS Server: not using forwarder when recursively resolving CNAME in delegated zone?Possible ipv6 issue with subdomain on Route53Expose internal route53 DNS over VPN to on-premise ActiveDirectoryHow to delegate DNS for sub-domain to domain with separate hosted zonespointing site to Route 53 for a domain already pointing to Cloudflarenginx: resolver does not refresh after dns update
Identify 80s or 90s comics with ripped creatures (not dwarves)
How to determine omitted units in a publication
different output for groups and groups USERNAME after adding a username to a group
Sub-subscripts in strings cause different spacings than subscripts
What can I do if neighbor is blocking my solar panels intentionally?
Does Parliament hold absolute power in the UK?
Am I ethically obligated to go into work on an off day if the reason is sudden?
Accepted by European university, rejected by all American ones I applied to? Possible reasons?
What was the last x86 CPU that did not have the x87 floating-point unit built in?
Why doesn't a hydraulic lever violate conservation of energy?
What's the point in a preamp?
Can the DM override racial traits?
What do I do when my TA workload is more than expected?
Can we generate random numbers using irrational numbers like π and e?
How to handle characters who are more educated than the author?
Intergalactic human space ship encounters another ship, character gets shunted off beyond known universe, reality starts collapsing
Is every episode of "Where are my Pants?" identical?
Simulating Exploding Dice
how can a perfect fourth interval be considered either consonant or dissonant?
Python - Fishing Simulator
Why don't hard Brexiteers insist on a hard border to prevent illegal immigration after Brexit?
How to support a colleague who finds meetings extremely tiring?
Can I visit the Trinity College (Cambridge) library and see some of their rare books
What other Star Trek series did the main TNG cast show up in?
DNS resolving to old IP address after one week
The 2019 Stack Overflow Developer Survey Results Are In
Unicorn Meta Zoo #1: Why another podcast?
Announcing the arrival of Valued Associate #679: Cesar Manara
Come Celebrate our 10 Year Anniversary!Route53 only for wildcard subdomainSome DNS servers in the world giving wrong IP address for our domain?Sender address rejected: Domain not found - after Route 53 (Amazon AWS) changesSubdomains not resolving in AWS Route 53Windows 2016 DNS Server: not using forwarder when recursively resolving CNAME in delegated zone?Possible ipv6 issue with subdomain on Route53Expose internal route53 DNS over VPN to on-premise ActiveDirectoryHow to delegate DNS for sub-domain to domain with separate hosted zonespointing site to Route 53 for a domain already pointing to Cloudflarenginx: resolver does not refresh after dns update
.everyoneloves__top-leaderboard:empty,.everyoneloves__mid-leaderboard:empty,.everyoneloves__bot-mid-leaderboard:empty height:90px;width:728px;box-sizing:border-box;
Our previous AWS account was hacked last week, on 03/30/2019. We've lost access to it, and had to make a new one.
Our domains are registered at registro.br , and we delegate DNS resolution to Route 53 NS servers. When the incident happened, we created the new account, redeclared a hosted zone on Route 53, and changed the delegation config @ registro.br accordingly.
In spite of this NS server shift, many of our users are still having their DNS's resolved to the IPs of our hacked account every now and then. The wrong behaviour is intermittent - using the same device, users witness their DNS resolution switching between a faulty and a correct one. I suspect this behaviour is caused by some stubborn cache at the route53 level.
Is this expected behaviour? If so, will it eventually go away? When? What could we do on our end to make it go away faster?
EDIT
We've gathered a DNS trace from one our complaining customers: a query for our site's address wound up being delegated to an AWS DNS server that isn't listed as one of our hosted zone's NS servers. The address isn't present on our registro.br configuration either. If I issue a 'nslookup pv.kuadro.com.br ' command on my laptop, I can see that the name gets indeed resolved to the wrong IP.
domain-name-system amazon-route53
New contributor
|
show 1 more comment
Our previous AWS account was hacked last week, on 03/30/2019. We've lost access to it, and had to make a new one.
Our domains are registered at registro.br , and we delegate DNS resolution to Route 53 NS servers. When the incident happened, we created the new account, redeclared a hosted zone on Route 53, and changed the delegation config @ registro.br accordingly.
In spite of this NS server shift, many of our users are still having their DNS's resolved to the IPs of our hacked account every now and then. The wrong behaviour is intermittent - using the same device, users witness their DNS resolution switching between a faulty and a correct one. I suspect this behaviour is caused by some stubborn cache at the route53 level.
Is this expected behaviour? If so, will it eventually go away? When? What could we do on our end to make it go away faster?
EDIT
We've gathered a DNS trace from one our complaining customers: a query for our site's address wound up being delegated to an AWS DNS server that isn't listed as one of our hosted zone's NS servers. The address isn't present on our registro.br configuration either. If I issue a 'nslookup pv.kuadro.com.br ' command on my laptop, I can see that the name gets indeed resolved to the wrong IP.
domain-name-system amazon-route53
New contributor
Hi, please collect more detail, as some ISP might badly cache the DNS/NS info, so it can be a test to do on the client side, on there side to do a nslookup to be sure what NS are listed for your DNS. Make them told you their ISP too
– yagmoth555♦
Apr 8 at 13:14
@yagmoth555 which windows/linux tools would you recommend to generate this client-side DNS resolution log?
– bsam
Apr 8 at 13:19
I would use nslookup -type=soa yourdomain.com, it would list the nameserver for windows, for linux I'm not sure
– yagmoth555♦
Apr 8 at 13:28
I just gathered a DNS trace from one of our complaining customers. Please check the edits I just made.
– bsam
Apr 8 at 14:47
1
there is nice tool in bind-utils -dig
. It is available also for windows. you can run it with+trace
option which would traverse the iteration process so you see where it is asking. More importatnt for this isNS
record (more than SOA as SOA doesn't have relation where to ask ;-)). Try this :dig +trace NS example.com
(replace example.com with your domain. You will see where what is returned values and where is it asking... Good luck!
– Kamil J
Apr 8 at 15:09
|
show 1 more comment
Our previous AWS account was hacked last week, on 03/30/2019. We've lost access to it, and had to make a new one.
Our domains are registered at registro.br , and we delegate DNS resolution to Route 53 NS servers. When the incident happened, we created the new account, redeclared a hosted zone on Route 53, and changed the delegation config @ registro.br accordingly.
In spite of this NS server shift, many of our users are still having their DNS's resolved to the IPs of our hacked account every now and then. The wrong behaviour is intermittent - using the same device, users witness their DNS resolution switching between a faulty and a correct one. I suspect this behaviour is caused by some stubborn cache at the route53 level.
Is this expected behaviour? If so, will it eventually go away? When? What could we do on our end to make it go away faster?
EDIT
We've gathered a DNS trace from one our complaining customers: a query for our site's address wound up being delegated to an AWS DNS server that isn't listed as one of our hosted zone's NS servers. The address isn't present on our registro.br configuration either. If I issue a 'nslookup pv.kuadro.com.br ' command on my laptop, I can see that the name gets indeed resolved to the wrong IP.
domain-name-system amazon-route53
New contributor
Our previous AWS account was hacked last week, on 03/30/2019. We've lost access to it, and had to make a new one.
Our domains are registered at registro.br , and we delegate DNS resolution to Route 53 NS servers. When the incident happened, we created the new account, redeclared a hosted zone on Route 53, and changed the delegation config @ registro.br accordingly.
In spite of this NS server shift, many of our users are still having their DNS's resolved to the IPs of our hacked account every now and then. The wrong behaviour is intermittent - using the same device, users witness their DNS resolution switching between a faulty and a correct one. I suspect this behaviour is caused by some stubborn cache at the route53 level.
Is this expected behaviour? If so, will it eventually go away? When? What could we do on our end to make it go away faster?
EDIT
We've gathered a DNS trace from one our complaining customers: a query for our site's address wound up being delegated to an AWS DNS server that isn't listed as one of our hosted zone's NS servers. The address isn't present on our registro.br configuration either. If I issue a 'nslookup pv.kuadro.com.br ' command on my laptop, I can see that the name gets indeed resolved to the wrong IP.
domain-name-system amazon-route53
domain-name-system amazon-route53
New contributor
New contributor
edited Apr 8 at 14:46
bsam
New contributor
asked Apr 8 at 13:10
bsambsam
92
92
New contributor
New contributor
Hi, please collect more detail, as some ISP might badly cache the DNS/NS info, so it can be a test to do on the client side, on there side to do a nslookup to be sure what NS are listed for your DNS. Make them told you their ISP too
– yagmoth555♦
Apr 8 at 13:14
@yagmoth555 which windows/linux tools would you recommend to generate this client-side DNS resolution log?
– bsam
Apr 8 at 13:19
I would use nslookup -type=soa yourdomain.com, it would list the nameserver for windows, for linux I'm not sure
– yagmoth555♦
Apr 8 at 13:28
I just gathered a DNS trace from one of our complaining customers. Please check the edits I just made.
– bsam
Apr 8 at 14:47
1
there is nice tool in bind-utils -dig
. It is available also for windows. you can run it with+trace
option which would traverse the iteration process so you see where it is asking. More importatnt for this isNS
record (more than SOA as SOA doesn't have relation where to ask ;-)). Try this :dig +trace NS example.com
(replace example.com with your domain. You will see where what is returned values and where is it asking... Good luck!
– Kamil J
Apr 8 at 15:09
|
show 1 more comment
Hi, please collect more detail, as some ISP might badly cache the DNS/NS info, so it can be a test to do on the client side, on there side to do a nslookup to be sure what NS are listed for your DNS. Make them told you their ISP too
– yagmoth555♦
Apr 8 at 13:14
@yagmoth555 which windows/linux tools would you recommend to generate this client-side DNS resolution log?
– bsam
Apr 8 at 13:19
I would use nslookup -type=soa yourdomain.com, it would list the nameserver for windows, for linux I'm not sure
– yagmoth555♦
Apr 8 at 13:28
I just gathered a DNS trace from one of our complaining customers. Please check the edits I just made.
– bsam
Apr 8 at 14:47
1
there is nice tool in bind-utils -dig
. It is available also for windows. you can run it with+trace
option which would traverse the iteration process so you see where it is asking. More importatnt for this isNS
record (more than SOA as SOA doesn't have relation where to ask ;-)). Try this :dig +trace NS example.com
(replace example.com with your domain. You will see where what is returned values and where is it asking... Good luck!
– Kamil J
Apr 8 at 15:09
Hi, please collect more detail, as some ISP might badly cache the DNS/NS info, so it can be a test to do on the client side, on there side to do a nslookup to be sure what NS are listed for your DNS. Make them told you their ISP too
– yagmoth555♦
Apr 8 at 13:14
Hi, please collect more detail, as some ISP might badly cache the DNS/NS info, so it can be a test to do on the client side, on there side to do a nslookup to be sure what NS are listed for your DNS. Make them told you their ISP too
– yagmoth555♦
Apr 8 at 13:14
@yagmoth555 which windows/linux tools would you recommend to generate this client-side DNS resolution log?
– bsam
Apr 8 at 13:19
@yagmoth555 which windows/linux tools would you recommend to generate this client-side DNS resolution log?
– bsam
Apr 8 at 13:19
I would use nslookup -type=soa yourdomain.com, it would list the nameserver for windows, for linux I'm not sure
– yagmoth555♦
Apr 8 at 13:28
I would use nslookup -type=soa yourdomain.com, it would list the nameserver for windows, for linux I'm not sure
– yagmoth555♦
Apr 8 at 13:28
I just gathered a DNS trace from one of our complaining customers. Please check the edits I just made.
– bsam
Apr 8 at 14:47
I just gathered a DNS trace from one of our complaining customers. Please check the edits I just made.
– bsam
Apr 8 at 14:47
1
1
there is nice tool in bind-utils -
dig
. It is available also for windows. you can run it with +trace
option which would traverse the iteration process so you see where it is asking. More importatnt for this is NS
record (more than SOA as SOA doesn't have relation where to ask ;-)). Try this :dig +trace NS example.com
(replace example.com with your domain. You will see where what is returned values and where is it asking... Good luck!– Kamil J
Apr 8 at 15:09
there is nice tool in bind-utils -
dig
. It is available also for windows. you can run it with +trace
option which would traverse the iteration process so you see where it is asking. More importatnt for this is NS
record (more than SOA as SOA doesn't have relation where to ask ;-)). Try this :dig +trace NS example.com
(replace example.com with your domain. You will see where what is returned values and where is it asking... Good luck!– Kamil J
Apr 8 at 15:09
|
show 1 more comment
1 Answer
1
active
oldest
votes
It can take up 48 hours for the DNS to propagate correctly globally.
I seen in a nslookup soa that the TTL is 1 day, as such the DNS server could cache the value for a day, thus a 1 day delay can be seen there.
Contact registro.br if the change is over 48 hours done in the past, as it would mean the update you did, to change NameServer, didn't worked, as on my side I still see the AWS server in the NS'S field. It could be a technical problem on their side, like the zone is not ok, but it's in their hands at this moment.
"It can take up 48 hours for the DNS to propagate correctly globally. " This is far more complicated than that. They are no hard rule, and it is not really a propagation (even if everyone says so) because the updates do not flow from top to bottom, it is the end resolvers that will after some time redo the query and update their local cache.
– Patrick Mevzek
yesterday
add a comment |
Your Answer
StackExchange.ready(function()
var channelOptions =
tags: "".split(" "),
id: "2"
;
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function()
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled)
StackExchange.using("snippets", function()
createEditor();
);
else
createEditor();
);
function createEditor()
StackExchange.prepareEditor(
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: true,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: 10,
bindNavPrevention: true,
postfix: "",
imageUploader:
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
,
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
);
);
bsam is a new contributor. Be nice, and check out our Code of Conduct.
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%2fserverfault.com%2fquestions%2f962026%2fdns-resolving-to-old-ip-address-after-one-week%23new-answer', 'question_page');
);
Post as a guest
Required, but never shown
1 Answer
1
active
oldest
votes
1 Answer
1
active
oldest
votes
active
oldest
votes
active
oldest
votes
It can take up 48 hours for the DNS to propagate correctly globally.
I seen in a nslookup soa that the TTL is 1 day, as such the DNS server could cache the value for a day, thus a 1 day delay can be seen there.
Contact registro.br if the change is over 48 hours done in the past, as it would mean the update you did, to change NameServer, didn't worked, as on my side I still see the AWS server in the NS'S field. It could be a technical problem on their side, like the zone is not ok, but it's in their hands at this moment.
"It can take up 48 hours for the DNS to propagate correctly globally. " This is far more complicated than that. They are no hard rule, and it is not really a propagation (even if everyone says so) because the updates do not flow from top to bottom, it is the end resolvers that will after some time redo the query and update their local cache.
– Patrick Mevzek
yesterday
add a comment |
It can take up 48 hours for the DNS to propagate correctly globally.
I seen in a nslookup soa that the TTL is 1 day, as such the DNS server could cache the value for a day, thus a 1 day delay can be seen there.
Contact registro.br if the change is over 48 hours done in the past, as it would mean the update you did, to change NameServer, didn't worked, as on my side I still see the AWS server in the NS'S field. It could be a technical problem on their side, like the zone is not ok, but it's in their hands at this moment.
"It can take up 48 hours for the DNS to propagate correctly globally. " This is far more complicated than that. They are no hard rule, and it is not really a propagation (even if everyone says so) because the updates do not flow from top to bottom, it is the end resolvers that will after some time redo the query and update their local cache.
– Patrick Mevzek
yesterday
add a comment |
It can take up 48 hours for the DNS to propagate correctly globally.
I seen in a nslookup soa that the TTL is 1 day, as such the DNS server could cache the value for a day, thus a 1 day delay can be seen there.
Contact registro.br if the change is over 48 hours done in the past, as it would mean the update you did, to change NameServer, didn't worked, as on my side I still see the AWS server in the NS'S field. It could be a technical problem on their side, like the zone is not ok, but it's in their hands at this moment.
It can take up 48 hours for the DNS to propagate correctly globally.
I seen in a nslookup soa that the TTL is 1 day, as such the DNS server could cache the value for a day, thus a 1 day delay can be seen there.
Contact registro.br if the change is over 48 hours done in the past, as it would mean the update you did, to change NameServer, didn't worked, as on my side I still see the AWS server in the NS'S field. It could be a technical problem on their side, like the zone is not ok, but it's in their hands at this moment.
answered Apr 8 at 16:28
yagmoth555♦yagmoth555
12.4k31842
12.4k31842
"It can take up 48 hours for the DNS to propagate correctly globally. " This is far more complicated than that. They are no hard rule, and it is not really a propagation (even if everyone says so) because the updates do not flow from top to bottom, it is the end resolvers that will after some time redo the query and update their local cache.
– Patrick Mevzek
yesterday
add a comment |
"It can take up 48 hours for the DNS to propagate correctly globally. " This is far more complicated than that. They are no hard rule, and it is not really a propagation (even if everyone says so) because the updates do not flow from top to bottom, it is the end resolvers that will after some time redo the query and update their local cache.
– Patrick Mevzek
yesterday
"It can take up 48 hours for the DNS to propagate correctly globally. " This is far more complicated than that. They are no hard rule, and it is not really a propagation (even if everyone says so) because the updates do not flow from top to bottom, it is the end resolvers that will after some time redo the query and update their local cache.
– Patrick Mevzek
yesterday
"It can take up 48 hours for the DNS to propagate correctly globally. " This is far more complicated than that. They are no hard rule, and it is not really a propagation (even if everyone says so) because the updates do not flow from top to bottom, it is the end resolvers that will after some time redo the query and update their local cache.
– Patrick Mevzek
yesterday
add a comment |
bsam is a new contributor. Be nice, and check out our Code of Conduct.
bsam is a new contributor. Be nice, and check out our Code of Conduct.
bsam is a new contributor. Be nice, and check out our Code of Conduct.
bsam is a new contributor. Be nice, and check out our Code of Conduct.
Thanks for contributing an answer to Server Fault!
- 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%2fserverfault.com%2fquestions%2f962026%2fdns-resolving-to-old-ip-address-after-one-week%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
Hi, please collect more detail, as some ISP might badly cache the DNS/NS info, so it can be a test to do on the client side, on there side to do a nslookup to be sure what NS are listed for your DNS. Make them told you their ISP too
– yagmoth555♦
Apr 8 at 13:14
@yagmoth555 which windows/linux tools would you recommend to generate this client-side DNS resolution log?
– bsam
Apr 8 at 13:19
I would use nslookup -type=soa yourdomain.com, it would list the nameserver for windows, for linux I'm not sure
– yagmoth555♦
Apr 8 at 13:28
I just gathered a DNS trace from one of our complaining customers. Please check the edits I just made.
– bsam
Apr 8 at 14:47
1
there is nice tool in bind-utils -
dig
. It is available also for windows. you can run it with+trace
option which would traverse the iteration process so you see where it is asking. More importatnt for this isNS
record (more than SOA as SOA doesn't have relation where to ask ;-)). Try this :dig +trace NS example.com
(replace example.com with your domain. You will see where what is returned values and where is it asking... Good luck!– Kamil J
Apr 8 at 15:09