Dear viewer, these subtitles were generated by a machine via the service Trint and therefore are (very) buggy. If you are capable, please help us to create good quality subtitles: https://c3subtitles.de/talk/1076 Thanks!
[Music]
because our talk is about to begin it
will be domain name system the
hierarchical decentralized naming system
used since 30 years it will be by Hannis
manat uh Mirage OS hacker who's been
developing security protocols TLS OTR
and others and is a coffee nerd please
give him a round a warm Round of
Applause welcome
him thank you as Ken was mentioning I'm
Hanes and I will talk about the domain
name system this is a part of the
foundation track at this conference so
if you already know a lot of details
about DNS uh I don't expect you to learn
anything new and if you don't know
anything about DNS I hope to uh explain
it to you so what is DNS all about well
its uh purpose is to resolve human
readable and human memorizable host
names to IP addresses that is the only
purpose of DM 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 um not as
static as a phone book but is
decentrally managed so we can push
updates much more frequently and we have
a decentral and
hierarchical um delegation system so
that people who own a domain name they
can update the
records and DNS is uh used in a lot of
applications and all around the 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. cc. which is the main
website and so on you get a reply from
this program and this program uses DNS
so the protocol I'm talking here about
in the background and requests record
for it obviously host then can also fail
if the name doesn't exist at all but
here host of events. CCC dode returns an
IP address which is
19544 541
16466 what is uh DNS as well well DNS is
a specified by the ietf which is the
internet engineering task force as a
collection of rfc's it started in
November 1987 so more than 30 years ago
with RFC 1034 and
1035 which specified the basics or the
fundamental protocol on how to resolve
host names into IP
addresses um and DNS has evolved over
the time as you might be able to see
here and DNS is uh nowadays maybe 20 30
or 40 different RFC so it's a quite
complex protocol but the same Basics and
the same um fundamentals are still used
and since DNS DNS is used since 30 years
I expected to be used for another 50
years or so so I believe that we won't
outlift that we won't outlift 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 uh
standardized and um specified 30 years
ago it uses a hierarchical name system
and it uses delegations to get some
decentralization aspect in there it is
it has a built-in redundancy and
built-in caching into the protocol
itself so let's uh look how the names
look in DNS so we saw as an as a first
example even
cc. and the name system as I mentioned
is hierarchical so it is a three like
structure we have the root at the top
the root is empty here 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
and then below CCC we have for example
the event uh name so it's a Tre like
data
structure each domain name so a domain
name is events. CCC dode consists of a
sequence of labels which are uh
separated by the dot character so if you
actually type events. CCC dode the DNS
protocol itself knows it is um the top
level domain name is De then you have
the second level domain name which is
CCC dode and the third level domain name
is events. CCC do e each label now may
contain only alpha numeric characters
which is a to z lower and upper case and
0 to 9 and dashes but dashes may not be
the first character the label length U
may be only between 1 and 63 characters
and the textual represent ation so the
representation using the dot format
which is events. CCC for example has a
maximum length of 253
characters domain names are case
insentive
insensitive so in any casing whichever
casing you ask a name a DNS server for
you will always get the same
answer the data format the data format
on the wire is uh in respect to some
requests so you your client or your
resolver asks request to some service
and the request is a triple of a name
which we 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 uh differently
depending on the
type 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 cach
timeout what are potential types or
resource record types 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 of
authority which is
z um the classes which we saw up here so
it's a triple where we now discuss the
name and the type and the class is uh
usually used
internet that is basically the only one
used uh in today's networks but there
are others as well as DNS was developed
back then there's also a chaos net which
which is uh not really used uh these
days 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 uh triples together with a time
to live and some
data a DNS packet has a header of 12
bytes for the first two bytes are some
transaction ID so some identifier which
is just echoed from the echo from the
client to the
server um then we have the next 16 bits
which are which contain Flex the
operation code and the return code and
then we have four fields which are each
two by in length and they contain the
amount of uh questions answers the
amount of authorities and the amount of
additionals and then after this 12 by
header we have uh arbitrary length um of
these uh things so an arbitrary number
of questions well a number of questions
as specified in the 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 um this whole
structure so how does we we have uh seen
host commands now there's a different
command called dig which is used for
debugging and for looking into um DNS
packets if I type into my laptop a dick
of the record type A so I want to
resolve the host name events. CCC dode
um with an a record so I want to get the
address record of of that and I'm asking
now not my default resolver but the
specific name server which is this ns.
cccv dode which is an authorative name
server for that um domain I get back as
uh a textual representation here so dick
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
evens.
cc. then I'm in the class internet and
then I I'm using the resource record
type A so I'm interested in address
records I also get an answer which is
even
cc. the time to live is 600 which is 5
minutes then also the class is in the
record type is a and then the actual
content the actual data is now the IP
address we've seen it earlier then I get
uh some additional information in the
Authority Section I get which name
servers are responsible for this
domain so for events.
cc. I also get time to lives and then
name server entries one is ns. CCC cccv
dode and the other one is ns. cc. and
then I get some additional information
namely that ns. CCC v.e is um has also
an IP address down
here 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
authority
record and then for the subdomain you
want to serve you need to insert into
the Super domain so into for example CCC
dode you need to include the delegation
that now min name servers are
responsible for this
subdomain what is this start of
authority um resource record type well
it Con consists so if you you can also
use di to request other resource record
types for example the start of authority
as done here and then you get as an
answer and I only copied the answer
section here you get events. cc. then a
time to live again and then you get the
start of Authority record that one
contains um first of all which name
server this information originated from
then an email address where the first
add is replaced by a DOT
character which is the responsible email
address for that zone then a serial
number which is here pretty high and
then some timers when you should refresh
uh things in the zone and what is the
minimum uh time to live in that zone
then if you ask um for the name service
of events. CCC we just saw that as a
part of the Authority Section but if you
specifically ask for the names of our
records you get those two names of
record back and you get as in the addal
section again an IP
address the as works that you have now a
service and servers have some delegation
and the root of the system is um part of
the root service so they they are um
organized or um deployed by aana and
every resolver or every client has
information about which are the root
name service 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 iter
ative resolver so my Unix system my
laptop for example asks by using the get
host by name um API asks for the record
for events. CCC and that one sends a quy
out to the local configured
resolver um which asks for the resource
record type A and then for the domain
name evens. CCC doe what does the
resolver do let's uh consider the
resolver doesn't know anything apart
from the root name service then it
queres oh what is the name server who's
responsible for the de domain to the
root name service they reply with oh
here's a list of name service which are
responsible for that the resolver then
asks that name server one of these name
servers what is the name server for CCC
dode that one replies with those name
servers then it asks oh who is
responsible for events.
cc. um and that one replies with the IP
address this IP address is then um
answered by the resolver to the get host
by name uh Unix uh
function that's how an iterative
resolution step works so you have
noticed there are multiple packets in
from the resolver sent to various other
um hosts and now here the host only have
uh names but no IP addresses so how does
the resolver actually know who's z.
nick. that is a problem which is uh also
called glue so uh DNS answer as we have
seen earlier needs to include some IP
address if the name server is inside of
the um domain of the responsible uh
server so since events. CCC dode uh
since the name server for C cccv dode is
also responsible for cccv
dode whenever you ask it for a name
server and it says oh it's ns. cv. it
also needs to reply oh by the way ns.
CCV
v.d has the following IP address because
otherwise you wouldn't be able to find
out which name server or which IP to ask
the iterative resolution I just showed
in the earlier slides um 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 dode this is a privacy feature which
has been standardized in 2016 and is um
nowadays deployed by at least some
resolvers but not by
all other it is a privacy feature
because otherwise you leak the
information at the to the root server
which host you are interested
in what about caching well every
resolver since there's this time to live
for every resource record set every
resolver can as well cash all the data
and all the records and then use reuse
the cach the cach data for new
replies usually a setup looks like um I
have my laptop over here and then I have
on my router likely a DNS resolver
forwarding resolver which doesn't do
iterative queries but which just queres
all the time another resolver run for
example by my
ISP and
that resolver run by my ISP is then
asking the authorative uh name
servers that is a common setup another
setup
another possible setup is that you just
don't ask the ISP name server but you
just ask your router and that does
interative
queries the resource record types I just
showed to you the three ones are not
that is not a complete list there are uh
many more some useful ones which I use
quite a lot is for example the way to
introduce aliases so if f. example.com
should always redirect to
bar.example.com
we can use a so-called C name or
canonical name resource record that one
will just reply to every query for food.
example.com independent of the resource
record type which is requested with oh
look at sp. 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 um
responsible for this domain then similar
to the address records we also have uh
quat a records which are used for IP
version 6 addresses so a for IP version
4 and quad a for IP version 6 txt is a
record which just contains some Text
data and it's used by a variety of
protocols
edns is an extension mechanism and the
extension mechanism is also done just by
using DNS and resource records type so
they have an in protocol um extension
mechanism which is pretty interesting
and pretty nice so I mean DNS since it's
30 years old it 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 um server and res base out
there so you don't want to end up in
interoperability problems with earlier
versions edns has uh been developed a
long time ago but there's a next year
reflect day to say oh now it is actually
required and um service should behave
well if there are EDS records uh
requested by the
client what transport um does DNS use
usually 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 UDP
frame and then if the reply is too big
it is just truncated at the point at
let's say 512 bytes and the flag in the
um DNS header is said that oh by the way
this answer is now um truncated and then
the requestor 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 but it's prefixed by
its by the length of the
content and the edting as resource
record we just saw that contains or
carries the datagram size of the UDP of
the maximum UDP
packet what more about DNS well first of
all if you want to register a second
level domain you are um forced to run at
least two authorative
DNS servers which are in dis join IP
network in order to have some fall
tolerance because some one IP network
maybe offline or the routing may be uh
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 to resolve
that you can now since you're running
multiple instances of the same data you
need a way to synchronize that DNS has a
method ology called Zone transfer to do
that within the protocol itself and this
Zone transfer uses the serial numbers in
order to compare whether the Zone
transfer is actually needed and also
some timers which are part of the start
of authority uh resource record type so
it's all very much in the protocol
encoded how you can do synchronization
and uh fance and
redundancy DNS has also tension in order
to do Dynamic updates so instead of
having to restart your server whenever
you reconfigure it you have a in
protocol update where you can say oh now
let's add this domain name with this uh
IP address or let's remove this domain
name since now we have DNS updates and
only this uh timers for the secondary
for the synchronization 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 off Authority
has increased please update
yourself 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 TC which
usually uses uh hmx secrets so shared
Secrets which you need
to um pre-share across the different
service but you can also use some Diffy
Helman um 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 with
all of them in a random order to all of
the clients so to all of the
requesters and the request will pick the
first one or again one at a Rand at
random and so if you have two re uh two
address records for the same domain name
the um probability 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 a some sort of load
balancing via DNS this is also called
DNS round robin
mod features well there's some security
mechanism which is which has been
specified and standardized but it's not
yet mandatory to use and it only
protects well it mainly protects um the
iterative resolver the communication
between the iterative resolver and the
authorative name
service there's DNS is also used for in
a multicast setting for service
Discovery something like ru or zero conf
that is all based on DNS DNS can also
use um
internationalized top level domains and
domain names by using some puni code
encoding for them what are DNS uh
threats there's on the one side a
sensorship 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 cloudfare they can at the Central
Point um filter domain names in
there and don't give you any reply for
example for domain names they don't like
like lip gen the library genesis. org is
in such a uh problematic situations 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 cash poisoning is another threat
so since DNS by default doesn't use any
authentication and every request has a
very low entropy so it's very aesthetic
an attacker for example in the local
network can can just reply with a huge
amount of uh replies and will be will
maybe fast than the other one so the low
entropy is because we only have the 16
bits in the header as a transaction 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 what else is a threat is uh
definitely user tracking so if you run a
central re solver which is used by a lot
of people you see a lot of information
from from all of those people and you
can track those people so you know about
um which domain names are around which
domain names are ask asked for and so
on another issue which has been uh
discovered in
the uh in yeah in DNS was uh
amplification attacks so-called
amplifications attacks and the issue
here is that your request your DNS
request is usually very small so it has
a 12 byte header and then only contains
the domain name type and
class whereas the uh reply the response
to it might be very very huge especially
if you use dnsc and use a cryptographic
signature on that so the ratio between
the bytes you requested versus the bytes
which was replied with is very small so
as a an attacker you can um fake your IP
address and ask a resolver with your
faked IP address with a lot of very
small uh packets and that and that DNS
server will then reply to that faked IP
address with a lot of large packets so
you can amplify your attack instead of
um 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 DS over TS is another privacy
enhancement it's uh specified in RFC
7858 and it's a connection between the
caching resolver and the alterative
resolver so between your router and the
alterative resolver you have to verify
the certificate of the alterative
resolver and the alterative resolver
needs to be trusted to avoid any man in
the middle and it protects against Eve
droppings and modifications so if you
are in a country where DNS is sensor you
can use DNS over Tas in order to connect
to some remote server some other country
where DNS may not be filtered and you
might happen to know some people who run
such um iterative resolvers and who are
more trusted than yours uh than your ISP
servers um I think
I'm now basically nearby the end of my
talk I will talk a bit about miru which
is an operating
system with a very tiny attack surface
and less attack vectors than a unic
system and it's developed in a
functional language called oel and DNS
and miru S how that how does that fit
together well I implemented over the
last years the the s server and resolver
including Dynamic updates authentication
using hm secret let's encrypt was also
implemented by um other people and I
also integrated it there we have
persistent storage in a g repository and
we can provision those let's encrypt
certificates using the DNS challenge so
you can get a certificate from let en
Crypt how does that work out well the
the idea is you start a virtual machine
or a mirage Unicon a so-called Unicon
with a static seed just for its private
key and an HM secret and that one then
generates its 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 type called tlsa used uh
well specified in the Dane
project and then if that one if that
certificate is found and the private key
mattress and the certificate is still
valid then we continue and can serve
some web server or some mail
server if it is not found then the
certificate signing
request is uploaded to the DNS
server and the DNS server is then uh ped
periodically for a
certificate in the meantime another
Unicon which is a DNS server is notified
and um communicates with the let and
crypt and tries to provision that
certificate so that's how I do my
deployments of DNS and uh self science
and let's encrypt sign
certificates
so I'm now at the end of the talk to
conclude DNS is widely deployed it 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 that's it from me do you have
any
[Music]
questions and the questions works as
follows you stand up behind the
microphones and then you allowed a
question and not a comment 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 yeah I got a question
regarding miros um what are your plans
for 2019 so like I think the new release
of manman coming up but what do you guys
have in store for next year in general
um I think that a bit out of scope for
this talk but we are organizing heck
retreats in maresh again next year and
we we have uh some plans for next major
version of mirat and also of integration
with the DNS and automated let's encrypt
things I also want to integrate some
DHCP stuff in
there we have some questions for
microphone number two uh what would be
like the pros and cons of using DNS for
load balancing versus running a
different like a load balancer like ha
proxy 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 a DNS
based load balancing you can just set up
a set of service which all gets uh
distributed load 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 some in some setups DNS round robin
is not very suitable but in others it is
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 and next question for
microphone number
two uh hi uh in the last time I heard
about techniques like do DNS over
https uh what are the pros and
cons well DNS over HTTP is now an
extension where you can where you don't
have to use UDP or TCP but you can
transport DNS directly over HTTP which
is an advantage if you already speak
HTTP and you are happy with ad Jason and
so on but it also adds some um some um I
mean some some more work some more data
because you need to do a do a HTTP
request for getting that data so there
are some pros and cons in various uh
setups and the DNS working group at ITF
is currently discussing this whole DNS
over HTTP uh in detail so one
disadvantage is that usually with DNS
you use UDP and you have a very low
delay 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 yeah
the internet is asking is do you know
there's DNS extension useful for ham
radio like think cosign to domain name
or vice
versa I didn't I didn't understand the
question can you repeat please of
course do do you know if there's any DNS
extension useful for ham
radio I unfortunately don't know that
but Yana the internet assigned uh the
internet Authority for names and uh
numbers they have assigned all the um
resource record types and that is a
central list 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
for microphone number two please um hey
um my question is about a geodns and so
for example if I want to uh connect to
wikipedia.org from Singapore or from
Europe so I would connect it to a
different data center how that's being
handled by
DNS well DNS depends so you can set up
for example your DNS servers as anycast
nodes and anycast is a uh
routing extension or routing mechanism
that you have the same IP address at
different geolocations and then the
closest one is used so using that
mechanism you can have your data center
and Singapore and your data center in
Europe both sharing the same IP address
for the name server and then hand out in
the your Singaporean data center an IP
address which is also hosted in
Singapore and then EUR 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 be
able to deploy that and to deploy having
the ability as a client to
um add some information into the request
about its own IP address so you 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 so there are various mechanisms
and uh you have
to find out and choose which one is
suitable for you one more question from
microphone number two uh could you
elaborate on DNS tunneling attacks as as
a means to um transport information
exfiltrate information out of an
organization like in
order get undetected yes unfortunately I
didn't uh talk too much about X
filtration but certainly since DNS uses
these domain names uh you can in a
request already impose or include some
information like using the domain name
and using a 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 uh
scenarios where your client shouldn't be
able to connect to the outside but DNS
is fine and DNS Works 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 where all internet access is uh
forbidden and you have to pay money for
it but DNS is still open then you can
have if you're in control over the
server and over your client then you can
actually communicate via DNS over that
uh over that
uh uh not paid for wireless hotspot
good we have uh we're nearly out of time
we have two more questions first from
microphone number
one hi how useful do you judge uh DNS to
uh ship certificates for other protocols
like SMTP or for the web uh I think that
is uh very useful if we would have a
trust chain in DNS so for example using
DNS SEC if we have dnsc 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 working on that extension
and I think the weakest point at the
moment is that DNS dnsc deployment is
not uh so huge or is not widely
deployed so the last question is from
the internet yeah um the internet is
asking what do you think about using DNS
services from Big ENT Rises like Google
cloudfare and so on concerning privacy
yeah you shouldn't use that there are
independent DNS
reservice run by nonprofit
organizations which also have some data
privacy laws and they don't lock
anything so I would recommend to not use
those
1.11.1 or 8.8.8.8 or 9.9
919 do not use those uh centrally
organized uh DNS results because there
you don't pay anything but the company
nevertheless gets all your
data what you should do though is thank
Hannis for his
[Applause]
[Music]
[Applause]
[Music]
talk
[Music]
oh