DNS for Developers
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 | ||
| Number of Parts | 96 | |
| Author | ||
| License | CC Attribution - NonCommercial - ShareAlike 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 and non-commercial purpose as long as the work is attributed to the author in the manner specified by the author or licensor and the work or content is shared also in adapted form only under the conditions of this | |
| Identifiers | 10.5446/51709 (DOI) | |
| Publisher | ||
| Release Date | ||
| Language |
Content Metadata
| Subject Area | ||
| Genre | ||
| Abstract |
|
NDC Oslo 201648 / 96
2
7
8
9
12
14
19
20
26
28
31
33
38
40
43
45
48
50
51
61
63
65
76
79
80
83
87
88
90
93
94
96
00:00
Direct numerical simulationSoftware developerSoftware developerDirect numerical simulationElectronic mailing listFrustrationQuicksortUMLComputer animation
01:11
Direct numerical simulationFrustrationWeb pageTap (transformer)Server (computing)Digital rights managementDigital mediaProof theoryDirect numerical simulationSoftware developerWebsiteResultantIncidence algebraWeb serviceComputer animationMeeting/Interview
03:07
Application service providerSoftwareFocus (optics)Content delivery networkInformation securityDirect numerical simulationArchitectureConfiguration spaceInternetworkingTime zoneDirect numerical simulationWeb serviceInformation securitySheaf (mathematics)DemosceneStructural loadBitCartesian coordinate systemComputer architectureSoftware developerMereologyInternetworkingNetwork topologyVideo gameBeat (acoustics)WebsiteCovering spaceQuicksortComputer animation
04:07
Direct numerical simulationInternetworkingGoogolAddress spaceWeb browserDNS <Internet>Physical systemCache (computing)Router (computing)IterationInternet service providerRootkitServer (computing)MereologyDirect numerical simulationBeat (acoustics)InternetworkingServer (computing)GoogolInfinityImage resolutionIn-System-ProgrammierungChainRootElectronic mailing listSoftware developerUniform resource locatorWeb browserDomain nameComa BerenicesPoint (geometry)Local ringRouter (computing)Virtual machineSoftwareWindows RegistryQuicksortMappingSystem callRecursionCache (computing)Address spaceIP addressSearch engine (computing)ResultantType theoryConnected spaceMultiplication signDifferent (Kate Ryan album)Digital mediaSpeech synthesisDot productComputer fileRoutingVideo gameGame theoryOrder (biology)Web serviceArithmetic meanComputer animation
07:19
Discrete element methodDependent and independent variablesDirect numerical simulationRecursionServer (computing)RootStructural loadDifferent (Kate Ryan album)Address spaceEntire functionGoogolComa BerenicesIn-System-ProgrammierungChainInternetworkingPhysical systemCache (computing)Image resolutionIP addressWindowExterior algebraVirtual machineLastteilungRow (database)Installable File SystemComputer animation
09:36
Sanitary sewerType theoryDirect numerical simulationAddress spaceEmailInformationDomain nameRule of inferenceImage registrationSession Initiation ProtocolPhysical systemServer (computing)RootkitUDP <Protokoll>Dependent and independent variablesDirectory serviceRootSelf-organizationIP addressDomain namePower (physics)Level (video gaming)Multiplication signDifferent (Kate Ryan album)Data storage deviceMereologyComa BerenicesDot productBitResultantAuthorizationRight angleSign (mathematics)RoutingConnected spaceInternetworkingEntire functionCasting (performing arts)CodecEmailField (computer science)MappingCommunications protocolQuicksortServer (computing)MathematicsAdditionImage resolutionWeightAreaPhysical systemGoogolArithmetic meanRule of inferenceImage registrationDirect numerical simulationWeb serviceElectronic mailing listWebsiteAddress spaceType theorySource codeInformationData conversionFunction (mathematics)Denial-of-service attackCache (computing)Computer animation
15:46
Server (computing)RootkitElectronic mailing listTime zoneDatabaseWindows RegistryComputer networkOpen setMietserverIndependence (probability theory)Reduction of orderCache (computing)Address spaceDirect numerical simulationRecursionInternet service providerRootServer (computing)Electronic mailing listDomain nameMathematicsImage resolutionCASE <Informatik>IP addressOperating systemVirtual machineComputer fileMultiplication signWordOpen setWebsiteComa BerenicesSelf-organizationRow (database)SoftwareCache (computing)Direct numerical simulationWeb browserPhysical systemLevel (video gaming)Web serviceProjective planeRight angleReal numberQuery languageForcing (mathematics)Point (geometry)Uniform resource locatorDifferent (Kate Ryan album)GoogolAreaQuicksort1 (number)Revision controlRouter (computing)Denial-of-service attackValidity (statistics)Software developerDefault (computer science)Resolvent formalismResultantRoutingDot productExecution unitDreizehnContext awarenessWeightComputer animation
21:56
Direct numerical simulationTime zoneCache (computing)Content (media)Physical systemSubsetDomain nameData structureHierarchyAddress spaceServer (computing)Service-oriented architectureMaxima and minimaFerry CorstenSerial portDigital rights managementEmailParameter (computer programming)WebsiteInformationMaizePointer (computer programming)Query languageHeat transferRevision controlComputer fileClosed setTime zoneServer (computing)Direct numerical simulationCommunications protocolDomain nameIP addressAddress spaceEmailRow (database)InformationDifferent (Kate Ryan album)Revision controlGoogolLatent heatHeat transferMultiplicationMappingFile formatPointer (computer programming)Reverse engineeringQuery languageWeb serviceWordRule of inferenceOpen setMereologyWeb 2.0Cache (computing)Identical particlesInformation securityDot productSystem administratorAuthorizationGroup actionType theoryDatabase normalizationMaxima and minimaInternetworkingState of matterPoint (geometry)Expert systemLevel (video gaming)RoutingTracing (software)SpacetimeComputer animation
27:46
Web pageCache (computing)Direct numerical simulationTime zoneInformation securityTime zoneHeat transferDirect numerical simulationMedical imagingServer (computing)IP addressRow (database)Link (knot theory)Domain nameCache (computing)Connected spaceVirtual machineSystem administratorQuicksortOpen setComputer fileAuthorizationInformationWeb pageGoogolCommunications protocolCASE <Informatik>Game controllerComa BerenicesComputer animationXML
29:11
Direct numerical simulationLocal ringOvalServer (computing)CAN busProxy serverConnected spaceServer (computing)Link (knot theory)QuicksortMedical imagingDirect numerical simulationRegular graphWebsiteCache (computing)InternetworkingVirtual machineGoogolDefault (computer science)Information securityDomain nameResolvent formalismIP addressPhysical systemLocal ringUniform resource locatorWeb pageSource codeComa BerenicesSpywareRight angleMathematicsException handlingAddress spaceRecursionStructural loadDirectory serviceComputer animation
32:02
Web pageDNSSECFormal verificationDemo (music)Direct numerical simulationExtension (kinesiology)Server (computing)Default (computer science)RecursionComputer networkUDP <Protokoll>Source codeDenial-of-service attackElectronic mailing listGamma functionQuiltOpen setFirewall (computing)Limit (category theory)Server (computing)Communications protocolGroup actionRight angleInformation securityOpen setExtension (kinesiology)Denial-of-service attackChainAddress spaceSource codeCache (computing)Sign (mathematics)Electronic mailing listDemo (music)Multiplication signSoftware testingIP addressGoogolRecursionRow (database)SoftwareWeb serviceDomain nameComputer fileTime zoneFormal verificationMathematicsGame controllerIn-System-ProgrammierungRootEntire functionQuery languageWebsiteResolvent formalismDirect numerical simulationDependent and independent variablesState of matterPhysical systemBlogBuildingControl flowVirtual machineQuicksortDataflowAdditionPublic key certificateAuthorizationArithmetic meanVideo gameComa BerenicesWindowLimit (category theory)Point cloudOnline helpFirewall (computing)Default (computer science)Insertion lossRoutingFigurate numberComputer animation
37:37
Direct numerical simulationArchitectureServer (computing)Internet service providerChemical equationCartesian coordinate systemSession Initiation ProtocolComputer architectureDirect numerical simulationPhysical systemDifferent (Kate Ryan album)Roundness (object)LastteilungRow (database)Structural loadIP addressMeasurementWeb serviceServer (computing)Chemical equationElectronic mailing listWebsiteComputer fileDomain nameMultiplication signImage resolution2 (number)Point (geometry)Address spaceQuery languageDigital rights managementTime zoneCache (computing)Computer animation
40:09
Demo (music)DataflowDirect numerical simulationWeb pageUser profileWebsiteDigital rights managementDialectDifferent (Kate Ryan album)MultiplicationData centerBitCartesian coordinate systemCASE <Informatik>Server (computing)Row (database)Game controllerGoogolWeb serviceType theoryRoundness (object)Electronic mailing listDirect numerical simulationAddress spaceWeightPoint (geometry)Uniform resource locator2 (number)MathematicsResultantComa BerenicesMobile WebComputer animationSource code
42:22
Content (media)Content delivery networkComputer networkServer (computing)Direct numerical simulationAddress spaceMaizeRootkitLogicCanonical ensembleInternetworkingIntegrated development environmentConfiguration spaceHierarchyConfiguration spaceVirtual machineType theoryInformationCASE <Informatik>Domain nameSoftwareWeb serviceRight angleContent (media)Server (computing)Source codeUniform resource locatorResultantDirect numerical simulationIntegrated development environmentIP addressComputer configurationRecursionCommunications protocolSet (mathematics)Decision theoryPhysical systemBuildingClosed setLatent heatInternetworkingSoftware developerAddress spaceContent delivery networkProduct (business)Query languageCartesian coordinate systemKey (cryptography)Source codeComputer animation
44:47
Demo (music)Configuration spaceDirect numerical simulationServer (computing)Local ringGoogolComputer fileProxy serverString (computer science)OvalData storage deviceRight angleServer (computing)Connected spaceMultiplication signCommunications protocolSkewnessType theoryResultantString (computer science)ImplementationData storage deviceConfiguration spaceStaff (military)Client (computing)Figurate numberInheritance (object-oriented programming)SoftwareRow (database)DatabaseDirect numerical simulationComputer fileRecursionKey (cryptography)Electronic mailing listCodeLibrary (computing)Web serviceDependent and independent variablesStandard deviationQuery languageComputer animationSource code
47:40
Cache (computing)Configuration spaceDirect numerical simulationIntegrated development environmentWeb serviceDirectory serviceComputer networkComputerCommunications protocolMultiplicationVirtual machineLocal ringDirect numerical simulationDefault (computer science)Server (computing)Address spaceSoftwareStructural loadIP addressWeb serviceInternetworkingQuicksortIntegrated development environmentMereologyOffice suiteDatabaseElectronic mailing listCommunications protocolDependent and independent variablesInformationDifferent (Kate Ryan album)LaptopCartesian coordinate systemLatent heatType theoryUniform resource locatorQuery languageMultiplication signString (computer science)Connected spaceSlide ruleCache (computing)Peer-to-peerTunisForestClient (computing)CASE <Informatik>Universe (mathematics)AreaFirewall (computing)Range (statistics)CircleComputer animation
51:26
Demo (music)Web serviceDirect numerical simulationSynchronizationOvalContext awarenessDependent and independent variablesUniform resource locatorWeb serviceWeb 2.0Local ringInformationIP addressInstance (computer science)Different (Kate Ryan album)ExistenceRevision controlSoftwareCategory of beingElectronic mailing listLatent heatClient (computing)Computer architectureMereologyCartesian coordinate systemBroadcasting (networking)Multiplication signDescriptive statisticsPlastikkarteType theoryBit40 (number)Right angleComputer animation
54:07
Proxy serverLocal ringClient (computing)Server (computing)Direct numerical simulationUDP <Protokoll>SineMaxima and minimaEncryptionWeb browserDNS <Internet>IP address2 (number)Direct numerical simulationIn-System-ProgrammierungWeb browserClient (computing)Row (database)BitServer (computing)EmailBand matrixProxy serverCache (computing)PlastikkarteCommunications protocolSoftwareWebsiteQuery languageWeb 2.0Particle systemSquare numberMusical ensembleUltraviolet photoelectron spectroscopyTransportation theory (mathematics)BuildingVideo gameComputer animation
56:16
Demo (music)Royal NavyString (computer science)Execution unitGoogolDirect numerical simulationServer (computing)BuildingImplementationAuthenticationRight angleControl flowComa BerenicesPoint (geometry)InternetworkingRow (database)Web browserVideo gameDean numberStreaming mediaVolumenvisualisierungNumberArchaeological field surveyMereologyWeb pageAddress spaceDependent and independent variablesMedical imagingLine (geometry)Entire functionValidity (statistics)CodeCartesian coordinate systemLatent heatDomain nameLink (knot theory)2 (number)Computer animation
59:10
UDP <Protokoll>Direct numerical simulationCommunications protocolData compressionSystem identificationDirect numerical simulationServer (computing)Communications protocolPoint (geometry)NumberClient (computing)RecursionDemon1 (number)Particle systemComputer animation
01:00:00
ArchitectureHierarchyDirect numerical simulationPhysical systemConfiguration spaceType theoryRow (database)Web serviceServer (computing)Row (database)Direct numerical simulationConnected spaceAdditionCommunications protocolStructural loadComputer architecturePhysical systemNetwork topologyCartesian coordinate systemResultantRoutingRootComputer animation
Transcript: English(auto-generated)
00:04
I'm not sure if I'm on, but I can hear myself through the speakers, so I think I am. Welcome to the session, DNS for Developers. When I first submitted this session, it was three years ago, I think, to NDC, to a couple of other conferences as well.
00:20
The way it works as a speaker is you submit a session, and then you submit another session, and you submit another session. In my beginning days of being a speaker, I was always preparing the session and then sending in the abstracts. With this session, and along the years, you sort of learn that you have to submit an abstract,
00:40
wait for it to get accepted, and then build the session. Now, this one was on my list for three years, and back then, I had a frustration with DNS and developers. I still have it a little bit. But I read the abstract, and I was like, damn, how am I going to fill an hour with it, which turned out to be quite easy. But the more important issue I had with it was
01:02
I have no idea if it's going to be one person in the audience, or a full room, or whatever. Thank you for being here. I hope you will enjoy it, but we'll see what gives. My frustration back then was something like this. Typically, you are working on your PC, and you are developing something,
01:21
working on something that actually provides value to the company you are working for. Then all of a sudden, your manager comes in, taps you on the shoulder, and goes like, hey, can we add a C name to the DNS? You're like, okay, sure. We can, but why? Well, we want to redirect this subdomain to a page somewhere on our server.
01:44
Okay. What the hell? That's not what DNS is meant for. That's not DNS. That was my frustration, why I came up with this talk. I do realize that's not a lot to go on. There's another frustration, and that one I suffered yesterday, which is quite incidental.
02:05
I have a big issue with karma. Whenever I want to do something, something happens relating to that thing. I want to do a talk on DNS for developers. My DNS server goes down. That was yesterday. I should actually do a talk on not becoming a millionaire
02:22
in the hope that I will actually become a millionaire or something. Yesterday, the DNS server went down, and customers were affected by this, but it only took five minutes before things were resolved, so not bad. During those five minutes, of course, the website wasn't available, and people could not hit it. He sends me, I cannot ping this website.
02:41
I'm like, can you try again? It still doesn't work. Can you do an NS lookup and look at the results and see if it actually resolves the DNS, because I knew it was a DNS problem. He mails me back a trace and goes, still doesn't work. I'm like, okay, but you just posted me the proof that it actually works on your end, so things are okay. He mails me back, okay, things are fine.
03:02
Another frustration, and I think a lot of developers actually are not very familiar with all the things in DNS. Who am I? I come from Antwerp, Belgium. I work at Microsoft. I do a lot of services there, so I get to touch a lot of DNS as well. If you want to sponsor my Oslo bar bill, please buy my book on NuGet.
03:26
The agenda for today. I sort of decided to split this talk into a couple of sections. One of those sections will be the 101 stuff. How does DNS work? What happens if you Google a website? Even before the first HTTP request goes out,
03:41
what happens behind the scenes at the DNS level? Next, I'll cover a little bit of security in DNS, because there are a couple of things you should be aware of when setting up your own DNS and doing things like that. Then I'll go into DNS in your application architecture, because most of us are probably developers, and there are a lot of nice things you can do with DNS, such as failover, load balancing, CDN, service discovery, things like that.
04:04
That's basically the three big chunks of this talk. Then I have a nice thing to beat airport Wi-Fi. How does the internet work? The DNS part. What happens if you Google? Of course, every developer will say we make an HTTP call to Google.com,
04:22
and we get back a result, maybe a redirect, and then do another call to Google.com, and then render the contents, and then we can search something in the search engine. Well, that actually happens, but there are a couple of things that happen before that. You need an IP address for Google.com. Actually, if you type that in your browser,
04:41
you want to hit the server or the server farm that is hosting Google, and you use DNS for that. DNS is actually a phone book that maps those names to an IP address that you can browse to, and the browser can then make a request to get the results back and render the search engine to you. So let's Google.
05:01
The things that are happening is on your machine, if you type Google.com, what will happen is your machine will actually check its own cache, its own host file, its own registry. There's a couple of locations on your local machine if it knows Google.com already, which is a nice thing because if you are doing development and you want to mimic a certain URL during development,
05:22
you can just add it to the host file, overwrite it, and your DNS resolution will not even go outside of your network. Your PC will just say, oh, Google.com, that's your local host, for example. Now, if data is not found in there, what will happen is typically if you're on your home connection, for example, we will check your home router.
05:42
Home router is typically your DNS server or your preferred DNS server that will serve all the requests that you are making. So your PC will ask the home router for give me the address for Google.com. Now, the home router itself also has a cache, and we'll check its cache if it already knows Google.com. If not, this one will actually defer to the DNS server at your ISP,
06:05
which, again, checks the cache and so on, checks if Google.com is already known, and returns the address if found. If not, it will do the resolution for you. So it's not that we have this infinite chain of DNS servers querying one another. At a given point in time, or at a given point in this chain,
06:23
one of the DNS servers will say, okay, I'm your recursive DNS server, and I will do the rest for you. So what happens is the DNS at your ISP will do several things. Typically it will be in cache, but imagine it's a new server, nothing has happened yet.
06:40
What will happen is the DNS server at your ISP will ask the root servers, where does .com live? It will get back a list of DNS servers that can query for .com domains. It will go there and ask the .com authoritative server, where does Google.com live? And this one will say, okay, Google has their name servers here.
07:01
So your ISP will then go to Google's DNS server and say, okay, Google, give me the IP address for www.google.com, which I am interested in. And eventually one server will give back an IP address, flows back to your PC, and you can navigate to Google.com. Awesome. And sort of magic.
07:20
And you can actually see this happening. There's a couple of tools if you want to troubleshoot DNS or see what's going on. And one of those are in pretty much every OS. It's nslookup. If you search google.com using nslookup, you will get back a response pretty fast. So this means somewhere along the road it may be cached,
07:41
or the ISP hosting the Wi-Fi for NDC here actually did the entire recursion of going to the root servers, the .com domain, google.com, and flowing this address back to you. One important thing to see here is that this answer was not an authoritative answer. It's a non-authoritative answer, which means there's a cache involved
08:00
and someone actually says, okay, I know google.com, no reason to go to the root server and do the entire resolution. I'll just give you the IP address. What's interesting is if we go to Google's DNS server directly, we actually get an authoritative answer because ns1.google.com is actually allowed
08:20
to give back the addresses for google.com. In this case, you get the address immediately from them. You can also see you get a different address from them, so they probably do some load balancing on their machines as well. This is pretty much how DNS works. nslookup does a lot of things, like this entire resolution for you,
08:40
and doesn't show what happens. There's another tool called DIG. If you're on Linux or Mac, you will probably have this tool available on your system. On Windows, you can install it. DIG will give you the same thing. The only thing is that we have to be more elaborate about what we want. We want the A record, more on that later on, and we want to trace the entire chain of what happens.
09:04
What DIG will do is actually do the entire recursion for us, go to the root server, go to whatever server is in between, and not just ask the ISP server. If you're using DIG and you add trace, you can see all the different steps that are happening. You can see we are hitting the DNS root servers.
09:22
They give me back where .com lives, that gives me back where Google lives, and then we get the address of google.com to navigate to it. That's pretty awesome, and actually pretty fast to do this recursion over the entire Internet. I already touched this briefly. You have two types of servers.
09:41
There's the authoritative server, which is the server that will actually serve the address, and is the one and only source of truth that owns the domain. ns1.google.com owns www.google.com and everything that is in the google.com domain. Then you have a recursor or a cache. The names are interchanged.
10:01
Those are basically just cache, and whenever they know the address, they will give you the address. They will also tell you that they are non-authoritative, and they will just say, OK, here's the result, but I don't know if this is correct. It's what I still know from the previous guy who asked where www.google.com lives.
10:21
All right, a little bit more on DNS. I went to Wikipedia and found out that it was designed in the year that I was born, so it's kind of cool and worrying at the same time that this protocol that still powers everything we do today on the Internet is actually 32 years old. That's cool and strange.
10:41
It's also cool that this guy designed something that is still being used 32 years later and actually works pretty much without a flaw. DNS, the only thing it does is beat the address book and convert host names into IP addresses and actually also vice versa. Along the years, some things happened.
11:01
Email came about. People started sending spam and things like that, so DNS is actually also abused to store information about mail servers. Can this mail server send email for this domain and things like that? In essence, it's just a mapping between a domain name, so a text field basically, and an address or a text field that contains some information on whatever you want to fetch there.
11:27
How do you get a domain name? I think most people know this. If you want to have your own domain name and host your own DNS, you basically go to a register, or some party that works with the register, and they register the domain for you, host your DNS, and so on.
11:44
Actually, the entire domain name system, as it's called, is fragmented a little more. For example, .com is a domain managed by VeriSign, a commercial entity. Our Belgian domain names are managed by DNS Belgium. They manage this entire top-level domain name area for the entire Belgian domain name there.
12:09
There's one for EU, there's one for Biz, there's one for .net, there's one for .org, and those things are there. All these different entities have their own rules. For example, .com may have different rules on who can register a domain name.
12:23
I know there's been... I can't remember which TLD it was, but there's actually a TLD that has very strict rules, and actually Belgium had this as well, where in the beginning of the Internet days, you could only register a domain name if you were a legal entity. Not as a person, only legal entities.
12:41
That's still different per top-level domain name, and you will see the difference in pricing as well. They also have their own rules in ownership changes and disputes and so on. If I register google.be, imagine it would still be available, and Google comes to me and says, OK, we are Google, we want that domain, and you are not getting any money for it because it's our domain.
13:02
In the Belgian DNS rules, they would just be able to get that domain, because that's the dispute resolution. If there's only one company and it's a trademark holder and they should own the domain, you are obliged to basically hand it over to them without asking any money from them, maybe a little fee to just cover whatever inconvenience.
13:23
And every TLD actually has their own rules around this. You register it, for example, at the Nsimple or whatever hoster, and they do both the registration of the domain name as well as hosting the name server. I already covered in this DIC trace output
13:42
that it's sort of a hierarchical system. Basically what happens is you sort of fetch the root servers. They will tell you where all the different top-level domains are, like .com, .org, .b, .nl, .no, and so on. They will have their own name servers, and they know where their registered domain lives.
14:02
Those registered domains will have their own name servers where they host their own host names in the domain server. But if you're like a large organization, and probably Google has this as well, they can still delegate their own subdomains to different name servers internally. It's not always root servers, top-level domain, and then the company domain, for example.
14:21
It can be more name servers along the way, depending on which part of the organization you are trying to hit in there. Actually quite flexible. The root servers. ICANN, which is the organization that manages the root servers, has 13 root servers around the globe. The first request in your DNS that goes out
14:42
goes to one of those root servers to find out where all the top-level domains live. Why only 13 root servers? Well, DNS works over UDP. The packet size of a UDP packet can only contain 512 bytes in this DNS thing, and having more than 13 entries in there would exhaust the size of the packets
15:02
and basically render DNS useless. That's why they only have 13 as a host name, because they use anycast and basically serve the root servers from anywhere around the globe. If you are trying to bring down the internet and you think, hmm, only 13 servers to put a DDoS attack on, then you are probably wrong, because there is way, way, way more than that.
15:22
You can actually see where they are. While I was going over this talk earlier today, I found out that Oslo actually has four of those root servers around the city here. There is one managed by VeriSign, there is one managed by ICANN itself, and a couple of others.
15:42
If you are going on the internet in Oslo, you probably get a really fast connection in your DNS resolution, because there is a server very nearby. You can find them all on this website. You can find all the different organizations, and you can actually query those name servers as well. If you take one IP address here from one of these servers
16:00
and tell it to look up Google, for example, it will tell me where .com lives, basically. It tells me, okay, find .com, these servers will tell you more about where Google lives. They don't serve Google.com directly, they don't do the entire recursion, but even if I ask for whatever domain name
16:21
with one of the root servers, they will tell me where the top-level domain lives, so I can continue my journey in discovering what's going on. The gTLD servers are managed by different organizations. Some are managed by countries, some are managed by foundations, some are managed by corporate entities,
16:41
so there's a couple of those. You can actually go to the IANA site and find out where all these TLDs live as well. That's actually quite a big list now with all the new top-level domains that are available. If, for example, you want .abudabi, you can go there and you can find out where this TLD lives,
17:03
which organization is doing this, who is the technical contact, where their name servers are to query for .abudabi domains, and so on. Some of those domain names or gTLDs are managed by the same organization, while others just manage like a small entity on some island somewhere in the Pacific.
17:22
So that's that step. The root servers are a convention, so you may wonder, OK, there are 13 root servers that we query for, but where do we get this list of those root servers? Those are actually baked into your operating system. On a Unix machine and a Linux machine, you can actually search for the file that contains these root servers,
17:42
and every DNS query that you make on a Linux machine will read that file and find out where the root servers are. They are called a.rootservers.net, b.rootservers.net, and so on. But they are basically hard-coded or hard-configured, as you may say, in your operating system. If you want to go into an entirely different realm,
18:02
you can, for example, change your root servers to use the root servers of, for example, the OpenNIC projects. They have their own root server serving their own TLDs, like .free, .null, .oss, and so on. And if I were to browse to a .oss domain name, I would probably not be able to resolve it
18:21
because my root servers are not the OpenNIC project root servers. So it's just a convention, and if you want to go hipster-style and just go into a completely different realm, you can just change the root servers to a different organization. There are those guys building basically their own domain name system, and there are lots of shady sites on there as well,
18:42
so I wouldn't recommend it. There is another organization called the Open Root Server Network. They basically host their own root servers in different locations around the globe, mostly in Europe, though. It's a European organization that thinks, okay, ICANN, the organization managing the real root servers,
19:02
is a US-based company, and if something happens like elections pretty soon and someone decides that things should change, if you're in Europe, you could use this Open Root Server Network and get a copy of all the domain names that are available right now. It will just all work. But if something happens in global politics,
19:22
they may decide to roll their own domain name system and keep Europe up and running, for example. There are different things there. If you Google a little bit, you will find more of these projects. I don't think a lot of people are actually using them right now. DNS has one really nice thing.
19:42
Caches. Caches everywhere. On every level of DNS resolution on my local machine, at my ISP, on my home router, there is caching involved. As you know, naming is hard in development, but cache invalidation is even harder. To link back to the story I had with my DNS issue yesterday,
20:00
I still have a couple of users who are seeing an old DNS record in their name server because my cache was set to expire after one day and I cannot force this other entity to flush their cache. So I just have to wait a day until it properly resolves. Now, if you are doing DNS changes,
20:20
you may want to see where does my domain name already resolve. There are a lot of tools, like whatsmydns.net, which actually have a really nice service where you can do things like finding out what your DNS points to in different locations around the globe. For example, NDC seems to all point to the same IP address,
20:42
but if we would make a change to the NDC Oslo domain name, we could see which servers already have the new value, which ones are still on the old value, so you sort of know the area where you may be seeing DNS resolution problems. There is also the local cache, if you want to flush that one.
21:01
There is a command ipconfig.slash flushdns, which you can use. That is also a nice one if you are making DNS changes to make sure that your machine actually resolves things correctly. IE is a nice browser. They also have their own DNS cache, so an ipconfig.slash flushdns is not enough
21:21
if you are using IE to test your websites or whatever. You may have to restart your browser or even your machine in those cases. One word of warning. If you do want to make a DNS change to a domain name, make sure you lower the time to live, which is basically the cache expiry time. Lower it so that whenever you make a change,
21:41
the change gets picked up more quickly. By default, it is typically one day. You lower it to one hour, wait a day, then make the change, and then increase it back to one day so that people will refresh the value within one hour, for example. DNS zones. DNS zones are actually the files describing a domain name.
22:04
If you go to Wikipedia, you get the closing keynote yesterday, a definition that repeats the word that it is actually defining, so not really useful. Basically, a DNS zone file looks like this. It is a simple text-based format that says, OK, I am the origin for this domain,
22:21
which means I am authoritative for this domain. My TTL in the cache is one hour in this example, and these are all the different records that I have, like who is my administrator, where can you find my mail server, where is my domain name, www, and things like that. All those things can be defined in your DNS zone.
22:42
Each record can have their own TTL, which means if you want to expire your web route, for example, more often or faster than a different part of your domain name, you could do so by just changing it on this one record instead. Each DNS zone, at the minimum, has an SOA record.
23:01
It is not something dirty. It is just a start-up authority record, which basically describes, OK, I am the owner of this domain. If you look back at the example here, there is the ns.example.com in this SOA record, which is basically telling, OK, I am the authoritative server. Here is my name server, where you can find all the information.
23:22
You will also see there is a username.example.com. That is actually the email address of the administrator of the server, so that if you want to contact them, you can also do this. How do they make the distinguishing between the dots and the ats in the domain name? I have no idea, so I do not know if you have firstname.lastname.example.com,
23:42
how you would ever find where to place the ats, but that is a 32-year-old protocol. There are typically some other records in there as well, most typically a name server record pointing to all the different name servers that can give you information about this specific domain name.
24:00
There are A records in there, which are address pointers, basically mapping, for example, Google.com to an IP address with IP version 6 coming out. There are also the AAAA records. It should have been AAAA. It would have been funny. But they are used to denote IPv6 addresses, if you have them. There are C names, which is not a redirect,
24:22
but it is basically telling people, hitting that C name, that this domain name is actually a different domain name, and you should make another query to get the actual value. So it is not a redirect. The mail exchanges are in there. There are text records. There are service records. Things like that. You can find those if you play with them. There is one special record as well, which is the PTR record.
24:43
It is a pointer record for reverse DNS. DNS typically maps a host name to an IP address, but if you have PTR records and PTR name servers, actually, you will get back the host name of that IP address. This is, for example, used by tools like traceroute
25:01
to find the host name for a given IP address, but also by anti-spam techniques to see if a mail server is actually who they pretend to be. Like, if I, as a home server, tell the mail server, like, hey, I am Google.com sending you an email, that email server will probably do a reverse DNS lookup to see if my IP address is actually Google
25:21
or if I am just a common spammer. And you can see it in action. If you just do an S lookup, set the type to a pointer record, and you go, for example, Google's open DNS resolver, you get back the information saying 888 maps to Google public dns8.google.com.
25:43
And you have this for any IP address. For example, even your local host, I think, will resolve because the OS will tell you it's your local host and it lives at this address. So that's quite nice, actually. All right. There's usually more than one name server involved in any domain.
26:03
Like I said, there's different countries and different top-level domains with their own rules. I know, for example, the Netherlands has this rule, like, if you want to register a domain name in the .nl domain space, you require at least two name servers. That's what they say. Why? Redundancy. If one goes down, people can still resolve you
26:22
because there is a secondary name server. There's other domains that just say one is enough. There's other domains that say you need four of them. So there's a couple of those there as well. Now, how do you manage this address book of potentially thousands or thousands of records on multiple DNS servers? You could do things like shipping the file
26:40
and copying it over and making sure it works everywhere. Luckily, DNS actually has a nice protocol called zone transfer, which actually transfers the zone files by itself and on itself. So you have your primary name server that holds the entire records, the secondary name server knows I serve this domain but doesn't have all the details yet,
27:02
both trust each other, so you set up the IP address of each server, and they just communicate, and the primary sends over the data to the secondary. That's actually a security risk as well, and there are still a lot of domains out there that didn't whitelist their zone transfer files,
27:20
which means that if you set up your own domain name server, you configure a domain name in there, and you link it to the actual name server of that domain. You just get all their records, maybe including TXT records, who can send email to them, and so on. So there's a lot of information in there, and if you are setting up your own DNS infrastructure, you probably want to whitelist so only your own primary and secondary can talk to each other
27:43
and not to the entire Internet, at least for the zone transfers. All right, security, another nice one. The zone transfer is one aspect of security. The other one is DNS cache poisoning. So imagine you register the domain name evil.com.
28:00
It would be an awesome domain name, by the way. And you configure it to have a couple of DNS records, namely these. You have a start-up authority record that says, I am nameserver.evil.com. This is my administrator. Oh, and by the way, one of my name servers is ns1.google.com. Perfectly valid. That's perfectly valid in DNS.
28:21
You can do all sorts of domain name redirects. The other thing I do in this zone file is add an IP address for ns1.google.com, which may be my own name server. The interesting thing is if I then create a web page that has a link to ww.evil.com and renders an image that doesn't exist, for example,
28:41
what will happen is my PC will make a connection to my name server. My name server may, if it's an open name server, for example, may go to this evil.com because I'm actually requesting a resource from this domain name. What will happen is I will get the name server information as well, and my local machine and all the caches that are sitting in between
29:03
will cache the IP address for ns1.google.com in this case, which is an IP address that I control. That's actually quite nice. And let's see if that works. You would think DNS would have fixed this problem, but again, it's a 32-year-old protocol, so it actually doesn't.
29:21
What I did is I created my own name server. I have recursion enabled. Basically, if I request bing.com, for example, my server will just fetch it from google.com and serve back the traffic and serve it like a regular name server. I do add that I am serving mathm.local
29:40
and that my name server is ns1.google.com. I'm also telling this system that Google's name server is my local host, and I'm also telling Google is on my local host. All right. Let's run this server. Let's change my name server in my connection.
30:01
That's the most important thing. You need a server that provides open relaying and things like that for this to work. I'd use the ndc-oslo default name server. This trick would not work, and I'll explain why in a bit. Let's set it to my local host. All right. I have a nice web page prepared, which is this one, the poison site.
30:27
Nothing wrong with it. I thought this was really funny. Anyway, you see that there's an image that is not loading. If we look at the source code of this page, you will see that I actually added an image to this...
30:43
My zoom, it doesn't work, so let's use Notepad. I actually added a link to this domain name that I have called mathm.local, and I just fetch a non-existing image, which doesn't load. It happens on the Internet. Nothing wrong. Except for the fact that if I now do a query
31:03
and say that I want to nslookup google.com, it actually points to my local host or whatever IP address that I magically injected in my name server there. That's a big security risk, and if you're on an open Wi-Fi,
31:20
never trust a DNS server because these things can happen and they may do all sorts of cool tricks to redirect you to other locations. I actually think there's spyware out there that hijacks the DNS resolver on your machine as well, so that if you go to google.com, you end up on their advertisement-based site and they make money out of it. DNS cache poisoning is actually not nice,
31:43
and this thing will work for as long as this cache is valid. Whenever I now look up google.com or even navigate to google.com, I will end up on my local machine on which I don't have a server, so I hijack Google basically.
32:00
Not too nice. Before continuing, I'm going to restore back to the NDC name server. There we are. DNS cache poisoning is one of the issues with DNS. Fortunately, DNS is a very basic protocol,
32:21
and it actually works quite well, and it's quite extensible as well. There was a security group who came up with DNSSEC, which is the Domain Name System Security Extensions, which is basically a way of doing origin verification. If the entire chain of all the name servers between your PC and the authoritative server of the DNS records
32:43
has DNSSEC enabled, you know you can trust that the domain or the IP address that you are getting has the IP address of the one you were requesting, that it's valid, and that it actually came from the origin that serves this domain name. The way it works is you add a public certificate into your DNS,
33:04
you add a couple of additional records that sort of sign the zone file as well, and if the entire chain has this, every hop in the chain of resolving the DNS records will validate the signature and make sure that this works. Probably Google.com, most probably, they implement DNSSEC.
33:24
Why did my demo just now work? Well, the reason for that was that I had my custom DNS server, which was this time on my machine, but it could be on the airport Wi-Fi or in the NDC building here somewhere. If one of the servers in the chain does not implement DNSSEC,
33:41
it sort of breaks down. So still be wary, even though this extension is there, all the servers in the chain have to support it for it to work properly. Otherwise, you can do things like I just did. There's another security issue with DNS, and that's called DNS amplification, or DDoSing using DNS servers.
34:03
DNS recursion is awesome. Your ISP supports DNS recursion. If you request a DNS record, your ISP will do the recursion, go to the root servers, go to this server, and basically make sure that you get the IP address. The only issue with that is that it means that it will serve traffic to anyone within that domain
34:23
if properly configured. Fortunately for people who want to do DDoSes, unfortunately for people running services that get DDoSed, there are a lot of DNS servers out there that have recursion enabled by default, which is a bad practice. The other bad practice is that they open up their recursors to anyone out there.
34:44
If you do a quick Google search, you will find a website that lists and actually tests lots of DNS servers around the world to see if they just resolve any address. Let's take the first one here, and let's see if we can look up Bing this time
35:01
from that Russian server apparently. We get back the IP address of Bing. They are open recursors, and we get back data from them, and they do the recursion for us. That's not a big issue in itself. The big issue in itself is that DNS is UDP-based,
35:21
which means you don't get traffic flow control and source verification and so on. I don't think it works on Windows, but if you're on a Linux machine or something that's closer to the networking stack, you can actually create your own UDP packets, change the source IP address in that UDP packet,
35:40
make a request to one of those open DNS resolvers, and get back the data from them, but to this fake or spoofed IP address. If you make a UDP packet that has the source address being the target you want to DDoS, then query that entire list we had back there. They will all send back their responses to that IP address that you injected in this packet,
36:02
and you're basically using their open DNS resolver to do a DDoS attack. Not bad in itself if you have a thousand servers. It is bad if the source just keeps requesting to that one specific address of your target and keeps requesting lots of records, and then you get lots of traffic. There's actually a couple sites like Cloudflare, for example.
36:21
They help you prevent DDoS attacks, and they did a blog post recently where they showed the amount of data coming from such open resolvers, and it's insane how many there are and how many traffic you can generate this way through them. Don't do this at home, but it's how most DDoSes nowadays work. Again, you have the attacker, you have your victim,
36:41
you have your DNS resolvers, you make a request to them all. Change the IP address where you are coming from because UDP supports it, and it means that they all hit your targets and basically DDoS them. If you're running your own DNS, make sure you disable recursion.
37:00
That's the best thing. If you do need a recursor, like being able to recurse to other domain names and so on, make sure that you limit it to your own network. For example, if you're a company and you have a public DNS server that you are using within the company, make sure that only that subnet can actually use the recursion on the DNS server. Other things are using services.
37:21
Akamai has them. Cloudflare has them. There's a couple more who do the filtering for you if you're afraid of getting DDoSed. And if you're afraid of getting DDoSed, you might as well use a stateful packet inspection firewall, but those guys are really expensive, but they can probably filter out the traffic for you. All right. Let's take a quick sip.
37:45
Let's move on to DNS in application architecture. DNS in application architecture, the first thing you would typically encounter when you want to use DNS in your application architecture is something like a failover or having multiple services
38:01
behind the same domain name, for example, or doing load balancing or something like that. The cheapest load balancer you can get online is your domain name system. Why? Well, if you make a zone file that, for example, has your example.local domain, and you create several records pointing to a different IP address,
38:22
what will happen is that most DNS servers will actually randomize that list every time a query is made, which means that every request going to the DNS will actually end up on a different IP address, so this is your cheapest load balancer possible. Now, it has one problem. It's DNS.
38:41
There's a lot of caching involved, which means if one of those IP addresses goes down, well, you still have your DNS-based load balancing, but the DNS server will not know that the system is actually down. It will cache the broken IP address, and you still have an issue with your website. How to solve that? Well, you can go to use an intelligent DNS server.
39:01
For example, Azure Traffic Manager has this. Amazon has this. There's a couple of services out there that actually have implemented their own DNS server, adding a layer of intelligence to the records they actually can serve. They can do things like round-robin load balancing, so basically anyone who comes in gets a different IP address to connect to.
39:20
They can do things like failover. Detective an IP address is down and just remove that record from the DNS zone temporarily. Or they can do things like performance DNS, where someone in the U.S. would get a DNS record that points to an IP address in the U.S., someone in the EU would get an IP address in the EU, and things like that.
39:41
That's quite interesting, because if one of those addresses goes down, the intelligent DNS server can actually see this thing is down and exclude it from the name resolution system. Still, you have one issue, which is caching. Typically, these systems use a very low TTL of five minutes, so that whenever you still cache an IP address
40:02
that does not resolve or doesn't work, the cache gets flushed every five minutes or even every 30 seconds before doing something. Let's quickly show you how you can use things like that. I created an NDC traffic manager profile in Azure,
40:21
and what I can do is configure this thing to do performance profiling or failover or waited or whatever, refresh every 30 seconds, and check my website on port 80 to see if it is up and running or not. If I have that, I can start adding endpoints.
40:41
Let's maybe add an endpoint, which would be Google. Let's say this one is... Let's put them all in the same location. Let's add another endpoint called Bing. There we go.
41:01
If we would now query ndc.trafficmanager.net, we would get back a list of addresses. I should probably set the type to CNAME first. We get back Bing in this case, I think.
41:22
Oh no, it points to Google. If we do this within 30 seconds, we might get Bing, or it might still stay Google. Let's wait a little bit for it to refresh. This is how it works. The DNS server knows all its different endpoints, checks if they are up and running.
41:41
If I would make a typo in Google.com and it would no longer resolve, I would always get Bing in the result here. It doesn't switch, but it can happen because I don't control this DNS server and traffic manager may decide to just stay on Google.com in this case. The nice thing is, it is intelligent and based on where you are coming from
42:02
or the status of your service, you will get a different record. That's interesting if you are building an application that you want to build either globally or want to just keep available in multiple data center regions and things like that. A service like this is really useful to work with. Now we get Bing. You see, it actually changes round robin.
42:24
Another way you can use these intelligent DNS servers is if you are building your own CDN. If you want to deliver content to your users and you want to make sure that the content comes from a location close to the user, what you can do is see what's the source IP of the one requesting the domain name
42:40
and based on that IP, decide on the location of the service you will return as a result of the DNS query. If you are in the EU and you want to get content from the EU, the DNS server would return that information instead of the server in the US, for example. That's how you can work with a CDN. The other option most CDNs actually use is IP Anycast, where around the globe
43:02
they just announce the exact same IP address. Like Akamai, for example, they just announce the same IP address everywhere and because of the way routing works on the internet, they just are available there. I did find a CDN, which is a Swiss-based CDN. If you look up their domain name,
43:28
you will get back a result pointing, in this case, to a server in the UK. This means their CDN is hosted in the UK and for them or for their network, the NDC network is closer to the UK
43:42
and they will serve it from there. If you would do this in the US, you would probably get an address in the US where you would request your data from. There are two approaches to building a CDN, and this one is, I think, a nice one as well. Another way you can use DNS in your application infrastructure is to use it for configuring your services.
44:03
Since DNS is just a key value pair and a type of value as well, you could basically spin up a DNS server and have your configuration value in the DNS and you would just use the DNS protocol to get the configuration values from your machine.
44:20
The nice thing about that is DNS supports recursion. Imagine you have a development environment, staging environment, production environment, and you have some global settings that should apply everywhere. What you can do is spin up a DNS server in each of these environments, have one DNS server that is accessible from all these environments, and just use recursion to get the values
44:42
from that one server, and otherwise get the values from your environment-specific DNS server. Let's see how you can do that. I'm going to close this one. I basically wrote a small library
45:01
which has a configuration client and a configuration server. This configuration server, let's build it first, this one basically hosts the DNS server and has a master file which contains resource records that have a key and a value. Not very special, this code. If we go to the actual server implementation,
45:22
you will see that I'm actually adding database connection strings to my DNS records and so on. By the way, probably this is not the way to go because you would be exposing all your secrets in this DNS server as well, and anyone on your network would be able to query it. Just as an example, you can store certain types of configuration data in here.
45:42
Let's run our server. Where is it? Let's run this one. If, even using nslookup, we set the server to our local host and we would set the type to txt
46:02
because that's the only type of record that I'm actually serving, and I would want to get my storage credentials, I would just resolve storage and it would give me back a response. It should be this one. Did I do something wrong?
46:22
Weird. Did I start the server, actually? Let's try it one more time. If not, we'll just keep it conceptual. It actually got the request,
46:41
but it's not getting the response back. Maybe something flaky on the network here, but we'll see. TB1. No, it's getting the request, but it's... Ah, now it got the database connection string from the DNS. This is how you could configure your service,
47:02
and because the protocol is already there, I could host my DB1 connection string, for example, on a parent name server and just use recursion to get data from there. Now, to be fair, I don't think using this type of configuration server based on DNS is the way to go.
47:21
I don't think it's a good way to do it because you still have to maintain your entire list of all the different resources that you have. You still have to make sure that you have this custom DNS server implementation and so on. What you could do is just use a standard DNS server and just make queries there as well. Even that is quite cumbersome.
47:42
The reason for that is, first of all, again, you have caches, caches, caches. If you would change your connection string and your connection string is cached for a day, you have an issue. Also, it's not very flexible. Imagine you are building a service where you can provision new services in the environment at any given time
48:02
based on, for example, the loads of the application. The issue there is, how are you going to add it to the DNS server in that case? Are you going to spin your own thing and register it in there and do things like that? Probably not. How are you going to maintain all these things across different environments and so on?
48:21
Well, it's quite cumbersome. You have to have all that data. Luckily for us, there are a couple of nice techniques that you can use to still use DNS for service discovery but in a slightly different way. Service discovery is actually a nice thing that Apple sort of reintroduced with iTunes and their iPods and so on.
48:43
It's kind of magic if you have iTunes running and you open your iPhone or your iPad. Both the application and the cell phone or your MP3 player can actually find each other. Well, that's because they use service discovery to discover each other in the network.
49:00
You can use different things there. You can use universal plug-and-play to open specific ports in a firewall, for example. You could use the service location protocol to do this. Or use ZeroConf, which is what I'm about to demo. That's actually a very nice technique. ZeroConf actually uses multicast DNS.
49:21
There are a couple of IP ranges that are private. There are a couple that are used on the Internet. There are a couple that are used for multicast protocols. For example, multicast DNS runs on this specific IP address you see on the slides. What does that mean? It means that anyone in your network can listen on this special address
49:41
and they will all get that data. If I make a request to this IP address in this specific port, any device on my network listening on that address and that port will actually respond and be part of the response that I'm sending. Which means if I run some sort of a DNS server that knows about just itself
50:02
and listens on this specific IP address, the service itself can respond to DNS queries with its own information. Imagine I'm searching for the database. Well, I can just ask the network on this specific IP address, database, and whoever holds the database will respond me with the details that I require for that.
50:23
That's actually really nice. And you're actually using this today. If you're using iTunes, if you're using anything Apple-related, you're using service discovery. If you are installing a new laptop and you have a network printer and you go to Add Printers and all of a sudden out of the blue your printer appears in the list of printers that are found,
50:42
that's actually using service discovery as well. Office 365 uses this to discover voice-related services and so on. The way it works is basically every service itself will respond with three different addresses or three different types of information by default
51:01
and potentially some other information as well. First of all, imagine I'm searching for a printer. What will I do? I will connect to this one specific multicast IP address, query printer.tcp.local. I will get back a response from all the different printers in my network saying I'm this printer, this is my name,
51:20
and this is my address, and I have this service called printer. That's the only thing that happens there. Let's try that and let's try and run some service discovery. Again, I hope that the network will work. I have a client and let's maybe just run the client
51:40
to see if this network is properly secured and multicast is allowed or not. If it would be allowed, I would get back a list of devices that my PC can discover, but apparently it's none, so I'll have to spin up my own service. I wrote a little web API, which is quite simple. It just returns hello world and listens on local host port 9,099.
52:03
I'm using a zero-conf service to announce that I am web API listening on TCP and I'm in the local domain. I'm even adding a description saying I'm the awesome API and I run on this specific port. If at any given time in the network I provision a new version of this service
52:22
and I can run one, but I can run 50 or I can run 60 or whatever, each one of these services will announce its own existence to all the different people or different services who are interested in this information. My API is running. I can browse to it and I will get back a nice hello world. The more interesting thing is,
52:41
if I now run my service discovery client, this one will query this multicast IP address and will get back, should get back, there we are, information about my service. It got back that on this specific IP address,
53:01
Martin's awesome API is running. It's this service type, so I can still distinguish on that service type. It's running on port 9,099 and I can even add things like properties, like for example, this thing supports only JSON or this thing supports XML or whatever you want to put in that property set as well.
53:20
Really nice. I can just use service discovery, run my application, spin up new instances of a different service, and the entire application will know the service exists and be able to find it and use it in the application as long as you are on the same multicast broadcast IP address. Can be in one subnet, can be broadcast across different subnets as well.
53:43
Also won't work on Azure. Okay, so that's service discovery and I think it's a quite nice approach of announcing that your services are running and a nice part of an application architecture. All right, there's one more thing I want to show you because it's always fun to abuse technology a little bit.
54:04
Being a speaker, I often end up at airports and at airports you typically want to connect to a public hotspot and you typically get a captive portal asking you to log in or fetch your credit card and pay $50,000 for two minutes of bandwidth that is not more than 10k bits a second.
54:22
You get these things and you cannot browse to any website at all on those networks. What I did find though is that on most of these networks you can just safely resolve DNS. So if you do a DNS query you will get back the IP address even though for HTTP you actually have to log in and pay.
54:42
So what if we could abuse DNS to serve HTTP traffic over this protocol and even benefit from local caching in the airport Wi-Fi hotspot? Let's see if we can. We would need a custom client of course because we are forcing HTTP into the DNS records.
55:01
We also need a custom server. Our server, if we want to have it for multiple clients we probably need a way to identify our clients. We need a way to fetch upstream data from a web server that we want to access, for example. On the client side, we want to expose it as a local proxy so that in our browser we can just point to the proxy
55:20
and browse over DNS and make DNS lookups with our custom server. A couple of things to be aware of. The UDP packet size. Maybe you want to encrypt your transport data as well. If you are on an airport Wi-Fi and you are checking your email over DNS and it's cached for a day in the hotspot's name server,
55:41
you probably don't want that. So there are a couple of things you should take care of. But if you think of all these things you can actually build something that does this. You have your browser. It hits your HTTP over DNS clients. I will trademark HOD because I think it's a cool name. This will connect to my HOD server
56:00
which will in turn make the actual HTTP requests. And a nice added benefit is if I'm on an ISP in a hotspot somewhere I will get caching for free because my DNS records there are cached or actually my HTTP requests are cached as DNS records. So let's see if we can do something like this.
56:21
I had a lot of fun building this thing. Let's close this one. Right. So I wrote my custom DNS server and I decided not to do things like authentication and go with the simplest implementation possible to make this happen. I'll probably first run it so you can see what it does. So you can see how it works.
56:42
I'm using my local server and it should now be running. Let's try. If I want to fetch google.com I hit my breakpoint. I even hit a failure. Okay. Let's see.
57:01
Let's try again. I get back a response saying chunks 19. So I'm actually sending back how many chunks of Google that I have to fetch before I have the entire page. So let's fetch chunk 1. This will give me back HTML as txt records.
57:20
Nicely split into maximum number of 13 records in there. I can get the second part, third part and so on. Just concatenate all that and stream it into my browser. Yay! Airport Wi-Fi hacking almost complete. Now I suck at UI but I also created a DNS browser
57:42
which basically is just a WinForms application that has an address bar without any validation and I can fetch google.com. It will make the DNS records to my custom server and eventually render the page. Of course I didn't do all the external resources loading like images and CSS and so on
58:00
but this is the HTML I get back from Google. Yay! Let's see how Bing renders without CSS. I think it's really ugly. But it works. It's now making an HTTP request and bringing it back to me over DNS. It works but it's not very useful. My browser still needs some work.
58:22
The way I built this was I built my own DNS server which would check if the record that I'm requesting is a txt record. If so, I would get the hostname that is being requested. If it starts with a number then I know it's requesting a chunk. If not, I know I can just fetch the entire HTTP request
58:43
and start responding with the number of chunks or the specific chunk that I'm requesting. Nothing more than that. I think it's less than 100 lines of code to do this. If I would host this server on a server somewhere on the internet, link a domain name to it
59:00
and then have my custom browser hit that domain name for name server queries, things would just work and I would be able to browse without paying or doing anything else. I think it's nice. I found out that I'm not the only guy who is insane and tries to abuse different protocols. There's actually a guy who wrote a daemon that you can run
59:21
and a client as well which is just IP over DNS which means you can run VPN over IP over DNS over TCP and so on. But it's actually quite cool because this guy has a DNS server running that serves just IP. He can connect to it, bring up a VPN and just work wherever he wants
59:41
and use any hotspot he wants without paying or without having to go through the captive portal. Just use DNS for it. The only downside for it is it's ridiculously slow. You only get like one megabits of speed because of all the recursion and the number of requests being made. It's a nice one to look at.
01:00:00
fun. In conclusion, I hope this was a nice talk. Do give me green points. I would really appreciate it. DNS is a hierarchical system. Whenever you make a request, it's always coming from root servers pointing to global TLD servers pointing to a name server somewhere, and you eventually get a result. It was built in 1983, but it's still being used
01:00:23
widely, still being used for pretty much anything we do nowadays with connected services. There's one addition made to the protocol called DNSSEC to at least prove that a DNS record comes from the name server that it's supposed to come from. You can abuse and use DNS for
01:00:40
a lot of things in your application architecture, like load balancing, CDNs, intelligent monitoring of the endpoint, and making sure that you can still access the service. Service discovery is one that I really like. You can just fire up the service and connect to it. Of course, if you want to have some fun with DNS, you can do so as well. Thank you for being here, and enjoy the rest of NDC.