ipv4.bbs.land
    ipv6.bbs.land

You specify a port and point it to a subdomain and it just immediately works, no maintenance necessary. The daemon only needs to be installed once with a simple terminal command

– TLS termination mandatorily happens at Cloudflare (i.e. your traffic is mitm'ed). That's because this free product is meant as a gateway drug (aka a loss leader) to Cloudflare's WAF/Anti-DDOS products (which require TLS termination to happen on their side for technical reasons).

– Other TCP protocols (including SSH) require every client to run the software too. So if you were thinking about bypassing the TLS termination restriction by creating a TCP tunnel instead of an HTTP(S) tunnel you can't.

– Max 100 MB uploads for HTTP(S).

– No media servers allowed.

Otherwise it's a really good service!

But on the flip side, this allows you to have a nice certificate on your outside connection without having to fiddle with letsencrypt or whathaveyou.

Can it be done? Sure. But do I want to spend money on this for my home lab if I can work around it? Not a chance.

I'm kinda sensitive to the "MITM as a service" argument, but for my use case, it's not a problem.

Afaik, every major registrar allows you to add an NS record for the _acme-challenge subdomain, allowing you to put the _acme-challenge subdomain on a custom, self-hosted DNS server.

That in turn allows you to make the permissions as specific as you'd like. Personally I just run powerdns in docker for this.

That said, personally I don't really have any devices that can use SSH but not a browser.

FWIW, I have been using it with Plex (just two users, me and my parents) and haven't gotten banned. The ToS are kind of unclear on whether this is allowed if I have to be honest.

Cloudflare threatened to terminate our $15k enterprise license last week for serving 76 TB of API JSON files last month (90% cache hits).

I moved half of the traffic to a new domain with a Business license to see what they say...

It's encrypted between the browser and Cloudflare, but you can also create a cert and encrypt between Cloudflare and your origin server. (but that isn't mandatory)

I setup some Cloudflare DNS records to the tail scale 100.x IPs to make them easy to remember.

There also dozens of existing DDNS daemons out there already with far more developer, testing, and user eyeballs on them.

The firewall solution is preferred because the firewall knows when the external interface changes IP addresses, so there's no system or network overhead from having an agent repeatedly testing if the IP has changed, nor any downtime between when the IP changes and when the next check happens.

That said, the only hole in my firewall/router is a port for Wireguard.

Though it occurs to me their may just be a language barrier and you may have a domain that you manage your DNS in Cloudflare already. If that's the case, a subdomain is just an A record under your domain's DNS settings for anything other than the root domain. So, if your domain is "example.com", the A record could be like "service" with an IP of "192.168.1.10", and your subdomain would then be served on "service.example.com" for example. Subdomains are free, if you have a domain in the first place.

If you're asking if you would already need the subdomain configured in your DNS settings in Cloudflare, then yes, most likely. Though there are tools that create those for you, like external-dns in kubernetes.

When I deleted the cloudflare DNS for one of my domains I also completely lost access to the cloudflare registrar for that domain.

Even though they should not be coupled at all and the UI makes it very much appear like they are decoupled.

I imagine this is a bug that's been fixed by now but it was still super panic inducing in the moment.

So ya keep those DNS and domains separate if possible.

Using the same provider for both domain registration and DNS hosting can introduce several risks. Here are some of the main risks and ways to mitigate them:

1. Single point of failure: If the provider experiences an outage or security breach, both your domain registration and DNS hosting could be affected simultaneously. This can cause your website or services to become unavailable. Mitigation: Consider using separate providers for domain registration and DNS hosting to reduce the impact of a single provider's issues.

2. Provider lock-in: Some providers make it difficult to transfer your domain or DNS management to another provider, leaving you dependent on their services. Mitigation: Choose a provider that allows easy domain transfers and supports standard DNS management protocols like EPP (Extensible Provisioning Protocol). Familiarize yourself with the transfer process before committing to a provider.

3. Security vulnerabilities: If the provider's security measures are inadequate, attackers may be able to gain unauthorized access to your domain and DNS settings, potentially leading to domain hijacking or DNS tampering. Mitigation: Select a reputable provider with strong security practices, such as two-factor authentication, IP restrictions, and regular security audits. Enable additional security features like DNSSEC (Domain Name System Security Extensions) to protect against DNS spoofing.

4. Lack of redundancy: Relying on a single provider for both domain registration and DNS hosting means you don't have a backup if that provider experiences issues. Mitigation: Consider using secondary DNS services from a different provider to ensure redundancy and failover capabilities.

5. Limited control and flexibility: Some providers may offer limited control over your DNS settings or have restrictions on the types of records you can configure. Mitigation: Opt for a provider that offers a comprehensive and user-friendly DNS management interface with support for various record types and advanced features like GeoDNS or failover.

To further mitigate risks, consider the following best practices:

1. Keep your domain registration and DNS hosting accounts secure with strong, unique passwords and enable two-factor authentication.

2. Regularly monitor your domain and DNS settings for any unauthorized changes.

3. Keep your contact information up to date with your domain registrar to ensure you receive important notifications and can respond promptly to any issues.

4. Familiarize yourself with the domain transfer process and keep backups of your DNS configuration to ease migration to another provider if needed.

5. Choose reputable providers with a track record of reliability, security, and customer support.

By being aware of these risks and implementing appropriate mitigation measures, you can minimize the potential impact of using the same provider for domain registration and DNS hosting.

(Although CF seems perfectly happy hosting really shady sites that host primarily illegal content)

## Risks

1. *Single Point of Failure*: - If the provider experiences an outage, both your domain registration and DNS services could be affected, leading to downtime for your website and email services[2].

2. *Security Vulnerabilities*: - Using a single provider increases the risk of DNS hijacking, DNS cache poisoning, and other DNS attacks if the provider's security is compromised[3][4].

3. *Limited DNS Features*: - Some domain registrars that offer DNS services may not provide advanced DNS features like DNSSEC, Anycast, or DDoS protection, which are crucial for security and performance[2][5].

4. *Vendor Lock-in*: - It may be more challenging to transfer your domain or DNS services to another provider if both are managed by the same company, potentially leading to higher costs or service disruptions[1].

## Mitigation Strategies

1. *Use DNSSEC*: - Implement DNSSEC (Domain Name System Security Extensions) to protect against DNS hijacking and cache poisoning. DNSSEC adds a layer of security by enabling DNS responses to be verified using digital signatures[3][4].

2. *Redundancy and Backup*: - Use secondary DNS providers to ensure redundancy. This way, if your primary DNS provider experiences an outage, the secondary provider can handle DNS queries, minimizing downtime[2][5].

3. *Choose a Reputable Provider*: - Select a provider that specializes in DNS services and offers robust security features, including DDoS mitigation, Anycast networks, and DNSSEC. This ensures that you are using the latest DNS technologies and security measures[2][7].

4. *Regular Security Audits*: - Conduct regular security audits of your DNS configurations and keep your DNS software updated to protect against vulnerabilities and exploits[7].

5. *Enable Two-Factor Authentication (2FA)*: - Use 2FA for accessing your domain and DNS management interfaces to prevent unauthorized access. Additionally, consider IP whitelisting to restrict access to trusted IP addresses only[3][5].

6. *Client Lock*: - Utilize client lock features provided by your registrar to prevent unauthorized changes to your DNS records without approval from a specific individual within your organization[3][5].

By implementing these strategies, you can significantly reduce the risks associated with using the same provider for domain registration and DNS hosting, ensuring better security, reliability, and performance for your online services.

Sources [1] Everything About Website Domain Registration : Best Practices And ... https://monsterhost.com/everything-about-website-domain-regi... [2] Should you keep your DNS management and domain registration ... https://blog.dnsimple.com/2015/03/benefits-and-drawbacks-of-... [3] What is DNS Hijacking and Mitigation Methods - GlobalDots https://www.globaldots.com/resources/blog/what-is-dns-hijack... [4] DNS Attacks: Tutorial & Prevention Best Practices - Catchpoint https://www.catchpoint.com/dns-monitoring/dns-attack [5] How to Prevent DNS Attacks: DNS Security Best Practices https://www.esecurityplanet.com/networks/how-to-prevent-dns-... [6] Unraveling the roles of domain registrars and web hosting providers https://www.godaddy.com/resources/skills/roles-of-domain-reg... [7] Top Five DNS Security Attack Risks and How to Avoid Them | Blog https://www.humanize.security/blog/cyber-awareness/top-five-...

For Dynamic DNS you want minimal TTL, ideally less than 60 seconds, otherwise the DNS records will be cached and will not reflect the correct address during the short period of time window it changes.

Dedicated DDNS services usually have very short TTL (some offering as low as 5 seconds IIRC), but free Cloudflare accounts have a minimal TTL of 300 seconds (5 minutes), coupled with the crontab running every 5 minutes, your endpoint could be out of contact for 10 minutes if everything aligns right.

For unproxied records you can set the TTL to 1 minute as per their documentation..

And normally your IP would change only when reconnecting, so it's not a big deal...

Recently upgraded my home router and the manufacturer operates a free dynamic dns service enabled with a toggle button. I have a cname record in my domain’s dns records pointing to the dynamic dns entry. I actually don’t even need that anymore. All the services I run at home are only for immediate family so only available remotely via a Wireguard vpn connection. I migrated that to the router also because it can do 900Mbs of Wireguard traffic and has a great vpn server management implementation. By default the client configs it generates points to the dynamic dns name. No real need for the cname but I have it out of habit.

I've got my additional services on a Ryzen R9 5900HX mini pc. My router is an N300 mini-pc with 4 network ports. I had trouble configuring wireguard on the router, so it's in a VM on the mini-pc and runs as well as can be expected.

It also runs AdGuard Home so that is another thing I have been able to remove from my home server.

Which got me into a 4-year exploration of FreeBSD! I'm still a bit sad I had to replace it with Proxmox on Debian to get what I wanted.

Mine is a golang executable that runs directly on my OpenWRT-based router on a 30 minute cron job. The beauty of running it on my router directly is that I can simply query the `eth0` interface for my public ip address - no need for a `curl` to determine my public IP.

https://github.com/jackphilippi/r53-ddns

At some point their rationale has to become irrelevant. It’s simply unprofessional behavior.

  curl -4 https://www.cloudflare.com/cdn-cgi/trace

  curl -6 https://www.cloudflare.com/cdn-cgi/trace

Listen, if you want to check the IPv6 address from the interface list go ahead I’m not trying to stop you.

But because I anyway need to reach a third party to know my own IPv4 address then yeah when that third party can also tell me IPv6 address I’m gonna do it that way.

The router is connected to the internal network in my home and has the IP address of 192.168.1.1.

Behind the router is my computer which has a non-public IP address, for example 192.168.1.2. My computer is the one I want to run the program to update the DNS entry. My computer does not know what the public IP address is by looking at its interfaces.

In my experience, you have to be careful if relying on one IP source because if they give you the wrong one, then your servers could be MITM’d. I say this because I have a script which does this exact thing, and found a couple of these ‘what’s my ip’ services giving me someone else’s IP. Because of that, I randomly select a few IP addresses and ensure they are identical before I trust any of them.

So you have some junk VPS or whatever that just has caddy hosting its log with an easy to remember domain (they're cheap enough), and you go like "curl http://easydomain.com/idreallylikemyip" and then once more: curl http://easydomain.com/N | grep "idreallylikemyip"

the code that used to work is on my github, i uploaded it there a week or two ago. Someone who needs a way to find out the public ipv4 of any device not just their own can probably figure out how to get it to work again!

>

> sudo systemctl restart cron

Hello author, there's no need to restart cron, crontab -e applies changes automatically on exit. And the daemon is called "cron", not "cronjobs".

The main difference is that, for security reasons, it uses a "Cloudflare worker" to change the DNS record.

> Since Cloudflare API Token permissions aren't granular enough to limit the token access to a single DNS record, we place a worker in front of it (this way the token with extra priviledges never leaves cloudflare's servers).

It works very well, no complaints until now.

[1]: https://github.com/SenseUnit/rgap

Decentralization of the internet has to start with Authoritative DNS. I know it's not free to host an authoritative server like this on a VPS, and there are DDoS considerations. But the flip side is that DNS is a metadata protocol and contains a wealth of information that anybody privacy focused should think twice about. It's also an incredibly powerful and important protocol to understand.

[0] https://doc.powerdns.com/authoritative/http-api/index.html

Consider Cloudflare (and large scale infrastructure providers like TLD operators) point of view on the traffic: If your private resolver is using root hints, it's IP is now correlated with the lookup of that domain even if they don't proxy the website. That's you and your users, and they can do that at scale - So it's important to point queries for your assets directly to your authoritative servers or rewrite inline without ever querying a internet source.

dnsdist[0] (also PowerDNS) allows you to load balance and apply rules across upstream resolvers which opens up allot of possibilities on the recursive side.

Trusted resolvers with a healthy number of users originating iterative queries from non-descript and changing IP's is probably the best way to anonymize your recursive traffic.

[0] https://dnsdist.org/

It just sets the AAAA every 5 minutes via cloudflare's API and their CDN proxies it automatically for the ipv4 only clients. I leave the A record blank.

EDIT: Has to he this way because ipv4 is behind CGNAT on their network where ipv6 is fully routed public addresses. The home internet product is setup differently and you can't host stuff on it.

  old_ip=`cat ~/.prev_ip`
  my_ip=`ifconfig em0 | awk '/inet/ {print $2}' 2>&1`
  [email protected]

  if [ "$my_ip" != "$old_ip" ]; then
    echo $my_ip > ~/.prev_ip
    echo $my_ip | mail -r $my_email -s "New IP: $my_ip" $my_email
  fi

It’s also trivial if you run your own nsd/bind instance.

Same. Our wireline ISPs used to issue new public IPs every 1-12 weeks. Now it's more like 6 mos to never.

I'm thinking this is due to pressure from IPv4 exhaustion and the rise of easy DDNS. There's also an overall shift - from using tech to protect profit-generating services to using lobbyists.

To share an anecdote from the before times: I was once trying to setup a VPN endpoint on a client's DSL connection. Every time I initiated the connection, their public IP would change. The lease renewal was fairly quick and I could trigger 5 changes a minute.

I think I may be able to stitch something together with periodically reconfigured packet filters, but I'd appreciate an existing solution.

Bonus points if running on freebsd.

Also, if running a home server you’d want that 5min wait time brought down to something like 1 minute.

matthewatcloudflaredotcom

So what are the cases you may have read about. They fall into two big buckets:

1. Streaming Video

A video stream is just a series of image files strung together. So some people have tried to use our free service to serve video. This causes two problems. First, a second of video is often as much as 10x the bandwidth as a typical web page load. We’ve done a lot to make bandwidth costs low, but it can add up fast.

Second, the people who tend to do this sort of janky video streaming are often streaming pirated video content. When that happens and we don’t shut it down we get sued. That’s costly.

We do offer a service to stream video. It’s creatively named Stream. It’s elegant and not janky and designed to be the least costly way to stream video content. It’s cheap but it’s not free.

2. Illegal Content

The site that is in the link you referenced was serving a gambling site to a jurisdiction where gambling is illegal. The problem was, the jurisdiction retaliated by blocking their IPs. If that only blocked the one gambling site, that’s their problem. But we share IPs between customers on our low end plans. So if a customer does something illegal somewhere and it causes an IP to get blocked then it causes harm to a bunch of other customers.

The solution is dedicated IP addresses. In a case like this we have a product called BYOIP (which is exactly what you think it is). It’s bespoke and expensive for us to maintain and customers who care about it tend to be customers who have budgets to pay for it, so it’s expensive. We could probably invest engineering resources to make it less bespoke, but there’s really not a ton of demand.

This customer was doing something illegal somewhere according to some government. We said — no judgment — but you’re getting our IPs banned and causing harm to other customers and we can’t let that happen. We presented a solution (albeit an expensive one). They balked and wrote a blog post. And now people assume there’s a bait-and-switch sales strategy. There’s not. Turns out people who use our Free plan rarely turn into million dollar customers. And people who are million dollar customers don’t really even consider our Free plan. So the world generally sorts itself correctly.

We get stymied by our policy of not talking about the details of customers without their permission, so it makes it hard to respond to blog posts like that one. But enough people have asked me about it and I’m tired enough about it that I’m going to make the decision to revise the policy: we won’t publicly disclose any details about a customer without their permission; but if you write a blog post complaining about us and leave out the salient details, then we’ll reserve the right to fill those details in.

Anyway, in 99.99% of cases, and especially if you’re not janky streaming or doing something illegal, our Free plan will work great for you and you’ll never hear from anyone on our Sales team.

Cloudflare is only "free" for hosting websites; doing something like hosting just images or binary data and pushing hundreds of gigabytes or terabytes a month is likely to get your domain dropped from Cloudflare [0]. However, they do allow these non-website use cases (like hosting binary files, tons of images, etc) when using their third party products like R2 and/or Workers.

But, even with those stipulation, they do have a somewhat dubious sales tactic where, if you're pushing a lot of data, they:

- send you an email saying "you're using a lot of data"

- Have a line threatening you to "pay us to safeguard your website from potential suspension or restricted access"

- If you don't pay, you're in limbo on whether or not you're actually violating T&S and should make plans for being dropped by CF

Going over X0 TB/mo seems to be the threshold for getting put in this sales funnel, based on the few instances i've seen, but I can't confirm it. In some of these cases, the accounts survived, and in others they were dropped, so this isn't always a death sentence.

I would be incredibly grateful if Matthew Prince / eastdakota commented on this sales tactic, because it's obvious that some sales EVP at some point in time said "When Trust & Safety flags a customer for bandwidth reasons, we need to try to upsell them before T&S can review and make a determination for the account", which seems incredibly bad manners with how often CF speaks about their anti-"bandwidth rent seeking" philosophy[1].

0: https://community.cloudflare.com/t/the-way-you-handle-bandwi...

1: https://blog.cloudflare.com/aws-egregious-egress

Not only was it exactly what I expected from the title, there were 3 obvious but unimportant flaws in the "Ubuntu/Debian" setup section:

- a cron line that runs every 60 minutes is commented as running every 5

- unnecessary crond restart. Not just reload, which would already be redundant, but a full restart

- unnecessarily restrictive heading. There's nothing specific to Ubuntu/Debian in those instructions

I mean, it's a fine solution, like the 100s of others out there. I'm not trying to throw shade on the author; they've made something a little more flexible than most one-offs, without going overboard like the ones that handle dozens of different services. But... why the front page? Why the upvotes? Can't you kids just stay off of the damn lawn?!

I have 3 domains there for years and I haven't paid them once.

Some time ago they started requiring that I mark the domains active each month. I wrote a script that intercepts that email and logs into their site to reup the domains. Recently that script broke and I haven't bothered to fix it because logging in once a month is a nothing burger.