Yup, it’s that time of year again. The time of year for sweeping declarations about how technology is changing and you better change with it or get left behind.
But we’re not going to bore you with the typical end of year nonsense. You already know what’s getting phased out, you’ve heard about what’s coming. You don’t need someone to summarize a year of fads.
So here’s something different… We rifled through a year of support tickets and pulled together the most interesting ways people are using Constellix to solve their network head-scratchers.
Open Source CDN
First up, we have Sebastiaan who used Constellix to turn up a new PoP (point of presence) for his open-sourced CDN service.
The GeoDNS configuration, using Constellix, now routes all traffic from visitors in Malaysia to the Kuala Lumpur PoP, with the two pre-existing Singapore PoPs as failover.
He used IP Filters, which are a type of GeoDNS rule, that funnel traffic that meets certain criteria to a specified IP address. In this case, he created an IP Filter for the country of Malaysia and applied it to a record that pointed to his Kuala Lumpur PoP.
In the same record, he enabled DNS Failover and set two backup IP addresses that will only be used in the event that the Kuala Lumpur PoP is unavailable.
Pretty cool, right? You can use this same configuration if you built your own CDN, manage traffic flow to microservices, and so much more…
The ANAME Problem
A few months later Sebastiaan came to us with a challenge. He noticed that when you combine ANAME records with IP Filters, the filter uses the EDNS subnet of our ANAME resolver… rather than the EDNS subnet of his end-users.
ANAME records are tricky because they aren’t like other record types. They require the use of an additional resolving nameserver. When a client makes a request, the authoritative nameserver (Constellix) finds the ANAME record, then makes a request to the ANAME resolver which returns the corresponding IP address.
The ANAME resolver bases its responses on the EDNS subnet of the Constellix nameserver that made the request, NOT the subnet of the end-user.
So we developed a way to pass the EDNS subnet of the querying client to the ANAME resolver. Now if you use IP Filters with ANAME records, the ANAME resolver will make its decision based on the user’s information.
More Monitoring Intervals
Speaking of user requests, one of our enterprise clients requested that we add more monitoring intervals to health checks.
At the time, we offered options for 30 seconds, a minute, five minutes, ten minutes, and so on… Which left anyone that needed anything between a minute and five minutes %$#* out of luck.
Alas, our developers came to the rescue and added monitoring intervals for two, three, and four minutes.
That also means that you can create failover configurations that will update as often as two, three, or four minutes.
ISP Failover
Failover is easily one of our most popular services, reeling in dozens of interesting use cases every year. Our favorite this year went to a client that uses failover to manage traffic flow between two ISP’s (Internet Service Providers).
Both ISP’s are connected to a single server in a data center, but only one provider is used about 99% of the time. The second provider is only used if the primary is unavailable.
Instead of using a hardware load balancer, he thought to use DNS failover. This way he didn’t have to code anything himself, or shell out any upfront costs to install hardware.
API Power User
Quick shout out to our hosting pros who use Constellix as their DNS services!! Over the last year, we’ve heard from a few of our super users who use our API with their own UI.
That way their hosting clients can make quick changes to their own DNS configurations without having to switch to a different control panel.
