For lack of a better name(server): DNS Explained
This is a modal window.
The media could not be loaded, either because the server or network failed or because the format is not supported.
Formal Metadata
| Title |
| |
| Title of Series | ||
| Part Number | 116 | |
| Number of Parts | 119 | |
| Author | ||
| License | CC Attribution 3.0 Unported: You are free to use, adapt and copy, distribute and transmit the work or content in adapted or unchanged form for any legal purpose as long as the work is attributed to the author in the manner specified by the author or licensor. | |
| Identifiers | 10.5446/19994 (DOI) | |
| Publisher | ||
| Release Date | ||
| Language | ||
| Production Place | Berlin |
Content Metadata
| Subject Area | ||
| Genre | ||
| Abstract |
| |
| Keywords |
EuroPython 2014115 / 119
1
2
9
10
11
13
15
17
22
23
24
27
28
41
44
46
49
56
78
79
80
81
84
97
98
99
101
102
104
105
107
109
110
111
112
113
116
118
119
00:00
RootkitAbsolute valueWhiteboardRootkitBitBit rateInteractive televisionComputer animationLecture/Conference
00:41
WhiteboardSoftwareInferenceLevel (video gaming)MereologyWhiteboardLocal ringJSONXMLUML
01:07
FrustrationProjective planeLecture/Conference
01:30
Coma BerenicesDirection (geometry)Direct numerical simulationWebsiteMathematical analysisWordRow (database)Solid geometryComputer animationLecture/Conference
01:52
Tape drivePoint cloudDirect numerical simulationInductive reasoningInternetworkingProxy serverTape driveKerberos <Kryptologie>InternettelefoniePoint cloudComputer animationLecture/Conference
02:26
WebsiteComa BerenicesElectronic mailing listEmailLocal GroupMathematical analysisExecution unitLink (knot theory)WebsiteEmailCASE <Informatik>Product (business)Direct numerical simulationLecture/ConferenceComputer animation
03:20
System programmingData storage deviceCache (computing)Computer fileLocal ringTime zoneSocial classRow (database)Data typeDirect numerical simulationDomain nameSystem programmingLatent heatResolvent formalismTime zoneServer (computing)Local ringRight angleRow (database)Data structureNeuroinformatikData storage deviceAddress spaceSocial classType theoryCache (computing)Lecture/ConferenceXMLUML
04:03
CountingInterior (topology)Execution unitBitGroup actionConnected spaceQuery languageType theoryLine (geometry)Programmer (hardware)Search engine (computing)Relational databaseMereologyOntologyOffice suiteFunctional (mathematics)Coma BerenicesDirect numerical simulationWeb browserAddress spaceGraphical user interfaceCommunications protocolLecture/ConferenceSource code
05:45
Inflection pointArtificial neural networkCountingExecution unitoutputHexagonComa BerenicesFluid staticsWebsiteQuery languageWeightComputer-assisted translationMathematical analysisQuery languageDirect numerical simulationAbsolute valueResultantTheory of relativityNatural numberComputer fileDifferent (Kate Ryan album)Coma BerenicesResolvent formalismLecture/Conference
06:46
Coma BerenicesWeightQuery languageComputer-assisted translationDomain nameAreaTime domainPointer (computer programming)Thermische ZustandsgleichungRootkitCAN busTorusInterior (topology)Time zoneMetropolitan area networkSpecial unitary groupAiry functionDomain nameGraphical user interfaceCoefficient of determinationDomain nameTheoryIncidence algebraPasswordQuery languageInformationRouter (computing)Internet service providerDirect numerical simulationWordAddress spaceNeuroinformatikRow (database)HierarchyDean numberBitMessage passingSoftware testingSeries (mathematics)Coma BerenicesBlack boxGroup actionPointer (computer programming)Server (computing)RootkitWhiteboardTwitterVisualization (computer graphics)MereologyDemoscenePoint (geometry)IP addressLetterpress printingLibrary (computing)FrequencyLocal ringQuicksortComplete metric spaceDifferent (Kate Ryan album)Graph (mathematics)System administratorWeb pageFlagRoutingLecture/ConferenceSource codeJSONXML
10:25
Coma BerenicesAddressing modeCAN busTrigonometric functionsSystem callWide area networkGoogolUniform resource nameData structureMetropolitan area networkCharacteristic polynomialBitRow (database)Coma BerenicesPoint (geometry)Web 2.0Time zoneComputer fileDirect numerical simulationLecture/ConferenceSource codeJSON
11:09
RootkitDirect numerical simulationServer (computing)Cache (computing)Resolvent formalismLevel (video gaming)Query languageLecture/Conference
11:31
Query languageCache (computing)Server (computing)Dependent and independent variablesQuicksortWebsiteExtension (kinesiology)Dependent and independent variablesServer (computing)Resolvent formalismType theoryRootkitAuthorizationDirect numerical simulationSinc functionRow (database)PropagatorDomain nameGradientData storage deviceQuery languageCovering spaceLocal ringCache (computing)
12:50
Direct numerical simulationStructural loadRow (database)Sound effectProcess (computing)Mobile appRootkitIn-System-ProgrammierungCache (computing)Server (computing)PropagatorMultiplication signQuery languagePoint (geometry)MathematicsNumberLocal ringNational Institute of Standards and TechnologyLecture/Conference
13:51
Computer clusterDirect numerical simulationServer (computing)Information securityAreaValidity (statistics)WordDependent and independent variablesIP addressDomain nameAuthorizationBlack boxForestExtension (kinesiology)HoaxComputer animationLecture/Conference
14:51
CuboidAddress spaceSet (mathematics)HierarchyRow (database)WebsiteDirect numerical simulationCache (computing)PropagatorServer (computing)Local ringIP addressParsingHierarchyComa BerenicesMereologyComputer animation
15:33
FlagFunction (mathematics)Row (database)Level (video gaming)Lecture/ConferenceComputer animation
15:54
Level (video gaming)Computer fileFood energyDirect numerical simulationSystem administratorTime zoneForcing (mathematics)ResultantLecture/Conference
16:12
WordComa BerenicesAddress spaceNmapMaxima and minimaRandom numberCache (computing)WordThread (computing)ResultantElectronic mailing listMoment (mathematics)Multiplication signDirect numerical simulation
16:51
InformationEmpennageComa BerenicesWeightValue-added networkCAN busAmsterdam Ordnance DatumCountingBus (computing)VacuumRoute of administrationType theoryNeuroinformatikDomain nameRow (database)MappingNumberSocial classProcess (computing)Dependent and independent variablesLevel (video gaming)Sign (mathematics)Sparse matrixDirect numerical simulationCache (computing)
17:52
Factory (trading post)Control flowCommunications protocolVarianceClient (computing)Multi-agent systemQuery languageOpcodeTime domainThermische ZustandsgleichungRow (database)Server (computing)Direct numerical simulationNatural numberPlanningWordMotion captureKnotQuery languageLecture/ConferenceJSON
18:19
Arc (geometry)Row (database)Data typeWide area networkComputer clusterConditional-access moduleSpecial unitary groupValue-added networkCAN busDirect numerical simulationDependent and independent variablesSocial classType theoryRow (database)INTEGRALRight angleCountingLecture/ConferenceJSON
18:43
Cache (computing)Local ringWaveForcing (mathematics)Group actionMultiplication signServer (computing)Local ringDirect numerical simulationComputer clusterAuthenticationDomain nameUMLComputer animationLecture/Conference
19:04
Game theoryCommunications protocolQuicksortAuthorizationPublic key certificateExtension (kinesiology)Domain nameAuthenticationDirect numerical simulationInformation securityComputer animation
19:23
ArmAuthorizationSoftware developerDirect numerical simulationInformationRow (database)Library (computing)Arithmetic progressionWeb 2.0MassServer (computing)Domain nameCore dumpBlogPublic key certificatePosition operatorSelf-organizationVulnerability (computing)BitDomain nameLecture/Conference
20:44
Server (computing)Server (computing)Boiling pointDirect numerical simulationWeb serviceImplementationRow (database)Computer animationLecture/Conference
21:05
Coma BerenicesDualismPoint (geometry)Data storage deviceClient (computing)World Wide Web ConsortiumInclusion mapClient (computing)Direct numerical simulationServer (computing)Row (database)Hash functionInformationRing (mathematics)DiagramSoftwarePoint (geometry)Time zoneMobile appKey (cryptography)Interface (computing)Archaeological field surveyInstance (computer science)Data storage device1 (number)ACIDTable (information)Degree (graph theory)Form (programming)Flow separationProgram flowchart
22:25
Key (cryptography)Hash functionFunction (mathematics)Continuous trackServer (computing)Configuration spaceRing (mathematics)Key (cryptography)Uniform resource locatorVirtual machineClient (computing)TrailInformationDirect numerical simulationHash functionRow (database)Social classRankingCASE <Informatik>Lecture/Conference
23:42
Server (computing)Ring (mathematics)Direct numerical simulationCharacteristic polynomialSystem programmingAuthorizationBitRing (mathematics)Public key certificateServer (computing)Arithmetic meanFamilyOnline helpLecture/Conference
24:14
InformationBlogArithmetic meanConfiguration spaceBitGoodness of fitBlack boxDirect numerical simulationLecture/Conference
24:34
GoogolMultiplication signComputer animationLecture/Conference
Transcript: English(auto-generated)
00:15
Our next speaker is Lynn Root, she doesn't need any introduction, she's a member of
00:21
the Python Software Foundation Board and founder of PyLadies and she's going to be speaking to us about using and creating DNSs with Python. Thank you very much. So yes, my name is Lynn Root, a little bit about me, I am a back-end engineer
00:44
at Spotify making some awesome APIs for external folks to consume. I'm also leader slash founder of PyLadies of San Francisco and board member of the Python Software Foundation. Since I have the stage, I just wanted to promote PyLadies a little bit.
01:01
If you'd like to start a local PyLadies or know someone who's interested, you can literally pip install PyLadies and it will contain all what's needed to start your own location. All right, so back to this talk, as a nerdy person building many side projects, I have many frustrating experiences when setting up deployment.
01:22
As I'm sure many of you have experienced, the very first git push to Heroku, it never works. So I'm assuming you wouldn't be here if you didn't experience that pain. You follow the directions on your host's website to properly set up DNS records, but
01:40
something still doesn't work. We've all been there without a solid understanding of DNS. Oftentimes, we just try something, see if it works, deploy, and see if it propagates, and hopefully it works. But that's not really a solid way to debug. So curiosity got the best of me. I've previously done pretty deep dives into technologies that I only had a cursory
02:05
knowledge of, like Kerberos. So naturally, I decided to dig into DNS, pun intended. I know that DNS was Internet's phone book. Sure it's the backbone of the Internet, and I knew the cloud was built on DNS and duct
02:21
tape, and DNS is actually built on duct tape too. But that's pretty much all I knew. So in this talk, I'll be going over what exactly DNS is and why it's important, what you can do with DNS, and a handful of awesome things I learned along the way. So in case you missed anything, this is the one link that you need to know and has links
02:43
to everything I talk about, and I'll show this at the end of the talk again. Note that I'm probably going to fill out the full 25 minutes and no questions, so maybe buy me a beer after this talk to ask me questions. Anyways, diving in. What exactly is DNS?
03:01
Why is DNS important? It allows you to visit productive websites like Reddit, receive critical emails like Groupon or Guilt, deploy your one-of-a-kind to-do app, or allow for your corporate meme generator to not be accessible by non-employees.
03:20
I don't know why you wouldn't want to hide your secrets or anything, but anyways, getting up to speed on what exactly DNS is, it stands for Domain Name System, and it's how they refer to being a phone book, translating human-readable names into computer-friendly addresses. The textbook definition is DNS is a distributed storage system for resource records.
03:44
Each DNS resolver or authoritative server stores these records in its cache or local zone file, and a record contains a label, a class, a type, and some data. So essentially, a resource record is the data structure specific to DNS.
04:03
All right, so textbook definition, kind of boring. Let's see it in action a little bit. Of course, I wanted to use a little bit of Python. My latest crush has been Scapy. For those of you who don't know, Scapy is very rich Python wrapped around TCP dump, kind of like T-Shark or Wireshark.
04:20
And so here, I'm using Scapy to sniff DNS traffic as I'm browsing the interwebs. I use Scapy's sniff function to pick up my local traffic, and I've filtered on UDP protocol and port to 53 to hone in specifically on DNS traffic, and I only wanted 10 packets
04:41
or datagrams. So as I let this sniff function run, I went to my browser and typed in roblin.com, and what I found was pretty cool, as you can see. As I was typing roblin.com into the Chrome's address bar, a DNS query would take place for every autocomplete guess that Chrome took.
05:03
So at first, pings www.google.com because the address bar is also a search function, and then as I type R, it autocompletes to Reddit because it's one of my most visited websites, and you can see the DNS query on the second line and the answers on the following lines. Then as I type ro, Chrome guesses roblin-spy.parochialapp.com, which, by the way, is my awesome how to spy
05:27
with Python talk that if you're here for PyData, you should come see on Saturday. And we can see the related queries that it points to. And then finally, as I type rog, it finds roblin.com, press enter with Chrome's autocompletion.
05:42
And so I guess this is more of a cool thing that Chrome does to speed up possible search queries that uses DNS to do such a thing. But notice one thing here, I don't know if you can kind of see here, but there's a trailing dot at the end of the host names. I'm sure a few of you know that this exists and that's kind of how DNS does things,
06:03
but why is it really there? So the difference between a trailing dot and none is the same difference between absolute file paths and relative file paths. So like relative file names, I'm sure we're all familiar with, it can be mangled or mapped incorrectly.
06:21
So depending upon how your local DNS is set up, if search example.net was in your resolve.com and you navigated to example.com, the DNS search query would take the URL to not be fully qualified and therefore look at example.com.example.net. If you navigated to example.com.dns would not apply that search path defined in resolve.com.
06:47
So if there is a dot at the end, it's unambiguous, fully qualified domain name, and not prone to search path spoofing. I did not put a dot while navigating to roblin.com. Chrome actually assumes the dot because it's kind of not user friendly to always have to
07:05
put the dot at the end. All right, so continuing on, handling all these DNS queries got me a bit more curious. What is the route that a DNS query takes to finally get an answer for where roblin.com is hosted? This is not exactly easy to figure out.
07:23
Once the DNS query hits my router, my wireless router, it's a bit of a black box where the query is forwarded to if it's not globally cached. I know that my computer's DNS set up to 192.168.1.1, which is my router, and then my router's DNS is set up to this IP address, which I figured out by logging onto the
07:45
admin page of my router and actually hacking in because I totally forgot the password to my router. So if I do a host query on my router's DNS, I get a pointer to comcast.net subdomain. Now if we do a whois on the IP, I see that Comcast, my internet service provider, owns
08:05
these IP addresses, but beyond that, I don't know if Comcast DNS has roblin.com cached and if not, where the query goes after that. But DNS is also hierarchical, and getting familiar with the dig command can also help
08:24
us understand at least how these queries are resolved. The dig command has a trace flag that makes iterative queries to resolve the name being looked up. It will follow referrals from root servers showing the answer from each server that was used to resolve the lookup.
08:41
So trying this out on python.org, I apologize for the small print, but if we do a dig command on python.org with the plus trace flag, we can see kind of the path that it took. You see the start on the dot, the root servers, and it goes down to the org dot, then python.org, and then finally we have an IP address at the end.
09:03
Now for the more visual learner, I made some nice graphs. So the dig query starts at my local DNS, 192.168.1.1, where, if not cached, is then passed on to the root server.
09:20
The query from my local DNS for python.org first asks the root server, the dot, who knows that one of these hosts should have information, so the name server responds with try one of these hosts, which corresponds to the dot org name server. The dot org name server receives a query and then says something like, well, try one of these hosts, which corresponds to the python.org name server.
09:44
And python.org name server says, yep, I seem to have an A record for python.org, and it's 140 to 11, 1069. And that's sort of the complete hierarchical path for python.org. But what if we wanted to know more about subdomains like hg.python.org or others?
10:02
If we do a dig command against hg.python.org, we actually get a CNAME record that points to osu.osl.org, which is a different name record elsewhere. Again, sorry for the flots of print. But I'm sure that python.org has more records set up, not just like one CNAME that we
10:26
know of. If we're curious, we could run the dig command against python.org with the any flag, which is up here. And unfortunately, not much has come back beyond A and NS records.
10:41
Looking at piladies.com, it's a little bit more interesting, with SOA records pointing to name.com and MX records pointing to Google and our A record pointing to our web host. What you won't get using any with dig is a full zone file or DNS setup, like all our CNAMEs. And I'll get a bit more into that later on.
11:04
So we can easily resolve the path that DNS would take to look at python.org or piladies. However, it's not the most efficient way that DNS can respond to queries. The root and top level name servers like dot and dot org would be inundated with many requests. And this is where DNS caching comes into play.
11:26
So when a DNS resolver or authoritative name server receives a query, it searches its local cache for a matching label. There is no label on its cache, the server may instead do one of two things, depending upon how it's configured.
11:42
It may either retrieve from its cache and return a referral response containing a resource record of a name server type whose label is closer to the query, however closer is defined. Or the DNS resolver may be able to initiate the same query to an authoritative DNS server
12:02
responsible for the domain name, which is the subject of the query. And so the authoritative name server can respond with an answer, a referral, or a failed response. And so that response then is accepted by the DNS resolver and if configured, it will most likely store in its cache.
12:20
So if my local DNS server did not have a cache record of python.org, it could send the DNS query to the root DNS server and get pointed to name servers that handled the dot org domain. But since I have visited many dot org sites, my DNS most likely has dot org name servers cache, so it can just skip that first root query and go on to the dot org.
12:42
It sort of trickles down from there. Very simplified. All right, so DNS caching sounds all great in hunky dory until you get to propagation. Provocation is how long one has to wait for DNS changes to show an effect. DNS will hold a record for as long as its TTL, or its time to live number, at which point
13:03
it deletes it. After it's deleted, if someone makes a request that refers to that deleted record, the DNS server will have to go through that whole process again, querying the root server and then caching it. Now setting a too high of a TTL number, then local and ISP caches will last longer
13:25
and therefore your friend may not be able to see your glorious to-do app immediately after initial deployment. Having too long of a TTL and then the server may or may not have the ability to deal with a higher query load. Now another pain point of propagation and TTL, some ISPs completely ignore it and set
13:45
their own expiry for records. Caching actually opens up the ability for poisoning. This is by far not my area of expertise, but as I understand it, DNS poisoning works like so. If the server doesn't validate DNS responses, for example via DNS security extensions, someone
14:04
could exploit that by essentially spoofing an IP address that he or she owns for a given hostname, forcing visitors of that certain hostname to be directed elsewhere. To be able to spoof a DNS entry, an attacker would have to create a response faster than
14:21
that of a legitimate authoritative server. You can effectively DDoS a DNS server with probable non-cache entries, giving the attacker many opportunities to respond with fake DNS responses. So while random domains that are cached are not very useful, the attacker would be able to give nefarious responses from their illegitimate name server for the desired
14:44
domain to compromise. All right, so TLDR, DNS is essentially a black box. Since you cannot simply spin up a DNS server yourself and be connected to the global DNS network, it's particularly hard to debug and get your hands on to take apart.
15:02
So essentially the takeaway is that DNS is hostnames mapped to IP addresses like reddit.com to its IP, and it's essentially set up like a hierarchy, so if your local DNS server doesn't have reddit cached, it knows where to go to find that record. And lastly, caching and propagation is probably why you want to rage quit when deploying
15:25
your sites. But DNS is pretty awesome. There are a few ways to interact with DNS as well as use this dinosaur of a technology that I found cool. So starting off with interacting with DNS, previously when doing the dig commands with
15:43
that any flag that I showed, you may have noticed that we couldn't really see any AC name records to map anything like www.pyladies.com. You can certainly run dig commands against www.pyladies.com, but how many other subdomains are there? Being able to look up a full DNS zone file is rarely allowed beyond being an admin
16:06
yourself. So there's this annual tool called dnsmap that literally brute forces subdomain lookup. So I tried this on PyLadies, and as you can see, it returned four results. This tool is limited to its built-in wordless, which you can also supply yourself.
16:24
So don't exactly expect the results to be comprehensive. As I can see, I know that PyLadies has over 30 subdomains, but I only got four here. And it's not that fast because it does searching based on a built-in or provide a
16:40
wordless one at a time with no multithreading. Next, when I was playing around with DNS, I wanted to figure out what exactly was cached on my local DNS. For at least OS X, you can see what's cached by literally killing the process, which flushes the cache to the syslog.
17:01
So if you take a look at my syslog, we can see some familiar records, or at least I know that they're familiar because I was dnsmappingspotify.net, and I got about more than 300 responses. So just for fun, this is the captured packet when I was sniffing traffic generated by DNS mapping Spotify.
17:22
As you can see, the ethernet layer and then the IP layer where it went from my computer to my router, and dnsmap was trying out the ZR from its wordless. And so you can see the question record down here, and then the name and then the type
17:40
in the class. The response to this was a no domain because it doesn't actually exist. Now we're at a Python conference, and I'm hearing you say not enough Python, don't worry, I got you covered. You can create your own DNS forwarder with Python, and I chose Twisted naturally.
18:02
Here is a simple DNS server from the Twisted docs. We can run this, we can fire up Scapey and run dig against the Twisted server for Python.org. So we can see that this captured datagram with Scapey is that query digging through
18:20
the Twisted DNS server. You can see the question, the name, type, and class, and then here is the response datagram with the DNS resource record and the data associated with it, including the original question, and then the type of record, TTL data, and resource record name. All right, so those are three awesome, interesting ways to interact with DNS.
18:43
I showed you how you can use dnsmap to find subdomains via brute force, even though it might not be inclusive, finding your local DNS cache, at least on Mac, and then running your own Python DNS server with Twisted. Now time for interesting ways to use DNS.
19:01
So, DANE. DANE stands for Domain-Based Authentication of Named Entries. It's basically a protocol for certificates to be bound to DNS names using DNS security extensions. It's sort of similar to two-factor authentication that we as users are familiar with. Essentially, DANE is a way to cross-verify the domain name and the certificate authority issued certificate.
19:24
The problem that DANE is trying to solve is that the TLS certificate does not verify that the organization running the web server officially owns the domain name. As well, the DNS record does not contain information regarding which certificate authority is preferred by this organization.
19:41
So this weakness was actually exploited twice in 2011, both with Komodo and with the Dutch certificate authority, where attackers were able to generate false certificates, giving them the ability to perform man-in-the-middle attacks. So again, what DANE does is provide a way to cross-verify domain name information with the host's certificate authority issued certificate.
20:03
On the blog post that I will show again, I explain a little bit more in detail and overview how DANE is set up with a DNS server. Just real quick though, for those curious, the DNS Python library does have support for domain name with ability to create and manage TLS A records.
20:21
And Twisted Names also has been working on implementing DNSSEC, including DANE support. I don't know if he is in here, but Richard Wall, Twisted Core developer, is giving a talk about Twisted DNS and the progress that he's made with DNSSEC, so I highly encourage you to go. Another nerdy nugget of awesomeness that I uncovered is that you can use DNS for service
20:47
discovery. There are a few ways and tools to implement service discovery, but it mainly boils down to the question, what servers run this service? So as mentioned, one can leverage DNS to help answer this question with the use of SRV records.
21:05
SRV records within DNS zones map canonical names, typically in the form of like underscore service name, dot underscore protocol, dot site, to host names. So for instance, Spotify, at Spotify, each service has its own SRV record with one
21:24
record canonically named after the service itself. When you spin up a Spotify desktop client, it does an SRV lookup similar to this DIG command, and then it finds the four possible hosts here. For the more visually inclined, and some of you are, this is a simplified diagram
21:44
of what happens. So the Spotify client looks up where to connect with an SRV DIG query, the service lookup then continues on. So the Spotify app connects to an access point, for example, ap1.spotify.com, and then the access point resolves the service that the client is looking for, which might be like
22:04
user service to grab your user information. This is all done with SRV records. Last little nugget I discovered is the ability to store a DHT ring within DNS. So DHT stands for distributed hash table, DHT gives you a dictionary like interface
22:21
or key value store, but the data or nodes are distributed among a network. So looking at Spotify again, we store some service configuration data with a DHT ring within DNS TXT records. Once again, you open up a Spotify client and want to play a particular song, FUBAR, one that has not been locally cached on your machine.
22:43
So the client performs a lookup on the song, the track ID is first hash, and then that hash is essentially the key within the DHT ring. And that particular key is then looked up within the DHT ring that is stored within the DNS TXT records.
23:01
The value associated with that key is essentially the host location of that service where the song or its relevant data is located. So in this case, instant E owns from 9E to CU1, which is where this particular track, FUBAR, lives. And is mapped to a particular host.
23:21
Completing this flow, instant E is mapped to a host name, which would be the machine that houses the data on the FUBAR track. This dummy host name tells me that this machine hosts information on tracks that can be connected to via port 4301, is located in our London data centers, is in pod A1, this is sort of like a dummy host name.
23:43
So a bit confusing, I know, but using DNS for DHT ring allows Spotify to leverage the distributed characteristics of a DNS system. All right, so hopefully I didn't lose you with DNS. Dane is going over real quick. Dane has suggested to secure DNS with your certificate authority.
24:01
You can also set up service discovery to help figure out what servers run which service. And finally, you can use DNS for a DHT ring. So yeah, I threw a lot at you, but DNS is by no means easy to understand within a 25 minute talk. And I guarantee you, you will screw up your DNS deployment configuration
24:22
because, well, DNS is hard. Bit of a black box because it's not easy to debug and it's certainly not easy to make a good talk out of. But I hope that you learned some things and if you want more information, this is the blog post. I'm out of time, but thank you so much.