The video provides a comprehensive explanation of primary and secondary DNS systems. It discusses the fundamental concept of DNS, which serves as a system for translating domain names like IBM.com into IP addresses, enabling computers to locate and access websites. The video outlines the role of a DNS resolver and the authoritative name server in this translation process, showing how these elements interact to ensure users can access desired internet destinations.

A detailed comparison between primary and secondary DNS is presented, highlighting that primary DNS is where DNS configurations are initially made by administrators, while secondary DNS copies these configurations automatically to provide backup and resiliency. This is crucial for maintaining service availability if a primary DNS server goes down. Techniques such as SOA records, and protocols like AXFR/IXFR for copying data are explained as essential for keeping the DNS configurations synchronized across multiple servers.

Main takeaways from the video:

Please remember to turn on the CC button to view the subtitles.

Key Vocabularies and Common Phrases:

1. resiliency [rɪˈzɪljənsi] - (noun) - The capacity to recover quickly from difficulties and maintain functionality. - Synonyms: (recovery, toughness, robustness)

Everything's great, right? Well, now I want to build in some resiliency so what happens? So that if NS one dot IBM

2. zone [zoʊn] - (noun) - In the context of DNS, it refers to a distinct part of the domain namespace managed by a specific DNS server. - Synonyms: (domain area, section, partition)

And I'm going to this is for the zone, IBM

3. nameserver [ˈneɪmˌsɜːrvər] - (noun) - A type of server that implements a network service for providing responses to DNS queries against a directory service. - Synonyms: (DNS server, domain server, internet server)

We'll say this nameserver is ns one dot IBM

4. replication [ˌrɛplɪˈkeɪʃən] - (noun) - The action or process of copying or reproducing something. - Synonyms: (duplication, copying, reproduction)

And they're both exact copies of each other because we've used this protocol that I'm going to describe in a second to make a copy of NS one to the NS two server.

5. protocol [ˈproʊtəˌkɔl] - (noun) - A set of rules governing the exchange or transmission of data between devices. - Synonyms: (convention, procedure, system)

The protocol and processes like AXFR/IXFR are vital in ensuring DNS records are consistent across servers.

6. delegation [ˌdɛlɪˈɡeɪʃən] - (noun) - The act of sending or establishing a representation or authority to do something on one’s behalf. - Synonyms: (authorization, assignment, transfer)

It's usually called delegation. I go to my registrar where I bought the domain name and I configure the name servers.

7. traffic steering [ˈtræfɪk ˈstɪrɪŋ] - (noun phrase) - A process or technique used to direct network traffic or requests to different servers or endpoints, usually based on certain criteria like location or load. - Synonyms: (routing, directioning, load balancing)

The biggest, primary and secondary, the biggest drawback is that advanced features are not supported and probably the biggest advanced feature you'll run into is global server load balancing or traffic steering

8. redundancy [rɪˈdʌndənsi] - (noun) - The duplication of critical components of a system to increase reliability. - Synonyms: (backup, duplication, surplus)

And so we have redundancy. So if either of these servers breaks then the other server is still available

9. notify [ˈnoʊtɪˌfaɪ] - (verb) - To give notice or inform someone. - Synonyms: (inform, alert, announce)

What will happen here is when you make a change on the primary server, it will actually send via UDP a notify message to the secondary.

10. configuration [ˌkənˌfɪɡjʊˈreɪʃn] - (noun) - An arrangement or set-up of elements in a particular form, figure, or combination. - Synonyms: (settings, setup, arrangement)

Primary DNS is the configuration origin point.

Primary and Secondary DNS - A Complete Guide

Today we're going to be talking about secondary versus primary DNS. We'll be covering what they are, why they're different and how you would use one or the other. So to start, I'm going to do a brief review of DNS, what it is and how it works.

So if you recall, if I have a user on the Internet and he wants to access IBM.com, his computer is going to use the DNS system to look up the IP address. What will happen is his computer will talk to a DNS resolver out on the Internet. The resolver will know how to navigate the DNS system. It will make its way to an authoritative name server which will have the IP address for www.IBM.com. it will send it back, send that IP address back to the user. And now my user can actually make his way to the IBM website and he can browse and see all of our products and services. Life is good.

But now you're the administrator and your job is to set up the DNS so that this user can make it to IBM.com. and you want to do it in such a way that it's resilient and ensures that if a server is down, the user can still make it to IBM.com dot. So what I'm going to do as an administrator is I'm going to go to my name server. We'll say this nameserver is ns one dot IBM.com common name for a name server. And I'm going to this is for the zone, IBM.com. and I'm going to set up the records in my zone. So I might have the record for www. It's going to be an a record and the IP address is nine dot nine dot nine dot one. And then it's going to have a name server record for IBM.com which is going to point at NS one IBM. And then I might also have a mail record for the name mail. It'll be an Mx record and it'll be mail dot IBM.com and so on and so forth.

I'll fill out my zone. So now that I have this set, when I first set this up, when my user goes to the Internet, he'll use the DNS service, he'll get to my server, ns one dot IBM.com. it will do a lookup, find that the IP address is nine dot nine dot nine dot one. Return it to the user. They'll make it to the IBM.com website. Everything's great, right? Well, now I want to build in some resiliency so what happens? So that if NS one dot IBM.com ever goes down, I'll have a backup.

And to do that I'm going to set up a second server with a complete copy of this same zone, only going to call that server, oops. I'm going to call that server ns two dot IBM.com. and I'm going to make a full copy of everything that's in there. So I'm going to create, I'm just not going to create the wWW record, the a record. I'm going to create the NS record and I'm going to create the Mx record. So it's a full copy of everything that I originally configured on the NS one dot IBM.com zone. We'll make a copy in the ns two dot IBM.com zone.

Now you could imagine, now I want to make a third copy and I could go and make a third copy of this. If I do it manually, that's a pain in the butt. And there's going to be a delay between me going in and configuring the first server to the second server to the third server. And so I need a way to do this automatically. And that's where primary versus secondary DNS comes in. So if I imagine here's my server, ns one dot IBM.com, and I've got my user here, put my user down here and my user is interacting with this server and filling in all the details.

So I figure and fill in my www record and so on and so forth. I'm interacting with this server. Now I want to set up my second server, ns two dot IBM.com dot. And I want to set, I want to make it so that ns two IBM.com automatically gets a copy of whatever I do in NS one dot IBM.com. so I want to be able to copy the records over.

This one is known as the primary because that's where I'm doing the configuration. And this one is known as the secondary because that's getting the copy, it's a second copy. And I'll dig into the details of how this interaction works in a second. But just to bring it back to users on the Internet, now on the Internet, I've got two name servers here. I've got ns one and ns two. And when a user on the Internet does his DNS lookup for www.IBM.com, he can come, the DNS can either get the answer from NS one, we're NS two. And they're both exact copies of each other because we've used this protocol that I'm going to describe in a second to make a copy of NS one to the NS two server. And so we have redundancy. So if either of these servers breaks then the other server is still available and I can replicate this multiple times.

So I could have five such servers, ten such servers on the Internet, all of them copies of NS one because there's only one primary. The primary is where I interact as an administrator where I make all the changes and all the other servers are copies of the primary. So now let's talk a minute about how does the copying actually work. The copying starts from the secondary server and there's another record type which, which I haven't drawn in yet, which I'm going to draw in now. It's something called the SOA record which stands for start of authority. It has a number of parameters in it related to the zone. But the most important one for this purpose is known as the serial number. And the SOA serial number can be any number. A lot of people use dates.

Some people use just integers that are increasing. For the purpose of this talk I'm just going to use an integer. So I'm going to say it starts at SOA one. The copy that I make is also going to be SOA one. Now let's say I make a change to the primary name server and I want to have it transfer over to the secondary. So what's going to happen? Let's say I add another a record in here. So I add nine dot, nine dot, 10 one.

I've added another server for my application and I want to get that to copy over to the secondary. What's going to happen when I made that change is the so is going to change to two. So this nameserver ns two, periodically, maybe every ten minutes, every 30 minutes or so forth is going to make a request over here and say what's your soa, what's your start of authority number? nameserver one is going to say, oh, it's two. Now nameserver two is going to go, oh, I still had soa one, so you must have done some kind of an update. So now nameserver two is going to make a request and it's called an AXFR or IXFR request. And then nameserver one is going to send back the information so that nameserver two gets properly updated. And so this will go to two and I'll get the second a record in here with the right information.

And now they're in sync. So now periodically as I said the nameserver two will do this. So a check. If it comes back the same, it's going to keep coming back two because I haven't made any changes to nameserver one and nothing will happen. As soon as I go and make a change to nameserver one and I update this to three. Now then I've got to do this transfer, the Axfr ixfr transfer, which I'll describe in just a second. And that way these two stay in sync and my user is happy because every time he goes to findibm.com comma, he can talk to either server and get the right answer.

So there's a problem with this approach, which is that when I make a change on the primary, I have to wait till the secondary, all the secondaries get around to talking to the primary and pulling back the change. So there was an addition to the protocol made a few years after it was originated called notify. What will happen here is when you make a change on the primary server, it will actually send via UDP a notify message to the secondary, and that will kick off all this stuff up above. So the notify, I make the change, I send the notify to the secondary, the secondary does a. So a check, finds out, yeah, you really did make a change. And then it will institute the AXfR transfer and get a new copy of the zone.

And that way the two servers say very closely in sync so that all my users when they're on the Internet can go to either server and they'll get completely updated information wherever they are. And I have the benefit that if one of these servers crashes and dies, ns two goes offline, NS one server is still operational and working. And again, in the real world, you wouldn't just have two servers, you probably have ten servers or 20 servers or 30 servers, and you would use this method to copy the zone to all of those servers.

One misconception I often hear about DNS is that when thinking about primary versus secondary, that it is visible to the users on the Internet. It's not, as you saw in this example, the primary and secondary servers have exactly the same copy of the zone. And so to the users on the Internet, they looked identical, they have the same information. There's no way to know which is primary and which is secondary. The only meaning of primary versus secondary is to me, the administrator. The primary server is the one where I make all the changes, and the secondary servers are where all those copies are, the servers that get copies from the primary.

So again, primary is what I interact with as an administrator either through a portal or an API. Secondary gets copies automatically from the primary, totally invisible to everyone on the Internet and it's active, active all the time.

Once you set this up and you delegate your name servers such that they're available and visible on the Internet, then this just works. It brings up another topic I should mention which is delegation. Once I've set up these copies I have to tell the world that all these copies existed. I go to my registrar and this is an act called, it's usually called delegation. I go to my registrar where I bought the domain name and I configure the name servers and I'll set up a record and I'll say I have to change my zone file and I'll say I added another nameserver. I added ns two dot IBM.com. i have to go up to my registrar through the delegation process and tell it that IBM.com is now served by not just one nameserver but two nameservers, ns one dot IBM.com and an s two dot IBM.com and so on and so forth.

So if I had ten nameservers, I have to put all ten name servers in the zone file and go tell my registrar that I want to delegate my zone to all ten of those name servers. And in that way users on the Internet can find all ten of these things, all ten of these name servers or however many I have.

So that's how I this is probably the most common way to achieve reliability through redundancy on the Internet. But there are some drawbacks to primary versus secondary. The biggest, primary and secondary, the biggest drawback is that advanced features are not supported and probably the biggest advanced feature you'll run into is global server load balancing or traffic steering. As you may recall, global server load balancing is where you can direct users to the server located closest to them.

So if I've got the Internet out here and I've got my application servers in say New York City, in London and San Francisco, and I want to direct my users to the location closest to them. So my users in the east coast of the US go to New York, users in Europe, you go to London and so on and so forth. I need to use this feature called global server load balancing or traffic steering, which we have another video on.

But the crux of it is that it's a special feature of DNS that directs the user to the right server based on their location. That feature is proprietary to most vendors and to most systems and it can't be transferred over XFR. So if I go to my primary server and I set up these great features to enable global server load balancing to really supercharge my application, that all works great. But I can't use the AXFR or IXFR to now transfer that configuration to my secondary servers. So I can't use GSLB plus secondary together. It just doesn't work.

So a couple techniques people use to fix that. One is you can use a DNS vendor that has a proprietary system to support multiple servers around the world. That's one common technique. The other technique we've seen is people when they want to use multiple vendors, they'll set up multiple primary servers. So instead of making this a secondary, they'll make this a primary and then their user will sit in the middle and they'll use an API to configure both of these directly.

And so none of this, none of this is working anymore. The user, like you, the administrator, would either use an API or just go into the console of each of these independently and set them up. But an API is usually the way you would do it and you would set up a front end where you would type in your configuration and it would automatically make the updates on each of those systems. That gets pretty complex, but we've seen it done successfully and it's another technique to get that redundancy you want while also getting the capability of global server load balancing or traffic steering.

So hopefully you've learned a little bit about secondary versus primary DNS. What are its pros and cons, and how you can use it to ensure that your services and your DNS is highly available on the Internet.

Technology, Internet, Science, Dns Configuration, Redundancy, Network Services, Ibm Technology