Question 1

Domain expires tomorrow and nobody saw the email

Accepted Answer

1. Log into the registrar and renew immediately if still possible
2. If it's in redemption, request restore, often 80 to 200 euros extra
3. Turn on auto-renew plus a backup payment method
4. Add the main email to a shared inbox so reminders don't get missed

When to bring us in: 
If the domain already dropped and got auctioned, talk to your IT partner about negotiation.

Question 2

Unsure whether to enable auto-renew

Accepted Answer

1. List active domains versus parked ones
2. Enable auto-renew for live brands plus typo variants
3. Disable for domains you intend to drop in 3 months
4. Schedule a biannual portfolio review

When to bring us in: 
Past 50 domains, export to CSV and delegate review to finance.

Question 3

New registrar asks for auth code, can't find it

Accepted Answer

1. Log into current registrar, look for 'transfer code', 'auth code' or 'EPP'
2. Some (TransIP, Hostnet) show it on the domain detail page
3. Paste it into the new registrar's transfer form
4. Check email for the confirmation link, click within 5 days

When to bring us in: 
If the code isn't visible, contact current registrar support, you have the right to it.

Question 4

Transfer rejected with 'domain locked' error

Accepted Answer

1. Open domain detail at current registrar
2. Find 'transfer lock' or 'registrar lock' and disable
3. Wait a few minutes, WHOIS status should show 'unlocked'
4. Retry transfer with the auth code

When to bring us in: 
For .nl domains it's called 'opt-out lock', ask the registrar to check SIDN status.

Question 5

Transfer email arrived, didn't click in time, now stuck

Accepted Answer

1. Check WHOIS status, 'pendingTransfer' means still in flight
2. gTLDs often auto-approve after 5 days if the old registrar doesn't refuse
3. For .nl it's the inverse, transfer fails without confirmation
4. Restart the transfer if it was rejected

When to bring us in: 
Ask the new registrar for exact status, sometimes there's an open ticket.

Question 6

Domain shows 'redemption period', can we get it back?

Accepted Answer

1. Ask current registrar for a redemption restore
2. Expect 80 to 250 euros plus normal renewal
3. DNS and mail come back after restore, sometimes a few hours delay
4. Enable auto-renew after restore

When to bring us in: 
For .nl the phase is called 'quarantaine', SIDN handles it via your registrar.

Question 7

A domain we want drops tomorrow, can we grab it?

Accepted Answer

1. Reserve via a drop-catch service (SnapNames, DropCatch.com, for .nl SIDN auctions)
2. Set a budget, multiple catchers triggers an auction
3. Sign up at multiple services to raise odds
4. Keep your registrar account ready to receive the catch

When to bring us in: 
High-value domains have strong competition. Plan a ceiling bid.

Question 8

SIDN is auctioning a .nl domain we want

Accepted Answer

1. Create an account at SIDN Auctions or via a participating registrar
2. Set max bid, auction closes after 7 days unless sniped late
3. On win, the domain lands at your registrar automatically
4. Pre-plan DNS so you can deploy right after transfer

When to bring us in: 
Above 5K budgets, use a domain broker.

Question 9

Should we grab .be or .de next to .nl?

Accepted Answer

1. Check residency: .de wants a German admin-c, .fr an EU address
2. Budget: .nl around 8 EUR, .be around 15, .de around 12
3. Plan at least a redirect so the ccTLD isn't empty
4. Register typo variants only if budget allows

When to bring us in: 
For market entry, get legal advice on trademark protection.

Question 10

Domain I want suddenly costs 800 euros, not 8

Accepted Answer

1. Read fine print, not just first-year price
2. Premium pricing often applies to renewals too
3. Compare alternative TLDs or a slight name variant
4. Sometimes Sedo aftermarket beats registrar premium

When to bring us in: 
If unsure about lifetime cost, ask for written confirmation.

Question 11

Someone registered my brand with a Cyrillic 'a'

Accepted Answer

1. Scan your brand with dnstwist or urlcrazy
2. Pre-register the most obvious look-alikes
3. Add homograph variants to mail filter blocklists
4. Set a brand-monitoring alert

When to bring us in: 
On active phishing use, file with the registrar plus police.

Question 12

Not sure what a good TTL is for our records

Accepted Answer

1. Standard A/AAAA, 3600 seconds (1 hour) is comfortable
2. MX and TXT often 3600 to 7200, rare changes
3. For migration, drop to 300 a day before
4. After migration, raise back to 3600 or more

When to bring us in: 
For multi-CDN or failover, see the dedicated DNS-failover entry.

Question 13

Change made, not everyone sees it yet

Accepted Answer

1. Verify change at the authoritative NS with dig +short @ns1.provider.nl name
2. Compare with public resolvers (1.1.1.1, 8.8.8.8) after minutes
3. Use dnschecker.org for worldwide sampling
4. Allow 1x TTL for broad propagation, longer for ISP resolvers

When to bring us in: 
Past 24h drift, check if an old NS set is still active somewhere.

Question 14

Want to move DNS management to Cloudflare, change NS records

Accepted Answer

1. First rebuild the full zone at the new host (all records 1-to-1)
2. Verify the zone is live, dig @ns1.cloudflare.com
3. Then change NS records at the registrar
4. Keep the old DNS host active as a safety net for a week

When to bring us in: 
Missing a record means that service breaks, hence 1-to-1 first.

Question 15

Secondary DNS server isn't picking up changes

Accepted Answer

1. Check current SOA with dig SOA yourdomain.nl
2. Format is usually YYYYMMDDNN, auto-incremented by most hosts
3. With a manual zonefile, bump serial yourself on every change
4. Force NOTIFY or trigger zone transfer if secondary stays stale

When to bring us in: 
On hidden-master setups, master xfr logs reveal the cause.

Question 16

Moving DNS to a new host, how do I migrate 80 records?

Accepted Answer

1. Ask the old host for an export, often a 'zonefile export' button or API
2. Cloudflare and Route53 both import BIND directly
3. Verify per record type that everything moved
4. Test on the new NS with dig before NS cutover

When to bring us in: 
No export button, ask support for the zonefile or dump records via dig AXFR.

Question 17

One server in Amsterdam, want failover to Frankfurt

Accepted Answer

1. Lower TTL to 60-120 on the A record being failed over
2. Configure healthcheck (HTTP, TCP) at a DNS host with failover support (Route53, NS1, Cloudflare paid)
3. Set primary plus secondary IP with failover policy
4. Test by deliberately killing primary, log the switchover time

When to bring us in: 
For sub-second failover, use anycast plus a load balancer, not DNS.

Question 18

US visitors have high latency to our NL server

Accepted Answer

1. Place copies of the service in multiple regions
2. Configure geo or latency routing (Route53, NS1, Cloudflare Load Balancer)
3. Healthcheck each endpoint so dead regions drop out
4. Verify via VPN or remote tests

When to bring us in: 
For static content, a CDN is simpler than rolling GeoDNS.

Question 19

Want 80 percent traffic to new server, 20 to old

Accepted Answer

1. Two A records with different weights (Route53, NS1, Cloudflare)
2. Low TTL (60-120) so shifts land quickly
3. Monitor errors per backend, roll back if needed
4. On green light step to 100 percent new

When to bring us in: 
For stickiness use a load balancer with session affinity, not DNS.

Question 20

What's the difference between A and AAAA, do I need both?

Accepted Answer

1. Add AAAA alongside A if your hosting does IPv6
2. Test reachability via test-ipv6.com
3. Many CDNs include AAAA for free, just enable
4. No IPv6 on the server, A only is fine but plan an upgrade

When to bring us in: 
Some cloud providers need extra config for dual-stack, check vendor docs.

Question 21

Want a CNAME on the root domain, getting an error

Accepted Answer

1. On www-subdomain CNAME is fine (www CNAME provider.host.com)
2. At apex use an A record, or ALIAS/ANAME if your DNS host supports it
3. Cloudflare does 'CNAME flattening' at apex automatically
4. Vercel publishes a static IP for apex A records (76.76.21.21). Netlify does not publish a static A record; it uses an ALIAS or ANAME-style record via Netlify DNS.

When to bring us in: 
With dynamic backend IPs, host DNS at Cloudflare for flattening.

Question 22

DNS host mentions 'ALIAS' or 'ANAME', what's that?

Accepted Answer

1. DNS host resolves the target internally and serves the IP as an A record
2. Only works where supported (DNSimple, Route53, easyDNS, Cloudflare via flattening)
3. Use for apex bindings to PaaS (Vercel, Netlify, Heroku)
4. TTL usually lower because target can change

When to bring us in: 
Not all hosts support it, ask support or move DNS.

Question 23

Cert request fails with 'CAA record disallows issuance'

Accepted Answer

1. Check current CAA with dig CAA yourdomain.nl
2. If your CA isn't listed, add it (CAA 0 issue 'letsencrypt.org')
3. For wildcards use a separate issuewild
4. Wait TTL and retry the cert request

When to bring us in: 
If CAA was unexpected, possibly legacy from a former vendor, audit all records.

Question 24

Domain never sends mail, want to signal it accepts none

Accepted Answer

1. Add: MX 0 . (literal dot)
2. Add SPF v=spf1 -all and DMARC p=reject
3. Together they hinder spoofing of the domain
4. Test with a probe that must hard-bounce

When to bring us in: 
If the domain still occasionally needs to send, skip null-MX and use normal config.

Question 25

TXT record too long, host truncates or rejects

Accepted Answer

1. Split TXT into two quoted strings: 'first part' 'second part'
2. Resolvers concatenate automatically
3. Some hosts want one blob without quotes, test after save
4. Verify with dig TXT yourdomain.nl

When to bring us in: 
If host truly limits, split the target (e.g. separate subdomain for DKIM).

Question 26

Microsoft Teams or XMPP complains about missing SRV records

Accepted Answer

1. For Teams hybrid, add SRV for _sip._tls and _sipfederationtls._tcp
2. For XMPP, _xmpp-client._tcp and _xmpp-server._tcp
3. Format: priority weight port target, target ends with a dot
4. Test with dig SRV _service._proto.yourdomain.nl

When to bring us in: 
M365 setup wizard prints exact values, paste 1-to-1.

Question 27

Torn between shared hosting, VPS or cloud

Accepted Answer

1. Shared (Antagonist, Hostnet, Mijndomein), simple CMS, low traffic, low ops
2. VPS (TransIP, Hetzner), full root, custom stack, you run the OS
3. Cloud (AWS, Vercel, Hetzner Cloud), scalable, pay-per-use, needs cloud skills
4. Choose by team skill, not just price

When to bring us in: 
Unsure about VPS, start shared and migrate when you hit a wall.

Question 28

Client demands EU hosting in writing

Accepted Answer

1. Ask the provider to confirm data-center location per service in writing
2. Check the sub-processor list for backup, monitoring, CDN
3. AWS, Azure, GCP have EU regions, pick eu-central or eu-west explicitly
4. Cloudflare caches at edge worldwide, plan data path separately

When to bring us in: 
For health or government, request DPA and sub-processor list during tender.

Question 29

Site appears under DDoS, slow or unreachable

Accepted Answer

1. Put the site behind Cloudflare via NS change or orange-cloud
2. Toggle 'Under Attack Mode' during the active attack
3. Hide origin IP, allow only Cloudflare IP ranges in firewall
4. Keep logs for post-mortem

When to bring us in: 
On targeted L7 attacks, upgrade to Cloudflare Pro or Magic Transit.

Question 30

Do we need a WAF?

Accepted Answer

1. For WordPress or standard CMS, enable an OWASP ruleset via Cloudflare or provider
2. Whitelist admin IPs so you don't lock yourself out
3. Monitor false positives the first week
4. Plan biannual rule review

When to bring us in: 
For custom apps with APIs, have the dev team validate WAF rules.

Question 31

Cloudflare record, orange cloud on or grey?

Accepted Answer

1. Websites: orange, you get CDN, WAF, SSL for free
2. Mail servers: grey, otherwise SMTP routing breaks
3. SSH or non-HTTP services: grey
4. Hide origin IP behind orange for extra DDoS protection

When to bring us in: 
Unexpected IP in dig output is a Cloudflare proxy IP, that's intentional.

Question 32

Images load slow on mobile

Accepted Answer

1. Cloudflare Polish, Vercel Image, BunnyCDN Optimizer or imgix
2. Serve WebP and AVIF to supporting browsers
3. Set resolution breakpoints for mobile, tablet, desktop
4. Verify Lighthouse before and after

When to bring us in: 
For heavy image libraries (e-commerce), consider DAM integration.

Question 33

Pushed update, old version still cached at the edge

Accepted Answer

1. Purge selectively per URL or extension when possible
2. For major releases, purge-all with timing in mind
3. Bake cache-busting into the build (hashed filenames)
4. Tune cache headers per asset (static long, HTML short)

When to bring us in: 
On Vercel, deploy auto-triggers a purge, no manual step needed.

Question 34

Move mail from Strato to Microsoft 365

Accepted Answer

1. Migrate all existing mailboxes first
2. Lower MX TTL to 300 a day before
3. Change MX and autodiscover records at cutover
4. Keep the old account active 30 days for stragglers

When to bring us in: 
For large mailboxes (>50GB), use the provider's migration tool, not IMAP sync.

Question 35

Outlook or mail client doesn't auto-find settings

Accepted Answer

1. M365: autodiscover.yourdomain.nl CNAME to autodiscover.outlook.com
2. Google Workspace: SRV records for _autodiscover._tcp
3. TTL 3600 is fine
4. Test with Outlook 'autoconfig' or the mail client wizard

When to bring us in: 
For hybrid M365 + on-prem Exchange, autodiscover gets complex, ask M365 admin.

Question 36

About to migrate, worried about missing something

Accepted Answer

1. Export the current zone (BIND or CSV)
2. List all subdomains and services (mail, www, api, vpn, status)
3. Lower TTLs to 300 24-48h before
4. Plan migration off-hours with a rollback path

When to bring us in: 
Records nobody recognizes: don't drop, find the owner first.

Question 37

Migration just done, how do I know everything works?

Accepted Answer

1. Run uptime checks per subdomain (UptimeRobot, Pingdom)
2. Send test mail to internal and external accounts
3. Check mail deliverability via mail-tester.com
4. Keep the old provider live a week as escape route

When to bring us in: 
On unexplained bounces, compare logs from both providers.

Question 38

WHOIS shows my home address and the inbox is full of spam

Accepted Answer

1. Enable 'WHOIS privacy' or 'domain privacy' at the registrar
2. For .nl, privacy is automatic for natural persons via SIDN
3. For gTLDs, check enablement per registrar
4. Update the admin address even if it's hidden

When to bring us in: 
In legal disputes WHOIS data can be requested via formal channels.

Question 39

Let's Encrypt cert expires every 90 days, how to automate?

Accepted Answer

1. Use certbot, acme.sh or the hosting panel's built-in renewer
2. Cron job tries renewal every 30 days
3. Test renewal with --dry-run before trusting it
4. Monitor cert expiry (UptimeRobot, certifytheweb)

When to bring us in: 
On rate-limit errors, wait or use the staging environment to test.

Question 40

Need a wildcard cert (*.yourdomain.nl), HTTP challenge fails

Accepted Answer

1. Generate an API token at Cloudflare, Route53 or your DNS host
2. Configure certbot or acme.sh with the right DNS plugin
3. First test --staging to validate the DNS flow
4. Plan auto-renewal, manual doesn't scale

When to bring us in: 
DNS host without API: fall back to single cert per subdomain.

Question 41

Domain costs creeping up annually, want to clean up

Accepted Answer

1. Export list with expiry, cost per year, purpose
2. Tag per domain: active, redirect, parked, drop
3. Disable auto-renew on the drop category
4. Annual review with finance and marketing

When to bring us in: 
For trademark domains, consult legal before dropping.

Question 42

.com or .nl for a new NL brand?

Accepted Answer

1. Primary .nl, redirect .com and typos to it
2. International ambition: primary .com, secondary .nl
3. Check availability on both before committing
4. Plan double cost plus mail config on both

When to bring us in: 
If a third party already holds variants, get legal advice on brand conflict.

Question 43

Strange transfer email or NS change notice

Accepted Answer

1. Call registrar support immediately, report unauthorized change
2. Reset the registrar password and enable 2FA
3. Request transfer-lock plus registry-lock
4. Audit all DNS records for foreign additions

When to bring us in: 
On a successful hijack, file with ICANN or SIDN plus police.

Question 44

Registrar account only has a password, no 2FA

Accepted Answer

1. Enable TOTP (authenticator app), avoid SMS
2. Use a shared 1Password vault for team access
3. Add registrar-lock plus 2FA on all primary accounts
4. Quarterly review of authorized users

When to bring us in: 
Lost 2FA device: start registrar recovery immediately, it can take days.

Question 45

Site offline, NS records changed without me doing it

Accepted Answer

1. Log into the registrar, restore original NS records
2. Pull the audit log of who changed what when
3. Reset password and 2FA
4. Enable registrar-lock to prevent recurrence

When to bring us in: 
If no log or unknown cause, request registry-lock via SIDN or ICANN.

Question 46

DNS records do not work as expected, dig shows two different SOAs

Accepted Answer

1. Run dig SOA your-domain.com @1.1.1.1 and dig SOA your-domain.com @8.8.8.8. Different serial numbers or name servers back: a mismatch.
2. Check WHOIS for the public NS records of your domain. Those are the servers the whole internet listens to.
3. Compare with where you set records. Your A record at the registrar but NS at Cloudflare? Nobody listens to the registrar records, only to Cloudflare.
4. Pick one DNS platform and put all records (A, MX, TXT, CAA, etc.) there. At the registrar leave only the NS delegation.
5. Wait the TTL before migrating between platforms, or first lower TTL to 300 seconds and wait a day before the switch. Otherwise you see a mix of old and new across resolvers.

When to bring us in: 
Mismatch in production with mail impact (MX going to the wrong server, mail bouncing): during migration a second pair of eyes saves an hour of panic per hour of solo effort.

Question 47

DNSSEC key rollover is scheduled, how do I do that without disruption?

Accepted Answer

1. Lower DS and DNSKEY TTLs first (often 1 hour). Wait twice that TTL before rolling, otherwise old DS sits in cache while a new key is active.
2. Two safe paths: 'Double Signature' (two KSKs active at once, zone signed twice) or 'Pre-publish' (publish new DNSKEY before using it). Most managed DNS providers (Cloudflare, Route 53) handle this automatically; on-premise BIND does not.
3. On managed DNS: trigger the rollover in the UI or API and wait. On BIND/PowerDNS: follow the official rollover procedure step by step, do not skip wait times.
4. Update the DS record at the registrar once the new key DS is ready. For .nl domains this goes via your registrar to SIDN; some registrars accept CDS records so the zone publishes it itself.
5. Verify with DNSViz (dnsviz.net) or Verisign DNSSEC Debugger: green = chain valid, red/yellow = mismatch somewhere. Do not go live until it is fully green.

When to bring us in: 
Chain-of-trust errors in production (validating resolvers see your domain as BOGUS, non-existent): file with your DNS provider and/or registrar in parallel with a temporary DNSSEC disable. We run this kind of rollover with a second person on the line for double checks.

Question 48

Let's Encrypt returns 'too many certificates' on a live domain setup

Accepted Answer

1. Stop the retry loops before fixing anything. A script trying every 5 minutes burns the rate limit in an hour and parks you for a week.
2. Confirm you are not duplicating cert requests: multiple subdomains via separate certs instead of one SAN cert is a fast path to the limit. Bundle where you can.
3. Use the LE staging endpoint (acme-staging-v02.api.letsencrypt.org) while testing setup. No rate limit, and you know when the real request will succeed.
4. If the rate limit is already hit and you need a cert: a 'duplicate certificate' exception exists, and you can temporarily fail over to another CA (ZeroSSL does ACME, Buypass too). Not a permanent choice, an escape route.
5. Going forward: use a renew tool with exponential backoff on failure (certbot, acme.sh, Caddy). They will not retry endlessly back-to-back themselves.

When to bring us in: 
Production site without a valid cert and the rate limit full for a week: do not improvise with self-signed or a random CA. Call us; together we pick the cleanest temporary fix and restore the automation afterwards.

Question 49

Self-host Uptime Kuma or take Better Stack?

Accepted Answer

1. Count the checks you actually need (sites, API endpoints, mail servers)
2. Pick Kuma on a 5 EUR VPS if you are fine with Docker and skip SMS
3. Pick Better Stack or similar if you want SMS alerts and status page without ops
4. For self-host, count backups, updates, and TLS certs in real cost

When to bring us in: 
If unsure, request quotes for the first 12 months on both options.

Question 50

Do we need a public status page?

Accepted Answer

1. Split: do you have external customers with SLA expectations?
2. External customers: public status page deflects support tickets during outages
3. Internal tools: a chat channel with automatic posts is enough
4. Draft a short template for incident updates so communication stays consistent

When to bring us in: 
For customers under formal SLA, wire the status page to your incident-tracking system.

Question 51

Apex domain needs to point at a hostname (e.g. Vercel or Netlify), but CNAME is not allowed there

Accepted Answer

1. First check whether your DNS provider supports flattening or ALIAS/ANAME. TransIP and Versio are limited, Cloudflare and Vercel handle it natively.
2. Move the DNS zone to a provider that does support it if needed, that saves later headaches when IP addresses shift.
3. Configure an ALIAS or flattened CNAME at the apex pointing to the target hostname, not to a fixed IP, otherwise the setup breaks the moment the platform changes IPs.
4. Verify with dig vectel.nl A and dig vectel.nl AAAA that you get address records back, not a CNAME chain.
5. Set TTL to 300 seconds during the first 48 hours after the change so you can roll back quickly.

When to bring us in: 
If you are unsure whether your apex points safely to an edge platform without downtime, we can review the DNS zone and plan the migration.

Question 52

Only A records, no AAAA, want to support IPv6 visitors as well

Accepted Answer

1. First check whether your server or edge has a working IPv6 address (curl -6 https://yoursite or dig AAAA at your hosting provider).
2. Add AAAA records alongside existing A records, same name, different record type. No replacement.
3. Test from an IPv6-only client or via test-ipv6.com whether the site is reachable and TLS is correct.
4. Check MX targets too, mail servers often pick up forgotten AAAAs while reverse-DNS does not match, leading to delivery issues.
5. Watch monitoring closely for the first week, issues often only show up at specific ISPs.

When to bring us in: 
If you want to roll out AAAA broadly including mail and monitoring without surprises, we can stage the rollout.

Question 53

Own mail server, mail lands in spam, likely missing or wrong PTR

Accepted Answer

1. Check the current PTR with dig -x 1.2.3.4 or host 1.2.3.4. Empty output or a generic ISP name (e.g. cust-1-2-3-4.kpn.net) is a red flag.
2. Request a PTR from hosting or ISP that exactly matches your mail server's A record, so mail.vectel.nl must resolve to 1.2.3.4 and 1.2.3.4 must resolve back to mail.vectel.nl.
3. Make sure the mail server's HELO/EHLO banner uses the same hostname as the PTR, otherwise spam filters still trigger.
4. Verify with mxtoolbox.com or mail-tester.com that PTR, SPF, DKIM and DMARC are all green.
5. With IPv6 mail servers a PTR is required too, do not forget it, or Google rejects mail sent over AAAA.

When to bring us in: 
If hosting refuses to set a PTR or you are on a shared IP, switching to a sending service (Postmark, Mailgun) is usually better than continuing to fight it.

Question 54

Site feels slow on first hit, want to know if DNS resolution is part of the blame

Accepted Answer

1. Measure from different locations with dig +stats vectel.nl @1.1.1.1 and @8.8.8.8 and @9.9.9.9, look at the Query time.
2. Compare with dig vectel.nl @ns1.yourcurrentdns.nl directly against the authoritative server, that separates resolver latency from authoritative latency.
3. For a user view, use DNSPerf, dnscheck.tools or synthetic monitors at Better Stack/Pingdom with probes in NL, DE, US.
4. Under 30 ms from NL is healthy, over 100 ms from an EU resolver is a signal to migrate or add an Anycast host.
5. Remember resolver cache distorts the measurement, use dig +trace or unique subdomains to bypass it.

When to bring us in: 
If you see consistently high DNS latency across regions while TTLs are low, an Anycast DNS host or split-zone setup is usually the fix and we can plan it with you.

Question 55

Unsure whether Anycast DNS is worth the cost for an SMB site

Accepted Answer

1. First ask yourself: if 90 percent of visitors are in NL and BE, a solid unicast zone (Versio, Antagonist) is fine.
2. If you have international clients, a SaaS product or mail that needs to arrive fast worldwide, Anycast (Cloudflare, NS1, Route 53, deSEC) easily shaves 50 to 150 ms off TTFB in distant regions.
3. For DDoS, Anycast absorbs attacks across PoPs, unicast DNS folds faster under volumetric attacks.
4. Check the provider supports DNSSEC, ALIAS/CNAME-flattening and API access, those are the usual migration breakpoints.
5. Migration cost itself is low: export the zone as BIND format, import at the new host, change NS records at the registrar.

When to bring us in: 
If you have a use case where every millisecond matters or you are a DDoS target, we can set up Cloudflare or NS1 and run the migration without downtime.

Question 56

Never noticed DNS briefly went down, want alarms on DNS outages

Accepted Answer

1. Set up DNS monitoring (DNSPerf, Better Stack, UptimeRobot, RIPE Atlas) that probes apex and MX records every minute from multiple regions.
2. Monitor each authoritative NS record separately (ns1, ns2, ns3) so you see a single node fail while the zone overall still works.
3. Alert on response content, not just status. An empty response or SERVFAIL differs from NXDOMAIN.
4. Add DNSSEC validation in the monitor so you notice signing breaking before resolvers reject the record.
5. Document the runbook: revert NS records to the old provider, short TTL required, contact at the DNS host.

When to bring us in: 
If you have no runbook or fallback DNS, we can set up a secondary zone at a second provider so a single host outage never takes everything down.

Question 57

DNS zone grew over years, nobody remembers what each record is for anymore

Accepted Answer

1. Export the zone (BIND format or provider export) and put it in a spreadsheet or git repo so you can diff it.
2. Per record: does the target still exist (curl, ping, cert check) and who owns it inside the company? Unknown = removal candidate.
3. Filter all CNAMEs: do they still point at live hostnames? A CNAME to an expired Heroku app or S3 bucket is immediate takeover risk.
4. Review TXT records: SaaS verifications, old DKIM keys, empty SPF leftovers. Anything unknown and old can go after a 30-day test period.
5. Schedule the audit yearly or at every DNS host migration, and log every change in a changelog or CMDB.

When to bring us in: 
If you have hundreds of records or multiple registrars and no overview, we can run an audit, flag takeover risks and reduce the zone to what is actually in use.

Question 58

Big DNS change on the calendar, no plan B if it goes wrong

Accepted Answer

1. Lower TTL to 300 seconds at least 24 hours before the change, not during the change itself.
2. Snapshot the current zone (BIND export or control-panel screenshots) and store it where you can reach it without logging in.
3. Schedule the change outside business hours when possible, especially for MX and NS, and keep at least two people on standby with DNS and registrar access.
4. Test immediately after publish with dig from multiple resolvers (1.1.1.1, 8.8.8.8, your own ISP) and not just via your browser, browser cache distorts.
5. Define a kill-switch criterion in advance: 'If within 15 minutes the monitor shows X% errors, we revert A to Y.' Decision fatigue is your biggest enemy.

When to bring us in: 
If a major DNS or mail migration is on the calendar and you want someone there to run the cutover and roll back on signal, we can plan it together.

Question 59

Marketing wants to manage a subdomain on its own DNS host, main domain stays with us

Accepted Answer

1. Ask the second party for their NS records for the subdomain, usually 2 or 4 nameservers.
2. Create NS records in the main zone for shop.vectel.nl pointing at those nameservers, not a CNAME.
3. Confirm with dig NS shop.vectel.nl @8.8.8.8 that the delegation is correct and dig +trace that the path to the second zone works.
4. Agree which records the second party owns and which they do not, because they get full control of everything under shop.vectel.nl.
5. Document the delegation in your DNS overview so the next admin understands why a record ends up at a different server in dig.

When to bring us in: 
If you want delegation set up safely with clear ownership and monitoring on both zones, we help arrange the agreements and records.

Question 60

Internal servers should be reachable via an internal name, the same domain must resolve differently externally

Accepted Answer

1. First decide whether split-horizon is truly needed. For fully cloud setups a single public DNS zone is usually simpler and safer.
2. Keep zone names identical (vectel.nl internal and external) but let an internal resolver (Active Directory DNS, Pi-hole, Unbound) override specific records.
3. Avoid different values for public records (MX, SPF, TXT). Keep them identical, otherwise mail and API tests from inside break.
4. Document which records differ internally, because anyone troubleshooting without that knowledge gets lost.
5. Test from both inside and outside regularly with dig or nslookup, a single DHCP change that bypasses the internal resolver wrecks it.

When to bring us in: 
If you have a hybrid setup where internal and external diverge and mail delivery acts up, we can redesign the DNS architecture.

Question 61

Confusion about what 'authoritative' and 'recursive' DNS do and which you need

Accepted Answer

1. For your domain you need an authoritative provider (TransIP, Cloudflare, Versio, Route 53). That is where you edit records.
2. For workstation clients you use a recursive resolver. Often the ISP/router default, but 1.1.1.1 or 9.9.9.9 are usually faster and more privacy-friendly.
3. In an office with AD: let clients use the Domain Controllers as recursive (they forward to public resolvers), not 8.8.8.8 directly.
4. Never open a recursive resolver to the public internet. That is an open relay for DNS amplification attacks.
5. When you wonder where a problem lives: dig @authoritative-server versus dig @public-resolver, the difference tells you whether cache or origin is at fault.

When to bring us in: 
If you have a mix of AD, on-prem resolvers and cloud DNS and records get tangled, we can lay out the architecture again.

Question 62

Read about DNS cache poisoning, want to know if the SMB setup is vulnerable

Accepted Answer

1. Do not run outdated DNS software in the office (old BIND, old Windows DNS). Patches close Kaminsky-class vulnerabilities.
2. Enable DNSSEC for your own domain at the registrar, which protects clients with validating resolvers from forged answers about your zone.
3. Have clients use a resolver that validates DNSSEC (1.1.1.1, 9.9.9.9, or your own Unbound), not just one that forwards.
4. Consider DNS over HTTPS (DoH) or DNS over TLS (DoT) for laptops off the network, so a man-in-the-middle on Wi-Fi cannot intercept DNS.
5. Disable open recursive resolvers on your firewall/router, those are both poisoning and DDoS-amplifier targets.

When to bring us in: 
If you want a review of your DNS chain from client to authoritative, with DNSSEC and DoH where it makes sense, we can plan it.

Question 63

Hosting provider warns our DNS server was used in an amplification attack

Accepted Answer

1. Restrict the recursive resolver to your own network: in BIND allow-recursion {trusted;}, in Windows DNS the equivalent scope restriction.
2. Disable large EDNS responses to unknown sources, or enable Response Rate Limiting (RRL) on your authoritative server.
3. Set firewall rate-limits on inbound UDP port 53 from the public internet, a few hundred queries per second max.
4. Check with openresolver.com or dnsinspect.com whether your IP is still on a list of open resolvers.
5. Where possible move to a managed Anycast DNS (Cloudflare, NS1) so amplification mitigation is no longer your problem.

When to bring us in: 
If you are a target or source of DNS abuse and abuse emails keep coming, we can help lock down the resolver and clean up the relationship with hosting.

Question 64

Browsers use DoH, IT wants to know what it means for monitoring and filtering

Accepted Answer

1. Inventory where DoH is already active: Chrome, Firefox, Edge and Windows 11 sometimes ship it on by default, sometimes behind a flag.
2. In an office with AD: push group policy 'Configure DNS over HTTPS' to Off for managed devices, and route them through your internal resolver.
3. For laptops off-network: pick one approved DoH resolver (NextDNS, Cloudflare for Teams) so you have policies and logs.
4. Block unknown DoH endpoints at the firewall via DNS-resolver blocklists, so clients cannot quietly use any resolver.
5. Communicate the reasoning to users: this is not privacy-hostile, it is required for security monitoring and compliance.

When to bring us in: 
If you want a DoH strategy that works at the office and on the road without blinding IT, we can deploy NextDNS or similar.

Hosting, domains and DNS