zenon/bachelorarbeit
1
0
Fork 0
Code Issues Pull Requests Releases Wiki Activity

Add text for DNS cache

Browse Source
This commit is contained in:
Tobias Eidelpes 2020-03-28 20:24:51 +01:00
parent bf0a2ba4be
commit f85fa101a4
2 changed files with 53 additions and 0 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

3
abbrev/acronym.tex
View File

@ -24,3 +24,6 @@
\newacronym {SQL} {SQL} {Structured Query Language}
\newacronym {CDN} {CDN} {Content Delivery Network}
\newacronym {ETag} {ETag} {Entity Tag}
\newacronym {DNS} {DNS} {Domain Name System}
\newacronym {IP} {IP} {Internet Protocol}
\newacronym {OS} {OS} {Operating System}

50
chapters/methods.tex
View File

@ -812,4 +812,54 @@ cleared by checking the \gls{ETag} header.
\subsection{DNS Cache}
\label{subsec:dns cache}
The \gls{DNS} is used every time a connection to a server has to be established.
It's main function is to map hard to remember \gls{IP} addresses to easily
memorizable domain names and vice versa. The hierarchical structure of the
system is particularly suited for caching as requests do not have to be passed
all the way to the top of the hierarchy but can possibly be answered by lower
level \gls{DNS} servers. Caching is especially beneficial when name resolution
is recursive, allowing servers to quickly respond to requests without having to
consult higher level ones. Since name resolution servers change less often the
closer they are to the root node, the probability of having a cache hit
increases with every step in the hierarchy. Caching also happens at the lower
levels of the hierarchy, directly at the client in multiple ways. The host
operating system has it's own cache that applications can ask for name
resolution. Some applications introduce another layer of caching by having their
own cache (e.g., browsers).
\citeauthor{kleinDNSCacheBasedUser2019} \cite{kleinDNSCacheBasedUser2019}
demonstrated a tracking method which is using \gls{DNS} caches to assign unique
identifiers to client machines. In order for the technique to work, the tracker
has to have control over a web server as well as an authoritative \gls{DNS}
server which associates the web servers with a domain name under the control of
the tracker. The tracking process starts once a user agent requests a web site
which loads a script from one of the web servers the attacker is controlling.
The process can then be sketched out as follows (see
\cite[p.~5]{kleinDNSCacheBasedUser2019} for a detailed description).
\begin{enumerate}
\item The snippet loads a resource from muliple domains (\texttt{1.ex.com},
\texttt{2.ex.com}, ...) the tracker controls.
\item The \gls{OS} forwards a \gls{DNS} request to the configured name
server.
\item The name server receives and caches multiple, randomly ordered
\gls{IP} addresses for the domain from the tracker-controlled \gls{DNS}
server. The results are forwarded to the \gls{OS}.
\item The \gls{OS} caches the result as well and the browser makes
\gls{HTTP} requests to (in most cases) the first \gls{IP} address.
\item The web server responsible for the \gls{IP} address responds with a
number. Other web servers would respond with a different number.
\item The script then constructs an identifier from the received values.
\end{enumerate}
Due to the random ordering of the received \gls{IP} addresses from the
authoritative \gls{DNS} server, the identifier that is assembled by the script
is unique and thus allows identification of not only the browser but the client
machine itself.
\todo{+ \& -}
\subsection{TLS Session Resumption}
\label{subsec:tls session resumption}
\end{document}