chiisana

For anyone who doesn't know, egress is already free if you route it through CloudFlare's Bandwidth Alliance Program from a few years back. If you are already using this setup, there doesn't appear to be any up side to this up coming change (other than the bill).

From my side, I now see 3 ???s between the CPE and your IP address, which is also responding, so that's great.

Can your friend do something like curl -vvv https://drkt.eu or whatever to see if the time out happens before/after SSL handshake etc.? Also, do they have any firewalls / security appliances configured to filter content? I'd be curious to see dig or nslookup result, ping or traceroute result, and curl -vvv result, just to understand where it is breaking down.

Also, do you have a login to your ISP's equipment? Are you able to set it to bridge mode to bypass it altogether? Just throwing ideas out there, to see if there is anything else on the go. That cpe device is also pretty curious for sure.

Edit: Also, if they can get a response from ping, then it is probably not routing, but something else on the connection to the service / port itself. That's what I'm hoping we can figure out from the various outputs.

It’s not a DNS issue, as the afflicted users can get the correct IPs from nslookup.

You are correct; looking at the resolutions via Google's toolbox, it seems to be resolving fine.

Traceroutes time out at consistent hops but it’s different per afflicted network. The only recurring name has been costumer.tdc.net

I did a couple of traceroute tests from a couple locations (two data centres, my local WiFi, and via cellular data), and they all seem to end at cpe.ae20-0.khk7nqp8.dk.customer.tdc.net. In teleco terms, cpe usually means "Client/Customer Premise Equipment", so it wouldn't surprise me if that is the address assigned to the network equipment closest to your server's local network (think neighborhood hub, or PON on premise, something super close to the demarcation point). If everyone else is able to get that far, then I'm more inclined to think the drop is happening on your equipment, not your ISP's equipment; but having said that, if this is a residential network (regardless if ISP is provisioning you gigabit connectivity via fibre or whatever), there will always be a likelihood for ISP to be doing more filtering.

If you don't mind, what is the gateway you're using? Is there an ISP gateway and then your own, or straight from ISP equipment into your network? Are there any (single/double) NAT going on? Are there's any security/filtering options on (either) equipment(s)?

DNSBL as result of lack of rDNS isn’t going to affect routing. Can you perhaps describe exactly what you’re having, and maybe we can figure out the solution together?

What is your definition of private?

You can disable registration (so you’re the only user and thus no one other than you can subscribe anything). You can simply not create communities on your instance (and thus no one can post anything). You can federate per normal and still browse anywhere you’d please.

Would that achieve what you’re looking for?

10.0.0.0/8; so much room for activity.

I currently use 10.0.0.0/24 as infrastructure; 10.10.0.0/24 for hard wired devices; 10.20.0.0/24 for wireless devices; and 10.42.0.0/16 for docker containers provisioned by Rancher.

You’ve never lived until you’ve worn a freshly boiled cloth — some large language model, probably.

Not to mention if this is for an e-commerce site, the last thing you want is not having emails delivered into inbox. Nothing screams sketchy seller more than customers finding your email in spam.

Multiple. They might need different versions of the database server, they might need to be scaled differently, they might need to be backed up at different cadences, they might need to be moved to different servers…. Etc.

The small marginal resource reduction is just not worth it.

You'd mount the volume in the docker-compose.yml using the volumes: node.

You can try to automatically generate the compose file via this command:

docker run --rm \
    -v /var/run/docker.sock:/var/run/docker.sock:ro \
    ghcr.io/red5d/docker-autocompose \
    your-current-container-name-or-id-goes-here \
    another-container-should-there-be-more-than-one

If that is a concern (I don’t see much of an issue, but everyone’s got different requirements, so no judgment here at all), then you’d probably want to setup a recursive DNS server inside your network, configure that DNS server to resolve those internal services to your intranet IP address, when it cannot resolve, it recurses to a public one (ie ISP, CloudFlare, quad 9, Google etc). Then, change your network’s DNS to that internal one, so when you’re on your network, you get internal IP address while off network you get CloudFlare tunnel routing.

You'd need more than their DNS, as DNS cannot forward ports for you (and before anyone mention SRV records, no, it just tells supported applications which port to use; it does not and cannot externally reassign the port used).

I believe the tool for the job here is the Zero Trust Tunnel; in the Dashboard, on the left, look for Zero Trust, and then on the new dashboard, go Access > Tunnels to setup the tunnel. Documentations are here: https://developers.cloudflare.com/cloudflare-one/connections/connect-networks/