Colin Perkins

 

00:00:00.400 In this lecture, I’d like to talk

00:00:01.866 about naming, and the tussle for control

00:00:04.000 over the names used in the Internet.

 

00:00:07.233 I'll start by introducing what is the

00:00:09.600 DNS, and how does DNS resolution work.

 

00:00:12.233 Then, I’ll move to talk about the

00:00:13.566 structure and organisation of DNS names and

00:00:16.366 the way names are assigned, the methods

00:00:19.133 for DNS resolution, and some of the

00:00:21.066 politics of how names are assigned in the Internet.

 

00:00:25.600 The paper you see on the slide,

00:00:28.300 the “Tussle in Cyberspace” paper, by David

00:00:31.066 Clark, John Wroclawski, Karen Sollins, and Bob Braden,

00:00:34.566 talks about some of these issues in

00:00:37.766 more detail. It talks about some issues

00:00:39.600 of control over the network, how protocol

00:00:42.833 design influences the control that can be

00:00:45.633 provided, how the protocols can evolve,

00:00:48.500 and who can provide control over the protocols.

 

00:00:52.800 And I’d encourage you to read it,

00:00:55.366 as the DNS is one of those

00:00:57.066 areas where we see this tussle most clearly, I think.

 

00:01:03.266 So, to start with, in this part

00:01:05.200 of the lecture, I’d like to talk about DNS name resolution.

 

00:01:08.366 I'll talk a little bit about what

00:01:10.133 is the DNS, a bit about the

00:01:12.133 structure of names, and how the name resolution works.

 

00:01:15.633

 

00:01:19.033 So to start with, what is the DNS?

 

00:01:23.133 Well, as we see in the packet

00:01:25.866 diagrams at the top of slide,

00:01:28.566 which have IPv4, on the left,

00:01:31.533 and IPv6 packets, we can see that

00:01:34.733 IP packets contain addresses rather than names.

 

00:01:40.600 When the network is delivering an IP

00:01:42.800 packet it doesn't use a domain name,

00:01:45.100 it uses an IP address. And the

00:01:47.100 IP addresses are designed for efficient processing

00:01:50.200 by routing hardware. They’re not designed to

00:01:53.833 be human readable.

 

00:01:55.833 Now, we have been lucky enough,

00:01:59.833 I think, that IPv4 addresses are at

00:02:02.266 least approximately human readable, at least no

00:02:05.233 less so than a phone number,

00:02:07.666 for example, and so people have used them

00:02:11.200 as human readable identifiers in some cases.

 

00:02:14.633 But, as we move more and more

00:02:16.800 towards IPv6, this is not really possible;

00:02:20.033 the IPv6 addresses are not at all memorable.

 

00:02:24.500 So, as users, we need a way

00:02:28.166 of using more meaningful names for devices

00:02:31.566 on the network, when we're connecting to

00:02:33.433 devices on the network,

00:02:36.000 that can be translated into the IP

00:02:38.766 addresses which the network uses internally.

 

00:02:42.333 And the Domain Name System, the DNS, provides such a

00:02:47.366 naming scheme.

 

00:02:50.666 The DNS is a distributed database.

00:02:53.266 It runs on top of the Internet,

00:02:55.600 and maps human readable names into IP addresses.

 

00:03:03.700 If you're going to a website,

00:03:06.666 and the example here is my website

00:03:09.933 and the teaching page where you can

00:03:12.266 find the lecture materials for this course,

00:03:14.800 you start with a URL, in this

00:03:17.533 case https://cperkins.org/teaching/.

 

00:03:23.066 And that comprises,

00:03:25.333 at the start, the protocol used to

00:03:28.200 access the site, HTTPS. It’s got a

00:03:31.233 domain name, and it's got the file

00:03:32.766 part which specifies which particular file,

00:03:36.633 which particular directory on the site, to access.

 

00:03:40.200 And you can extract the domain name

00:03:42.066 from that, in this case www.csperkins.org

 

00:03:46.900 And that's the name of the site.

 

00:03:52.366 But, of course, that's just the name,

00:03:54.533 it's not something which can be used in the packets.

 

00:03:56.933 So the role of the DNS is

00:03:59.233 to translate that domain name, and turn

00:04:01.800 it into a set of IP addresses

00:04:03.800 which can be used to reach the server.

 

00:04:06.300 So you'd feed that name into the

00:04:09.666 DNS, and out would pop a set

00:04:12.033 of IP addresses. And, in this case,

00:04:15.366 for this particular site, there’d be an

00:04:17.033 IPv4 address and an IPv6 address,

00:04:19.433 as you see at the bottom of the slide.

 

00:04:23.233 And for people and applications, we deal

00:04:26.700 with the names. People don't care about

00:04:30.133 the IP addresses, they care about the

00:04:31.666 names, and the application’s should care about the names.

 

00:04:35.500 And the Internet routing and forwarding should

00:04:37.666 deal with the IP addresses. And the

00:04:39.500 very last step before establishing a connection,

00:04:42.200 should be to resolve the name to the addresses

00:04:44.866 which can then be used to establish

00:04:46.900 the connection. And everything else in the

00:04:48.933 application should work on the names.

 

00:04:55.600 We see that the DNS names are structured hierarchically.

 

00:05:02.766 There’s a sequence of subdomains, a top-level

 

00:05:07.133 domain, and the DNS root.

 

00:05:11.700 We start with the subdomains, which describe

00:05:16.366 the particular site, the particular part within

00:05:18.800 the site. And, in this case,

00:05:21.433 the subdomains are www and csperkins.

 

00:05:27.700 And obviously there are lots of these.

00:05:32.733 We’re used to sites such as google.com

00:05:35.600 or facebook.com, or in the university dcs.glasgow.ac.uk

00:05:44.300 where the “dcs”, “glasgow”, and “ac”, are the subdomains.

 

00:05:51.833 The subdomains all live within a top-level domain.

 

00:05:55.666 The top-level domain can be either a

00:05:58.500 country code top-level domain such as “.uk”,

00:06:02.233 “.de”, “.cn” for China, “.io” for the

00:06:06.800 British Indian Ocean Territory, “.ly” for Libya,

00:06:10.733 and so on. Or it can be

00:06:12.900 a generic top-level domain, such as “.com”,

00:06:15.266 “.org”, or “.net”.

 

00:06:18.000 And the top-level domains live within the DNS root.

 

00:06:21.433 The DNS root is, kind of,

00:06:23.733 the invisible bit after the “.org” in

00:06:26.733 this case. It’s the servers which identify

00:06:30.866 and deliver the top-level domains. Someone has

00:06:33.833 to control what is the set of

00:06:35.700 possible top-level domains, and it's the DNS

00:06:37.566 root which defines this.

 

00:06:41.200 And there’s a set of what are

00:06:42.966 known as root servers, which advertise the

00:06:44.866 top-level domains, and specify the top of the hierarchy.

 

00:06:49.466 And, as I think should be clear after

00:06:53.500 a little bit of thought, the DNS root can't live in the DNS.

 

00:06:58.433 This is the place where you start

00:07:00.866 doing DNS resolution, so the root servers

00:07:02.900 have to have well-known, fixed, IP addresses,

00:07:05.866 and be reachable by IP address,

00:07:08.166 because they're the thing you contact in-order

00:07:10.666 to start making use of the DNS.

 

00:07:13.300 So new DNS resolves need to be

00:07:15.766 able to reach them to find the

00:07:17.466 top-level domains, before they can answer DNS

00:07:19.466 queries. So the root has to work independently of the DNS.

 

00:07:24.800 Each of the levels in the hierarchy

00:07:26.833 is independently administered, and independently operated.

 

00:07:30.433 The root server operators, and ICANN,

00:07:34.933 operate the root zone, and we'll talk

00:07:36.800 about that in one of the later

00:07:38.133 parts of the lecture. They delegate to

00:07:41.200 the top-level domains, the top-level domains delegate

00:07:44.600 down to the subdomains, and so on.

 

00:07:47.266 And each level is, as I say,

00:07:50.266 independently administered

00:07:51.366 and independently operated. It's a

00:07:54.266 distributed database. It’s distributed both in

00:07:57.200 implementation, in that the different parts of

00:08:00.666 the namespace are all controlled and served

00:08:03.533 by different servers, but also in authority,

00:08:06.200 with the authority what goes in each

00:08:08.700 subdomain being delegated down through the hierarchy.

 

00:08:11.733 And each domain, each level in the

00:08:13.966 hierarchy, controls its own data.

 

00:08:20.533 The point of the DNS is to

00:08:22.933 provide name resolution. Given a name,

00:08:26.866 the goal of the DNS is to

00:08:28.666 look up a particular type of record,

00:08:30.533 giving information about that name.

 

00:08:34.233 In the usual case, what you're looking up

00:08:36.666 are what are known as A records

00:08:39.233 or AAAA records.

 

00:08:41.533 An A record is a mapping from

00:08:43.600 a name to an IP address.

00:08:45.500 It says, this name, in this case

00:08:50.566 “www.csperkins.org”, corresponds to this IPv4 address,

00:08:56.033 or this set of IPv4 addresses.

 

00:08:59.366 And AAAA records do the same,

00:09:01.500 but for IPv6 addresses.

 

00:09:05.000 What's perhaps less well known is that there are

00:09:08.300 several other different types of records in the DNS.

 

00:09:14.766 NS records, for example, can be used

00:09:17.900 to give you the IP address of

00:09:19.800 the name server for domain.

00:09:22.000 CNAME records provide that canonical names,

00:09:25.033 they provide alias in the DNS.

00:09:29.200 MX records, mail exchanger records, let you

00:09:33.333 look up the email server for a

00:09:35.533 particular domain. And these got generalised into

00:09:38.500 SRV records which allow you to look-up

00:09:40.866 any other type of server within a domain.

 

00:09:46.666 The process of resolution, the process of

00:09:49.100 looking-up a name, happens when a DNS

00:09:51.933 client asks a DNS resolver to perform the look-up

 

00:09:59.000 And this is usually triggered by an

00:10:01.433 application, when it calls the getaddrinfo() system

00:10:04.600 call. And we saw this in the

00:10:06.833 examples of the labs, where the first

00:10:09.500 thing that the client does, after creating,

00:10:12.300 after getting the name to look-up,

00:10:14.633 is call getaddrinfo(), then loop through the

00:10:17.233 results, try to make connections to each one in turn.

 

00:10:22.266 A DNS client is just a machine

00:10:26.666 which runs the getaddrinfo() call, and knows

00:10:29.200 how to talk to a resolver.

 

00:10:31.300 A resolver is

00:10:33.500 a process, an application, which can look up names.

 

00:10:39.600 The resolver could be process running on your local machine.

 

00:10:43.933 More commonly, it's a process that runs

00:10:47.300 on a machine provided by your Internet

00:10:49.433 service provider, by the network operator,

00:10:52.266 and your client talks over the network to the resolver.

 

00:10:57.266 And when you configure the machine to

00:10:59.066 talk to the network, you specify the

00:11:01.833 IP address of the DNS resolver for that network.

 

00:11:05.400 And if your machine is using dynamic

00:11:07.700 host configuration, with the DHCP protocol,

00:11:11.000 the resolver IP addresses one of the

00:11:15.233 details it gets configured with.

 

00:11:17.766 Usually this happens automatically. You connect your

00:11:20.633 machine to the network, and the network

00:11:22.600 configuration provides the IP address of the

00:11:25.266 resolver your Internet service provider, your network

00:11:28.533 operator, is operating.

 

00:11:34.400 So when the client wishes to look

00:11:37.133 up a name, what happens?

 

00:11:40.566 Well, in this case we're looking-up the

00:11:43.733 A record for my website, www.csperkins.org.

 

00:11:49.033 And the client talks to the resolver,

00:11:52.433 and says what is the A record for csperkins.org?

 

00:11:57.933 And, if we assume that this is

00:11:59.966 the first query this revolver has ever

00:12:01.933 received, so it has no information about

00:12:04.366 the rest of the network,

00:12:06.400 what happens is it says, ‘I don't

00:12:08.900 know, first I need to find what

00:12:11.233 is “.org”’. It needs to find the

00:12:13.066 top-level domain, and then worked down.

 

00:12:16.433 So the resolver would talk to the

00:12:17.933 root servers, and it would send a

00:12:19.600 query to the DNS root servers and

00:12:21.466 say what is the name server record,

00:12:23.133 the NS record, for “.org”?

 

00:12:26.633 And that answer would come back from

00:12:28.200 the root servers, and it will tell

00:12:30.566 the local resolver what is the IP

00:12:33.400 address of the name server which knows about “.org”.

 

00:12:38.466 The resolver would then talk to that

00:12:40.733 name server. It would send a query

00:12:42.500 to “.org” to say what's the name

00:12:44.766 server record for “csperkins.org”?

 

00:12:48.500 It’s working its way down the hierarchy.

00:12:50.700 We've gone from the root servers,

00:12:52.033 to “.org”, then it asks “.org” what's

00:12:54.700 the name server for “csperkins.org”.

 

00:12:58.200 And then, once it gets that answer,

00:13:00.400 it contacts that server. It contacts the

00:13:02.466 server for “csperkins.org” and says what is

00:13:05.266 the A record, the address, for “www.csperkins.org”?

 

00:13:11.566 And the server, the DNS server for

00:13:13.866 csperkins.org. responds. That gets to the local

00:13:16.333 resolver, and now it has the information

00:13:18.466 it needs, so it returns the answer to the client.

 

00:13:24.266 And we see it's quite an iterative

00:13:27.400 process. The resolver talks to the DNS

00:13:30.533 root servers to get the

00:13:33.766 name server record for the top-level domain,

00:13:36.733 in this case “.org”. It talks to

00:13:38.633 the top-level domain, to get the name

00:13:40.300 server record for the sub domain.

00:13:42.466 and so on. If there are multiple

00:13:44.500 subdomains, it will keep working its way

00:13:46.366 down through those domains until it finds

00:13:48.233 the end of the query, in which

00:13:49.766 case it asks for the A record.

 

00:13:55.266 The various responses coming back from these

00:13:58.233 servers, whether they're coming back from the

00:14:00.100 root servers, the top-level domain servers,

00:14:03.033 or the subdomain servers for a particular

00:14:05.833 site, all include a time-to-live.

 

00:14:09.833 So, as well as the IP address,

00:14:12.433 as well as the particular record and

00:14:15.900 the IP address corresponding to that record,

00:14:17.933 they also have a time-to-live value which

00:14:20.333 says how long the resolver can cache

00:14:23.800 that record. A promise it won't change

00:14:27.400 for a certain amount of time.

 

00:14:30.800 And, in future, if you ask the

00:14:33.933 same query, if you make the same

00:14:36.366 query to the resolver again, provided it

00:14:38.733 has one of these cached values,

00:14:40.733 provided it's not reached its maximum time-to-live,

00:14:43.233 it can just respond from the cache.

 

00:14:45.666 And that saves all the look-up times,

00:14:47.800 and makes the responses much quicker.

 

00:14:51.000 When the entry times-out, it gets refreshed and

00:14:55.266 the resolver asks the next level up

00:14:58.433 in the hierarchy in case it's changed.

00:15:00.600 And, eventually, it would work its way

00:15:02.533 back up to the root servers.

 

00:15:06.233 The IP addresses for the root servers

00:15:08.700 are well-known. They essentially have an infinite

00:15:11.333 time-to-live, and haven't changed in the last

00:15:13.733 30 years or so.

 

00:15:17.833 What value do you give to the

00:15:20.533 time-to-live if you're configuring a domain?

 

00:15:24.500 I think it very much depends on what you're doing.

 

00:15:27.166 A site which is just hosted on

00:15:31.333 a single server, and doesn't receive a

00:15:34.066 heavy load, such as my website,

00:15:36.366 will probably give quite a long time

00:15:38.500 to live. A day, a couple of

00:15:41.666 days, or a week, perhaps,

00:15:43.966 because it's just not going to change.

 

00:15:47.900 It's always on the same server.

 

00:15:51.733 A big site, where there are possibly

00:15:55.233 many hundreds of servers hosting that site,

00:16:02.533 will probably give a much shorter time

00:16:04.766 to live, maybe on the order of

00:16:06.766 a small number of seconds, and will

00:16:09.500 probably give you a different answer every

00:16:11.466 time you look up the domain,

00:16:14.600 because it's load balancing between the different

00:16:17.233 servers. And you see this when you

00:16:20.000 look-up names for servers such as those

00:16:23.000 for Google, Facebook, or Netflix,

00:16:25.733 where every time you make a query,

00:16:27.933 you get a different address because it's

00:16:29.700 pointing you at a different one of

00:16:31.466 the servers that serve that domain.

00:16:34.200 And it has quite a short time

00:16:35.566 to live, so you keep rotating around

00:16:37.833 for load balancing purposes.

 

00:16:41.166 Similarly, if you're accessing a content distribution

00:16:44.733 network, it's likely that it will have

00:16:46.866 a short time to live,

00:16:48.500 so it can point you to one

00:16:51.066 of the local caches, and so it

00:16:52.733 can change which local cache, which local

00:16:55.100 proxy, it redirects your query to,

00:16:57.533 based on the load, and based on

00:17:00.033 as you move around.

 

00:17:02.766 So you can play games with the

00:17:04.766 time-to-live to affect the behaviour of the DNS.

 

00:17:11.500 And that's it for this part.

 

00:17:13.666 The DNS names are hierarchical. They work

00:17:16.733 their way up from the sub domains,

00:17:19.066 which describe particular sites and

00:17:22.100 sub-parts of a site, up to the

00:17:26.600 top-level domains, and up to the root domain.

 

00:17:30.033 And they're structured hierarchically. It's a distributed

00:17:32.800 database, with distributed implementation,

00:17:37.233 and distributed control, distributed authority.

 

00:17:40.233 And the name resolution follows the structure

00:17:43.400 of the names. It works its way

00:17:45.466 down from the root, contacting the servers

00:17:48.066 at each level in turn, until it

00:17:49.666 gets the required answer. And it caches the results.

 

00:17:54.266 In the next part, I’ll move on

00:17:56.066 and talk more about the structure of the names.

 

00:00:00.333 In this part of lecture I'd like to talk about DNS names.

 

00:00:03.733 I’ll talk about who controls the DNS,

00:00:06.366 what top-level domains exist, and what process

00:00:09.566 is followed to assign new top-level domains

00:00:12.166 in the DNS. I’ll talk about internationalisation

00:00:15.166 of the DNS. And I’ll talk about

00:00:16.966 who operates the DNS root servers.

 

00:00:21.433 So, as we saw in the previous

00:00:23.600 part of the lecture, DNS names are assigned in a hierarchy.

 

00:00:28.666 A DNS name comprises a sub-domain,

00:00:31.633 which is delegated from potentially other sub-domains,

00:00:34.833 which are delegated from a top-level domain,

00:00:36.833 which is delegated from the root.

 

00:00:39.900 If we consider my website, for example,

00:00:43.466 we see the domain name, “www.csperkins.org”,

00:00:47.533 on the slide and “www” and “csperkins”

00:00:51.100 are subdomains within the top level domain,

00:00:54.800 “.org”. And the “.org” top-level domain exists

00:00:57.500 within the DNS root.

 

00:01:00.400 And this hierarchical structure naturally leads to

00:01:02.900 a bunch of questions.

 

00:01:04.966 You might ask what top level domains exist?

 

00:01:09.300 For each given top level domain,

00:01:11.366 you might ask what policy that top-level

00:01:13.400 domain has for deciding when to allocate

00:01:16.000 subdomains? What's a valid name within “.org”,

00:01:20.733 for example, what's a valid name within “.com”?

 

00:01:25.166 You might ask who decides when to

00:01:28.000 add new top level domains? And what's

00:01:30.300 the set of valid top level domains

00:01:32.300 in the network? And you might ask

00:01:34.766 about the DNS root: who controls the

00:01:36.966 root? What what does it do? How does it operate?

 

00:01:43.000 Well, thinking first about top level domains.

 

00:01:47.400 The set of top-level domains in the

00:01:49.333 Internet is controlled and defined by an

00:01:52.233 organisation known as the Internet Corporation for

00:01:54.866 Assigned Names and Numbers, ICANN.

 

00:01:59.166 ICANN has a long and somewhat complex history.

 

00:02:06.733 The original project which led to the

00:02:10.366 development of the Internet, was something known as ARPANET.

 

00:02:13.600 The ARPANET was a US government funded

00:02:16.066 research project, that ran from the late

00:02:18.200 1960s up until about 1990.

 

00:02:21.500 The ARPANET project develops the initial versions

00:02:24.700 of the Internet protocols, we use today.

00:02:27.466 It developed the initial versions of TCP/IP,

00:02:29.866 for example, and some of the early application protocols.

 

00:02:35.266 As part of the development of the

00:02:37.966 ARPANET, it was found that the researchers

00:02:42.066 working to develop those protocols needed a

00:02:44.966 set of protocol specifications, they needed to

00:02:47.200 write down the descriptions of the protocols

00:02:49.666 they were developing, and they needed a parameter registry.

 

00:02:53.933 They needed a way of storing the addresses,

00:02:56.300 and the various parameters that the protocols had.

 

00:02:59.833 And one of the researchers involved in

00:03:01.833 that effort, Jon Postel, volunteered to do

00:03:04.933 this. He volunteered to act in the

00:03:08.766 role of what became the RFC Editor,

00:03:11.766 editing and distributing the protocol specifications,

00:03:15.466 and in a role which became known

00:03:18.066 as the IANA, the Internet Assigned Numbers

00:03:20.366 Authority, to assign protocol parameters.

 

00:03:25.033 And, initially, when he started doing this,

00:03:27.433 he was a graduate student working at

00:03:29.533 UCLA, and later he did this,

00:03:33.866 later in his career, while working at

00:03:37.100 the University of Southern California’s

00:03:40.200 Information Sciences Institute.

 

00:03:44.033 And, while working at ISI, Postel handled

00:03:48.100 domain name allocation. As the DNS came

00:03:52.033 into being, as people started registering names,

00:03:54.733 it seemed natural to register these names

00:03:56.966 in the existing protocol parameter registry,

00:03:59.566 which Postel was operating as essentially the

00:04:03.966 IANA organisation.

 

00:04:07.133 And he did this as a part

00:04:09.666 time, fairly informal, activity, as part of

00:04:13.266 his ongoing research into the Internet,

00:04:16.633 and Internet-related protocols, primarily funded by the

00:04:20.133 US Government.

 

00:04:24.633 The IANA role gradually became more formalised.

 

00:04:28.666 By the late 1990s, IANA was becoming

00:04:34.366 more structured, there were people other than

00:04:36.600 Postel working on it, because the Internet

00:04:38.300 was starting to take off.

 

00:04:40.333 And, in 1998, this led to the

00:04:43.500 formation of ICANN, the Internet Cooperation for

00:04:47.200 Assigned Names and Numbers, as a dedicated

00:04:49.966 organisation to manage domain names.

 

00:04:53.200 ICANN was formed in September 1998,

00:04:56.633 as a US not-for-profit corporation based in

00:05:00.666 Los Angeles, actually based in the same

00:05:03.200 building where Postel worked, and where ISI

00:05:06.900 was based, in Marina del Rey in Los Angeles.

 

00:05:12.366 And, unfortunately, Postel passed away in October

00:05:16.733 1998, just two or three weeks after

00:05:19.133 ICANN was formed. He's actually the only

00:05:22.833 person, so far, have an obituary published

00:05:26.000 as an RFC. And you see the link on the slide there.

 

00:05:31.966 And after he passed away, ICANN look

00:05:34.800 over the management of the domain names.

 

00:05:37.933 And it's very-much been run as a

00:05:40.666 global multi-stakeholder forum. It’s trying to get

00:05:45.033 input from as many people as possible,

00:05:48.033 trying to take as many different views

00:05:50.166 on how the network should work,

00:05:52.500 what domain name should exist, as possible.

 

00:05:55.733 Organisationally, it's not-for-profit corporation based in

00:06:00.766 Los Angeles, so it's a registered US charity, essentially.

 

00:06:05.200 And, as of 2016, it's now no

00:06:09.466 longer under contract to the US Government,

00:06:12.933 and officially, the domain names are managed by ICANN.

 

00:06:20.200 ICANN, has a fairly, in addition to

00:06:25.000 its complex history, ICANN has a fairly

00:06:27.733 complex governance model.

 

00:06:31.700 And, in part, this comes from,

00:06:35.166 this springs out of, the history of

00:06:37.233 ICANN. The original domain names, the original

00:06:40.733 development of the network, as we saw,

00:06:43.033 was sponsored by the US Government.

 

00:06:45.200 And the Internet became much more

00:06:47.933 widespread, as it became more ubiquitously deployed,

00:06:51.300 as it became more global,

00:06:53.800 people outside the US started to be

00:06:56.766 uncomfortable with this, and were pushing for

00:07:00.600 ICANN turn to divest from the US Government.

 

00:07:04.400 And, as a result of that,

00:07:06.333 it has a governance model which takes

00:07:09.133 input from a large number of different

00:07:11.133 organisations around the world, to try and

00:07:13.433 make sure that the needs of the

00:07:15.166 different stakeholders are balanced, and it's not

00:07:17.133 controlled by any one company.

 

00:07:20.366 So ICANN is controlled by a Board

00:07:22.166 of Governors. They take input from a

00:07:25.566 number of organisations, including a generic names

00:07:29.133 supporting organisation, which represents generic top

00:07:32.633 level domains such as “.org”, “.com”, and so on.

 

00:07:36.266 A country code names supporting our organisation,

00:07:39.933 which represents the country code domains such

00:07:44.200 as “.uk” or “.de”, for example.

 

00:07:47.700 It takes input from an address supporting organisation,

00:07:51.133 which represents the regional Internet registries,

00:07:54.433 such as RIPE, APNIC, and ARIN,

00:07:58.033 which assign IP addresses to ISPs and other organisations.

 

00:08:02.966 It takes input from a Governmental Advisory

00:08:05.900 Committee, and the Governmental Advisory Committee is

00:08:10.233 formed of representatives from each of the,

00:08:13.066 I think, 112 UN recognised countries.

 

00:08:16.133 It takes input from an at-large advisory

00:08:18.933 committee, a root server operators advisory committee,

00:08:23.400 a stability and security committee, and a

00:08:25.366 technical liaison group.

 

00:08:27.200 And, in addition to this, it holds

00:08:29.033 regular public meetings, three or four times

00:08:32.133 a year, circling around the globe,

00:08:34.600 to get input from interested parties.

 

00:08:38.333 ICANN has evolved into a massive organisation.

 

00:08:42.000 It's got an annual budget of somewhere

00:08:45.300 on the order of 140 million US dollars.

00:08:47.966 It takes input from an enormous range

00:08:51.166 of people, including representatives from the different

00:08:54.833 countries in the United Nations, and it's

00:08:57.366 an incredibly political organisation.

 

00:09:00.400 Many, many countries and organisations want to

00:09:03.433 influence the way domain names are managed,

00:09:06.066 the way domain names are allocated,

00:09:08.000 and what sort of domain names exist.

 

00:09:10.500 This is no longer a simple,

00:09:12.400 part-time, project by an academic at a

00:09:15.800 University in California, it's a global mega-corporation.

 

00:09:20.400 That said, it seems to work.

 

00:09:23.500 The DNS seems to be stable,

00:09:27.033 and while some of the names that

00:09:29.866 ICANN has allocated are certainly controversial,

00:09:33.033 the process is, I think, broadly working.

 

00:09:39.466 So what names exist?

 

00:09:41.933 Well, there are four types of top-level

00:09:44.800 domain in the Internet.

 

00:09:46.600 There are country code top-level domains,

00:09:49.400 generic top-level domains, infrastructure top-level domains,

00:09:53.466 and special-use top-level domains.

 

00:09:58.666 The country code top-level domains are those

00:10:02.533 which identify the portions of the namespace

00:10:06.433 assigned to different countries.

 

00:10:10.433 And the way this is done is that

00:10:13.700 ICANN has essentially delegated the problem of

00:10:17.733 deciding who is a country to the

00:10:20.666 International Organisation for Standards, ISO.

 

00:10:24.233 ISO has a Standard, ISO 3166-1,

00:10:28.433 which defines the set of allowable country

00:10:32.766 name abbreviations.

 

00:10:36.033 And these are reasonably widely used.

00:10:38.700 They form the top-level domains in the

00:10:40.666 Internet, but they're also things like the

00:10:43.600 stickers which go on cars if you

00:10:46.366 drive abroad, the GB sticker on your

00:10:49.866 car if you drive abroad, for example.

 

00:10:53.433 And ISO 3166-1 defines country code abbreviations

00:10:59.100 for Member States of the United

00:11:01.266 Nations, for the UN special agencies such

00:11:04.200 as the International Monetary Fund, UNESCO,

00:11:07.100 the World Health Organisation, and so on.

 

00:11:09.933 And it defines abbreviations for parties to

00:11:11.933 the International Court of Justice.

 

00:11:14.333 And essentially what's happened here is that

00:11:16.533 ICANN has delegated

00:11:20.433 the decision of what top-level country code

00:11:23.866 domains exist to ISO, and ISO has,

00:11:26.666 essentially, delegated it to the United Nations.

 

00:11:29.533 And this neatly sidesteps the argument of

00:11:32.633 what is a country. In that if

00:11:35.400 you're a Member States of the UN,

00:11:37.600 you’re a country, and ISO assigns you

00:11:40.166 a country code, and that then gets

00:11:42.200 reflected into the Internet.

 

00:11:44.933 And every country code defined in ISO

00:11:48.266 3166-1 is added into the DNS root zone.

 

00:11:52.666 And that gives you the country code

00:11:55.566 top-level domains we’re all familiar with,

00:11:58.100 such as “.uk “for the United Kingdom,

00:12:00.866 “.fr”, “.de”, “.cn” for china, “.us” for

00:12:04.933 the United States, and so on.

 

00:12:07.900 And these country code domains include some

00:12:11.000 which, perhaps, are less familiar: “.ly”,

00:12:14.700 for example, is Libya; “.io” is the

00:12:17.400 British Indian Ocean Territory.

 

00:12:21.200 And each country can then set its

00:12:23.133 own policy for what it does for

00:12:25.033 subdomains of that country code domain.

00:12:27.633 And that can be delegated to the

00:12:29.433 government of those countries.

 

00:12:34.766 There are a number of exceptions,

00:12:37.000 and a number of oddities, in the system.

 

00:12:40.233 One historical curiosity, which is perhaps of

00:12:45.000 interest in the UK, is to do with Czechoslovakia.

 

00:12:50.266 And the issue here is that,

00:12:53.666 in the 1980s, and early 1990s,

00:13:00.466 very early 1990s,

00:13:03.433 the UK ran a non-Internet based research

00:13:07.833 academic research network,

00:13:10.000 a system called JANET, the Joint Academic

00:13:12.266 NETwork. And JANET

00:13:16.366 ran a set of protocols known as

00:13:19.333 the coloured book protocols, and they had

00:13:21.000 an alternative name resolution system.

 

00:13:23.133 And names for sites in this network

00:13:27.100 used something which looked a lot like

00:13:30.066 DNS names, but worked backwards. So they

00:13:32.666 have the country code at the front,

00:13:35.133 and then worked their way down towards the subdomain.

 

00:13:40.200 So, for example, the University of Glasgow

00:13:45.166 would be “uk.ac.glasgow” using the JANET name

00:13:48.866 resolution system, versus “glasgow.ac.uk” using the DNS.

 

00:13:55.800 And this worked fine. Fundamentally it doesn't

00:13:58.600 matter which way around you write the

00:14:00.933 names, so writing the names in the

00:14:03.233 opposite order works just fine. And there

00:14:06.266 was a gateway, which translated email messages between

00:14:10.833 the machines on the UK Joint Academic

00:14:13.233 Network and the machines on the rest

00:14:14.933 of the Internet. And it did this

00:14:17.000 just by rewriting the addresses, changing the

00:14:19.100 order of the components of the domain name.

 

00:14:22.866 And this work just fine, until Czechoslovakia

00:14:25.566 joined the Internet was assigned the country

00:14:28.933 code domain “.cs”.

 

00:14:32.400 And, at this point, the gateway got

00:14:34.400 confused, because it suddenly became difficult to

00:14:37.266 tell whether “uk.ac.glasgow.cs” was

00:14:41.566 the Computing Science Department in Glasgow University,

00:14:45.333 or a site in Czechoslovakia. You couldn't

00:14:48.900 look at the first, or last,

00:14:51.033 part of the domain name, and see

00:14:52.833 whether it was one of the valid

00:14:54.666 country code domains, and if it wasn't then reverse it.

 

00:14:59.700 And this problem got solved in two

00:15:01.766 ways. Firstly, it got solved by all

00:15:04.500 the Computing Science departments in UK universities

00:15:07.866 suddenly renaming their domain names.

 

00:15:11.433 This is the reason why Computing Science

00:15:15.433 in Glasgow is “dcs.glasgow.ac.uk”,

00:15:19.133 rather than “cs.glasgow.ac.uk”,

00:15:21.700 “Department of Computing Science”.

 

00:15:24.033 This is the reason why the Computer

00:15:26.200 Science department in Cambridge is the Computer

00:15:28.866 Lab, “cl.cam.ac.uk”. To avoid the conflicts with,

00:15:34.533 to avoid using “.cs”, anywhere.

 

00:15:37.366 And the problem also, of course,

00:15:39.566 got solved because Czechoslovakia went away.

 

00:15:42.266 There are also four oddities, four exceptions,

00:15:45.866 where the top-level domains in the Internet

00:15:49.433 don't match what is in ISO 3166-1.

 

00:15:56.000 The first is the United Kingdom.

00:15:59.266 The country code abbreviation for the United

00:16:02.933 Kingdom in ISO 3166-1 is GB.

 

00:16:06.700 So if it followed the prescribed form, we should

00:16:12.000 be using “.gb” rather than “.uk”.

 

00:16:15.033 And indeed, and what is now “.gov.uk”

00:16:18.933 used to be registered under “.hmg.gb”,

00:16:23.000 Her Majesty's Government, GB.

 

00:16:25.933 But this was never widely used, and

00:16:29.200 the initial people who set up the

00:16:34.500 Internet in the UK, and this was

00:16:37.766 primarily the fault of someone known as

00:16:39.766 Peter Kirstein at University College London,

00:16:42.733 who set up the initial Internet nodes

00:16:45.033 in the UK, decided they preferred to use “.uk”

00:16:48.766 and this kind-of stuck.

 

00:16:53.866 In addition to that,

00:16:56.866 the country code top-level domain for the

00:17:00.966 Soviet Union, “.su”, still exists in the

00:17:04.900 Internet and, I believe, is still accepting

00:17:08.066 new domain registrations, which is a little

00:17:11.133 bit of an oddity.

 

00:17:13.866 The European Union, “.eu”, has a country

00:17:18.033 code top-level domain, but it's not registered

00:17:21.333 in ISO 3166-1 and, sadly, Australia changed

00:17:26.600 and no longer uses “.oz”, but follows

00:17:29.700 “.au” to match the standard.

 

00:17:35.866 So that's the country code top-level domains,

00:17:38.566 what else exists?

 

00:17:40.666 Well, there's also a set of generic top-level domains.

 

00:17:44.866 And originally this comprised the set of core

00:17:48.766 domains that represented different types of use:

00:17:53.300 “.com”, “.org”, and “.net”, originally for companies,

00:17:58.600 nonprofit organisations, and networks,

00:18:01.700 but for many, many years now available

00:18:05.900 for unrestricted use; “.edu” for higher educational

00:18:10.333 organisations, primarily US-based; “.mil” for the US

00:18:14.900 military; “.gov” the US Government;

00:18:17.466 and “.int” for international treaty organisations,

00:18:21.000 such as the United Nations, Interpol,

00:18:24.333 NATO, the Red Cross, and organisations like that.

 

00:18:28.900 And, for a long time, those were

00:18:31.066 the only set of generic top-level domains

00:18:33.100 that existed, and there was a debate

00:18:35.966 about whether organisations should register in one

00:18:38.700 of these generic top-level domains, or whether

00:18:40.733 they should register under their country code domain.

 

00:18:44.466 More recently, ICANN has massively expanded the

00:18:47.500 set of possible generic top-level domains.

 

00:18:51.066 Rather than the original 7, I think

00:18:53.700 there’s now about 1500 generic top-level domains registered.

 

00:18:57.766 And these have a whole bunch of

00:18:59.733 different uses. “.scot” is a generic top

00:19:02.600 level domain, for example, and there’s others

00:19:05.466 for many other cities and regions around

00:19:07.700 the world. And it's possible to get

00:19:10.500 generic top-level domains for brands and other

00:19:12.933 organisations,

00:19:14.900 although this process is difficult and expensive.

 

00:19:21.866 And the country code top-level domains,

00:19:24.066 and the generic top-level domains, comprise the

00:19:26.000 overwhelming majority of top-level domains in the Internet.

 

00:19:30.800 There's a few more which you may

00:19:33.700 come across occasionally. One of these is

00:19:36.566 what’s known as the infrastructure top-level domain,

00:19:38.866 “.arpa”.

 

00:19:40.600 Now, obviously, that name, “.arpa”, stems from

00:19:44.066 the original development of the network,

00:19:45.733 from the ARPANET.

 

00:19:47.500 And it's mostly a historical relic,

00:19:50.300 that was used in this transition from

00:19:54.066 the ARPANET to the Internet.

 

00:19:56.166 That top-level domain has one current use,

00:20:00.600 which is reverse DNS.

 

00:20:03.233 Now, what we spoke about in the

00:20:05.233 last part of the lecture was what's

00:20:07.233 this forward DNS lookup. Where you take

00:20:09.433 a domain name, and you look that

00:20:11.466 name up in the DNS, and it

00:20:13.066 gives you the corresponding IP addresses.

 

00:20:15.333 For example, if you look up my

00:20:17.000 website, “csperkins.org”, it will give the IPv4

00:20:20.266 address 93.93.131.127.

 

00:20:25.366 Reverse DNS lookup is the process of

00:20:28.400 going the other way. It’s the process

00:20:30.666 of going from an IP address to a domain name.

 

00:20:35.033 And the way this is done, is that the

00:20:40.433 human-readable

00:20:43.066 form of the IP address, the numeric

00:20:46.033 human-readable form of the IP address,

00:20:48.300 is reversed and stored as a domain

00:20:51.433 name under the “.arpa”

00:20:53.600 top-level Domain.

 

00:20:56.200 So, for example,

00:20:58.366 the domain name 127.131.93.93.in-addr.arpa

00:21:05.533 is registered. And, if you do a

00:21:08.066 domain name lookup of that name in

00:21:11.800 the DNS, it will return you a

00:21:14.900 DNS CNAME record which points to csperkins.org

 

00:21:19.366 What you see is that this is

00:21:21.433 the IP address of my site,

00:21:23.533 reversed, and registered as a name,

00:21:26.066 which allows you to look-up, to go

00:21:28.000 back from that address, to the site name.

 

00:21:31.300 And the same thing works for IPv6

00:21:33.200 addresses, where each

00:21:36.433 four bits of the IP address are

00:21:39.433 done as a separate subdomain. So the

00:21:42.433 address you see here, 0.1.0.0.0… etc.

00:21:46.933 “.in6.arpa”, which is the reversed IPv6 address

00:21:52.000 of that website,

00:21:53.566 when resolved in the DNS, will give

00:21:55.500 you the DNS CNAME record that points

00:21:57.900 to the site. It’s a way of

00:21:59.833 going back from either the IPv4 or

00:22:01.600 IPv6 addresses to the original domain name.

 

00:22:04.666 And that's the only current use of “.arpa”.

 

00:22:09.700 In addition to that, there are six

00:22:11.866 special use top-level domains.

 

00:22:14.666 “.example” which is used for examples as

00:22:18.400 you might expect, used for documentation,

00:22:21.366 is registered, and there's also

00:22:25.966 generic top-level domain versions of it,

00:22:28.400 so “example.com”, “example.org”, and so on which

00:22:31.133 exist and are guaranteed not to be

00:22:33.666 used for anything than for documentation.

 

00:22:36.866 “.invalid” is guaranteed that it will never

00:22:41.333 be registered,

00:22:42.800 as a testing domain name which will

00:22:46.566 never exist. “.test” is there for testing

00:22:50.233 sites, testing uses, for a domain name which does exist.

 

00:22:54.666 “.local” and “.localhost” represent the local network

00:22:58.133 and the local machine. And “.onion” is

00:23:01.400 used as a gateway for Tor hidden

00:23:03.900 services, and the RFC on the slide

00:23:07.033 talks about that in more detail;

00:23:09.066 this is The Onion Router, which is

00:23:11.966 an anti-censorship technology.

 

00:23:18.766 The original DNS,

00:23:22.100 and all the DNS names we've spoken

00:23:24.166 about, all use ASCII.

 

00:23:27.766 The initial set of top-level domains,

00:23:30.000 the initial set of subdomains, were all

00:23:31.633 registered in an ASCII.

 

00:23:34.700 And, of course, this is problematic if

00:23:37.000 you don't speak English, or if you

00:23:39.000 speak a language which can't be represented

00:23:42.500 within the ASCII character set.

 

00:23:47.033 In principle, there's nothing in the DNS

00:23:50.133 protocol that should stop you being able

00:23:52.733 to register names in UTF8 format.

 

00:23:55.366 DNS just deals with strings of bytes,

00:23:59.233 and doesn't really care what they are.

 

00:24:01.533 In practice, a lot of the software

00:24:04.433 which deals with DNS names assumes they

00:24:06.633 are ASCII, and when people experimented with

00:24:09.600 using UTF8 names, to allow non-ASCII domain

00:24:12.566 names, it was found it didn't work in practice.

 

00:24:16.900 As a result of this, we have

00:24:19.600 a somewhat complex approach to translating non-ASCII

00:24:23.166 names into ASCII, which allows them to

00:24:25.833 be used in DNS.

 

00:24:28.700 And it's based on a system known

00:24:31.333 as Punycode. And Punycode is an encoding

00:24:35.000 of Unicode, the global character set,

00:24:38.666 into a sequence of ASCII letters,

00:24:41.333 digits, and hyphens.

 

00:24:43.900 So, for example, we see some examples

00:24:48.933 for how München, the German city Munich,

00:24:52.266 can be translated into Punycode. And we

00:24:56.000 see that the

00:24:58.533 characters which are not representable in ASCII

00:25:00.800 get omitted from the initial

00:25:05.533 name, and then there's a hyphen and

00:25:07.733 an encoded sequence at the end,

00:25:09.800 after the hyphen.

 

00:25:11.666 And that encoded sequence at the end

00:25:13.533 is a base-36 encoded representation of the

00:25:17.433 Unicode character, which was omitted, and the

00:25:19.866 location of where it was omitted from,

00:25:22.200 and so where it should be inserted.

 

00:25:24.133 This allows you to represent any name

00:25:27.666 as something which can be represented as

00:25:30.533 ASCII, as a sequence of ASCII characters.

 

00:25:33.633 And the internationalised DNS uses this,

00:25:36.333 but it prefixes each of the names

00:25:39.466 with the special prefix “xn—“ which was

00:25:43.366 found not to exist in any of the registered,

00:25:46.600 legitimate, top-level domains of the time,

00:25:52.400 to allow resolvers to distinguish internationalised names

00:25:58.666 from regular names, and know that they

00:26:00.633 have to perform the translation.

 

00:26:03.100 And this works. If you look-up the

00:26:07.333 example in Cyrillic at the bottom there,

00:26:11.233 it translates, the browser, for example,

00:26:14.066 will translate this into the string “xn--70ak…”

00:26:22.000 which then gets resolved as normal in

00:26:25.400 the DNS. And this is Yandex,

00:26:28.200 which is one of the popular Russian search engines.

 

00:26:32.166 So the format the names have on

00:26:34.866 the wire, is this

00:26:37.733 unfortunately encoded form which translates them into

00:26:41.900 ASCII, but what gets displayed to the

00:26:44.633 users is the native form in Unicode.

 

00:26:52.833 So.

 

00:26:54.733 ICANN decides the set of legal top level domains.

 

00:26:58.766 They can be country code domains,

00:27:01.266 or they can be generic top-level domains,

00:27:04.533 or special-use domains, or they can be

00:27:07.033 internationalised names these days.

 

00:27:11.233 ICANN then tells the root server operators

00:27:13.933 that set of names, and the root

00:27:15.800 servers then advertise the name servers for

00:27:18.300 those top level domains. Those name servers

00:27:21.600 then advertise the names which exist within

00:27:24.200 those top level domains.

 

00:27:27.233 What are the set of root servers?

00:27:30.166 Where do the names come from?

 

00:27:33.700 Well, there’s a set of 13 servers

00:27:36.733 which advertise the name servers for the

00:27:38.866 top level domains.

 

00:27:41.500 They’re registered in the DNS. They’re called

00:27:44.500 “a.root-servers.net”, “b.root-servers.net”,

00:27:48.133 through to “m.root-servers.net”. And they

00:27:51.166 also have well-known IPv4 and IPv6 addresses

00:27:55.166 because, as you should perhaps

00:28:00.600 understand, the point of the root servers

00:28:03.966 is to advertise the top level domains, to make the

00:28:07.800 starting point for the DNS hierarchy,

00:28:10.000 so they need to be reachable without

00:28:11.666 using the DNS. So they've got well-known

00:28:14.066 IPv4 and IPv6 addresses

00:28:16.933 by which they usually reached. And these

00:28:19.633 13 servers advertise the top-level domains,

00:28:22.500 and they're the key to the whole DNS.

 

00:28:26.800 Why 13 of them?

 

00:28:29.433 Well, we want to be able to ask a DNS

00:28:32.600 server for the list of possible root servers.

 

00:28:37.433 That means it has to fit in

00:28:39.800 a DNS message. And DNS, for a

00:28:42.633 long time, and we’ll talk about this

00:28:45.000 in the next part, but DNS for

00:28:46.833 a long time only ran over UDP.

 

00:28:49.300 And there's a size limit in replies

00:28:50.866 for UDP. And 13 is the maximum

00:28:53.900 number of servers that will fit in

00:28:55.300 a single UDP packet, that's why there

00:28:57.166 are 13 root servers.

 

00:29:01.566 Who operates these root servers? Well the

00:29:05.466 slide shows the current set.

 

00:29:08.366 Each of the 13 is identified by

00:29:11.600 letter, and it has a well-known IPv4

00:29:14.800 address and a well-known IPv6 address.

 

00:29:17.900 And on the right, we see the

00:29:19.433 operators of these servers.

 

00:29:23.666 Now, what you see, looking at this

00:29:26.400 list of operators. is that they are

00:29:28.700 very heavily US-based.

 

00:29:33.400 Verisign, that

00:29:36.166 operates “a.root-servers.net”, is a

00:29:40.400 US-based domain name provider, for example.

00:29:45.766 The University of Southern California, USC/ISI,

00:29:49.900 is the organisation where Jon Postel worked,

00:29:52.600 which still operates a root server.

 

00:29:55.666 Cogent Communications is a US ISP.

00:29:59.400 The University of Maryland and NASA are

00:30:02.300 both research organisations in the US.

 

00:30:05.466 The Internet Systems Corporation, again, is US-based...

00:30:09.300 a couple of US government sites.

00:30:11.800 The only ones of these which are

00:30:14.233 not in the US, are RIPE NCC,

00:30:18.466 which is the European

00:30:20.666 Regional Internet Registry, and the WIDE project

00:30:24.000 which is in Japan.

 

00:30:26.566 And that's there for historical reasons.

00:30:30.500 The root servers were set up at

00:30:32.100 a time when the Internet was entirely

00:30:34.066 US dominated.

 

00:30:37.333 It’s not clear that that's necessarily appropriate

00:30:40.000 now, we'll talk much more about this

00:30:42.300 later, but it's there for historical reasons.

 

00:30:46.600 The IP addresses of these root servers

00:30:50.066 cannot be changed. They are hard coded

00:30:53.633 into, essentially, every DNS resolver in the

00:30:56.200 world, and they’re far too widely known

00:30:59.433 to be changed.

 

00:31:01.000 Who operates the servers can change,

00:31:03.333 but the IP addresses are pretty much

00:31:05.533 fixed forever now.

 

00:31:12.133 Now there are 13

00:31:15.066 root servers, but there are not 13 physical machines.

 

00:31:19.133 Almost all of the root server operators

00:31:22.033 use a technique, known as anycast routing,

00:31:24.233 which we'll talk more about in Lecture 9.

 

00:31:26.866 And the idea of anycast routing,

00:31:28.700 is that you have multiple machines that

00:31:31.000 have the same IP address. And they

00:31:33.233 get advertised into the routing system from

00:31:35.666 several different places in the network.

 

00:31:37.733 And the routing system then ensures that

00:31:40.633 traffic sent to that IP address goes

00:31:43.566 to the closest machine that has that address.

 

00:31:47.166 So, as a result, there are 13

00:31:49.533 IP addresses used to identify root servers,

00:31:52.400 but there are actually many more than 13 physical servers.

 

00:31:55.700 Most of the root servers actually have

00:31:58.533 several hundred machines using the same address,

00:32:01.266 in different data centres, and in different

00:32:03.466 locations around the world.

 

00:32:05.733 So it's a very heavily load balanced,

00:32:08.833 very heavily protected, system, even though it

00:32:11.566 appears as only 13 IP addresses,

00:32:13.633 only 13 machines.

 

00:32:17.266 That's all I want to say about

00:32:19.033 DNS names. I’ve spoke briefly about who controls the DNS,

00:32:22.966 and about ICANN, and the history of

00:32:25.400 ICANN. I’ve spoken about the types of

00:32:27.866 top-level domains, the country code and the

00:32:29.933 generic top-level domains, and the various special

00:32:32.133 use and infrastructure domains. And I’ve spoken

00:32:34.700 briefly about the international DNS, and the

00:32:36.900 DNS root servers.

 

00:32:38.533 In the next part, I’ll talk about how DNS queries are made.

 

00:00:00.333 In this part of the lecture I'd

00:00:01.600 like to talk about methods for DNS resolution.

00:00:04.133 I’ll talk a little bit about the security of the DNS,

00:00:06.366 and some of the historic security problems with the

00:00:09.233 DNS. And I'll talk about how DNS

00:00:11.166 resolution is performed today, using either UDP,

00:00:14.966 TLS, HTTPS, or QUIC.

 

00:00:19.100 So let's start by talking about DNS security.

 

00:00:22.966 The issue with the DNS is that,

00:00:25.166 historically, it has been completely insecure.

 

00:00:29.066 The original DNS protocol made requests,

00:00:32.533 and delivered, responses using UDP. And it

00:00:35.933 used UDP in a way which did

00:00:37.400 not have any form of encryption or authentication.

 

00:00:41.833 This meant it was trivial for attackers

00:00:45.733 on the path between the host making

00:00:48.700 the request, and the resolver which was

00:00:50.400 answering that request, to eavesdrop on what

00:00:53.333 names were being looked-up.

 

00:00:55.933 And the requests are not encrypted,

00:00:59.033 so anyone on the path, anyone who

00:01:01.166 can read the network traffic, can see

00:01:03.033 which hosts are looking at which names.

 

00:01:06.000 In addition, because the messages and the

00:01:08.933 replies are not authenticated in any way,

00:01:11.600 such an on-path attacker can easily forge

00:01:15.666 a response. If it responds faster than the

00:01:19.066 intended DNS resolver, there's nothing for the

00:01:22.633 requesting host to know that this is

00:01:25.600 a forgery, rather than the correct response.

00:01:28.300 There’s no way to authenticate the responses.

 

00:01:30.800 And this makes it straightforward to

00:01:33.533 redirect hosts in malicious ways by forging

00:01:36.500 DNS responses.

 

00:01:40.700 Now, obviously, this is a problem.

 

00:01:43.533 And over the last few years we've

00:01:45.833 seen a number of attempts at securing the DNS.

 

00:01:50.433 These fall into two categories. Some of

00:01:53.933 them relate to transport security, and some

00:01:55.900 of them relate to record security.

 

00:01:59.733 The issue about transport security is whether

00:02:02.200 we can make it possible to deliver

00:02:05.300 DNS requests, and receive replies, securely.

 

00:02:09.833 Make it possible to send DNS requests

00:02:12.766 over some sort of secure channel,

00:02:15.100 and get the answer, get the response,

00:02:17.900 back over that same channel.

 

00:02:20.033 And the idea here is that we

00:02:21.766 use a protocol, such as, for example,

00:02:23.633 TLS, to deliver the DNS requests and

00:02:28.100 retrieve the responses.

 

00:02:30.133 And,

00:02:32.066 since that the requests and the responses

00:02:34.233 are encrypted, they can't be understood or

00:02:37.600 modified by attackers. And that provides a

00:02:41.466 form of security, provided you trust the

00:02:43.600 resolver to give you the right answer.

 

00:02:47.833 This provides a trusted, and secure,

00:02:50.433 and encrypted and authenticated channel between the

00:02:53.300 host making the request and the resolver

00:02:55.633 that stops anyone reading the DNS messages

00:02:58.500 in transit., and stops them forging replies.

 

00:03:01.400 So, as long as the resolver is

00:03:02.966 correctly answering the queries,

00:03:04.366 this protects you from the DNS.

 

00:03:08.833 The other approach is what’s known as record security.

 

00:03:12.166 Add some form of digital signature to

00:03:15.333 the DNS responses, such that the client

00:03:18.066 can verify the data it’s receiving is valid.

 

00:03:22.500 And the idea here might be that

00:03:25.300 ICANN attaches a digital signature to the

00:03:29.233 root zone, which specifies the set of top-level domains.

 

00:03:33.600 The root server operators sign the information

00:03:37.266 they provide about the top-level domains.

00:03:39.633 The top-level domains then sign the information

00:03:42.800 they provides about subdomains. And so on.

 

00:03:45.966 And there’s a chain of digital signatures

00:03:48.366 that leads all the way back to

00:03:49.666 ICANN, and the root, for every name

00:03:52.533 that gets looked-up.

 

00:03:54.500 In this case, when you perform a

00:03:58.366 DNS lookup, when you resolve a name,

00:04:00.200 and you get a name back,

00:04:01.633 in addition to

00:04:03.266 the record which says this is the

00:04:05.266 name you looked-up, and this is the

00:04:06.733 corresponding IP address, you also get a

00:04:09.066 digital signature which allows you to verify

00:04:11.933 that it's not been tampered with.

 

00:04:14.066 And the clients, at least in principle,

00:04:16.033 can then verify the signatures, all the

00:04:18.866 way back up the hierarchy to the

00:04:20.266 root, and provide a chain of trust

00:04:21.833 that demonstrates ownership of the domain.

 

00:04:25.366 And this is implemented. And it makes

00:04:28.866 extensive use of digital signatures and public

00:04:31.433 key cryptography.

 

00:04:34.233 And, at least the top-level domains,

00:04:36.633 and the root zone, are all signed.

00:04:39.033 And a few of the more popular

00:04:41.833 sites are starting to

00:04:43.400 do this, and starting to sign their

00:04:45.700 requests, so the integrity of their data,

00:04:49.600 of the records, can be verified.

 

00:04:51.666 But it's not yet widely used.

00:04:53.800 It's starting to get use, but it's

00:04:55.666 not yet widely deployed.

 

00:04:58.500 Ideally, we want both transport security and

00:05:01.233 record security. Ideally, we want to both

00:05:04.666 secure the requests, so no one can

00:05:07.800 see which requests we are making,

00:05:10.100 and no one can modify the responses

00:05:12.033 we’re getting back from the resolvers,

00:05:14.333 and also use record security to verify

00:05:16.933 that the resolvers are not lying to us.

 

00:05:19.900 At present, we have the ability to

00:05:23.066 provide transport security, and we're starting to

00:05:25.833 see record security being deployed.

 

00:05:30.700 So, how does the transport actually work?

 

00:05:34.666 Well, historically DNS has run over UDP.

 

00:05:37.666 It’s run over UDP port 53.

 

00:05:41.666 The ideas of using UDP for DNS,

00:05:44.633 is that the requests and the responses are both small.

 

00:05:48.366 So, in theory, you don't need any

00:05:49.966 sort of reliability. You don't need any

00:05:52.400 form of congestion control.

 

00:05:54.800 The usual way this works in the

00:05:56.433 DNS, is that the client makes a

00:05:57.966 query to the resolver, the resolver looks-up

00:06:01.333 the name, and replies.

 

00:06:03.500 And the query is small. It's just a name:

00:06:07.166 “www.csperkins.org”,

00:06:10.433 “google.com”,

00:06:11.733 “facebook.com”, whatever it is.

 

00:06:13.866 And the response is just an IP address.

 

00:06:17.600 That doesn't need much space. It doesn't

00:06:20.400 need lots of packets.

 

00:06:23.500 So we can make both the request,

00:06:25.366 and get the response, each in a single packet.

00:06:27.633 And get the answer in

00:06:28.966 a single round-trip time, if the data

00:06:30.866 is cached by the resolver.

 

00:06:33.100 And this is more efficient than running it over TCP.

 

00:06:38.033 If you look at the example,

00:06:39.966 the packet diagram, on the left of

00:06:41.500 the slide, you see the query and

00:06:44.266 the response happen in one round-trip running over UDP.

 

00:06:47.533 Whereas, if you look at the diagram

00:06:50.066 on the right-hand side of the slide,

00:06:51.866 you see if you're running this over

00:06:53.333 TCP, you have the SYN, SYN-ACK,

00:06:56.000 ACK handshake to set up the connection;

00:06:59.133 the DNS query is sent immediately following

00:07:01.500 that ACK; and you get the response

00:07:03.833 one round-trip time later over the TCP

00:07:06.100 connection. And then you've got the FIN,

00:07:08.166 FIN-ACK, ACK handshake to tear down the TCP connection.

 

00:07:13.133 And you end up sending six packets,

00:07:16.500 three round-trips, for the TCP connection.

 

00:07:21.766 The initial handshake to set-up the connection,

00:07:25.700 the request and the response, and then

00:07:27.766 a handshake to tear-down the connection.

00:07:29.666 And it’s sending far more packets than is needed.

 

00:07:33.766 And there's not really any benefit to

00:07:36.866 using TCP. Once you've got the connection setup,

00:07:40.866 if a packet gets lost, what happens?

 

00:07:44.566 Well, TCP retransmits it.

 

00:07:48.166 Okay, but we don't need to TCP

00:07:50.666 to do that. We can just have

00:07:52.933 a simple timeout, and retransmit the packet

00:07:55.700 over UDP. There's no need

00:07:58.800 for complicated reliability measures, there’s no need

00:08:03.633 for congestion control, because the data being

00:08:05.933 sent just fits in one packet.

 

00:08:08.100 So it's perfectly reasonable to have a

00:08:09.966 timeout and retransmission.

 

00:08:12.466 Triple duplicate ACKs won't help, because there's

00:08:14.900 only ever one packet being sent.

 

00:08:17.366 Congestion control won't help: there's only ever

00:08:19.566 one packet being sent.

 

00:08:21.866 So, as a result, DNS historically has

00:08:24.800 run over UDP, and avoided the complexity

00:08:27.700 and the overheads of running over TCP.

 

00:08:32.466 So what's in a DNS over UDP packet?

 

00:08:36.000 Well, the diagram shows an IPv4 packet,

00:08:40.600 with a UDP header in it,

00:08:42.833 and then the contents of the DNS message.

 

00:08:46.633 The contents of the DNS message are

00:08:49.600 fixed header to indicate that this is a DNS packet,

00:08:53.633 a question section, an answer section,

00:08:57.100 an authority section, and some additional information.

 

00:09:02.566 When you're making a request, the question

00:09:06.133 section gets filled it. And this is

00:09:08.600 the list of domain names that are

00:09:11.333 querying and the requested record types.

 

00:09:14.366 So the question section might say,

00:09:16.366 for example, what is the AAAA record

00:09:19.066 for domain “csperkins.org”.

 

00:09:21.666 And you can include more than one

00:09:23.266 question in a request, provided they fit in the packet.

 

00:09:29.633 The DNS response contains, in addition to

00:09:33.200 the question section, which just echoes back

00:09:35.400 the question being asked, echoes back the

00:09:38.166 name being looked-up, also includes the answer

00:09:40.866 section, and the authority,

00:09:42.433 and the additional information sections.

 

00:09:44.966 And the answer section contains the answer.

00:09:47.433 It contains the IP address corresponding to

00:09:50.633 the name that was being looked-up,

00:09:52.966 and it contains a time-to-live to specify

00:09:55.800 how long that's valid. And the authority

00:09:58.200 section describes where the answer came from.

 

00:10:05.366 And this slide shows an example of

00:10:07.233 how this works. This is captured using

00:10:09.633 a tool called dig, which is a

00:10:11.566 standard DNS lookup utility that exists on

00:10:14.400 Linux and macOS.

 

00:10:17.166 And what we see, highlighted in black

00:10:20.433 here, is the question section, which shows

00:10:23.700 that we're looking up the A record

00:10:25.900 for my website, “csperkins.org”.

 

00:10:28.966 In blue, we see the contents of

00:10:30.933 the answer section, where it specifies that

00:10:35.100 the IP address of the site is

00:10:37.500 93.93.121.127, and it has a time-to-live of

00:10:44.566 2681 seconds.

 

00:10:48.200 We see an authority section, which specifies

00:10:51.833 that the response came from the name

00:10:54.400 servers for ns1.mythic-beasts.com or ns2.mythic-beasts.com,

00:11:01.466 and these are the name servers that

00:11:03.300 are hosting that domain. And we see,

00:11:06.266 in the additional information section in red,

00:11:10.266 where it's telling us

00:11:12.566 the IP addresses of those name servers,

00:11:15.433 so we can contact those servers if

00:11:17.500 we want to find out additional information about the domain.

 

00:11:21.500 And this is the typical structure,

00:11:24.000 you see in a DNS packet.

 

00:11:27.033 A question in the requests and the

00:11:29.833 responses. And the question, the answer,

00:11:32.733 the authority, and the additional information sections.

 

00:11:38.566 And that's DNS over UDP, which is

00:11:41.600 the way DNS has historically been used.

 

00:11:45.866 And as we mentioned earlier, DNS over

00:11:47.833 UDP is insecure. The packets are not

00:11:50.433 encrypted or authenticated in any way.

 

00:11:53.233 And this means that devices on the

00:11:54.933 path between the client and the resolver

00:11:56.733 can see the DNS queries and the

00:11:58.466 responses, and they can forge responses.

 

00:12:03.200 One way of getting around that is

00:12:05.366 to run DNS over TLS, rather than

00:12:08.766 running it over UDP.

 

00:12:12.033 And the way this works, is that

00:12:14.333 the DNS client opens a TCP connection

00:12:17.766 to the resolver, rather than sending UDP

00:12:20.600 packets. It makes a TCP connection to

00:12:23.000 the resolver on port 853.

 

00:12:25.633 The DNS client then negotiates a TLS

00:12:28.933 1.3 session within that TCP connection.

 

00:12:33.200 And, once it's done that, it sends

00:12:35.233 the query and receives the response over

00:12:37.466 that TLS connection, which is running over

00:12:39.433 the TCP connection.

 

00:12:42.933 Now what's in the request, and what's

00:12:45.200 in the response, is exactly the same

00:12:47.200 as if it was sending over UDP.

 

00:12:49.566 The contents of the request are formatted

00:12:52.133 exactly the same way, as would be

00:12:53.933 the contents of the UDP packet.

00:12:56.233 Except, instead of being sent in a

00:12:58.166 UDP packet, they’re sent within a TLS record.

 

00:13:02.900 And the response that comes back is

00:13:05.233 exactly the same as the response that

00:13:06.733 would be delivered over UDP.

 

00:13:09.166 Again, the only difference is that it's

00:13:10.833 sent inside a TLS record, inside a

00:13:13.066 TCP connection, rather than being sent inside

00:13:16.066 a UDP packet.

 

00:13:19.233 Now, this clearly provides security.

 

00:13:22.266 You're running over TLS, which encrypts and

00:13:26.033 authenticates the connection, which lets you authenticate

00:13:30.466 the identity of the resolver you're connected to.

 

00:13:36.366 It's also, clearly, a lot higher overhead.

 

00:13:40.066 You have to first negotiate a TCP connection.

00:13:43.100 Then you have to negotiate a TLS

00:13:45.300 connection. And then you can send the

00:13:47.933 DNS request, and get the response.

00:13:50.533 Then you tear down the TLS connection,

00:13:52.666 and you tear down the TCP connection.

 

00:13:55.966 So, what would be a single round-trip

00:13:58.233 time, to send the request and get the response

00:14:02.466 with DNS over UDP, turns into

00:14:06.933 a round-trip time to set-up the TCP

00:14:09.300 connection, followed by a round-trip time to

00:14:11.566 negotiate TLS, followed by a round-trip time

00:14:14.600 to make the DNS request and get the response,

00:14:18.033 followed by a couple more round-trip times

00:14:20.566 to tear down all the connections.

 

00:14:22.633 It’s a lot higher overhead, and it

00:14:24.833 runs it runs noticeably slower, but it

00:14:27.700 provides more security.

 

00:14:34.233 DNS server TLS actually works reasonably well,

00:14:37.366 and is moderately widely deployed.

 

00:14:40.800 We’re also starting to see a couple

00:14:42.766 of alternative methods of providing secure access

00:14:46.133 to the DNS.

 

00:14:47.833 One of these DNS over HTTPS,

00:14:50.666 often shortened to “DoH”.

 

00:14:54.600 And DoH is a way of allowing

00:14:57.100 a client to some queries to a

00:14:58.600 DNS resolver using HTTPS, rather than using

00:15:02.100 UDP or TLS.

 

00:15:05.900 And the idea here, is that you

00:15:08.900 open an HTTPS connection to the resolver,

00:15:12.233 and you then send the query over

00:15:15.366 that connection, and you get the response back in return.

 

00:15:19.833 There's two ways in which the request can be formatted.

 

00:15:24.166 It can be formatted as a GET

00:15:26.766 request. In this case you send an

00:15:28.766 HTTP GET request for the URL,

00:15:32.066 for the file part of the URL,

00:15:35.633 “/dns-query?dns=“ and then the base-64 encoded version

00:15:43.433 of the data you would have sent in the UDP packet,

00:15:48.266 with an “Accept:” header to indicate that

00:15:51.233 you expect a response type “application/dns-message”.

 

00:15:56.466 Alternatively, you use an HTTP POST request,

00:16:00.900 again with the URL path of “/dns-query”,

00:16:05.766 where the content type of the post

00:16:08.500 request is “application/dns-message”, and the content of

00:16:12.366 the query is the content is the DNS request.

 

00:16:18.800 And, in both cases, the request being

00:16:21.633 made is exactly the same request that

00:16:23.433 would be sent in a UDP packet.

 

00:16:27.266 If it's a POST query, the contents

00:16:29.833 that would go in the UDP packet

00:16:31.766 just go straight into the body of

00:16:34.033 the POST query, of the POST request.

 

00:16:36.600 And, if it's a GET request,

00:16:38.466 they’re base-64 encoded and put it in

00:16:41.166 the GET line. But, again, it's exactly

00:16:44.433 the same content as-if it was sent in a UDP packet.

 

00:16:50.400 No matter whether it's done using a

00:16:52.233 GET or a POST, the response that

00:16:54.666 comes back will be, assuming the name

00:16:58.033 exists, will be an HTTP 200 Ok

00:17:00.666 response, and that the body will have,

00:17:03.900 the header will say, it’s content type

00:17:05.666 “application/dns-message”, and the body of the response

00:17:08.733 will be the contents of the DNS

00:17:10.800 message. And, again, it's exactly the same

00:17:13.533 data that would come back in a UDP-based DNS response.

 

00:17:21.033 And the final way we're seeing people

00:17:24.533 starting to think about making DNS queries,

00:17:26.833 is to run them over QUIC.

 

00:17:29.833 And the idea with making DNS queries

00:17:32.833 over QUIC, is that it can avoid

00:17:34.466 some of the overheads, while still providing security.

 

00:17:38.033 So the principle is the same as

00:17:39.800 running DNS over TLS.

 

00:17:42.766 The client opens a QUIC connection to

00:17:44.933 the resolver and, as part of opening

00:17:47.000 that connection, it negotiates TLS security.

 

00:17:49.900 And then it sends the DNS request

00:17:52.666 inside that connection, and gets the response

00:17:55.433 back over the same connection. And,

00:17:58.133 again, they contain exactly the same data

00:18:00.600 as they would if the queries and

00:18:02.533 responses were sent in UDP.

 

00:18:05.466 Unlike DNS over TLS, or DNS over

00:18:09.100 HTTPS, DNS over QUIC is not yet standardised.

 

00:18:15.466 The URL on the slide points that

00:18:17.266 to the draft specification, but that's still

00:18:20.200 a work in progress.

 

00:18:24.700 What we see, is that there are

00:18:26.200 increasingly many ways of making DNS queries.

 

00:18:29.833 There’s the traditional approach of sending the

00:18:32.066 queries over UDP.

 

00:18:34.033 You can also send them over TCP,

00:18:36.200 over TLS, over HTTPS, or over QUIC.

 

00:18:40.966 And, in all of these cases,

00:18:42.966 the contents of the request, the contents

00:18:46.000 of the query, and the contents of

00:18:47.633 the response are identical.

 

00:18:50.166 You're sending the exact same DNS queries,

00:18:53.333 the exact same DNS requests. You're getting

00:18:56.033 the exact same DNS responses back.

 

00:18:59.366 All that's changing is the transport protocol.

 

00:19:01.666 All that’s changing is how the query

00:19:03.566 is delivered to the resolver, and how

00:19:05.500 the response is returned.

 

00:19:07.600 It doesn't change the contents of the messages at all.

 

00:19:11.866 What it does, is change the security guarantees.

 

00:19:15.900 If you're using TLS, or HTTPS,

00:19:18.500 or QUIC to deliver the DNS queries

00:19:22.166 you're guaranteed that nobody, none of the

00:19:26.866 devices on the network between the client

00:19:29.033 and the resolver, can see those queries.

 

00:19:31.933 So you’re providing confidentiality.

 

00:19:34.300 And you're guaranteed that none of the

00:19:35.933 devices on the network between the client

00:19:37.933 and the resolver can forge responses.

 

00:19:40.900 So it protects from eavesdropping on the

00:19:44.933 messages, and it protects from people on

00:19:47.566 the local network spoofing DNS responses

00:19:50.666 and redirecting you to a malicious site.

 

00:19:59.433 What it doesn't do, is protect you

00:20:01.266 if you don't trust the resolver.

 

00:20:04.366 We still need DNS security, we still

00:20:07.433 need signed DNS responses, to allow you

00:20:11.500 to check if the resolver is lying,

00:20:14.733 but it at least makes the connection

00:20:16.600 between the client and the resolver secure.

 

00:20:19.766 And, certainly with the option of running

00:20:22.400 DNS over HTTPS, it also gives the

00:20:24.600 client the flexibility to query different resolvers,

00:20:28.233 to make requests to whichever resolver it

00:20:31.866 likes, using HTTPS.

 

00:20:35.033 So that gives some flexibility to choose

00:20:38.066 a resolver that it trusts for a particular domain.

 

00:20:43.900 And that’s all I want to say

00:20:45.333 about DNS resolution. As we've seen that

00:20:48.166 there are some security challenges, both in

00:20:51.033 providing transport security to prevent eavesdropping and

00:20:55.433 prevent forged requests, and in terms of

00:20:58.500 record security for authenticating the responses that

00:21:01.033 come back.

 

00:21:02.633 The traditional approach to DNS resolution,

00:21:05.166 over UDP, doesn't address any of those security challenges.

 

00:21:09.033 But we're increasingly seeing devices moving to

00:21:11.600 using DNS over TLS, or over HTTPS,

00:21:15.300 and I expect in future DNS over QUIC as well.

 

00:21:18.566 And that provides transport security, it prevents

00:21:21.766 people eavesdropping on the DNS requests,

00:21:24.200 and it prevents people forging the responses.

 

00:21:26.766 And, I hope, we will also see

00:21:29.133 signed and authenticated DNS records getting broader

00:21:33.600 use, in order to prevent

00:21:36.933 malicious resolvers from spoofing responses.

 

00:00:00.166 In this final part of the lecture,

00:00:01.966 I want to talk about the politics of names.

 

00:00:04.600 I’ll talk about the choice of DNS

00:00:06.666 resolver, some issues around intellectual property rights

00:00:10.633 and the DNS, about what domains should

00:00:13.033 exist, who controls what domains exist,

00:00:15.933 and who controls the DNS root.

 

00:00:20.566 So let's start by talking about the

00:00:22.466 choice of the DNS resolver. How does

00:00:24.733 a host know which DNS resolver to use?

 

00:00:28.333 Well, when it connects to a network,

00:00:30.366 a host uses something known as the

00:00:32.666 Dynamic Host Configuration Protocol to discover the

00:00:36.733 network settings and configuration options.

 

00:00:39.266 DHCP provides the host with its IP

00:00:43.266 address, tells it the IP address of

00:00:45.200 the router, the network mask, and parameters

00:00:47.933 such as that. And it also tells

00:00:50.333 the host what DNS resolver to use

00:00:52.300 on that network.

 

00:00:54.166 And, usually, this would be a DNS

00:00:56.100 resolver operated by the network operator,

00:00:58.933 operated by the Internet service provider.

 

00:01:02.333 If the host connects to multiple networks,

00:01:05.033 if the host has multiple network interfaces,

00:01:07.900 DHCP runs separately on each interface,

00:01:10.600 and it may give a different DNS resolver for each interface.

 

00:01:15.233 For example, if a device connects to

00:01:17.666 both a 4G cellular network, and to

00:01:21.366 a private company Ethernet, then it’s possible that

00:01:25.100 the company Ethernet might make available names

00:01:28.366 for internal services which didn't exist outside

00:01:31.733 the company, and which are not visible on the 4G network.

 

00:01:34.933 So applications on multi-homed hosts, on hosts

00:01:39.633 with multiple network interfaces, should specify which

00:01:43.666 network interface

00:01:45.566 they're resolving names on, by specifying a

00:01:49.300 local IP addresses as one of the

00:01:51.166 parameters, one of the hints parameters,

00:01:53.700 in the getaddrinfo() call, to make sure

00:01:55.900 the names are resolved in the correct

00:01:57.700 interface, on the correct network.

 

00:02:00.466 And, of course, it's also possible to

00:02:02.566 manually configure the host. And a common

00:02:06.033 use of this might be, for example,

00:02:08.000 to talk to the Google’s public DNS

00:02:11.466 resolver, on IP address 8.8.8.8, but there

00:02:15.966 are several other public resolvers available.

 

00:02:24.566 DNS resolution has typically been implemented as

00:02:28.033 a system wide service. DHCP configures the

00:02:31.800 host, tells it the resolvers to use,

00:02:34.166 and then all applications on the host

00:02:37.033 access the same resolvers through the operating

00:02:39.666 system interface.

 

00:02:41.866 And this means you get a consistent

00:02:43.933 mapping of names to addresses.

00:02:45.800 No matter which application makes the query,

00:02:48.400 it will always get the same answer,

00:02:50.666 because it's always talking to the same DNS resolver.

 

00:02:54.800 The use of protocols such as DNS

00:02:57.366 over HTTPS is starting to change this, though.

 

00:03:02.133 When you have DoH, when you have

00:03:05.200 DNS over HTTPS, it's possible for applications

00:03:08.966 to easily perform their own DNS queries.

 

00:03:11.900 And, in particular, it's possible for web

00:03:14.100 applications, written in JavaScript, to perform DNS

00:03:18.000 queries by making HTTPS requests to any website,

00:03:22.400 any website that supports DoH. And this

00:03:26.266 means that different applications, different websites,

00:03:28.533 can have different views of what the

00:03:30.300 network looks like; of what names exist,

00:03:32.900 and what names map to what IP addresses.

 

00:03:36.866 And, in principle, it was always possible

00:03:39.100 for applications to do. It was always

00:03:41.133 possible for applications to override the choice

00:03:43.266 of DNS, it was always possible for

00:03:45.766 an application to bundle it’s own UDP-based DNS resolver.

 

00:03:51.133 But it's now much easier.

00:03:53.266 And, because it's easier,

00:03:54.566 more applications are starting to do it.

 

00:03:59.400 Is this a problem? Does it matter

00:04:02.066 if we're giving applications the ability to

00:04:04.366 pick different DNS resolvers, to resolve names

00:04:07.700 according to a resolver of their choice?

 

00:04:10.200 In particular, given that we're allowing applications

00:04:13.300 to securely resolve names using DNS server

00:04:18.166 of their choice, why does that matter?

 

00:04:21.400 Is it a problem that we're giving

00:04:23.666 flexibility? Is it a problem that we're

00:04:26.100 allowing applications to make their own DNS queries?

 

00:04:30.266 Well, I think there’s pros and cons here.

 

00:04:33.966 In some ways, it's clearly beneficial.

 

00:04:36.866 In some ways it's clearly a good

00:04:39.133 thing, and it's not a concern that

00:04:42.033 different applications can perform DNS queries in

00:04:44.800 different ways.

 

00:04:46.633 And you can easily make the argument

00:04:48.700 that applications should have the ability to

00:04:50.566 choose a DNS server they trust.

00:04:53.366 To make sure that they avoid phishing

00:04:55.900 attacks, to make sure they avoid malware,

00:04:58.366 to make sure they avoid monitoring.

 

00:05:01.766 I think you can easily make the arguments that

00:05:05.600 network operators should not be able to

00:05:08.000 see the DNS queries, they should not

00:05:09.933 be able to modify the responses.

 

00:05:12.333 Resolvers run by network operators should not

00:05:15.033 be able to see what queries applications

00:05:17.366 are making, and that by allowing this,

00:05:19.700 this is a privacy and security risk.

 

00:05:22.233 And there's a benefit in allowing applications

00:05:24.666 to talk to a DNS resolver of

00:05:26.766 their choice, and prevent the network operator

00:05:29.600 from snooping on their traffic.

 

00:05:32.533 I think these are all perfectly reasonable

00:05:36.800 arguments; this makes a lot of sense.

 

00:05:42.200 Equally, though, it's possible to make the

00:05:44.700 argument that it's problematic for applications to

00:05:47.633 have the ability to override the choice of DNS.

 

00:05:53.733 Network operators will say that they can

00:05:58.000 filter DNS responses to block access to

00:06:01.466 sites which are providing malware, or which

00:06:05.700 are being malicious, or which are fraudulent.

 

00:06:08.766 And that allowing applications to override the

00:06:11.400 choice of DNS, talk to a server

00:06:13.566 of their choice, allows them to bypass

00:06:16.966 these security services.

 

00:06:20.066 It allows them to bypass the filtering

00:06:22.366 which is protecting them from malware,

00:06:24.266 that's protecting them from fraudulent websites.

 

00:06:29.066 And, in many countries,

00:06:31.333 network operators are required by law to

00:06:33.933 filter DNS responses, to enforce legal or

00:06:37.866 societal constraints.

 

00:06:40.233 For example, in the UK, the Internet

00:06:42.600 service providers apply a DNS block list

00:06:46.266 provided by the Internet Watch Foundation,

00:06:48.900 which is there to prevent access to

00:06:51.033 sites hosting child sexual abuse material.

 

00:06:54.233 By allowing applications to make their own

00:06:57.166 choice of DNS resolver, by allowing them

00:06:59.766 to access resolvers other than the one

00:07:02.633 provided by the Internet service provider,

00:07:04.966 this allows the applications to opt out

00:07:07.000 of such filtering, and to access such

00:07:09.666 prohibited content.

 

00:07:11.900 And, fundamentally, the problem is that both

00:07:15.000 legitimate filtering, and malicious and harmful DNS

00:07:19.400 filtering, use the same mechanisms. And the

00:07:23.066 mechanisms to protect against

00:07:25.766 phishing attacks, malware, and monitoring the DNS,

00:07:29.833 also protect against, and prevent, the legitimate

00:07:33.766 filtering of DNS requests.

 

00:07:39.366 Can the network restrict the choice of

00:07:42.600 DNS resolver? Can the network stop applications

00:07:45.633 from choosing their own DNS, if they wish to do so?

 

00:07:50.400 Well, for DNS-over-UDP or for DNS-over-TLS,

00:07:53.900 this is certainly possible.

 

00:07:56.066 If a network blocks outgoing UDP traffic

00:08:01.100 on UDP port 53, for example,

00:08:03.600 in its firewall, this will effectively block

00:08:06.500 DNS-over-UDP to any sites which it chooses.

 

00:08:10.666 Similarly for DNS-over-TLS resolver, you can block

00:08:14.233 access, a network operator can block access,

00:08:16.733 to TCP port 853, and prevent outgoing

00:08:19.900 traffic to that port, and that will

00:08:22.100 stop DNS-over-TLS to any sites other than

00:08:24.833 the ones it allows.

 

00:08:27.933 it's much harder, though, to block DNS-over-HTTPS.

 

00:08:32.766 The problem here, for the network operators,

00:08:35.833 is that since the traffic is encrypted,

00:08:38.733 all it can see is an outgoing,

00:08:41.433 encrypted, TCP connection to a web server.

 

00:08:45.966 And it can't tell whether the data

00:08:48.266 being exchanged over that connection is regular

00:08:51.233 HTTPS traffic comprising web pages,

00:08:54.133 or DNS-over-HTTPS requests.

 

00:08:58.300 Now, in some cases, it's possible to

00:09:01.433 make this distinction from the IP address.

 

00:09:04.666 For example, Google runs a public DNS-over-HTTPS

00:09:09.300 server on IP address 8.8.8.8.

 

00:09:13.133 And, you know if you're seeing HTTPS

00:09:17.233 requests going out to this address,

00:09:18.833 this is DoH traffic, because Google doesn't

00:09:22.266 run any other websites on that address.

 

00:09:25.466 But, if you have a web server

00:09:27.100 that handles a mix of both regular

00:09:29.066 web traffic, and DNS over HTTPS traffic,

00:09:32.400 it's not possible for an ISP to

00:09:34.533 block one of these without blocking the other.

 

00:09:37.333 And if this is a popular website,

00:09:40.400 if Google decided to offer DoH services

00:09:44.433 along with its regular web services,

00:09:46.566 it would be very difficult for network

00:09:48.133 operators to block the DNS over HTTPs traffic.

 

00:09:53.166 And many of the Internet service providers,

00:09:55.700 many network operators, many governments, are getting

00:09:59.266 concerned that this use of DNS over

00:10:02.066 HTTPS is making it harder to use

00:10:05.900 DNS as a control point.

 

00:10:08.266 Many organisations are used to using DNS

00:10:12.033 to block access to certain types of traffic.

 

00:10:15.800 And this is becoming much harder for

00:10:17.633 them, as more and more traffic moves

00:10:20.033 to DNS over HTTPS.

 

00:10:23.200 And, of course, whether that's a good

00:10:24.733 or a bad thing depends on your

00:10:26.633 politics, and it depends on what type

00:10:28.233 of traffic is being blocked. But it's

00:10:31.133 certainly an issue, and it's a change

00:10:33.133 in the way the network operates.

 

00:10:40.900 DNS, and DNS names, also tend to

00:10:45.600 impinge on questions of intellectual property rights.

 

00:10:49.800 And the issue here is that intellectual

00:10:52.433 property laws tend to be managed on a national basis.

 

00:10:58.200 For example, it's entirely possible that a

00:11:01.300 particular company might own a certain trademark

00:11:04.800 in the UK, while a different company

00:11:07.433 might own that trademark in the Republic of Ireland.

 

00:11:11.266 And, in that case, it would be

00:11:13.033 perfectly reasonable, and perfectly sensible, for

00:11:17.333 the domain name “trademark.ie” to be owned

00:11:21.133 by the company in the Republic of

00:11:22.933 Ireland, and the domain name “trademark.co.uk” to

00:11:26.600 be owned by the company in the

00:11:29.666 UK. And which of those companies should

00:11:34.033 own which of those domains is then

00:11:35.700 a very straightforward legal question,

00:11:38.100 and it's handled by the courts in

00:11:41.300 those in those countries.

 

00:11:45.200 And, for

00:11:46.766 country code top-level domains, this sort of

00:11:49.300 question is straightforward.

 

00:11:51.266 For the generic top-level domains, though,

00:11:53.666 it gets a bit trickier.

 

00:11:55.633 Which of those companies, for example,

00:11:57.566 should own “trademark.com”?

 

00:12:02.000 Each of the companies has the respective

00:12:04.666 trademark in the jurisdiction where they're based.

 

00:12:09.433 Yet you have a generic domain,

00:12:11.366 which is not tied to a particular

00:12:13.066 country, to a particular jurisdiction, so which

00:12:15.166 of those should have the rights over it?

 

00:12:18.066 And, in particular, this may get hard

00:12:20.566 because “.com” is operated by US-based organisation

00:12:24.133 currently, and a different organisation may own

00:12:27.300 that trademark in the US.

 

00:12:31.100 Country code top-level domains have the advantage

00:12:34.500 of clearly operating under the legal regime

00:12:37.166 of a particular country. It makes it

00:12:39.233 easy to resolve legal questions about intellectual

00:12:42.500 property, and about ownership of the domains.

 

00:12:46.366 Generic top-level domains are much less clear.

 

00:12:52.366 Is the right of ownership for a

00:12:54.333 generic top-level domain based on where the

00:12:56.600 domain operator is? Or based on where

00:12:59.033 the person requesting the name is?

 

00:13:01.033 And, if there are multiple people who

00:13:03.033 want the name, in multiple different countries,

00:13:05.033 and they're not necessarily the same country

00:13:07.233 as the domain operator, this gets legally

00:13:09.633 tricky to work out who has ownership

00:13:11.600 and who has control.

 

00:13:17.266 And this also ties in, to some

00:13:19.400 extent, to the questions about which top-level

00:13:22.200 domains, and which subdomains should be allowed to exist.

 

00:13:27.933 And If you think about top-level domains,

00:13:30.866 what generic top-level domains should ICANN permit to exist?

 

00:13:40.766 What's the list of domains that should

00:13:43.366 be allowed? And who gets to control that?

 

00:13:46.933 And an example which has been long-running,

00:13:52.466 and is contentious, is the domain “.xxx’,

00:13:56.566 the top-level domain “.xxx”.

 

00:14:00.800 And question is about whether this domain,

00:14:03.633 this top-level domain, should exist, in order

00:14:06.466 to host adult content.

 

00:14:09.266 And if it does exist, who gets

00:14:12.100 to decide what content should sit within

00:14:15.933 that domain, within that top-level domain? And

00:14:19.200 what content must sit within that domain?

 

00:14:22.800 And, different countries have very different norms,

00:14:25.733 and very different standards, for what constitutes

00:14:28.666 adult content, and for what type of

00:14:30.633 filtering is, and isn’t, appropriate.

 

00:14:35.866 And this is, obviously, a contentious example,

00:14:38.700 but there are many other such examples.

00:14:40.933 What top-level domains should exist, and who

00:14:43.466 gets to decide? Because different parts of

00:14:46.233 the world have very different norms for

00:14:49.133 what's acceptable or not.

 

00:14:55.066 When it comes to particular subdomains,

00:14:57.466 again, different regions,

00:15:01.400 different countries, have significant

00:15:04.700 differences in their laws and norms about

00:15:07.300 freedom of speech, and about permissible topics,

00:15:12.000 about permissible topics for websites.

 

00:15:19.100 And a country code top-level domain can

00:15:22.333 clearly enforce the local conventions and rules

00:15:25.933 for the country that it represents.

 

00:15:30.466 If you have a “.co.uk” domain,

00:15:33.966 for example, it’s pretty clear that it

00:15:35.566 should enforce UK law. If you have

00:15:38.433 a “.de” domain, it's pretty clear that

00:15:40.566 should be enforcing German law.

 

00:15:43.100 But what about generic top-level domains? What

00:15:46.600 about “.com”, for example?

 

00:15:49.433 If a site in a generic top-level

00:15:52.033 domain is hosting content which is legal

00:15:55.066 in some countries, but illegal in other

00:15:58.033 countries, should that be permitted?

 

00:16:01.833 If a particular country, or a particular

00:16:05.000 group, finds the content of a site

00:16:06.866 objectionable, should that site be taken down

00:16:10.033 if it's in a generic top-level domain?

 

00:16:14.333 If a country X, for example,

00:16:17.133 decides that certain content is illegal and

00:16:20.400 should be prohibited, but if it's legal

00:16:23.666 in country Y,

00:16:25.266 should a generic top-level domain operating out

00:16:28.100 of country Y, but accessible in country

00:16:30.433 X, permit such content?

 

00:16:33.700 To make this concrete, holocaust denial is

00:16:37.366 illegal in Germany, but not in the US.

 

00:16:41.500 Should “.com”, operating from the US,

00:16:44.900 permit sites which host material which denies

00:16:48.266 that the Holocaust happened?

 

00:16:50.533 It's legal where “.com” exists, but those

00:16:54.600 sites are accessible from countries, from Germany,

00:16:58.033 where this content is illegal.

 

00:17:01.066 And who gets to enforce these decisions?

00:17:03.633 Who gets to arbitrate between the sites?

 

00:17:06.566 Should the generic top-level domains be bound by,

00:17:11.366 only be bound by, the laws of

00:17:15.100 the country which they operate from?

 

00:17:17.433 Or do we need some sort of international

00:17:20.900 norms, international set of laws, about how

00:17:24.300 globally accessible domains should operate, and what

00:17:27.133 rules they should enforce?

 

00:17:32.800 I think there are similar questions about the root servers.

 

00:17:36.733 Currently, most of the DNS root servers

00:17:41.666 are operated, or controlled, by US-based organisations.

 

00:17:48.000 And they all currently host the same

00:17:51.333 content. They all currently follow the set

00:17:55.533 of top-level domains that ICANN defines.

 

00:18:01.700 But there's nothing technically requiring they do so.

 

00:18:07.033 The question is, is it a risk

00:18:09.466 to other countries that all of these

00:18:12.300 root servers are controlled, that most of

00:18:15.400 the root servers are controlled, by a

00:18:17.033 single country? Should we be looking to

00:18:19.900 broaden the mix of countries that operate,

00:18:22.466 and that control, the root servers?

 

00:18:27.433 And if we do, who gets to decide how this happens?

 

00:18:33.400 Is this something where

00:18:35.966 ICANN should be deciding, ICANN should be

00:18:39.300 mandating, that the root servers move to

00:18:42.666 be operated in different countries? Is this

00:18:45.966 something that a particular national government should do,

00:18:50.000 and declare that they will run a

00:18:52.600 different root server for hosts in their

00:18:54.833 country? Is this something where the United

00:18:56.933 Nations should step in?

 

00:18:59.666 And is there a benefit in controlling

00:19:01.733 a DNS root server? Or is it

00:19:03.666 just an administrative overhead that nobody actually wants?

 

00:19:08.666 In theory, all the root servers return

00:19:11.266 exactly the same content anyway, so why

00:19:13.766 should you care if you control one?

00:19:16.800 Unless, perhaps, you want a different view

00:19:19.400 of the DNS, unless you want a

00:19:21.300 different set of top-level domains in your

00:19:23.066 country than in other parts of the world.

 

00:19:27.733 Similarly, is there benefit in controlling a

00:19:30.600 generic top-level domain server?

 

00:19:33.666 Is there a benefit to a country

00:19:36.233 in hosting “.com”, for example?

 

00:19:40.366 And I don't know the answer,

00:19:42.466 but there are questions that should be

00:19:44.266 asked, and there are interesting political questions

00:19:47.533 that should be asked, about the control

00:19:49.833 of the DNS root servers and the

00:19:52.866 generic top-level domain servers.

 

00:19:57.833 There’s also the question about whether there

00:20:00.033 should be a single DNS root?

 

00:20:02.933 Should all of the top-level domains be

00:20:05.400 accessible from everywhere? Should the global view

00:20:08.033 of the DNS be the same,

00:20:10.266 no matter where you're coming from?

 

00:20:12.633 Should the same name always resolve to

00:20:14.866 the same site? And, with content distribution

00:20:18.133 networks which host sites at local proxies

00:20:22.166 throughout the world, can you tell?

 

00:20:26.333 And what sort of filtering of the

00:20:28.133 DNS traffic should be permitted? And should

00:20:30.666 different countries be allowed to do this,

00:20:33.300 and are there any restrictions on what

00:20:35.433 filtering should be permitted, and how it

00:20:37.966 should be implemented?

 

00:20:40.733 And, as we've seen with DNS-over-HTTPS,

00:20:43.466 it's currently very difficult to distinguish modifications

00:20:47.266 made to DNS responses, in order to

00:20:51.166 conform to government mandated filtering requirements,

00:20:54.333 from those made by malware, and phishing

00:20:56.700 attacks, and so on.

 

00:20:58.966 And I guess the question here is,

00:21:00.600 is this a feature of the DNS,

00:21:02.333 or is this a bug?

 

00:21:04.100 And what sort of filtering should be

00:21:06.566 permitted? Should be possible?

 

00:21:13.233 So that concludes the discussion of DNS.

 

00:21:16.200 I’ve spoken about what is the DNS,

00:21:19.266 how the queries are made,

00:21:21.533 and in a reasonable amount of detail

00:21:23.366 about what names exist, and who controls

00:21:26.666 the set of names, and

00:21:28.800 how and what sorts of filtering should happen.

 

00:21:33.766 DNS is one of the more contentious

00:21:35.933 parts of the Internet. It ties-in with

00:21:39.533 notions of national sovereignty,

00:21:41.766 with intellectual property laws,

00:21:43.900 with societal norms about what sort of

00:21:47.833 content should, or should not, be accessible.

 

00:21:50.666 And it's one of the interesting areas

00:21:53.833 where the technology and the politics combine.