← All coursesBack to the simulator →

DNS and names in the network

From the “phone book” into depth: who asks whom (client, resolver, authority), cache and TTL, your own local DNS in a company as well as public resolvers and the path from the root, record types (A, CNAME, MX, TXT, NS, PTR) and what they are for — and finally what happens when DNS fails or lies.

This is a text preview of the lessons for reading. The full version – an interactive simulator with animations, exercises and quizzes – runs in the app.

▶ Launch the interactive version

Lesson 1: From a name to an address

Why names: addresses change, names stay

PCDNSNETROOT/TLDAUTHWEBATTACKERa human remembers a name, not a number

In Course 1 you saw that DNS is the “internet’s phone book”: you type example.com and DNS returns a number, an IP address. This course goes further – it shows who actually gives that answer, where they get it, and what happens when they get it wrong. We start with a question almost nobody asks out loud: why do we use names at all? The answer “so people can remember them” is only half the truth. The other, more important half: addresses change, names stay. A server moves to another provider and gets a new IP address, a company swaps hardware, a service splits across ten machines in five countries – and you still type the same name. If browsers, links, configurations and emails held hard-coded numbers, every such move would mean visiting all those machines and rewriting the numbers. A name therefore works as a layer of distance between what you remember and where the service physically sits right now. You see the whole thing on the scene: your PC knows the name, DNS knows the name↔address pair, and WEB has some address that may well change tomorrow. Try it in the simulator too: every host (PC, server…) has a DNS name (FQDN) field in its detail, on the Type & services tab – and you will then be able to find it under that name in the path test (the test panel next to the canvas), where by-name targets appear in the “By name (DNS)” group. Filling in the name alone is not enough, though – something has to serve that name, namely a DNS server holding it in its records. You will build exactly that in lesson 2.

Step by step

  1. You type a name into the browser – web.acme.local. You would never remember a number, nor read it out to a colleague on the phone.
  2. But one day the server moves and gets a different IP address. In a network’s life that happens routinely.
  3. Only a single DNS record needs fixing. The name stays the same – no user has to rewrite anything.
  4. The name is a layer of distance between you and where the service physically sits. In the simulator you set it in the DNS name (FQDN) field.

Who asks whom: client, resolver, authority

PCDNSNETROOT/TLDAUTHWEBATTACKERclient: web.acme.local = ?

Course 1 drew DNS as one box that simply knows the answer. In reality every name resolution has three roles, and the difference between them is the core of this whole course. 1) The client – your computer. It knows the least: it can ask one question (“what IP belongs to this name?”) and wait for a finished answer. It handles nothing else. 2) The resolver – the server the client asks. It is usually a DNS server in your network or at your provider. The resolver generally does not know the answer – but it can find it out: it walks the other servers on your behalf and returns the result. It is a kind of errand runner. 3) The authoritative server – the one that actually owns the answer. It holds the records for its domain because somebody put them there. When it says “web.acme.local is 10.0.2.20”, that is a definition, not a guess. This difference is worth taking seriously: the authority KNOWS the answer, the resolver only FINDS IT OUT. You could ask the authority directly, but you would have to know which authority it is – and that is exactly the work the resolver does for you. In the simulator the role shows up in the network settings as “DNS server for this network”: clients on that network ask precisely that one. And the resolver role does not have to be played by a server – a router, firewall or L3 switch can take it too. You will see exactly how in the next lesson, in the module “Who resolves? The router as a resolver”.

Step by step

  1. The client can do one thing: ask “what IP belongs to this name?” and wait for a finished answer.
  2. It asks the resolver. The resolver usually does not know the answer – its job is to find it out for you from other servers.
  3. The resolver reaches the authoritative server – the one that owns the record. Its answer is a definition, not a guess.
  4. The resolver returns the finished result to the client. In the simulator you set this role on a network as the “DNS server for this network”.

Cache and TTL: why we do not ask every time

PCDNSNETROOT/TLDAUTHWEBATTACKERfirst query: the resolver must go out

If the resolver walked the world on every query, the internet would be unbearably slow – opening a single page asks for dozens of names. So every link in the chain caches answers: the client in its system and its browser, and above all the resolver on behalf of all its users at once. Then when anyone asks for the same name, the answer comes instantly from memory, without a single query going out. That is why opening a page a second time is noticeably faster than the first. But an answer in memory ages: what if the address has changed in the meantime? So that a cache never gets stuck on a permanent lie, every DNS answer carries a number with it – the TTL (time to live): how many seconds that answer may be kept before it must be discarded and looked up again. The TTL is set by whoever owns the record – that is, the authority. And it is an interesting choice between two annoyances. A long TTL (say a day) = few queries, fast answers, but a change takes a whole day to spread through the world. A short TTL (say a minute) = a change is almost immediate, but the servers get far more queries. Remember the practical consequence: when you change a record, the change does not take effect at once – part of the world will see it only after the TTL expires. That is why the TTL is lowered first, and only then is the server moved. Once you have built your own DNS in lesson 2, try it in the simulator. Run the same by-name test twice in a row from the same device. The second time you will see “from the client’s local cache” – the client did not even ask the resolver. Now the same name from a different device: it does ask, but gets “from the resolver cache”. Those are exactly the two cache levels. (The remaining TTL on each record shows in advanced mode – the Simple / Advanced toggle is at the top of the app.) What a device remembers is shown in its detail on the DNS cache tab – and you can flush it by hand (the classic helpdesk step). In advanced mode you’ll notice the client remembers “does not exist” too (negative caching) and the time left on each entry. Note that the cache here is a teaching simplification – it is emptied as soon as you change anything in the topology, so your edit to a record takes effect immediately (the real world would have to wait for the TTL).

Step by step

  1. The first query for a name costs time: the resolver must walk the world and only then find the answer.
  2. The resolver stores the answer in its cache, along with a TTL: how many seconds it may be kept.
  3. The second query for the same name returns instantly from the cache – nothing travels out. That is why a second visit is fast.
  4. The price of speed: when you change the address, part of the world sees it only after the TTL expires. So the TTL is lowered before a move.

▶ Open in the simulator

Lesson 2: Local DNS: names in your own network

Why have DNS at home and in a company

PCDNSNETROOT/TLDAUTHWEBATTACKERown record: web.acme.local → WEB

So far this sounded as if DNS were an internet thing. It is not – your own DNS server makes enormous sense inside a company or a home too, for three reasons. 1) Names for your own servers. Your printer, file server and internal applications are not in any public DNS and never will be – nobody outside the company is meant to meet them. Yet you still want to type web.acme.local instead of 10.0.2.20. Your own DNS lets you: you simply write the records into it yourself. 2) Independence and speed. An internal name resolves at home, in milliseconds, without anyone outside learning about it. And with the resolver standing in your own network, users find answers to everyday names already in its cache. 3) Visibility and control. The resolver sees what your network is asking about – a golden source both for troubleshooting and for security (in Course 8, Advanced security, you saw that odd DNS queries can betray a tunnel or malware). For this luxury you pay one price, covered at the end of this lesson: the resolver becomes a critical device. Build it in the simulator: add a Server from the palette and in its detail (Type & services) turn on the DNS (port 53) service – DNS is a service, not a device type of its own. That unlocks a new DNS tab on the server with the editor of records (name → IP address); fill them in by hand or click “Fill from device names”. It also learns website addresses: a web server (with port 80/443 on) carries them on its own Web tab, so one web server can serve several addresses. Finally, in the client network settings choose that server as the “DNS server for this network” – without this step no name in the network resolves at all, because the clients have nobody to ask (and the topology check flags a network with no resolver). From then on the path test lets you pick a destination under “By name (DNS)”.

Step by step

  1. Names for your own servers: your printer and internal site are in no public DNS. Into your own DNS you write them yourself.
  2. Independence and speed: an internal name resolves at home, in milliseconds, and nobody outside needs to know about it.
  3. Visibility and control: the resolver sees what your network asks about – gold for troubleshooting and security (Course 8 – Advanced security).
  4. In the simulator: add a DNS server, fill in records (or use “Fill from device names”) and set the network’s “DNS server for this network”.

Records and forwarding: what I know, the rest I pass on

PCDNSNETROOT/TLDAUTHWEBATTACKERwhat I know → I answer myself

So your company resolver has your own servers’ names written in it. But what happens when somebody asks it for example.com – a name nobody wrote into its records? The answer is a simple two-sentence rule: what I know, I answer – what I do not know, I pass on. That passing on is called forwarding. The resolver hands the query for a foreign name to another server (typically the provider’s resolver or a public one), waits for the answer, caches it and returns it to the client. The client notices nothing – it asked once and got an answer. The second option is more interesting: turn forwarding off. Then the resolver answers an unknown name with “no such name exists” – abbreviated NXDOMAIN (that is how the simulator reports it; a real resolver that refuses to ask further would rather answer “I refuse” – REFUSED, see the glossary). That sounds like a fault, but it is a legitimate choice: in a strictly separated network (say the OT environment from Course 13, OT/ICS: industrial network security) you do not want anything inside asking outside; a resolver that knows only your own names is a feature there, not a bug. The simulator has exactly this switch (in advanced mode): the server’s DNS tab has “Forward unknown names out (to the internet)”. In simple mode the switch is hidden and the value comes from the topology – so a preset or a task may have it turned off. On = a name I do not know gets forwarded out. Off = I answer that no such name exists. Try both – and notice that when the resolver wants to forward but cannot get out (say a firewall stops it), the ending is the same: the name does not resolve.

Step by step

  1. Rule, sentence one: a name I have in my records I answer myself, at once.
  2. But now somebody asks for example.com – a name nobody wrote into my records.
  3. Sentence two: forwarding. I pass the query on, wait for the answer, cache it and return it. The client notices nothing.
  4. With forwarding off I answer NXDOMAIN – “no such name exists”. In a strictly separated network that is a feature, not a bug.

Who resolves? The router as a resolver

PCRTRISP DNSWEBthe client asks the router: web = ?

So far we drew the resolver role as a standalone DNS server. But recall your home: no server stands there – and names still resolve. Who does it? The router. A home router is the typical forwarder: it has no records of its own, it just relays the clients’ queries onward to the provider’s resolver (the upstream), caches the answers and returns them. To the clients it is the resolver – whoever really does the resolving for it is called the upstream. A company network usually differs: there the resolver role is played by a full DNS server with its own records (as you built in this lesson’s first module) – because no upstream knows, or should know, internal names like web.acme.local. When to pick which? In a small network, feel free to keep the role right on the router; once you want to back the resolver up or load it harder, a standalone server pays off. The boundary between the two roles is exactly this:a forwarder knows nothing and passes everything on; a server owns its answers. In the simulator you try both in advanced mode: a router, firewall or L3 switch has a DNS tab in its detail with the “DNS role” choice – forwarder (relays queries onward) with an “Upstream DNS server” picker (with no selection the queries go out to the internet, exactly like a home router), or DNS server (own records) with the same record editor you know from a server. Then just pick the router in the network settings as the “DNS server for this network”. And the last piece of the puzzle: the resolver need not be the same for everyone. In advanced mode a specific device can have its own DNS server (an override in its network settings) – it then asks elsewhere than the rest of the network. Handy for testing, but remember it as a troubleshooter too: “it works for everyone but him” can mean that one machine asks a different resolver than the others.

Step by step

  1. No DNS server stands at home – the client asks the router. To the clients it is the resolver.
  2. A home router is a forwarder: it knows nothing itself, it relays the query to the upstream (the provider’s DNS), caches the answer and returns it.
  3. The other role: a DNS server with its own records – a company router or firewall answers an internal name itself, no upstream needs to know it. In advanced mode: the DNS tab → “DNS role”.
  4. And beware: a specific device can have its own DNS server (an override, advanced mode). “Works for everyone but him” then means: it asks a different resolver.

When DNS fails: the server runs, but nobody finds it

PCDNSNETROOT/TLDAUTHWEBATTACKERthe server runs, by address it passes ✓

And now the price of that convenience. When a whole company has one resolver and it fails – or clients simply cannot reach it – you get the situation every helpdesk knows and that makes no sense at first glance: the network is up, but nothing works. The web server runs. The firewall passes what it should. A ping to the address goes through. And yet nothing opens in the browser, because the browser never learns where to connect. The server is healthy, only nobody finds it. Beware the trap almost every beginner falls into: the DNS server need not be broken for this to happen. It is enough that the query does not reach it – a firewall blocks UDP port 53, a link drops, a network gets a misconfigured resolver. From the client’s view the result is identical. Luckily there is a diagnostic trick worth remembering for life: try the same destination by name and then by address. If it works by address but not by name, the fault is not in the network – it is in DNS. And beware: a single resolver holds name resolution for the whole network – leave it alone and the topology check flags it as a single point of failure (SPOF), so double it up: add a second DNS server and pick it as the Backup DNS server in the network settings – the client asks it when the primary can’t be reached (down or blocked port 53) – and once the primary answers again, clients return to it; the backup serves only for the duration of the outage. Try it: power off the primary (right-click) and the name still resolves “via the backup DNS server”. A DNS outage also shows in the Live traffic simulation: flows going by name never even start without resolution, and the log reads “name did not resolve (DNS)”. Try exactly this in the task “The network is fine, nothing works (DNS)”: in the path test pick the destination web.acme.local under “By name (DNS)” (resolution fails) and then the same target as the device Web by address (it passes). You will see the difference with your own eyes. And the design lesson? The resolver is a critical device – it deserves the same care as the gateway: two servers, so one may fail (Course 14 – Network resilience and scaling).

Step by step

  1. Starting point: the server runs and traffic to its address passes normally. Nothing is wrong with the network.
  2. But the query to the resolver does not arrive – a firewall blocks UDP 53, a link dropped or the resolver is dead. To the client it is all the same.
  3. The result: the network is up, but nothing works. The server is healthy, only nobody finds it – the browser never learns where to connect.
  4. A trick for life: works by address but not by name? DNS is at fault, not the network. Try the task “The network is fine, nothing works (DNS)”.

▶ Open in the simulator

Lesson 3: Public DNS: the path from the root

The name hierarchy: root, TLD, domain

PCDNSNETROOT/TLDAUTHWEBATTACKERa name reads right to left: root is rightmost

So far we moved at home, where you invent names yourself. Out on the internet, though, it could not work for everyone to register whatever they wanted – names would collide. So the public name space is a hierarchical tree, and one unusual rule applies to it: a name reads right to left. Take www.example.com. At the far right sits (invisibly) the root – the top of the whole tree and the shared beginning of every name in the world; “invisibly” because it is never written in an everyday name (formally it is the empty end after the last dot). Below it is com, a TLD (top-level domain; such as com, cz, org). Below that is example – the domain somebody registered and has owned ever since. And only at the far left is www – a specific name inside that domain, decided solely by its owner. That hierarchy is not for show: it solves two things at once. Uniqueness – there can be only one example.com in the world, because names are handed out from the top down. And division of labor (technically delegation) – the root does not care about billions of names, it only says “for com, ask over there”; com does not care about domain contents, it only says “example.com is run by that server”. Each floor knows just one step and hands the rest downward. How you walk that tree is the next module.

Step by step

  1. An unusual rule: a name reads right to left. At the far right sits (invisibly) the root – the top of the tree of all names.
  2. Under the root sits a TLD – a top-level domain, such as com, cz or org.
  3. Under the TLD sits the domain (example) – somebody registered it and decides its contents alone ever since.
  4. At the left is a specific name inside the domain (www). The tree gives uniqueness and delegation: each floor knows one step down.

Recursion in practice: root → TLD → authority

PCDNSNETROOT/TLDAUTHWEBATTACKERthe client asks ONCE and waits

Now we join it up: the three roles from lesson 1 and the tree from the last module. The client asks the resolver one question and waits. The resolver has no answer in its cache and nobody to forward to – so it sets out itself and walks the tree from the top down. This is called recursion (a recursive query): the client asks once, the resolver asks as many times as needed. It looks like this. 1) The resolver asks the root: “where is www.example.com?” The root does not know the answer and does not care – it returns a referral: “for com, ask these servers.” 2) The resolver asks the TLD server for com. It does not know the answer either, but it knows one step more: “the domain example.com is run by these authoritative servers.” 3) The resolver asks the authority – and it alone owns the answer: “www.example.com is 203.0.113.10.” 4) The resolver caches the result and sends it to the client. Notice two things. First: none of the three lied or guessed – each said only what it knows, and that is always either a referral one floor down or a finished answer. Second: all of this happens only on the first query. The root’s and TLD’s answers have long TTLs, so the resolver has the tree’s floors cached long since and in practice usually goes straight to the authority. That “walk around the world” is thus the exception, not the rule.

Step by step

  1. The client asks one question and waits. That a world tour hides behind it does not concern it – that is recursion.
  2. The root: does not know the answer, returns a referral – “for com, ask these servers”.
  3. The TLD com: also does not know, but knows one step more – “example.com is run by these authoritative servers”.
  4. The authority owns the answer and gives it. 4) The resolver caches it and returns it. The same name is then answered straight from the cache – and other names in this domain go straight to the authority.

Public resolvers and privacy

PCDNSNETROOT/TLDAUTHWEBATTACKERdefault: the provider’s resolver

So who is your resolver when you have none of your own? By default the one your internet provider assigns – at home automatically over DHCP. But there is a second option: public resolvers, which anyone in the world may use for free. The best known deliberately have memorable addresses: 8.8.8.8 (Google) and 1.1.1.1 (Cloudflare). They tempt you by being fast, reliable and by answering even where the provider’s resolver misbehaves or censors some names. But before you set one, think this course through to its conclusion. A resolver sees every query you send it – that is, the list of all names your network asks about. That is an extraordinarily telling record: which sites you read, which bank you use, which apps run in the background and at what hour. Remember it this way: whoever is your resolver sees what you ask. Choosing a public resolver is therefore not “better or worse” – it is choosing who gets that list: your provider, a large company on the other side of the world, or (with your own resolver) yourself. And one more reason to take it seriously: queries are classically unencrypted, so anyone along the path sees them too – and the answer can be forged. Both are the last lesson’s topic. A practical recommendation for a company: run your own resolver for internal names and let it forward the rest to one deliberately chosen server outside. The best of both worlds: your own names at home, and one place where you can see and set whom you trust.

Step by step

  1. By default your resolver is the one your internet provider assigns – at home automatically over DHCP.
  2. The other option: public resolvers with memorable addresses – 8.8.8.8, 1.1.1.1. They tend to be fast and reliable.
  3. The catch: whoever is your resolver sees what you ask – which sites you read, which bank you use, what runs in the background.
  4. A recommendation for a company: your own resolver for internal names, forwarding the rest to one deliberately chosen server outside.

▶ Open in the simulator

Lesson 4: Record types and what they are for

A and AAAA: a name to an IP address

PCDNSNETROOT/TLDAUTHWEBATTACKERA: web.acme.local → 10.0.2.20

The whole course we spoke of “a record” as if there were only one kind. There is not – DNS is not just a list of addresses, it is a small database about a domain, and every row in it has a type. The type says what you are actually asking about: you can ask one domain for its website’s address, for where to deliver its mail, or for who runs it – and get a different answer each time. The most important and most common type is A: the pair name → IPv4 address. This is the record we have been drawing all along, and it is by far the most common type of query in the world. It looks plain: web.acme.local → 10.0.2.20. Its twin is AAAA (read “quad A”): the same, but name → IPv6 address. Why that name? An IPv6 address is four times longer than an IPv4 one – hence four letters. Good to know: a name can have both records at once, and a modern computer picks for itself which protocol version to connect with (usually it tries both and uses whichever answers first). And one more thing beginners rarely expect: one name can have several A records with different addresses. The server then answers with them in turn and traffic gets roughly split across several machines – the cheapest (and dumbest) kind of load balancing, because unlike the load balancer from Course 14 (Network resilience and scaling), DNS has no idea whether those machines are still alive. In the simulator a name → device record is exactly an A record (rotating several addresses for one name is not something this model does – two A records with the same name will always return the first) – in the DNS server’s detail you enter it directly in simple mode (name → target); in advanced mode you also get a type dropdown and a TTL on each row (the “Fill from device names” button creates A records – and MX ones for mail servers). Let me flag the boundary up front so the next modules do not surprise you: A, CNAME (from the next module) and MX (from the mail module) can actually be tried out. The simulator has no TXT, NS or PTR – for those the explanation stays theory, but you still need to know them, because you will meet them in a real domain right away.

Step by step

  1. A is the pair name → IPv4 address – the record we drew all along. Nine out of ten queries go for it.
  2. AAAA (“quad A”) is the same for IPv6. Four letters because an IPv6 address is four times longer than an IPv4 one.
  3. A name can have both records at once. A modern computer tries both protocol versions and uses whichever answers first.
  4. One name can have several A records. Traffic gets roughly split – but DNS has no idea if those machines live (unlike an LB, Course 14 – Network resilience and scaling).

CNAME: an alias of another name

PCDNSNETROOT/TLDAUTHWEBATTACKERshop.example.com = ?

The second type you will meet constantly is CNAME – an alias (canonical name). It points not at an address but at another name: “shop.example.com is really web.example.com – go ask for that instead”. That extra query is then made by the resolver, which returns both at once – the client does not ask a second time. It sounds like a pointless detour, but it solves one specific pain: a single source of truth. Imagine five names on one server – shop, blog, intranet, wiki and www. Make each an A record with an address and, when the server moves, you will be rewriting five addresses and are sure to forget one. Make them CNAMEs to a single name that has the A record, and a move means changing one number in one place. CNAME is therefore used massively where you do not and cannot know the address: cloud services and CDNs tell you “point a CNAME at us”, because they change their addresses as they please. Two things worth knowing. Chaining: a CNAME may point at a name that is itself a CNAME – but each link means another query, so a long chain slows things down and adds places to break (and must never form a loop). And a restriction: a name that has a CNAME generally may not carry other records – which is why you classically cannot put a CNAME on a domain’s root (example.com without www), you need an A there. Try it: in the DNS server’s detail, in advanced mode, switch a record’s type to CNAME and give it a target name instead of a device. A by-name test will then show you the whole alias path. Try making the chain loop, too – the simulator spots it and tells you (so does a real resolver).

Step by step

  1. The client asks for shop.example.com. It expects an address – but this name has no address of its own.
  2. The answer is a CNAME – an alias: “shop is really web.example.com, go ask for that”.
  3. So the resolver asks again – and only that name has the A record with the address. The alias moved it one query on.
  4. The point: a single source of truth. Five names as CNAMEs to one name with an A record = a move changes one number, not five.

MX and TXT: mail and verification

PCDNSNETROOT/TLDAUTHWEBATTACKERMX: where to deliver mail for example.com?

Now two types that together hold up e-mail. When you write a message to someone@example.com, where does your mail server deliver it? It cannot use the website’s address – the site and the mail may well sit on entirely different machines. So there is MX (mail exchanger): the record that says, about a domain, where to deliver mail. The sending server asks for the MX of example.com, gets a mail server’s name, resolves that to an address (with an A record – see how the types compose) and only then connects there. There can be several MX records and each has a priority – a number where lower means preferred. That is simple redundancy: when the main server does not answer, mail goes to the backup. You can try MX in the simulator too: a server with a mail service (port 25/143) has a Mail tab where you enter a domain; DNS learns it as an MX record via “Fill from device names”, and in the test you pick the “Mail for domain (MX)” target – you’ll see which mail server it points to. One boundary up front, though: the simulator has no priorities – an MX here points straight at a device, so a second MX as a backup cannot be tried out and stays theory. TXT, by contrast, is simply free text at a domain, where the owner may write whatever they like. It sounds pointless, but two indispensable things grew out of it. Domain ownership verification: a service tells you “add this random string to your TXT” and then checks it. If it is there, you have proven you really control the domain – because only its owner can write into its DNS. And SPF: a TXT record in which the owner lists the servers allowed to send mail in their name. The recipient then checks whether the message came from a permitted server – and if not, it is most likely a forgery. The best part is the idea: here DNS turned from a mere list of addresses into the place where a domain’s owner publicly declares the rules about that domain.

Step by step

  1. You write to someone@example.com. Deliver where? The website’s address will not do – mail sits elsewhere. That is what MX is for.
  2. MX returns the mail server’s name – which the sender resolves with an A record. Several MX records have priorities: lower is preferred, the rest are backup.
  3. TXT is free text at a domain. It serves for ownership verification: write a random string there – only the domain owner can.
  4. And SPF: a TXT where the owner lists the servers allowed to send mail in their name. A message from elsewhere is most likely a forgery.

NS and PTR: delegation and reverse lookup

PCDNSNETROOT/TLDAUTHWEBATTACKERNS: this domain is run by this server

The last two types close the picture. NS (name server) is the record that says: this part of the name space is run by this server. It is exactly the delegation from lesson 3, written as a database row: the com TLD has an NS record that, asked about example.com, returns the names of that domain’s authoritative servers. So the referrals a resolver follows during recursion are no magic – they are NS records. Companies use them internally too: “the whole production.acme.local branch is handled by another server”. PTR (pointer) goes the other way: IP address → name. A reverse lookup. You ask “who is 203.0.113.10?” and get a name. Two cautions: a PTR is maintained separately from the A record (it does not appear automatically) and it is set by whoever owns the address – usually the provider, not the name’s owner. So a PTR cannot be relied on as proof. What is it for then? First, for logs and diagnostics: in an incident record, mail.example.com is incomparably more readable than a bare number. And second, far more practically, for antispam: mail servers routinely reject messages from machines lacking a sensible PTR matching the name they introduce themselves with. The logic is nicely plain – only someone who really controls the address can set its PTR, so it is a cheap but effective sieve against randomly infected computers spewing spam.

Step by step

  1. NS says which server runs a given part of the names. The referrals a resolver follows during recursion are no magic – they are NS records.
  2. Companies delegate internally too: “the whole production.acme.local branch is handled by another server”. That splits the work.
  3. PTR goes the other way: address → name. It is maintained separately from the A record and set by whoever owns the address – usually the provider.
  4. What for: logs (a name reads better than a number) and antispam – mail rejects a machine without a sensible PTR.

▶ Open in the simulator

Lesson 5: When DNS lies

A rogue resolver: you get the attacker’s address

PCDNSNETROOT/TLDAUTHWEBATTACKERthe client never verifies the answer

The last lesson takes everything you know and turns it inside out. The whole course rested on one unspoken assumption: that the resolver tells the truth. What if it does not? A client has no way to verify the answer – it simply gets one and connects where it was told. So whoever controls the resolver decides where your connection goes, without touching a single router or cable. This is called a rogue DNS. The attacker either slips you a resolver (say via a fake DHCP or Wi-Fi from Course 12, Wi-Fi: security in depth) or takes over yours. Then it answers the name web.acme.local with its own address – and you connect to it in perfectly good faith. The most frightening part is how quiet it is: neither the network nor the firewall sees anything odd. From their point of view the connection is completely normal – right protocol, right port, an allowed rule. It just points somewhere else than you thought. The technical name for this attack is DNS hijacking (a rogue resolver): what defines it is that the attacker controls the resolver. Forging a single answer in transit is something else – that is called DNS spoofing and comes right in the next module. Course 8 (Advanced security) showed the opposite problem, a tunnel hidden inside DNS traffic; here it is DNS itself that lies. Here you see why it works: a DNS answer is classically unencrypted and unsigned, so truth cannot be told apart from invention. What saves you? The HTTPS certificate. The attacker’s server may look like the real one, but it has no valid certificate for that name – and the browser screams. That is why you never click through a certificate warning. Try it in the task “Rogue DNS”: the network is configured with the attacker’s resolver, pick the name as the test’s destination and look at what it pointed to.

Step by step

  1. The whole course assumed the resolver tells the truth. The client has no way to verify the answer – it just gets one and trusts it.
  2. A rogue DNS: the attacker slips you a resolver or takes over yours – and answers the name with its own address.
  3. You connect to the attacker – and neither network nor firewall sees anything odd. Right protocol, port, allowed rule. Just a different target (the technical name: DNS hijacking).
  4. The HTTPS certificate saves you: the attacker has none valid for that name and the browser screams. Try the task “Rogue DNS”.

Poisoned cache and DNSSEC

PCDNSNETROOT/TLDAUTHWEBATTACKERan honest resolver sends a query out

The rogue resolver from the last module needs the attacker to control the resolver. But there is an attack on an honest resolver too: cache poisoning. Recall lesson 1 – the resolver stores answers. If an attacker smuggles in a single forged answer, the resolver caches it and then hands it out to all its users of its own accord until the TTL expires. One successful forgery thus diverts an entire company. How can it even be attempted? When the resolver sends a query out, the attacker tries to answer before the real authority does – query and answer are unencrypted and the resolver takes the first one that arrives and looks right. It is a race, but races can be won. So the first defense – and the one actually deployed everywhere to this day – mainly made that race much harder: the resolver sends the query from a random source port (and randomizes the letter case of the name – the 0x20 trick), so a forgery has far more numbers to guess. The full fix, though, is not to “run faster” but to make the answer verifiable. That is what DNSSEC is for: every answer is digitally signed by whoever owns the record, and the resolver checks the signature before accepting and caching it. A forgery without a valid signature is simply discarded – the race is suddenly worthless. Trust is built along the same tree as the names in lesson 3: the root signs the TLD, the TLD signs the domain, the domain signs the record. Two honest notes. DNSSEC solves the answer’s authenticity, not privacy – the query is still readable to everyone along the path (that is the next module). And it is far from deployed everywhere, because it costs extra work. But the idea is clean: do not trust the answer, verify the signature.

Step by step

  1. This time the resolver is honest and sends a query out to the authority. But query and answer are unencrypted.
  2. The attacker tries to answer first, before the real authority. The resolver takes the first that arrives and looks right – it is a race.
  3. Cache poisoning: the resolver caches the forgery and then hands it to everyone until the TTL expires. One forgery diverts a whole company.
  4. DNSSEC: the answer is signed by its owner and the resolver verifies it. A forgery without a signature is discarded – the race is worthless.

DoH and DoT: an encrypted query

PCDNSNETROOT/TLDAUTHWEBATTACKERan unencrypted query: everyone en route sees it

One hole remains: DNSSEC verifies that nobody changed the answer, but the query is still readable to everyone along the path. Anyone between you and the resolver – the provider, the café Wi-Fi admin, anyone with access to the link – therefore sees the list of all names you ask about. The fix is obvious: encrypt the query. We have two forms of the same idea. DoT (DNS over TLS) sends DNS in its own encrypted tunnel on a dedicated port – it is clearly recognizable as DNS, only the contents are hidden. DoH (DNS over HTTPS) wraps the query in plain HTTPS, so on the network it looks like ordinary web traffic and cannot be told apart from other connections. Now the interesting part, because this is a classic case where one technology helps one party and hurts another. It helps the user: on a foreign network nobody sees the list of names you ask for, and nobody can rewrite your answers in transit. (That you then connect to that particular domain is still given away by the destination IP and by SNI – the server name the browser sends unencrypted when setting up HTTPS, as Course 1 showed. DoH hides the query, not your whole trail.) It bothers the admin twice over. First, they lose the visibility from lesson 2 – when a browser silently uses its own DoH resolver on the internet, the company resolver never learns of the queries, so internal names and malicious-domain blocking stop working. Second, because DoH looks like web traffic, abuse is harder to spot too – recall DNS tunneling from Course 8 (Advanced security). The sensible answer is not to ban encryption, but to take the choice back: run your own resolver with DoT/DoH and point clients at it. The traffic is encrypted and you ask a server you deliberately trust.

Step by step

  1. A hole remains: the query is readable to everyone along the path. The provider and the Wi-Fi admin see the list of names you ask about.
  2. The fix: encrypt the query. DoT sends it in its own tunnel (recognizable as DNS), DoH wraps it in ordinary HTTPS.
  3. The flip side: when a browser silently uses its own DoH resolver outside, the company resolver never sees the queries – internal names and blocking stop working.
  4. The sensible answer: your own resolver with DoT/DoH, with clients pointed at it. Encrypted and to a server you deliberately trust.

▶ Open in the simulator