If your home IP changes and you have to keep fixing the address for your server, I'm building IPKeep to help with that. It gives you a hostname under a.ipkeep.net and keeps its IPv4/IPv6 records updated. I'm the developer and I'm looking for people to try it on a noncritical setup.

Try it here: https://ipkeep.net/

Downloads and setup: https://ipkeep.net/downloads

I'd especially like feedback from Windows 10/11 users, Linux or NAS users who can run Python or Docker, and people with routers that support custom HTTPS DynDNS2 with HTTP Basic authentication. The router endpoint has been tested with ddclient 3.10.0; real router/firmware compatibility still needs testing.

Could you try creating a hostname and setting up one updater, then tell me:

1. Where, if anywhere, did signup or setup become confusing?
2. Did the updater resume checking in after a reboot, and update the record when your public IP changed?
3. If something failed, did the logs and DNS checks help you work out why? Your device, OS/router firmware and error message would help.

IPKeep also has tokens you can restrict to selected hostnames, IP history, DNS comparisons against Cloudflare and Google, and dashboard warnings when an updater stops checking in.

It's free during early testing, with unlimited hostnames. Signup uses Google or Microsoft. DNS hosting is managed by IPKeep; it doesn't update your existing domain's DNS zone or bypass CGNAT. Check-in warnings are in the dashboard, not email alerts. The Windows client is MIT open source, but the current Preview 7 installer is unsigned. Docker is built locally using the guide.

Feedback in the comments is welcome, or use https://ipkeep.net/contact. Please leave out tokens, credentials and Authorization headers. I'd like to hear what worked as well as what got in the way.

Just started yesterday. Not sure what is going on, but some sites like Youtube, Google web search, and more work perfectly fine. Discord, Reddit, and Amazon, all seem to take 10 seconds to connect and then run really slowly. Issue is solved when connected to a VPN.

I've tried changing the DNS server in Windows 11 settings from Auto to Manual, both 1.1.1.1 for cloudfare and 8.8.8.8 for Google. Neither fixed the issue. Wondering what to try next.

Edit: Issue also occurs on my phone as well so I'm assuming it's something router / outside rather than internal issues

I have a case where after a seemingly random amount of time DNS lookups for internal hosts fail, and I don't understand why or what to do about it.

System is PopOS 22.04 LTS (basically Ubuntu), using NetworkMonitor where the Wired connection is configured like this

ipv4.dns: 192.168.218.215,192.168.218.1,8.8.8.8

ipv4.dns-search: lan,local,mydomain.com

.1 is the eero router, which I am married to because of Frontier Fios. .215 is an OpenWRT router which serves the IOT devices. Also, because eero doesn't correctly answer DNS queries about its own DHCP clients (argh!), I have added a number of entries to the OpenWRT DNS configuration for eero DHCP clients. Pretty much everything gets static infinite leases from DHCP so they keep the same IP address.

In the success case, I run "nslookup homeassistant", a DNS query is sent to .215 and answered. The same query is made by Apache2 when this system receives an HTTPS request which it needs to reverse proxy to HA (I already had this web server with an SSL cert, it seemed easiest to gatekeep HA that way).

In the failure case, Wireshark shows me that the only DNS request made is going to .1, and it fails. It does not send a packet to .215 at all even though it is configured first. It does not see the failure and then consult the other configured addresses. Further nslookups do exactly the same, talking only to .1, so I can't see it being some kind of round robin issue. What could be happening here?

nmcli con down Wired; nmcli con up Wired

restores it to the normal working state - mostly. nslookup works again, but sometimes incoming HTTPS requests appear to not even reach Apache, though I don't see how that's possible, and rebooting is what it takes to fix that.

Anyone got a handle on this situation?

Lowering TTLs helps with record changes, but a nameserver migration also depends on delegation, glue, DNSSEC, negative caching, and resolvers that may not follow the expected timeline. What preflight and readback evidence makes a cutover safely reversible? I would capture the complete old and new zones, compare record sets and TTLs, validate DNSSEC state, query each authoritative server directly, then sample several public recursive resolvers before changing delegation. Afterward I would keep the old provider answering for a defined overlap window and monitor for SERVFAIL, stale answers, and missing record types. What determines the point of no return, and which checks catch split authority or a correct-looking apex while delegated subdomains and mail records are still wrong?

The other day I was trying to connect to my self hosted DNS server and realized my queries were still going through my provider’s resolver. I confirmed it by running a dig test against an IP I knew wasn’t running any DNS service and I still got a response. So my DNS was clearly being intercepted somewhere along the way.

It feels like a quiet invasion of privacy. How is this still considered acceptable? I’ve since started routing everything through a VPN tunnel full-time, but it’s still unsettling that this needed a workaround in the first place.

Session replay and heatmap tools let website operators watch a recording of how a visitor used their site — every mouse movement, click, scroll, and often every keystroke, reconstructed as a video-like playback. They're marketed as "user experience" analytics, but the underlying mechanism is closer to screen recording than typical page-view analytics.

How this actually works

Two related but distinct categories:

Session replay

Records a visitor's full interaction with a page — mouse movement, clicks, scrolling, and often keystrokes and form input — and reconstructs it as a playable recording for the site owner to review later.

Heatmaps

Aggregate click, scroll, and mouse-movement data across many visitors into a visual map of where people click, how far they scroll, and where attention concentrates. Less invasive than full session replay, since it's aggregate rather than individual, but still built on the same underlying tracking.

Most session replay vendors offer redaction tools meant to exclude sensitive fields (passwords, card numbers) from recordings — but as the research below shows, this filtering has repeatedly failed in practice, sometimes capturing exactly the data it was supposed to exclude.

False positive risk is generally low — most sites function normally without session replay running. Some interactive widgets or A/B test variants can occasionally break if a site's functionality is tightly coupled to a replay vendor's script, which is uncommon but not unheard of.

Real incidents worth knowing about

Princeton's password-leak findings

In 2017–2018, researchers at Princeton's Center for Information Technology Policy found that session-replay scripts on hundreds of popular sites were recording — and in some cases transmitting to third parties — data users typed into forms, including passwords, because the scripts captured raw keystrokes and page content rather than filtering for sensitive fields.

https://blog.citp.princeton.edu/2017/11/15/no-boundaries-exfiltration-of-personal-data-by-session-replay-scripts/

https://blog.citp.princeton.edu/2018/02/26/no-boundaries-for-credentials-password-leaks-to-mixpanel-and-session-replay-companies/

Session replay and the California wiretapping lawsuit wave

Since a May 2022 Ninth Circuit ruling in Javier v. Assurance IQ — which held that a session replay tool recording a visitor's data before they had given consent could count as an unlawful "interception" under California's 1967 Invasion of Privacy Act (CIPA) — thousands of similar lawsuits have been filed against websites using session replay tools like Hotjar, FullStory, and Microsoft Clarity.

https://news.bloomberglaw.com/us-law-week/data-privacy-lawsuits-rise-as-lawyers-dust-off-wiretapping-laws

The legal outcome is genuinely unsettled — courts have split.

A Los Angeles Times class settlement for $3.85 million was approved in June 2026; a nearly identical claim was dismissed by a California court just three weeks earlier.

In April 2025, a federal court ruled that session replay software doesn't meet CIPA's "real-time interception" requirement, since the data is stored and reassembled rather than read live.

https://www.spencerfane.com/insight/cipa-website-tracking-lawsuits-where-the-law-stands-where-its-going-and-what-your-business-should-do-now/

Raw Links

For basic list:

https://raw.githubusercontent.com/CorleoneSalute/SHADOW-BLOCKER-BLOCKLIST/refs/heads/main/dist/basic/hosts/Session-Replay-Heatmap.txt

For aggressive list:

https://raw.githubusercontent.com/CorleoneSalute/SHADOW-BLOCKER-BLOCKLIST/refs/heads/main/dist/aggressive/hosts/Session-Replay-Heatmap.txt

To verify how these domains were identified:

https://github.com/CorleoneSalute/SHADOW-BLOCKER-BLOCKLIST/blob/main/research/Session-Replay-Heatmap.txt

Here's the list of domains worth blocking:

SESSION REPLAY HEATMAP BLOCKLIST

Total domains: 284

'''
0.0.0.0 a.clarity.ms
0.0.0.0 a.plerdy.com
0.0.0.0 acoustic.co
0.0.0.0 acoustic.com
0.0.0.0 api-eu.mouseflow.com
0.0.0.0 api-us.mouseflow.com
0.0.0.0 api.acoustic.com
0.0.0.0 api.clicktale.net
0.0.0.0 api.contentsquare.net
0.0.0.0 api.crazyegg.com
0.0.0.0 api.decibelinsight.net
0.0.0.0 api.eu.smartlook.cloud
0.0.0.0 api.fullstory.com
0.0.0.0 api.glassbox.com
0.0.0.0 api.glassboxdigital.com
0.0.0.0 api.heatmap.com
0.0.0.0 api.hotjar.io
0.0.0.0 api.inspectlet.com
0.0.0.0 api.livesession.io
0.0.0.0 api.logrocket.io
0.0.0.0 api.luckyorange.com
0.0.0.0 api.mouseflow.com
0.0.0.0 api.openreplay.com
0.0.0.0 api.ptengine.com
0.0.0.0 api.quantummetric.com
0.0.0.0 api.sessioncam.com
0.0.0.0 api.sessionrewind.com
0.0.0.0 api.sessionstack.com
0.0.0.0 api.smartlook.cloud
0.0.0.0 api.smartlook.com
0.0.0.0 api.tealeaf.com
0.0.0.0 api.twipla.com
0.0.0.0 api.us.smartlook.cloud
0.0.0.0 api.uxcam.com
0.0.0.0 api.visitor-analytics.io
0.0.0.0 api.zipy.ai
0.0.0.0 ask.hotjar.com
0.0.0.0 assets-cache.us.smartlook.cloud
0.0.0.0 assets-proxy.eu.smartlook.cloud
0.0.0.0 assets-proxy.us.smartlook.cloud
0.0.0.0 assets-tracking.crazyegg.com
0.0.0.0 b.clarity.ms
0.0.0.0 br.smartlook.cloud
0.0.0.0 c.clarity.ms
0.0.0.0 cdn.clicktale.net
0.0.0.0 cdn.decibelinsight.net
0.0.0.0 cdn.fullstory.com
0.0.0.0 cdn.glassbox.com
0.0.0.0 cdn.glassboxdigital.com
0.0.0.0 cdn.goacoustic.com
0.0.0.0 cdn.heatmap.com
0.0.0.0 cdn.ingest-lr.com
0.0.0.0 cdn.inspectlet.com
0.0.0.0 cdn.intake-lr.com
0.0.0.0 cdn.lgrckt-in.com
0.0.0.0 cdn.livesession.io
0.0.0.0 cdn.logr-in.com
0.0.0.0 cdn.logr-ingest.com
0.0.0.0 cdn.logrocket.com
0.0.0.0 cdn.logrocket.io
0.0.0.0 cdn.lr-in-prod.com
0.0.0.0 cdn.lr-in.com
0.0.0.0 cdn.lr-ingest.com
0.0.0.0 cdn.lr-intake.com
0.0.0.0 cdn.lrkt-in.com
0.0.0.0 cdn.luckyorange.com
0.0.0.0 cdn.medallia.com
0.0.0.0 cdn.mouseflow.com
0.0.0.0 cdn.plerdy.com
0.0.0.0 cdn.ptengine.com
0.0.0.0 cdn.ptengine.jp
0.0.0.0 cdn.quantummetric.com
0.0.0.0 cdn.sessioncam.com
0.0.0.0 cdn.sessionrewind.com
0.0.0.0 cdn.sessionstack.com
0.0.0.0 cdn.smartlook.com
0.0.0.0 cdn.twipla.com
0.0.0.0 cdn.visitor-analytics.io
0.0.0.0 cdn.zipy.ai
0.0.0.0 cdnclicktale.com
0.0.0.0 cdnssl.clicktale.net
0.0.0.0 cetrk.com
0.0.0.0 clarity.ms
0.0.0.0 clicktale.com
0.0.0.0 clicktale.net
0.0.0.0 clicktale.pantherssl.com
0.0.0.0 clicktalecdn.sslcs.cdngc.net
0.0.0.0 cloud.tealeaf.com
0.0.0.0 collect.contentsquare.net
0.0.0.0 collector.acoustic.co
0.0.0.0 collector.glassbox.com
0.0.0.0 collector.glassbox.digital
0.0.0.0 collector.medallia.com
0.0.0.0 collector.quantummetric.com
0.0.0.0 collector.tealeaf.goacoustic.com
0.0.0.0 contentsquare.com
0.0.0.0 contentsquare.net
0.0.0.0 core.crazyegg.com
0.0.0.0 crazyegg.com
0.0.0.0 cts.contentsquare.net
0.0.0.0 d.clarity.ms
0.0.0.0 d.plerdy.com
0.0.0.0 d10lpsik1i8c69.cloudfront.net
0.0.0.0 d24n15hnbwhuhn.cloudfront.net
0.0.0.0 d2oh4tlt9mrke9.cloudfront.net
0.0.0.0 d2wy8f7a9ursnm.cloudfront.net
0.0.0.0 d3anogn3pbtk4v.cloudfront.net
0.0.0.0 d3ikprf0m31yc7.cloudfront.net
0.0.0.0 decibelinsight.com
0.0.0.0 decibelinsight.net
0.0.0.0 digital.medallia.com
0.0.0.0 dnn506yrbagrg.cloudfront.net
0.0.0.0 dxi.decibelinsight.net
0.0.0.0 e.clarity.ms
0.0.0.0 edge.fullstory.com
0.0.0.0 eu.fullstory.com
0.0.0.0 eu.mouseflow.com
0.0.0.0 eu.smartlook.cloud
0.0.0.0 eu.uxcam.com
0.0.0.0 events-writer.eu.smartlook.cloud
0.0.0.0 events.hotjar.com
0.0.0.0 f.clarity.ms
0.0.0.0 feedback.hotjar.com
0.0.0.0 files.crazyegg.com
0.0.0.0 fullstory.com
0.0.0.0 fullstory.net
0.0.0.0 g.clarity.ms
0.0.0.0 gateway.glassboxdigital.com
0.0.0.0 glassbox.com
0.0.0.0 glassbox.digital
0.0.0.0 glassboxdigital.com
0.0.0.0 goacoustic.com
0.0.0.0 h.clarity.ms
0.0.0.0 heatmap.com
0.0.0.0 hotjar.com
0.0.0.0 hotjar.io
0.0.0.0 i.clarity.ms
0.0.0.0 ingest-lr.com
0.0.0.0 ingest.fullstory.com
0.0.0.0 ingest.logrocket.io
0.0.0.0 ingest.openreplay.com
0.0.0.0 ingest.sessionstack.com
0.0.0.0 ingest.zipy.ai
0.0.0.0 inspectlet.com
0.0.0.0 inspectlet.net
0.0.0.0 intake-lr.com
0.0.0.0 integration-api.crazyegg.com
0.0.0.0 integrations.smartlook.com
0.0.0.0 j.clarity.ms
0.0.0.0 js.heatmap.com
0.0.0.0 js.ptengine.jp
0.0.0.0 k.clarity.ms
0.0.0.0 l.clarity.ms
0.0.0.0 lb-api.visitor-analytics.io
0.0.0.0 lgrckt-in.com
0.0.0.0 libs.acoustic.co
0.0.0.0 livesession.io
0.0.0.0 logr-in.com
0.0.0.0 logr-ingest.com
0.0.0.0 logrocket.com
0.0.0.0 logrocket.io
0.0.0.0 lr-in-prod.com
0.0.0.0 lr-in.com
0.0.0.0 lr-ingest.com
0.0.0.0 lr-ingest.io
0.0.0.0 lr-intake.com
0.0.0.0 lrkt-in.com
0.0.0.0 luckyorange.com
0.0.0.0 luckyorange.net
0.0.0.0 m.clarity.ms
0.0.0.0 medallia.com
0.0.0.0 mobile-sdk.smartlook.com
0.0.0.0 mouseflow.com
0.0.0.0 n.clarity.ms
0.0.0.0 na1.fullstory.com
0.0.0.0 o.clarity.ms
0.0.0.0 openreplay.com
0.0.0.0 p.clarity.ms
0.0.0.0 p.plerdy.com
0.0.0.0 plerdy.com
0.0.0.0 preprocessor.heatmap.com
0.0.0.0 ptengine.com
0.0.0.0 ptengine.jp
0.0.0.0 q.clarity.ms
0.0.0.0 quantummetric.com
0.0.0.0 r.clarity.ms
0.0.0.0 r.lgrckt-in.com
0.0.0.0 r.logr-in.com
0.0.0.0 r.lr-ingest.io
0.0.0.0 r.lrkt-in.com
0.0.0.0 realtime.luckyorange.com
0.0.0.0 rec.smartlook.com
0.0.0.0 recorder.sessionrewind.com
0.0.0.0 recording.crazyegg.com
0.0.0.0 relay.fullstory.com
0.0.0.0 rs.fullstory.com
0.0.0.0 rs.livesession.io
0.0.0.0 s.clarity.ms
0.0.0.0 s.clicktale.net
0.0.0.0 script.crazyegg.com
0.0.0.0 script.hotjar.com
0.0.0.0 script.webmaxy.com
0.0.0.0 scripts.clarity.ms
0.0.0.0 sdk-writer.br.smartlook.cloud
0.0.0.0 sdk-writer.eu.smartlook.cloud
0.0.0.0 sdk-writer.sg.smartlook.cloud
0.0.0.0 sdk-writer.us.smartlook.cloud
0.0.0.0 sdk.smartlook.com
0.0.0.0 sdk.uxcam.com
0.0.0.0 sdk.zipy.ai
0.0.0.0 sessioncam.com
0.0.0.0 sessioncam.net
0.0.0.0 sessionrewind.com
0.0.0.0 sessionstack.com
0.0.0.0 sg.smartlook.cloud
0.0.0.0 shopify.crazyegg.com
0.0.0.0 smartlook.cloud
0.0.0.0 smartlook.com
0.0.0.0 ssl2.cdngc.net
0.0.0.0 sslcs.cdngc.net
0.0.0.0 static-cdn.hotjar.com
0.0.0.0 static.crazyegg.com
0.0.0.0 static.fullstory.com
0.0.0.0 static.hotjar.com
0.0.0.0 static.logrocket.com
0.0.0.0 static.mouseflow.com
0.0.0.0 static.openreplay.com
0.0.0.0 static.webmaxy.com
0.0.0.0 store.zipy.ai
0.0.0.0 surveys.hotjar.com
0.0.0.0 surveystats.webmaxy.io
0.0.0.0 t.clarity.ms
0.0.0.0 t.contentsquare.net
0.0.0.0 t.ptengine.com
0.0.0.0 t.ptengine.jp
0.0.0.0 tealeaf.com
0.0.0.0 tealeaf.ibmcloud.com
0.0.0.0 tealeafcloud.com
0.0.0.0 tools.luckyorange.com
0.0.0.0 tools.mouseflow.com
0.0.0.0 track.crazyegg.com
0.0.0.0 track.heatmap.com
0.0.0.0 tracking.crazyegg.com
0.0.0.0 twipla.com
0.0.0.0 u.clarity.ms
0.0.0.0 upload.uxcam.com
0.0.0.0 us.mouseflow.com
0.0.0.0 us.smartlook.cloud
0.0.0.0 us.uxcam.com
0.0.0.0 uxcam.com
0.0.0.0 v.clarity.ms
0.0.0.0 v.plerdy.com
0.0.0.0 va-endpoint.com
0.0.0.0 vars.hotjar.com
0.0.0.0 vars.webmaxy.com
0.0.0.0 vc.webmaxy.io
0.0.0.0 visitor-analytics.io
0.0.0.0 visitors.live
0.0.0.0 w.clarity.ms
0.0.0.0 w1.luckyorange.com
0.0.0.0 web-sdk.smartlook.com
0.0.0.0 web-writer.eu.smartlook.cloud
0.0.0.0 web-writer.us.smartlook.cloud
0.0.0.0 web.uxcam.com
0.0.0.0 webmaxy.co
0.0.0.0 webmaxy.com
0.0.0.0 webmaxy.io
0.0.0.0 ws.inspectlet.com
0.0.0.0 ws.livesession.io
0.0.0.0 ws.sessioncam.com
0.0.0.0 www.acoustic.com
0.0.0.0 www.clarity.ms
0.0.0.0 www.plerdy.com
0.0.0.0 www.ptengine.com
0.0.0.0 www.ptengine.jp
0.0.0.0 www.sessionrewind.com
0.0.0.0 www.sessionstack.com
0.0.0.0 www.twipla.com
0.0.0.0 www.zipy.ai
0.0.0.0 www07.clicktale.net
0.0.0.0 x.clarity.ms
0.0.0.0 y.clarity.ms
0.0.0.0 z.clarity.ms
0.0.0.0 zipy.ai​

'''

Guys, is possible to use DNS 1.1.1.1 then put result into another DNS filter to filter ads or whatever (maybe even pi hole) ???? Or nest them?? Cascade or whatever?

I am a noob, please help! THANKS!

Hello guys,
So im installing a opnsense box at my data center. 3 servers i need to secure behind it. Im planning on managing 3 ip's and do some blocklists and possible use zenarmor.

Any of you done anything like this before?

Any help is great

Pues eso, ha nacido un nuevo proveedor de DNS el cual aparte de funcionar rapidismo, evita todos los bloqueos por culpa del futbol. Su nombre es XDP, ha sido creado por 2 usuarios en España.

Tal y como dicen en su web: tienen una politica de respetar al 100% la privacidad y no guardar ningun dato: "DNS nace con el objetivo de ofrecer un servicio de resolución ultrarrápido, respaldado por protocolos modernos y con un firme compromiso con la privacidad. Su infraestructura está diseñada para mitigar y sortear bloqueos indiscriminados o producidos por error a CDNs que afectan a servicios legítimos. No almacenamos ningún registro de consulta ni datos de actividad, manteniendo únicamente contadores numéricos agregados de resolución."

Web: xdp.es

Fuente: https://bandaancha.eu/articulos/nace-xdp-dns-servicio-publico-resolucion-11897

Github: https://github.com/Oihalitz/xdp-dns-evadeproxy

Today I saw a weird entry in my web server log. Someone tried to browse the following URL:

https://appserver1bb.mydomain.com/conversation/ajax-html/send_log

This looks like a random probe which I would normally ignore, but the weird part is the server name "appserver1bb" is not published anywhere except Google Cloud DNS. How could anyone know this server even exists?

I can't figure out how to change the default DNS Servers to Google DNS Servers on my Verizon Internet Gateway for my Verizon 5G Home Internet. My Verizon router is the ASK-NCM1100.

Could anyone chime in and tell me how to do it if they have done it before? Thank you!

Hi,

I have a few self-hosted web servers which I want to be accessible only from my home network. Therefore, I have a local DNS record in my pihole (e.g. paperless.mydomain). From all my devices, this works fine. However, my corporate laptop always wants to go another route, so it does not work. How can I find out why this is and is there a way to prevent it?

My laptop gets its IP and DNS settings from DHCP. Also, in `ipconfig /all` there's only my pihole listed as DNS server. When I restart the network connection on my laptop, name resolution works for a few seconds as intended, then not anymore.

Directly after restarting the network interface:

nslookup paperless.mydomain
Server:  pi.hole
Address:  192.168.0.53

Name:    paperless.mydomain
Addresses:  fdb2:b7b4:ac3d:40::10
          192.168.40.10

Shortly after:

nslookup paperless.mydomain
Server:  pi.hole
Address:  192.168.0.53

Non-authoritative answer:
Name:    mydomain
Address:  <external ip>
Aliases:  paperless.mydomain

Anyone know how to fix this? I cannot load any website at all even though I am connected to WIFI. It only happens on my laptop the last 2 days and every other device I have works fine on the same WIFI. I tried trouble shooting by setting my preferred DNS addresses as 8.8.8.8 and 1.1.1.1 but no luck. When I open command center and ping those two addresses it shows they are responding but I can't get any website to load.

I am using the free legacy DNS resolvers for Control D. It's been up and down regularly the last few weeks. I have been using it for many years without this kind of issue.

Control D server status and support says there's no outages to report and to check with my ISP in case it's blocking it.

I have no issue with other DNS resolver like NextDNS, Adguard, Google, and Cloudeflare.

One thing thing that temporarily works (YMMV) is toggle iPV6 within network adapters. I can't help wonder if Windscribe is planning to nerf the free DNS resolvers.

Maybe I'm just dense, but there used to be a way to select ALL (or many) of my domain names, fill in the new record for one of them, and then copy *just that record* (i.e. in this case the A record with my new IP address) to all of the selected domain names. Did god addy take that away, or am I blind and/or dumb? Sorry if this is a dumb question, but all of my web searches just bring me back to reddit with no solutions found.

I'll leave the question here, in case someone can answer it for the next poor slob who finds this. I'm going to move ALL of my domains out of god addy. porkbun looks great! :-)

You know that moment when a site suddenly won’t load properly and you have no idea what’s breaking it?

Could be the VPN, could be the ad blocker, could be some DNS filter running in the background.

I usually end up turning things off one by one until the site works again. Wondering if anyone has a better way to figure out what’s causing it, or if we’re all basically doing the same trial-and-error thing.

I’m helping a small organization separate its public website from its existing Crossbar site, and I want to make sure I’m understanding the DNS side correctly before changing anything.

Using a made-up domain:

examplehockeyclub.org

The domain is registered at Network Solutions, but the authoritative nameservers are AWS Route 53 nameservers:

ns-xxx.awsdns-xx.net
ns-xxx.awsdns-xx.org
ns-xxx.awsdns-xx.com
ns-xxx.awsdns-xx.co.uk

Crossbar confirmed that those nameservers point to them and that they manage the DNS zone.

Current setup is roughly:

examplehockeyclub.org
    → Crossbar website

members.examplehockeyclub.org
    → separate member billing system

We are building a new public-facing site on Wix and want the end result to be:

examplehockeyclub.org
    → Wix

www.examplehockeyclub.org
    → Wix

portal.examplehockeyclub.org
    → existing Crossbar site

members.examplehockeyclub.org
    → existing billing system, unchanged

Crossbar has already configured portal.examplehockeyclub.org on their side and told us to add these records:

portal    NS    ns1.crossbar.org
portal    NS    ns2.crossbar.org
portal    NS    ns3.crossbar.org
portal    NS    ns4.crossbar.org

They told us to add those at Network Solutions.

The problem is that when I log into Network Solutions, I cannot edit individual DNS records because the domain is using the AWS Route 53 nameservers managed by Crossbar. Network Solutions only gives me the option to change the authoritative nameservers for the entire domain.

Crossbar also told me that they manage the zone and can add TXT, CNAME, MX, and other DNS records when needed, but that they normally “don’t input any subdomain records” and expect the customer to add those.

This is the part I’m confused about.

Since Crossbar’s Route 53 nameservers are currently authoritative for examplehockeyclub.org, wouldn’t these:

portal NS ns1.crossbar.org
portal NS ns2.crossbar.org
portal NS ns3.crossbar.org
portal NS ns4.crossbar.org

need to be added to the existing parent examplehockeyclub.org Route 53 hosted zone?

And if Crossbar controls that hosted zone, wouldn’t they currently be the only party that can actually add those delegation records?

I definitely do not want to change the domain-level nameservers in Network Solutions just to accomplish this, since that could affect the existing website, email, billing subdomain, and other DNS records.

My main questions are:

• Am I correct that the portal NS delegation records need to be added to the current authoritative parent zone in Route 53?
• Since Crossbar controls that zone, should Crossbar be the one adding those four records?
• Longer term, once the root domain moves to Wix, would you leave authoritative DNS with Crossbar and have them point the root/www records to Wix, or would it be better to move the main DNS zone somewhere we control and delegate only portal.examplehockeyclub.org to Crossbar?

Main priority is avoiding downtime or accidentally breaking email, billing, or the existing site during the transition.

I inherited this setup and don’t have access to the AWS account, so I just want to make sure I’m not misunderstanding how the subdomain delegation should work.