DNS can be confusing in its own right and when you start to unlock truly advanced DNS capabilities with NS1, there are even more concepts to wrap your head around. We've built out a glossary that includes some of the more commonly used industry terms.
DNS is the Domain Name System. Very simply, the DNS is an internet-wide distributed system responsible for translating domain names (like "yourdomain.com") into server addresses or other service related information. Think of the DNS as a big, distributed phone book. Say you know a domain name -- you use the DNS to look up a server address, a mail host, or other information about that domain much like you'd look up someone's phone number in an index of names. So, for example, when you type "ns1.com" into your web browser, the browser uses the DNS to find our web servers to show you the right content.
Traditionally, DNS is mostly static. The content associated with a DNS record is stored in a database, and returned on demand. Advanced DNS services like NS1 can do traditional, static DNS of course, but add intelligent software that can make decisions in real time about the answers to give back for a query. For example, NS1's platform can determine the location of someone asking for "yourdomain.com" and pick the web server closest to them ("geotargeting"). There are many ways of making dynamic decisions about how to answer DNS queries. With NS1's Filter Chain, the sky's the limit.
Data Driven DNS
NS1's intelligent platform goes beyond even "advanced" DNS and introduces a new paradigm: Data Driven DNS. NS1's Data Driven DNS takes in real time feeds of data about your infrastructure -- like server upness, load, response times, application metrics, and so on -- and feeds them to our traffic management algorithms to adjust DNS responses on the fly. No other DNS provider on the planet is as tightly coupled to your application.
A DNS zone is simply a domain name (like yourdomain.com) and all subdomains associated with it (like www.yourdomain.com). In the DNS, you delegate "authority" for a zone to a DNS provider like NS1, which then serves as the database of record when lookups are done for information in your zone. You can also think of a zone as a collection of related DNS records.
A DNS record is the basic unit of information in the DNS. A record is identified by a domain name (like www.yourdomain.com), a type (like A, AAAA, MX, NS, and so on) indicating the type of information contained in the record, some control information like DNS cache time-to-live (TTL), and "answer" data like server IPs, mail hosts, etc, depending on the record type.
An answer is the data associated with a DNS record that is the subject of a DNS query. Unlike traditional DNS software, NS1 treats answers as entities on their own, with all "potential" answers for a DNS record grouped under that record. This enables us to make complex decisions about which answers to return for a given record when we get a query for the record.
Within a DNS record in NS1's platform, you can group answers into "regions". Often these regions are geographical in nature -- for example, you might lump all your West coast servers into one region, and all your East coast servers into a different one. But you can think of regions as general groupings of related servers that need not be geographical.
Metadata about records, regions, and individual answers is the driver behind NS1's most advanced Data Driven DNS technologies. Think of metadata as bits of information that can be used to make decisions about how to respond to a DNS query. For example, if you have an answer for a record that corresponds to a server in New York, you might attach metadata to it indicating if it's up or not; that it's in the "US-EAST" region; and so on.You can attach metadata to individual answers, to regions, and to records. Metadata is identified by simple field names (like "up", "georegion", "weight", etc). If a metadata field is specified in a record's metadata "table", it applies to all answers in the record. If a field is specified in a region's metadata table, it supersedes the record-wide metadata field for all answers in that region. And, if a field is specified in an answer's metadata table, it supersedes both record-wide and region-wide metadata fields with the same name.So, for example, if you've got 3 servers in New York, you might group them into a single region and set a "georegion" metadata field with the value "US-EAST" in the region's metadata table. All 3 servers now effectively have that metadata. If one of the servers is down, you might set the "up" metadata field for the corresponding answer to "0" -- this applies only to that answer.
NS1's Filter Chain is our powerful traffic management technology. Think of the Filter Chain as a sequence of simple "filters" that take in the full list of potential answers to a query, and each do simple actions on the list in turn. Whatever pops out the end of the Filter Chain is the final set of answers returned to the requester.Each filter in the filter chain generally examines metadata about the answers to make some kind of decision. For example, NS1's UP filter examines the "up" metadata field and discards answers that aren't marked up, passing the remaining answers along to the next filter in the chain.NS1 supports a large and ever-growing list of traffic management filters that you can mix and match to build a Filter Chain perfectly suited to your application.
Data Sources are the workhorses behind NS1's powerful Data Driven DNS. NS1 supports many different kinds of Data Sources -- from widely used monitoring services to our own native NS1 API. Think of a single Data Source like an account for the associated service, that you're connecting to NS1. For example, if you create an Amazon Cloudwatch Data Source, it corresponds to your AWS account; you could also create a second Cloudwatch Data Source if you have a different AWS account to connect to NS1.
Data Feeds come from Data Sources and can be thought of like "topics". For example, if you have connected a Cloudwatch Data Source, you might create several Data Feeds from that source corresponding to different Cloudwatch monitors. Data Feeds are generally identified by service-specific details like monitor or health check ids, unique labels, etc. Each Data Feed generates metadata updates specific to its "topic". For example, a Data Feed from a Cloudwatch monitor may update "up" metadata depending on the status of the monitor.A Data Feed, once it is created, can be connected to one or more metadata tables in any of your DNS records. It is perfectly normal to connect a single Data Feed to many different metadata tables -- in fact, this can be incredibly powerful. For example, if you have a shared web server hosting several sites, you may have an answer corresponding to that server in the DNS records for all the sites. Connecting a monitoring Data Feed to those answers (and configuring appropriate filters) means they will all failover instantly when the monitor trips.
In addition to our API and native integrations, we offer monitoring jobs run over ICMP or TCP from up to five locations across the globe. Our built in monitoring capabilities provide a quick and easy way to detect a down server and, because it’s fully integrated with out Filter Chain technology, the ability to reroute traffic based upon real time infrastructure telemetry. For more information on Monitoring please visit this knowledge base article.
Global Server Load Balancing (GSLB)
Suppose you, a content provider or application developer, have servers in several datacenters around the planet. You want to direct your users to the server that will give them the best experience. How you define "best" is up to you -- often, "best" means some mix of lowest latency, highest performance, etc. The process by which traffic is directed to your servers is Global Server Load Balancing, or GSLB. NS1's platform enables you to do GSLB in myriad ways, informed by real time metrics about your infrastructure and application.
Failover / Disaster Recovery (DR)
Failover is the process of shifting traffic away from "failed" or "down" servers to healthy ones. In general, failover is a key component of a Disaster Recovery (DR) plan. In a disaster scenario (your primary datacenter was just carried away by a tornado, for example), you need the ability to shift your traffic to a DR facility instantly. NS1's platform seamlessly manages this transition, and can be signaled by many popular monitoring tools and services or by your application directly to enact a failover (or "failback" when things get back to normal).
Fundamentally, geotargeting is about picking DNS answers based on geographical information -- about the requester, your servers, and so on. A common scenario is to direct a user to the server closest to them. Usually, geotargeting is a pretty good approximation for "pick the lowest latency server for this user". NS1 supports geotargeting based on coarse regions ("send users in the Eastern US to Server A, and in the Western US to Server B"), based on latitude/longitude and precise geographical proximity, and based on countries/states/provinces.
Geofencing "fences" certain answers depending on the geographical location of the requester. For example, you may want to direct users in China to a local CDN, and users everywhere else in the world to a different CDN. This is subtly different than geotargeting, which just picks the "closest" answers. NS1 supports geofencing based on coarse regions or based on countries/states/provinces.
Some servers are beefier than others. For example, maybe you have a primary deployment of bare metal servers in colocation in your main data center, and a secondary "fallback" of auto-scaled cloud servers for overflow traffic. Maybe you want to send 90% of your traffic to your primary facility, and 10% to the cloud. NS1 supports weighting schemes like this -- and lets you adjust weights on the fly through our portal and API to shift traffic truly dynamically.
Some applications are more "stateful" than others. Stateful applications require the same user to visit the same server consistently instead of balancing requests across multiple servers. NS1 supports "stickiness" -- always give the same answers to a given requester.