Domain Name System
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 |
| |
| Subtitle |
| |
| Title of Series | ||
| Number of Parts | 165 | |
| Author | ||
| License | CC Attribution 4.0 International: 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/39238 (DOI) | |
| Publisher | ||
| Release Date | ||
| Language |
Content Metadata
| Subject Area | ||
| Genre | ||
| Abstract |
| |
| Keywords |
00:00
Roundness (object)Musical ensembleDomain nameHacker (term)System programmingInformation securityCommunications protocolLecture/Conference
00:42
MereologyDomain nameSystem programmingDirect numerical simulationIP addressMeeting/Interview
01:15
Address spaceEvent horizonIP addressSemiconductor memoryDirect numerical simulationCartesian coordinate systemComputer programmingReal numberRow (database)Utility softwareSystem programmingOperating systemHierarchyInternetworkingType theoryNumberWebsiteCommunications protocolEvent horizonLatent heatDomain nameComputer animation
02:32
Event horizonDirect numerical simulationMultiplication signIP addressCommunications protocolDirect numerical simulationEvent horizonResolvent formalismComputer animation
03:27
Communications protocolTransportschichtDirect numerical simulationAuthenticationDomain nameRational numberEllipseRSA (algorithm)Electronic signatureSystem programmingAlgorithmRevision controlField extensionCommunications protocolDirect numerical simulationFundamental theorem of algebraData storage deviceKey (cryptography)Term (mathematics)Computer animationLecture/ConferenceMeeting/Interview
04:06
Cache (computing)Database normalizationDirect numerical simulationDomain nameRepresentation (politics)Maxima and minimaCommunications protocolHierarchyDatabase normalizationCache (computing)System programmingFile formatData structureNetwork topologyLevel (video gaming)SequenceDomain nameMaxima and minimaRepresentation (politics)LengthCASE <Informatik>Direct numerical simulationRootkitEvent horizonType theoryCartesian closed categoryServer (computing)Computer animation
06:17
Server (computing)Service-oriented architectureAddress spaceType theorySocial classInternetworkingChaos theoryFile formatCountingDirect numerical simulationOpcodeFlagEvent horizonQuery languageSheaf (mathematics)Domain nameServer (computing)File formatAdditionLengthRow (database)Domain nameAuthorizationDirect numerical simulationCommunications protocolInternetworkingType theoryField (computer science)Event horizonBitIdentifiabilityDatabase transactionClient (computing)Address spaceSocial classEmailCartesian closed categoryElectronic mailing listSheaf (mathematics)Multiplication signChaos theoryVector potentialSet (mathematics)Inheritance (object-oriented programming)WeightInformation2 (number)Latent heatCache (computing)Directory serviceOpcodeIP addressLaptopDefault (computer science)Resolvent formalismSystem programmingNumberData structureCodeSoftwareCountingQuicksortQuery languageContent (media)Front and back endsRepresentation (politics)Texture mappingLecture/ConferenceMeeting/InterviewComputer animation
12:27
Event horizonSheaf (mathematics)Server (computing)Domain nameIterationDirect numerical simulationComponent-based software engineeringRootkitCartesian closed categoryIRIS-TInformation privacyQuery languageRouter (computing)Cache (computing)Internet service providerAddress spaceEmailMail ServerMechanism designField extensionType theoryResolvent formalismRootkitServer (computing)Directory serviceRow (database)Domain nameQuery languageResultantIP addressType theoryMultiplication signImage resolutionLaptopEvent horizonIterationDirect numerical simulationInformationSinc functionInformation privacyIn-System-ProgrammierungMereologyClient (computing)Slide ruleService (economics)System programmingMaxima and minimaEntire functionRouter (computing)Sheaf (mathematics)NumberElectronic mailing listFunctional (mathematics)Time zoneCache (computing)EmailDependent and independent variablesTask (computing)Address spaceOvalAliasingAuthorization1 (number)Cartesian closed categoryExterior algebraDiagram
18:29
Address spaceEmailMail ServerField extensionMechanism designType theoryFile formatUDP <Protokoll>Overhead (computing)Maxima and minimaType theoryEmailCanonical ensembleField extensionService (economics)Row (database)Communications protocolDomain nameClient (computing)Server (computing)Address spaceRevision controlResolvent formalismOverhead (computing)Mechanism designVariety (linguistics)Direct numerical simulationSinc functionMultiplication signFrame problemFlagComputer animation
20:38
File formatOverhead (computing)UDP <Protokoll>Maxima and minimaDomain nameComputer networkDirect numerical simulationService-oriented architectureTime zoneHeat transferComputational fluid dynamicsAuthenticationServer (computing)Address spaceChemical equationServer (computing)MultiplicationHeat transferRow (database)Communications protocolDomain nameDirect numerical simulationFault-tolerant systemStructural loadIP addressSchlüsselverteilungLengthOrder (biology)AuthorizationContent (media)Address spaceTime zoneClient (computing)Extension (kinesiology)MereologyPoint (geometry)BitFlagAuthenticationSicSoftwareMechanism designVulnerability (computing)EmailShared memoryNumberMaxima and minimaInstance (computer science)Serial portFrame problemFile formatMultiplication signSynchronizationLevel (video gaming)Lastteilung2 (number)Type theoryDatabase normalizationComputer animation
24:27
Internationalization and localizationResolvent formalismClient (computing)Domain nameDirect numerical simulationMechanism designLastteilungSet (mathematics)Directory serviceRandomizationService (economics)Address spaceInformation securityTelecommunicationQuicksortRow (database)Roundness (object)Lecture/ConferenceMeeting/Interview
25:38
Semiconductor memoryDomain nameDirect numerical simulationCodeDirect numerical simulationDomain nameServer (computing)Centralizer and normalizerPoint (geometry)Point cloudLibrary (computing)Resolvent formalismLecture/ConferenceComputer animation
26:13
Domain nameDirect numerical simulationCache (computing)Entropie <Informationstheorie>Video trackingIterationWebsiteSource codeCASE <Informatik>Database transactionEmailSocial classDependent and independent variablesBitDirect numerical simulationDefault (computer science)TrailLocal area networkDomain nameResolvent formalismType theoryIn-System-ProgrammierungInformationLatent heatFilter <Stochastik>AuthenticationEntropie <Informationstheorie>Cache (computing)WhiteboardComputer animation
28:14
Direct numerical simulationServer (computing)Electronic signatureIP addressResolvent formalismDirection (geometry)Domain nameCryptographyInformation privacyMeeting/Interview
29:03
Public key certificateFormal verificationIterationDirect numerical simulationSurfaceSystem programmingLibrary (computing)Vector graphicsFormal languageFunctional (mathematics)Server (computing)ImplementationAuthenticationComputational fluid dynamicsEncryptionData storage deviceRepository (publishing)Fluid staticsServer (computing)BitDirect numerical simulationResolvent formalismOrder (biology)Information privacyRouter (computing)AuthenticationSystem programmingVirtual machinePublic key certificateEncryptionData storage deviceRepository (publishing)Connected spaceMetropolitan area networkOperating systemFunctional programmingSurfaceVector spaceFitness functionIn-System-ProgrammierungComputer animation
31:04
Public key certificateFluid staticsEncryptionDirect numerical simulationServer (computing)Validity (statistics)Cache (computing)Server (computing)Database normalizationPublic key certificateData storage deviceKey (cryptography)Sign (mathematics)Direct numerical simulationCommunications protocolPublic-key cryptographyDynamical systemMatching (graph theory)AuthenticationWeb 2.0Type theoryProjective planeCache (computing)EmailEncryptionRow (database)Musical ensembleMetric systemComputer animation
32:49
1 (number)NumberPlanningBitData storage deviceAxiom of choiceLecture/Conference
33:26
EncryptionPlanningRevision controlINTEGRALOffice suiteBitDirect numerical simulationNumberHecke operatorProxy serverDifferent (Kate Ryan album)LastteilungPoint (geometry)Structural loadLecture/ConferenceMeeting/Interview
34:02
Point (geometry)Proxy serverSet (mathematics)Structural loadInstance (computer science)Connected spaceService (economics)LastteilungNumberDirect numerical simulationWebsiteServer (computing)Roundness (object)State of matterLecture/ConferenceMeeting/Interview
34:59
NumberMultiplication signDirect numerical simulationRoundness (object)Connected spaceField extensionPoint (geometry)Group actionLecture/ConferenceMeeting/Interview
36:15
System callInternetworkingMappingSign (mathematics)Domain nameTrigonometric functionsMusical ensembleRow (database)Electronic mailing listField extensionAuthorizationNumberType theoryDirect numerical simulationMultiplication signLecture/Conference
37:07
GeometryNumberMultiplication signDirect numerical simulationUniform resource locatorFlagData centerIP addressField extensionMechanism designDifferent (Kate Ryan album)Client (computing)InformationServer (computing)Lecture/ConferenceMeeting/Interview
38:50
Arithmetic meanDirect numerical simulationNumberPoint (geometry)Server (computing)InformationProxy serverBit rateClient (computing)SoftwareField extensionWeb 2.0Communications protocolGroup actionGame controllerDomain nameFerry CorstenMultiplication signPublic key certificateInternetworkingOrder (biology)Wireless LANSelf-organizationSphereImplementation1 (number)ChainMoment (mathematics)Lecture/ConferenceMeeting/Interview
41:06
Moment (mathematics)Direct numerical simulationResolvent formalismMusical ensemblePoint cloudSelf-organizationIndependence (probability theory)Physical lawEnterprise architectureService (economics)Information privacyInternetworkingLecture/ConferenceMeeting/Interview
42:12
Semiconductor memoryCartesian closed categoryStorage area networkMusical ensembleLecture/ConferenceDiagram
Transcript: English(auto-generated)
00:18
Because our talk is about to begin.
00:20
It will be domain name system, the hierarchical decentralized naming system used since 30 years. It will be by Hannes Miernat, Mirage OS hacker, who has been developing security protocols TLS, OTR and others, and is a coffee nerd. Please give him a warm round of applause to welcome him.
00:49
Thank you. As Karen was mentioning, I'm Hannes, and I will talk about the domain name system. This is part of the foundations track at this conference, so if you already know a lot of
01:01
details about DNS, I don't expect you to learn anything new. And if you don't know anything about DNS, I hope to explain it to you. So what is DNS all about? Well, its purpose is to resolve human-readable and human-memorizable host names to IP addresses.
01:21
That is the only purpose of DNS. So it's basically very similar to a phone book. You may know it from the old days. It's a piece of paper or a real book where you can look up a human name and find their phone number in a specific city. But DNS is actually not as static as a phone book, but it's de-centrally managed.
01:46
So we can push updates much more frequently, and we have a de-central and hierarchical delegation system so that people who own a domain name, they can update their records.
02:01
And DNS is used in a lot of applications and all around the internet. So there's a command line utility called host on Linux and other Unix operating systems. And if you type in host of events.ccc.de, which is the main website and so on, you
02:22
get a reply from this program, and this program uses DNS, so the protocol I'm talking here about in the background, and requests a record for it. Obviously, host then can also fail if the name doesn't exist at all. But here, host of events.ccc.de returns an IP address which is 195.54.164.66.
02:51
What is DNS as well? Well, DNS is specified by the IETF which is the Internet Engineering Task Force as a collection
03:00
of RFCs. It started in November 1987, so more than 30 years ago, with RFC 1034 and 1035, which specified the basics of the fundamental protocol on how to resolve host names into IP addresses. And DNS has evolved over time, as you might be able to see here, and DNS is nowadays
03:27
maybe 20, 30 or 40 different RFCs, so it's a quite complex protocol, but the same basics and the same fundamentals are still used. And since DNS is used since 30 years, I expect it to be used for another 50 years or so.
03:47
So I believe that we won't outlive DNS so that DNS will be around when I die. That's why I care about DNS. DNS in other terms is a distributed key value store which has been standardized and specified
04:07
30 years ago. It uses a hierarchical name system, and it uses delegations to get some decentralization aspect in there. It has a built-in redundancy and built-in caching into the protocol itself.
04:23
So let's look how the names look in DNS. So we saw as a first example events.ccc.de, and the name system as I mentioned is hierarchical, So it is a tree-like structure. We have the root at the top. The root is empty here.
04:41
And then below the root, we have, for example, the top-level domain DE and the top-level domain ORC and other top-level domains. Then below the DE, we have also some second-level domains like CCC and various others here.
05:00
And then below CCC, we have, for example, the events name. So it's a tree-like data structure. Each domain name, so a domain name is events.ccc.de, consists of a sequence of labels which are separated by the dot character.
05:21
So if you actually type events.ccc.de, the DNS protocol itself knows it is the top-level domain name is DE, then you have the second-level domain name which is ccc.de, and the third-level domain name is events.ccc.de. Each label now may contain only alphanumeric characters, which is A to Z, lower and upper
05:45
case, and 0 to 9, and dashes, but dashes may not be the first character. The label length may be only between one and 63 characters. And the textual representation, so the representation using the dot format, which is events.ccc.de,
06:06
for example, has a maximum length of 253 characters. Domain names are case-insensitive. So in any casing, whichever casing you ask a DNS server for, you will always get the
06:23
same answer. The data format. The data format on the wire is in respect to some requests, so your client or your resolver asks request to some service, and the request is triple of a name, which we
06:41
just saw, then a record type and a class. The reply contains the very same information, so a name, a type, and a class, but additionally it includes a time to live, a length, and a data field, and the data field is interpreted differently depending on the type.
07:04
The time to live field specifies an amount of seconds for how long this resource record may be cached. So we have built-in caching and cache timeout. What are potential types or resource record types?
07:21
There's one which is the address record which we just saw. It's also called a record. Then we have other types like name server record which is also named NS, and start-up authority which is Zoa. The classes which we saw up here, so it's a triple where we now discuss the name and
07:43
the type, and the class is usually used internet. That is basically the only one used in today's networks. But there are others as well as DNS was developed back then. There's also a chaos net which is not really used these days.
08:04
How does a DNS packet look like? So we have a request, a request is this triple, and the reply is a set or a list of these triples together with the time to live and some data. A DNS packet has a header of 12 bytes, but the first two bytes are some transaction
08:26
ID, so some identifier which is just echoed from the client to the server. Then we have the next 16 bits which contain flex, the operation code and the return code,
08:41
and then we have four fields which are each two byte in length and they contain the amount of questions, answers, the amount of authorities and the amount of additionals. And then after this 12-byte header, we have arbitrary length of these things. So an arbitrary number of questions, well, a number of questions as specified in the
09:06
question count, then answers, then authority and then additionals. Each of the questions as mentioned earlier is this triple, and all the other fields are this whole structure.
09:23
So how does, we've seen a host command, and now there's a different command called DIC which is used for debugging and for looking into DNS packets. If I type into my laptop DIC of the record type A, so I want to resolve the host name
09:45
events.ccc.de with an A record, so I want to get the address record off of that. And I'm asking now not my default resolver, but the specific name server which is this ns.ccc.de which is an authoritative name server for that domain.
10:04
I get back as a textual representation here. So DIC also uses a DNS protocol in the back end, and I get here as an answer back. First I get the question repeated, so I get events.ccc.de, then I'm in the class internet and then
10:21
I'm using the resource record type A, so I'm interested in address records. I also get an answer which is events.ccc.de, the time to live is 600, which is five minutes. Then also the class is in, the record type is A, and then the actual content,
10:41
the actual data is now the IP address we've seen it earlier. Then I get some additional information in the authority section, I get which name servers are responsible for this domain. So for events.ccc.de, I also get time to lives.
11:00
And then name server entries, one is ns.ccv.de and the other one is ns.ccc.de. And then I get some additional information, namely that ns.ccv.de has also an IP address down here.
11:20
So how does this whole delegation, we have now seen names and the query, how does the delegation system work together? Well, first of all you need to set up your name service for the specific domain or subdomain, so you need to insert into your name server some name server records and some start of
11:42
authority records. And then for the subdomain you want to serve, you need to insert into the super domain, so into, for example, ccc.de, you need to include the delegation that now my name servers are responsible for this subdomain.
12:04
What is this start of authority resource record type? Well, it consists, so if you, you can also use DIC to request other resource record types. For example, the start of authority as done here, and then you get as an answer, and
12:21
I only copied the answer section here, you get events.ccc.de, then a time to live again, and then you get the start of authority record. That one contains, first of all, which name server this information originated from, then an email address where the first ad is replaced by a dot character, which is the responsible
12:46
email address for that zone, then a serial number which is here, pretty high, and then some timers when you should refresh things in the zone and what is the minimum time to live in that zone.
13:02
Then if you ask for the name servers of events.cc.de, we just saw that as a part of the authority section, but if you specifically ask for the name server records, you get those two names of records back, and you get as in the additional section again an IP address.
13:23
DNS works that you have now a service, and service have some delegation, and the root of the system is part of the root service, so they are organized or deployed by IANA, and every resolver or every client has information about which are the root name
13:44
servers whom you can ask to do resolutions. So how does a resolver work? So on the other side, we have a resolver, and there are two kinds of resolvers, one is an iterative one and a forwarding one, and I will go into detail of an iterative resolver.
14:01
So my Unix system, my laptop, for example, asks by using the get host by name API, asks for the record for events.cc.de, and that one sends a query out to the local configured resolver, which asks for the resource record type A, and then for the domain
14:24
name events.cc.de. What does the resolver do? Let's consider the resolver doesn't know anything apart from the root name service. Then it queries, oh, what is the name server? Who is responsible for the DE domain to the root name service? They reply with, oh, here's a list of name servers which are responsible for that.
14:43
The resolver then asks that name server, one of these name servers, what is the name server for ccc.de? That one replies with those name servers. Then it asks, oh, who is responsible for events.cc.de? And that one replies with the IP address.
15:02
This IP address is then answered by the resolver to the get host by name Unix function. That's how an iterative resolution step works. So you have noticed there are multiple packets from the resolver sent to various
15:22
other hosts, and now here the hosts only have names but no IP addresses. So how does the resolver actually know who is z.nic.de? That is a problem which is also called glue, so DNS answer, as we have seen earlier, needs
15:44
to include some IP address if the name server is inside of the domain of the responsible server. So since events.ccc.de, since the name server for cccv.de is also responsible for cccv.de,
16:03
whenever you ask it for a name server and it says, oh, it's ns.ccv.de, it also needs to reply, oh, by the way, ns.ccv.de has the following IP address because otherwise you wouldn't be able to find out which name server or which IP to ask.
16:21
The iterative resolution I just showed in the earlier slides uses query name minimization to improve privacy. That is a concept that you don't ask the top level, so that you don't ask the root name server for the entire address, for the entire domain name, so you don't ask the root name server for who is events.ccc.de.
16:45
This is a privacy feature which has been standardized in 2016 and is nowadays deployed by at least some resolvers but not by all. It is a privacy feature because otherwise you leak the information to the root server
17:01
which host you are interested in. What about caching? Well, every resolver, since there's time to live for every resource record set, every resolver can as well cache all the data and all the records and then reuse the cache data for new replies.
17:24
Usually, a set-up looks like I have my laptop over here and then I have on my router likely a DNS resolver, a forwarding resolver which doesn't do iterative queries but which just queries all the time another resolver run, for example, by my ISP.
17:45
And that resolver run by my ISP is then asking the alternative name servers. That is a common set-up. Another set-up, another possible set-up is that you just don't ask the ISP name server
18:04
but you just ask your router and that does iterative queries. The resource record types I just showed to you, the three ones, are not, that is not a complete list, there are many more.
18:20
Some useful ones which I use quite a lot is, for example, a way to introduce aliases. So if foo.example.com should always redirect to bar.example.com, we can use a so-called CNAME or a canonical name resource record.
18:40
That one will just reply to every query for foo.example.com independent of the resource record type which is requested with, oh, look at bar.example.com. Another resource record type is MX records or mail exchanges which contain a priority and the name of the mail server which is responsible for this domain.
19:05
Then, similar to the address records, we also have quad-A records which are used for IP version 6 addresses. So, A for IP version 4 and quad-A for IP version 6.
19:20
TXT is a record which just contains some text data and it's used by a variety of protocols. E-DNS is an extension mechanism and the extension mechanism is also done just by using DNS and resource record types. So they have an in-protocol extension mechanism which is pretty interesting and pretty nice.
19:45
I mean, DNS, since it's 30 years old, has to be developed over time and you need to, whenever you want to extend it, you have to be sure to be backwards compatible because you have a huge deployed server and resolver base out there. So you don't want to end up in interoperability problems with earlier versions.
20:05
E-DNS has been developed a long time ago but there's next year a flag day to say, oh, now it is actually required and server should behave well if there are E-DNS records requested by the client.
20:24
What transport does DNS use? Usually it uses UDP because it has a very low overhead, only 8 bytes of header and a very low delay. But you can also use DNS over TCP and that is actually done if the reply is too big for a UDP frame.
20:44
And then if the reply is too big, it is just truncated at the point, let's say 512 bytes, and the flag in the DNS header is said that, oh, by the way, this answer is now truncated.
21:02
And then the requester has to re-request or can re-request the same request using TCP. TCP then requires it to set up a whole TCP session. TCP, if you use DNS over TCP, it uses the very same packet format as we have seen earlier
21:22
but it's prefixed by the length of the content. And the E-DNS resource record we just saw, that contains or carries the datagram size of the UDP, of the maximum UDP packet.
21:41
What more about DNS? Well, first of all, if you want to register a second level domain, you are forced to run at least two authoritative DNS servers which are in disjoint IP networks in order to have
22:00
some fault tolerance because one IP network may be offline or the routing may be broken at any given time, and in order to resolve your host name, you need to have another one so that clients will always be able to resolve that.
22:20
You can now, since you are running multiple instances of the same data, you need a way to synchronize that. DNS has a methodology called zone transfer to do that within the protocol itself. And this zone transfer uses the serial numbers in order to compare with the zone transfers actually needed, and also some timers which are part of the start-up authority resource
22:45
record type. So it's all very much in the protocol encoded how you can do synchronization and fault tolerance and redundancy. DNS has also extensions in order to do dynamic updates, so instead of having to
23:02
restart your server whenever you reconfigure it, you have an in-protocol update where you can say, oh, now let's add this domain name with this IP address, or let's remove this domain name. Since now we have DNS updates and only the timers for the secondary for the synchronization,
23:23
there's also a notification mechanism specified. So the primary server where you do the updates, where you do the dynamic updates, that one then tells or notifies the secondary name servers to say, oh, by the way, the serial number of my start-up authority has increased.
23:41
Please update yourselves. And since sometimes if you want to do updates, you don't want to allow it to everybody, and only filtering by IP addresses might be a bit weak, there's an authentication mechanism called TSIC, which usually uses HMAC secrets, so shared secrets, which you need to preshare
24:04
across the different servers, but you can also use some Diffie-Hellman key exchange in that layer. You can use DNS to do load balancing. So if you encode multiple address records for the same name, the server will reply
24:22
with all of them in a random order to all of the clients, so to all of the requesters. And the requester will pick the first one, or again, one at random. And so if you have two address records for the same domain name, the probability
24:42
that roughly half of the clients will use one of the address records and the other half will use the other address is very high. So we can actually do some sort of load balancing via DNS. This is also called DNS round robin. More DNS features, well, there's some security mechanism which has been specified
25:05
and standardized, but it's not yet mandatory to use. And it only protects, well, it mainly protects the iterative resolver, the communication between the iterative resolver and the authoritative name service.
25:20
DNS is also used in a multicast setting for service discovery. Something like rendezvous or zero conf. That is all based on DNS. DNS can also use internationalized top-level domains and domain names by using some puny code encoding for them.
25:43
What are DNS threats? There's on the one side a censorship. So anyone who runs a DNS server can filter domain name. Or if you use a DNS resolver like the one from Google or the one from AT&T or the one from Cloud Fair, they can at the central point filter domain names in there.
26:08
And don't give you any reply, for example, for domain names they don't like. Like libgen, the library genesis.org is in such a problematic situation.
26:21
In some countries there are people or some governments want to filter certain websites and they do that by requiring all the ISPs to have filters for specific domain names. Cache poisoning is another threat. So since DNS by default doesn't use any authentication and every request has a very
26:44
low entropy, so it's very static, an attacker, for example, in the local network can just reply with a huge amount of replies and maybe faster than the other one. So the low entropy is because we only have the 16 bits in the header as a transaction
27:05
ID and apart from that we can only do some entropy by modifying the casing of the domain name and that's it basically. We can also play with the UDP source board to get some more entropy.
27:21
What else is a threat is definitely user tracking. So if you run a central resolver which is used by a lot of people, you see a lot of information from all of those people and you can track those people. So you know about which domain names are around, which domain names are asked for and so on.
27:45
Another issue which has been discovered in DNS was amplification attacks, so-called amplification attacks. And the issue here is that your request, your DNS request is usually very small.
28:01
So it has a 12-byte header and then only contains the domain name, type and class. Whereas the response to it might be very huge, especially if you use DNSSEC and use a cryptographic signature on that. So the ratio between the bytes you requested versus the bytes which was replied with is
28:26
very small. So as an attacker, you can fake your IP address and ask a resolver with your fake IP address with a lot of very small packets and that DNS server will then reply to that fake
28:43
IP address with a lot of large packets. So you can amplify your attack instead of putting all the packets to your victim directly. You put them first to a DNS resolver and the DNS resolver will amplify it and put that all onto the victim.
29:03
DNS over TLS is another privacy enhancement. It's specified in RFC 7858 and it's a connection between the caching resolver and the iterative resolver, so between your router and the iterative resolver. You have to verify the certificate of the iterative resolver and the iterative resolver
29:26
needs to be trusted to avoid any man in the middle and it protects against eavesdroppings and modifications. So if you are in a country where DNS is censored, you can use DNS over TLS in order to connect to some remote server, some other country where DNS may not be filtered.
29:45
And you might happen to know some people who run such iterative resolvers and who are more trusted than your ISP servers. I think I'm now basically near by the end of my talk.
30:04
I will talk a bit about MirageOS, which is an operating system with a very tiny attack surface and less attack vectors than a Unix system and it's developed in a functional language called OCaml. And DNS and MirageOS, how does that fit together?
30:24
Well, I implemented over the last years the DNS server and resolver, including dynamic updates, authentication, using hmax-secret, let's encrypt was also implemented by other people and I also integrated it there.
30:41
We have persistent storage in a git repository and we can provision those let's encrypt certificates using the DNS challenge so you can get a certificate from let's encrypt. How does that work out? Well, the idea is you start a virtual machine or a MirageOS so-called unicon with
31:05
a static seed just for a private key and an hmax-secret and that one then generates a private key from the static seed and a certificate signing request. Now it requests the certificate from a DNS server, which uses another resource record
31:24
type called TLSA, used, well, specified in the Dane project. And then if that certificate is found and the private key matches and the certificate is still valid, then we continue and can serve some web server or some mail server.
31:42
If it is not found, then the certificate signing request is uploaded to the DNS server and the DNS server is then pulled periodically for a certificate. In the meantime, another unicon which is a DNS server is notified and
32:04
communicates with the let's encrypt and tries to provision that certificate. So that's how I do my deployments of DNS and let's encrypt signed certificates. So I'm now at the end of the talk to conclude.
32:22
DNS is widely deployed and has been around for 30 years. I believe it will be around for another at least 50 years. It's a redundant and federated distributed key value store and it already includes in protocol caching and dynamic updates and authentication. So it's a pretty complete protocol.
32:44
That's it from me. Do you have any questions? And the questions works as follows. You stand up behind the microphones and then you're allowed a question and not a comment.
33:01
And those of you leaving, please leave quietly so that we can do the Q&A. We have a question from microphone number one. Yeah, I got a question regarding merge OS. What are your plans for 2019? So like I think we have the new release of Furman coming up,
33:21
but what do you guys have in store for next year in general? I think that's a bit out of scope for this talk, but we are organizing heck of retreats in Marrakesh again next year, and we have some plans for next major version of Mirage OS and also of integration with the DNS and automated let's encrypt things.
33:43
I also want to integrate some DHCP stuff in there. We have some questions from microphone number two. What would be like the pros and cons of using DNS for load balancing versus running a different load balancer like HAProxy?
34:02
Well, with a proxy you have at the end a single point which needs to handle all the load, so which needs to handle all the connections. Whereas with DNS-based load balancing, you can just set up a set of servers which all gets distributed load.
34:21
But with a load balancer or with a proxy in front of that, you have the advantage that you have a single point where all the connections are flowing, so you have a central instance. Some in some setups DNS round robin is not very suitable, but in others it is.
34:42
So if you need some common shared state between all of the connections, you better use a proxy and have somewhere the shared state. Whereas if you don't have shared state, like if you have a static website or a static server, then you can use DNS round robin and you don't lose anything. Next question from microphone number two.
35:02
Hi, in the last time I heard about techniques like DOH, DNS over HTTPS, what are the pros and cons? Well, DNS over HTTP is now an extension where you don't have to use UDP or TCP,
35:22
but you can transport DNS directly over HTTP, which is an advantage if you already speak HTTP and you are happy with JSON and so on. But it also adds some more work, some more data,
35:40
because you need to do a HTTP request for getting that data. So there are some pros and cons in various setups, and the DNS working group at ITF is currently discussing the whole DNS over HTTP in detail. So one disadvantage is that usually with DNS you use UDP and you have a very low delay,
36:02
whereas if you use TCP, you have to first do the connection establishment and you lose quite some round trips until you get to the point where you can send and receive data. I can see from the signal angel, we have a question from the internet.
36:24
Useful for ham radio like mapping call sign to domain name or vice versa? I didn't understand the question, can you repeat please? Do you know if there's any DNS extension useful for ham radio?
36:45
I unfortunately don't know that, but Jana, the internet authority for names and numbers, they have assigned all the resource record types and that is a central list
37:01
and you can browse it, so you can maybe find it in there. There is still time for more questions, so please get out of your seat if you have a question, there will be time for your question as well. Question from microphone number two please. Hey, my question is about a geo DNS and so for example if I want to connect to Wikipedia.org
37:23
from Singapore or from Europe, so I would connect it to a different data center, how that's being handled by DNS? Well, DNS it depends, so you can set up for example your DNS servers as anycast notes and anycast is a routing extension or routing mechanism that you have the same IP address at
37:48
different geo locations and then the closest one is used. So using that mechanism you can have your data center in Singapore and your data center in Europe both sharing the same IP address for the name server and then hand out in
38:04
your Singaporean data center an IP address which is also hosted in Singapore and in your European data center one which is in Europe. You can also use, well the one motivation for the EDNS flag day for next year is to
38:20
be able to deploy that and to deploy having the ability as a client to add some information into the request about its own IP address. So if you know at the server side that your client is hosted in Europe, you can reply with an IP address that is also in Europe.
38:41
So there are various mechanisms and you have to find out and choose which one is suitable for you. One more question from microphone number two. Could you elaborate on DNS tunneling attacks as a means to transport information, exfiltrate information out of an organization like in order to get undetected?
39:06
Unfortunately I didn't talk too much about exfiltration but certainly since DNS uses these domain names you can in a request already impose or include some information
39:20
like using the domain name and using an automatically generated domain name or encode some information in the domain name and then if you are in control over the server you can exfiltrate some data from the client or the client network to the server which is very useful if you are in scenarios where your client shouldn't be able to connect to the outside
39:43
but DNS is fine and DNS also works via the proxies so you can exfiltrate information using DNS and domain names and then as well you can there are even implementations that you can talk IP over DNS so if you are in some setups where for example a wireless network hotspot
40:03
where all internet access is forbidden and you have to pay money for it but DNS is still open then you can have if you are in control over the server and over your client then you can actually communicate via DNS over that not paid for wireless hotspot.
40:28
We're nearly out of time we have two more questions first from microphone number one. Hi, how useful do you judge DNS to ship certificates for other protocols like SMTP or
40:41
for the web? I think that is very useful if we would have a trust chain in DNS so for example using DNSSEC if we have DNSSEC and we have a trust anchor then we could ship any other certificates just via DNS there's the Dane protocol working the Dane working group
41:03
working on that extension and I think the weakest point at the moment is that DNSSEC deployment is not so huge or is not widely deployed. So the last question is from the internet. What do you think about using DNS services
41:25
from big enterprises like Google, Cloudflare and so on concerning privacy? Yeah you shouldn't use that there are independent DNS resolvers run by non-profit organizations which also have some data privacy laws and they don't log anything
41:48
so I would recommend to not use those 1.1.1.1 or 8.8.8.8 or 9.9.9.9 do not use those centrally organized DNS resolvers because there you don't pay anything but
42:06
the company nevertheless gets all your data. What you should do though is thank Hannes for his talk.