Skip to content

Vultr support actually taught me DNS from scratch

Reviews by dave39 19 replies 1.5K views
#11
dave39 said:
I had moved the domain to a new registrar and never updated the glue records at the parent

Ah that makes sense. I did something similar last month with a .co.uk transfer. Took me two days to figure out the Nominet side needed the glue update separately. Is that the same for .com with Verisign or do registrars handle it automatically now?

9 #12
nate_pad said:
Do registrars handle it automatically now

No no no this is still manual at registry level for many tlds!! Some registrars have nice checkbox "update glue" but behind scenes is same call to registry. Verisign, Nominet, DENIC all want explicit glue if your ns is inside the zone itself. Common mistake. I have seen people wait 48 hours for propagation when glue was wrong whole time.

swimming upstream since 2019 🐟
#13
ana_mad said:
I have seen people wait 48 hours for propagation when glue was wrong whole time

This is why I run my own monitoring. If I change DNS I watch the TTLs and query from six locations. "Propagation" is usually just "your old record is cached and you didn't check." Vultr's Madrid DC is handy for EU-side validation.

436 days. reboot is surrender.
#14
uma said:
Vultr's Madrid DC is handy for EU-side validation

Amsterdam is closer to me in Utrecht but Madrid's fine for redundancy. What I actually want to know: has anyone here pushed Vultr's block storage hard enough to hit the IOPS wall? Their NVMe local is fine but the networked stuff feels oversold in Frankfurt. Not a support issue, just curious if my experience matches.

virsh list --all | wc -l: 47
#15
kate3 said:
The networked stuff feels oversold in Frankfurt

I run a small CI farm on Ampere in Seoul and the block storage there is consistent enough. Not amazing, not terrible. The local NVMe is where the ARM boxes shine anyway. I wouldn't put a database on networked storage regardless of provider.

one small ping for man...
#16
armstrongvds said:
14 minutes sounds fast but was it actually useful at minute 14

Going back to this—my last ticket with another provider took 6 hours for "we are investigating" and then 2 days for "please reboot." 14 minutes with actual troubleshooting steps is better than most of the industry. I don't care about speed if it's copy-paste but Ana's first response had dig commands in it. That's useful.

#17
dave39 said:
I thought Vultr had borked their resolvers again

This is why I run unbound locally and don't trust provider resolvers for anything. Vultr's are fine for bootstrapping but I point everything at my own recursive setup. Less metadata leakage that way. Not that I think Vultr sells it, but principle is principle.

Neuland. Aber schnell.
8 #18
Fritz48 said:
Teaching and fixing together is rare. Ana earned that role.

This.

Also Dave your sublist numbering was broken in the original post

  • Glue records
  • Delegation chain
  • Authoritative vs recursive

Fixed that for you. You're welcome.

#19
liam_funky said:
Your sublist numbering was broken

I was on mobile and the comma key was getting more action than the period key ok leave me alone

Also yeah I run unbound now too after Ana explained the difference. Baby steps.

#20

Salam kenal all. This thread made me check my own glue records. Found two domains with stale data. Fixed before customer complaint, so thank you Ana and dave39 for the reminder. Vultr support has been good to me in Singapore DC also, though never this detailed. Usually "check your firewall" which is fair, I forget ufw exists.

traffic worse than my packet loss

Post a reply

You need an account to reply. Log in or register to join the conversation.

Post reply Preview Save draft