Excuse me if I’ve simply failed to spot this in Cloudflare’s documentation or detailed via the community.
Just as Cloudflare can be used to ‘sit’ in front of your website and cache it I’d like to do the same with our DNS records. Due to us using a slightly less common DNS record type, namely CERT (which I notice Cloudflare supports), we host our DNS servers.
For some time I’ve been considering, as is detailed in this digitalocean tutorial, setting up a BIND forwarding / caching DNS server - https://www.digitalocean.com/community/tutorials/how-to-configure-bind-as-a-caching-or-forwarding-dns-server-on-ubuntu-14-04. As the DNS servers we currently host are Java based apps and so they’re no where near as performant as something like BIND. But ultimately it’d be convenient if either far fewer or even none of the DNS queries ever actually reach us which is where I think Cloudflare is well suited.
As Cloudflare offers API’s an alternate approach would be to use their APIs to push out the DNS records we want made public but I’d prefer the forwarding DNS approach as it’d mean one less thing to build and then monitor as the DNS records are far from static. Automated processes are adding and deleting records every few days as the digital certificates published via CERT DNS record type expire.
You seem to have some confusion between recursive and authoritative DNS. The caching and forwarding referenced in your Digital Ocean article applies to DNS revolvers. Publishing records for your domain is handled by authoritative DNS. There is no forwarding in authoritative DNS.
If you want to use Cloudflare for your authoritative DNS, you will want to look into updating your automations to use the Cloudflare API. This will require your DNS to be hosted on Cloudflare. If you are a project with a larger budget, you could explore Enterprise-only features that would allow you to run your secondary servers on Cloudflare.
Hi, there quite likely confusion on my end… usually is the case.
We host our own authoritative DNS servers due to the odd CERT records as many DNS providers simply don’t support them. From my read of the digital ocean tutorial the forwarding DNS server seems exactly what we’d want to take load off our backend less performant DNS servers.
I’ve quite likely phrased my question poorly or at the very least oddly as I’d be the last to say I’m a DNS expert.
In terms of what it would look like publicly to the world as the authoritative name servers for the domains we host, yes it would look like Cloudflare hosts the authoritative name servers just as is done when you place Cloudflare in front of your website so www.example.com resolves to Cloudflare instead of wherever you decide to have your site hosted. Wherever your website is actually hosted is still hit with requests but it’s far less frequent.
So I’m looking for a similar solution but with DNS, typically it shouldn’t be necessary as ideally everyone just queries their local DNS server which shouldn’t be needing to update it’s cache until the TTL expires. Unfortunately at least one if not more unidentified customers of ours seem to wanting to query our DNS servers either every time they need to interact with us or at the very least query us multiple times a minute.
Without getting into too much detail, trying to identify and contact the customer(s) isn’t so straight forward as they appear to be using dynamically assigned public IPs by - I’ll let you guess which global cloud hosting provider.
While using Cloudflare’s API to push out and maintain DNS records is certainly an option I’d prefer to avoid it as it’d end up meaning there’s two sources of truth in that we need to maintain the internal records as that’s where the public and private key pairs are maintained but we’d then need a separate record in Cloudflare of all the public keys that can be retrieve by a DNS CERT record query… while it is certainly possible and doable it’s always nice to just rely on an existing service that automatically updates it’s cache instead of needing to write your data replication along with the monitoring to ensure when something fails to be replicated to alert a human.
I should have probably explicitly called it out that the I wouldn’t be precisely following the details mentioned in the digital ocean tutorial. I was instead using it as the basis for what I’m planning & putting in place. I’m in a sense doing the opposite of what the tutorial explains, instead of a proxy I’m putting in place a reverse proxy.
For now I’ve got the following configured to test out the ‘mechanics’ of it and commands like dig @127.0.0.1 are successfully resulting in BIND forwarding the initial query on to the backend DNS server and then all subsequent queries are responded to from BIND’s cache until the TTL expires.
So while Cloudflare would still be good to avoid queries ever reaching us with any luck this ought to give us enough breathing room to avoid the barrage of queries being an issue any time soon and like you’ve said avoids jumping up to an Cloudflare enterprise plan before we need it.
Cheers
options {
listen-on port 53 { 127.0.0.1; };
directory "/var/named";
dump-file "/var/named/data/cache_dump.db";
statistics-file "/var/named/data/named_stats.txt";
memstatistics-file "/var/named/data/named_mem_stats.txt";
recursing-file "/var/named/data/named.recursing";
secroots-file "/var/named/data/named.secroots";
allow-query { localhost; };
recursion yes;
dnssec-enable yes;
dnssec-validation yes;
/* Path to ISC DLV key */
bindkeys-file "/etc/named.root.key";
managed-keys-directory "/var/named/dynamic";
pid-file "/run/named/named.pid";
session-keyfile "/run/named/session.key";
forwarders {
**<ip of backend dns server>** port **<port of backend dns server>**;
};
forward only;
};
Ok, finally see what I wasn’t aware of. BIND configured as a forwarder won’t pass through the authority section of a DNS response from an authoritative DNS server… so I’ve now moved on to dnsdist, exactly what’s needed.