Dns Security

DNS SECURITY
OUTLINE
• Terminology
• Following a simple DNS query
• What's in a DNS packet?
• Resource Record Types
• Drilling down to a real query
• What's in the cache?
• Poisoning the cache
• Solution
• References 2
TERMINOLOGY
 Zone
a "domain": a collection of hostnames/IP pairs all managed together.
(unixwiz.net, google.com)
 Nameserver
the server software that answers DNS questions, such as "What is the
IP address for www.unixwiz.net?". (authoritative or recursive
nameserver).
 Authoritative Nameserver
For every zone, the NS that maintain a file of the hostnames and IP
address associations
3
TERMINOLOGY …
 Recursive Nameserver
the nameserver that's willing to go out on the internet and find the
results for zones it's not authoritative for
 Resolver
the client part of the DNS client/server system: it asks the
questions about hostnames
 Resource Record
DNS is really a database of "resource records". The most common
type is an IP Address (an "A" record), but other records exist too:
NS (nameserver), MX (mail exchanger) and so on.
4
FOLLOWING A DNS QUERY
 Ping www.unixwiz.com
1. The client (noted as "User's PC") makes a request
for www.unixwiz.net, and it's routed to the
nameserver provided by the user's ISP. It requests
the A record, which represents an IP address.
The ISP's nameserver knows that it's not
authoritative for unixwiz.net, so it can't look it
up in its local zone database. It also doesn't find
the name in its cache of recently-seen data, so it
knows it has to go out to the internet to find it for
us.
5
FOLLOWING A DNS QUERY …
2. All recursive nameservers are
preconfigured with a list of 13 root
servers, a selection of which looks
like:
 these IP addresses don't change very

often.
 The nameserver picks one at random
and sends off the query for the A
record of www.unixwiz.net; here it's
6
going to b.root-servers.net
3. The root server doesn't know anything

about unixwiz.net, but send the Global
Top Level Domain (GTLD) servers
responsible for the .net domain.
(NS records and the IP address of each:
this is known as "glue”)
7
4. With the helpful referral from

the root servers, this
nameserver chooses one of the
authoritative servers at
random — here, c.gtld-
servers.net — and sends off
the same query: "I was told to
ask you: what's the A record
for www.unixwiz.net?".
8
5. The GTLD server doesn't know the

specific answer to our query, but it
does know how to get us closer. Like
the root servers, it sends back a
referral (a set of NS records) that are
likely to have what we seek.
9
6. Once again the recursive

nameserver is following a chain of
referrals on the client's behalf,
and it picks one of the
nameservers at random and
sends off a third query (the same
as the other two)
10
7. This NS actually has what we were

looking for: it provides the A
record for www.unixwiz.net.
In addition, the response includes
a flag saying "This is an
authoritative response",
indicating it came from the source
of truth for this domain.
11
8. Now, the ISP's recursive

nameserver hands that answer
back to the client, and also files
away this answer into its own
cache in case this or some other
client makes the same query later.
This procedure goes on under the hood

trillions of time every day over the
internet. DNS is quite fast, so the eight-
packet handshake (for this particular
query) routinely completes in just a split
second.
12
A DNS PACKET
 Source / Destination IP address
 Source / Destination port numbers
DNS servers listen on port 53/udp for
queries from the outside world (first
packet UDP destination port).The
source port varies considerably.
 Query ID
a unique identifier created in the query
packet that's left intact by the server
sending the reply: it allows the server
making the request to associate the
answer with the question. 13
A DNS PACKET …
 QR (Query / Response): 0 for a query by a
client, 1 for a response from a server.
 AA (Authoritative Answer) Set to 1 in a server
response if this answer is Authoritative, 0 if not.
 TC (Truncated) Set to 1 in a server response if the
answer can't fit in the 512-byte limit of a UDP
packet response;
 RD (Recursion Desired) The client sets this to 1 if
it wishes that the server will perform the entire
lookup recursively, or 0 if it just wants the best
information the server has and the client will
continue with the iterative query on its own.
 RA (Recursion Available) The server sets this to
indicate that it will (1) or won't (0) support
recursion.
 rcode: Response code from the server: indicates 14
success or failure
RESOURCE RECORD TYPES
15
DRILLING DOWN TO A REAL QUERY
 Recalling our query

exchange, we're going to
study steps 4 through 7
in some detail (Step 4).
16
DRILLING DOWN TO A REAL QUERY …

17

18

19
WHAT'S IN THE CACHE?
The Time-To-Live
When a DNS answer is stored in the
local cache, it can't keep it forever.
Administrator of the zone specifies
this information for every resource
record (known as a Time To Live (TTL)).
20
POISONING THE CACHE
 Cache poisoning is where the bad guy manages to inject bogus

data into a recursive nameserver's cache.
 DNS only accepts responses to pending queries:
1. The response arrives on the same UDP port we sent it from: otherwise the network stack
would not deliver it to the waiting nameserver process (it's dropped instead).
2. The Question section (which is duplicated in the reply) matches the Question in the
pending query.
3. The Query ID matches the pending query
4. The Authority and Additional sections represent names that are within the same domain
as the question: This prevents ns.unixwiz.net from replying with not only the IP
address of www.unixwiz.net, but also fraudulent information
about BankOfSteve.com.
21
POISONING THE CACHE …
 The first step of the attack: Guessing the

Query ID
1. Bad guy asks the victim nameserver to look up a name in a zone for a
nameserver he controls (perhaps test.badguy.com).
2. He might query the server directly, if it permits recursion from his location, or
he might convince a user to lookup a name — perhaps by including the test
hostname on a web page.
3. Victim nameserver receives the request and makes the usual rounds to resolve
the name starting at the root servers. Here, we've put the root and GTLD
servers in the same category to separate them from the bad guy's nameserver.
4. Eventually, the victim nameserver will be directed to the bad guy's nameserver:
after all, it's authoritative for badguy.com.
5. Bad guy monitors this lookup of test.badguy.com by sniffing the IP traffic
going to his own machine, or perhaps even with a custom modification to the
nameserver software, and from this discovers the source port and Query ID
used. Aha!
22
Step 1 — Bad guy sends a DNS query to

the victim nameserver for the hostname it
wishes to hijack. This example assumes that
the victim nameserver allows recursive
queries from the outside world.
Step 2a — Knowing that the victim will

shortly be asking ns1.bankofsteve.com
(as directed from the root/GTLD servers) for
an IP address, the bad guy starts flooding
the victim with forged DNS reply packets. All
purport to be from ns1.bankofsteve.com,
but include the answer with the IP of
badguy's fraudulent webserver.
23
Steps 2b & 3 — Root/GTLD servers provide

referral tons1.bankofsteve.com. This may be
multiple queries, but we're showing just one
for simplicity.
Step 4 — victim nameserver

asks ns1.bankofsteve.com for the IP address
of www.bankofsteve.com, and it uses query
ID 1001 (one higher than the previous
query).
Step 5 — the real nameserver provides a

legitimate response to this query, with
QID=1001. But if the bad guy has
successfully matched the query ID in the
step 2a flood, this legal reply arrives too late
and is ignored. Oops. 24
Step 6 — With the bogus IP address (of the

bad guy's webserver) in cache it provides
this poisoned answer to the requesting DNS
client. Boom.
Step 7 (not illustrated) — future DNS clients

asking for www.bankofsteve.com will receive
the same fraudulent answer.
The bad guy will typically set a very high TTL

in the poisoning responses so that the victim
will keep the bogus data in cache as long as
possible.
25
MITIGATIONS
 randomizing the Query ID (16 bits)
 randomizing the source port (2500 UDP ports)
 DNSSEC or IPv6 (only in theory) 26

REFERENCES
1. Steve Friedl's Unixwiz.net Tech Tips , An Illustrated Guide to

the Kaminsky DNS Vulnerability,
http://unixwiz.net/techtips/iguide-kaminsky-dns-vuln.html, last
visited Nov. 2021.
27

Dns Security

Uploaded by

Copyright:

Available Formats

Dns Security

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Dns Security

Uploaded by

Copyright:

Available Formats

DNS SECURITY

 these IP addresses don't change very

3. The root server doesn't know anything

4. With the helpful referral from

5. The GTLD server doesn't know the

6. Once again the recursive

7. This NS actually has what we were

8. Now, the ISP's recursive

This procedure goes on under the hood

 Recalling our query

 Recalling our query

 Recalling our query

 Recalling our query

 Cache poisoning is where the bad guy manages to inject bogus

 The first step of the attack: Guessing the

Step 1 — Bad guy sends a DNS query to

Step 2a — Knowing that the victim will

Steps 2b & 3 — Root/GTLD servers provide

Step 4 — victim nameserver

Step 5 — the real nameserver provides a

Step 6 — With the bogus IP address (of the

Step 7 (not illustrated) — future DNS clients

The bad guy will typically set a very high TTL

 randomizing the Query ID (16 bits)

 randomizing the source port (2500 UDP ports)

 DNSSEC or IPv6 (only in theory) 26

1. Steve Friedl's Unixwiz.net Tech Tips , An Illustrated Guide to

You might also like

Pfad - The Proxy pFad of © 2024 Garber Painting. All rights reserved.