diff --git a/abbrev/acronym.tex b/abbrev/acronym.tex
index fd671c0..e26e88e 100644
--- a/abbrev/acronym.tex
+++ b/abbrev/acronym.tex
@@ -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}
diff --git a/chapters/methods.tex b/chapters/methods.tex
index a41c123..26416fb 100644
--- a/chapters/methods.tex
+++ b/chapters/methods.tex
@@ -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}