I've been following Bunny (BunnyCDN/Bunny.net) for a while and love what they are doing. Couple of suggestions:<p>• Every code snippet should be copy/pasteable (and work well), that article might be the entry point to what many are doing.<p>• I have this feeling this is following Cloudflare's Workers style of `addEventListener('fetch', eventHandler);`. I need to write a 500-word essay on that, but the short version is that I strongly believe that it'd be way better for their clients if the client could just do `export default async function handleDns(event) { ... }` instead of having a global (what?) context where there's a function unattached called `addEventListener` and you need to know it's for `"dns"` (is there even other possibility here?) and that the respondWith() only accepts a promise, which is not common (it's more common to accept an async fn which then becomes a promise). Compare these two snippets, current and with my small proposal:<p><pre><code> // Current API:
addEventListener('dns', event => {
event.respondWith(handleRequest(event.request));
});
function handleRequest(request) {
return new TxtRecord('Hello world!, 30);
}
vs
// Potential/suggested API:
export default function handleDns(event) {
return new TxtRecord('Hello world!, 30);
}
</code></pre>
This way it's easier to write, to reason about, to test, etc. It's all advantages from the client point of view, and I understand it's slightly more code from Bunny's point of view but it could be done fairly trivially on Bunny's end; they could just wrap the default export with this code on their infra level, simplifying and making dev lives a lot easier:<p><pre><code> // Wrapper.js
import handler from './user-fn.js';
addEventListener('dns', event => {
if (typeof handler === 'function') {
event.respondWith(handler(event));
} else {
// Could support other basic types here, like
// exporting a plain TxtRecord('Hello', 30);
throw new Error('Only handler functions supported now');
}
});</code></pre>
We serve thousands of custom domains for our SaaS customers.<p>The end users of these domains are globally distributed and served from 14 different data centre locations across the world.<p>To do the geo IP matching we tried a lot of things, third party services etc but couldn't find one that works well and are priced well.<p>For example, the hosted DNS service we use also have a IP based filter chain feature but are priced around $22 per domain per month as add-on.<p>At the end, we built a anycast based solution that was very painful to setup but works fine now and can use a single A record that works across the world. We had a get a ASN, a /24 block and hell lot of back n forth with a government run org to set it up.<p>A "hosted" scriptable DNS server which takes the location as input and output IP of nearest edge server as output is the exact thing I needed. So yes there is definitely a niche market for it.<p>I still have to explore and see how closely bunnydns is able to get the source IP/location (tricky) and how does health check etc could work but definitely something I would explore and consider.
They had me at the combination of the words "scriptable" and "DNS." My monkey brain is susceptible to that clever trick.<p>I'm struggling to see what this could be used for, but the comments here help.<p>In summary:<p><pre><code> - an alternative to anycast.
- an alternative to routing inside your app (your app could detect the IP, and have different behavior based on rules internally). This means you are always going to the same origin, which scriptable DNS would prevent, you could put things at the edge and reduce hops.
</code></pre>
Why else would you use this?
Well dang, that's what I get for taking too long to implement my idea :-D<p>Seriously this is great. I started building a "scriptable DNS" to make it easy to have a DNS record that always points at the valid K8s nodes in my cluster (and randomizes the order of the IPs each time). Since nodes can come and go very quickly (especially during an upgrade), and their IP changes every time, it's useful to be able to act dynamically.<p>This is most assuredly better than what I was building though. Mine is rust-based but the "script language" is a very simple DSL. I considered allowing docker containers that receive some command arguments and must write the answer to standard out, but that felt like a brittle interface and I worried about performance (even with offering a cache). I also considered writing it in Elixir and allowing elixir code snippets, but I got scared of how hard it would be to secure that.<p>Anyway really neat idea! I hope to see more innovations and implementations!
Like the idea. But…<p>1) Claim privacy first and then have a cookie banner.<p>2) Say “routing” when you mean location/IP based DNS.<p>3) Is that a loosely typed language in the scripting engine? Not sure I would want DNS queries to be relying on that.<p>I am sure there is still some innovation left in DNS. SDDNS I’d call it: Software defined DNS. Especially with the splinternet we are walking into these days. Just don’t think this version cuts it. Nevertheless an interesting company to follow. I see potential.
Oh ffs, why does TFA refer to this as "internet routing"?? This is HTTP routing, or "web routing" if you want, but "internet routing" is something else entirely -- think BGP and OSPF. Is this a thing now, to refer to HTTP routing as "internet routing"?
Well this is embarrassing: <a href="https://imgur.com/a/VoG4N3X" rel="nofollow">https://imgur.com/a/VoG4N3X</a><p>Also routing and DNS are different things. Misunderstanding what routing is while trying to sell your technology to technologists is likely not a winning strategy.
Another mature option with Lua scripting is LuaDNS[1]<p>[1]: <a href="http://www.luadns.com/" rel="nofollow">http://www.luadns.com/</a>
For people who want to understand, learn about, or stay on top of their, DNS check out dug. Its a cli tool I made to help visualize DNS propagation but is a great learning tool.<p><a href="https://github.com/unfrl/dug" rel="nofollow">https://github.com/unfrl/dug</a><p><a href="https://dug.unfrl.com" rel="nofollow">https://dug.unfrl.com</a>
Somewhat related (and shameless plug), I coded a Lua-scriptable (Javascript planned) DNS server a while ago[0]. I'm using it in a few low traffic domains, but the code needs some additional love :-)<p>[0] <a href="https://github.com/luismedel/redns" rel="nofollow">https://github.com/luismedel/redns</a>
Does location-based DNS even have a future? fly.io doesn't seem to think so: <a href="https://fly.io/blog/the-5-hour-content-delivery-network/" rel="nofollow">https://fly.io/blog/the-5-hour-content-delivery-network/</a>
One of the things that would be nice is if this would mean that Bunny's Let's Encrypt support would do wildcard certs. Right now, because Bunny doesn't control the DNS, they can't create wildcard certs. I know this is mostly about the scriptable DNS, but it is also an announcement that they're entering DNS more generally.
Surprised by all the negativity and dismissiveness in the comments.<p>Bunny in general has been a positive experience for me so looking forward to trying this<p>Not so sure about the per million pricing on scriptable dns queries. Isn’t it quite easy to generate billions of dns queries? ie I hope there is some sort of ddos mitigation in front of that
This is very clever, and something I wished existed inside of AWS/Route53. It would greatly simplify some of the work needed for redundancy/resilience. Something similar as a locally-deployable "unbound/dnsmasq style" component would be neat as well.
there is so much wrong with this site i thought it was april 1st.<p>i thought it's been proven that geo-ip data is not reliable?<p>second.. DNS is not routing.
Looks a bit like the PowerDNS LUA records <a href="https://doc.powerdns.com/authoritative/lua-records/index.html" rel="nofollow">https://doc.powerdns.com/authoritative/lua-records/index.htm...</a> but with JavaScript and shinier GUI?