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.
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.
I setup some Cloudflare DNS records to the tail scale 100.x IPs to make them easy to remember.
Dynamic DNS is literally one little service you run to "phone home" to the dynamic DNS provider. This service is bundled in consumer routers; just find it in the WebUI, put in the credentials and turn it on.
You know what could be simple: a periodic job that figures out your public IP address, and if it has changed, generates a hosts file entry for it, and e-mails it to you. If all you care about is just you having access to home while you are roaming about, that could do it. It also occurs to me that it makes a good backup strategy in case something goes wrong with DDNS while you are traveling.
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.
Will this work if the "home services" include authoritative DNS.
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.
ddclient already works with Cloudflare: https://developers.cloudflare.com/dns/manage-dns-records/how...
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.
It also runs AdGuard Home so that is another thing I have been able to remove from my home server.
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.
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.
Is there any Cloudflare service one can use to determine the IP instead? That way there’s not an extra company in addition to Cloudflare itself that you need to continue existing.
[0]: https://www.icanhazip.com/ [1]: https://major.io/p/a-new-future-for-icanhazip/
Pick your poison as you wish - either is great! :-)
current_ip=$(curl -s -X GET https://1.1.1.1/cdn-cgi/trace | grep -Po "(?<=ip=)(.*)")Example: https://www.fullspectrum.dev/a-less-suspect-way-to-get-exter...
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!
Similar things are also possible with nginx and Apache.
And they offer a similar service on their DNS resolver over IPv6.
This page lists the IPv6 addresses to use when connecting to their resolver over IPv6
https://developers.cloudflare.com/1.1.1.1/ip-addresses/
and with that I just tried
dig @2606:4700:4700::1111 ch txt whoami.cloudflare +short
And it works, returning the IPv6 address that the request came from :)>
> 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.
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.
[1] - https://openwrt.org/packages/pkgdata/ddns-scripts-cloudflare
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.
ipv4.bbs.land
ipv6.bbs.landGoLang: https://github.com/wyattjoh/cloudflare-ddns
C#: https://github.com/nick-funk/dyn-dns
Mine is more barebones since I threw it together quickly in an afternoon. I feel like many a HomeLab person fighting their ISP is taking advantage of this Cloudflare API trick
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`
my_email=me@example.com
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
fiSame. 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.
It’s also trivial if you run your own nsd/bind instance.
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.
I'd probably prefer doing this at lower layers like pf, since I know how to reload those configs via cron, and since I want to avoid unwanted or malicious packets to even make it to the syslog code.
I was just surprised to find no recipe online, it's apparently more of a niche case than I thought. Worth documenting, probably.
Also, if running a home server you’d want that 5min wait time brought down to something like 1 minute.
https://github.com/favonia/cloudflare-ddns
It's cache friendly and respectful of rate limits
I was researching whether it's worth it to switch my pet project to Cloudflare's various offerings (D2, Workers) instead of AWS/GCP, since Cloudflare has a very generous free tier.
But from quick googling (I think it's Reddit), some people said Cloudflare uses bait-and-switch where at some point you will need certain features that are only available in enterprise plan or something, basically significant cost increase.
Should I be concerned?
EDIT: I want to make it clear that I'm talking about significant cost increase, something that will catch many people by surprise.
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...
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.