much dns
This commit is contained in:
1
.gitignore
vendored
Normal file
1
.gitignore
vendored
Normal file
@@ -0,0 +1 @@
|
||||
#
|
||||
13
Protocols/init_Prof-Posegga.txt
Normal file
13
Protocols/init_Prof-Posegga.txt
Normal file
@@ -0,0 +1,13 @@
|
||||
- Anmeldung
|
||||
- Zweitkorrektor
|
||||
- Abschlusspräsentation/Verteidigung
|
||||
|
||||
----------------------------------------------
|
||||
|
||||
2 Vorträge:
|
||||
- nach 6 Wochen
|
||||
- Abschluss
|
||||
|
||||
NDA?
|
||||
|
||||
Cuellar (Kolumbien)
|
||||
BIN
Releases/Masters_Thesis_Exposé_v1.pdf
Normal file
BIN
Releases/Masters_Thesis_Exposé_v1.pdf
Normal file
Binary file not shown.
BIN
Releases/Timeline.pdf
Normal file
BIN
Releases/Timeline.pdf
Normal file
Binary file not shown.
@@ -1,17 +1,95 @@
|
||||
@article{fritz2013highly,
|
||||
title={Highly precise taint analysis for android applications},
|
||||
author={Fritz, Christian and Arzt, Steven and Rasthofer, Siegfried and Bodden, Eric and Bartel, Alexandre and Klein, Jacques and le Traon, Yves and Octeau, Damien and McDaniel, Patrick},
|
||||
journal={EC SPRIDE, TU Darmstadt, Tech. Rep},
|
||||
year={2013}
|
||||
@misc{rfc1034,
|
||||
added-at = {2013-12-17T09:42:01.000+0100},
|
||||
author = {Mockapetris, Paul},
|
||||
biburl = {http://www.bibsonomy.org/bibtex/2151af157c981c783982e48315896f65a/jullybobble},
|
||||
interhash = {49594fc012a73e4d0d442e4f1da54b93},
|
||||
intrahash = {151af157c981c783982e48315896f65a},
|
||||
keywords = {imported phd},
|
||||
timestamp = {2014-07-27T15:43:19.000+0200},
|
||||
title = {{RFC 1034 Domain Names - Concepts and Facilities}},
|
||||
url = {http://tools.ietf.org/html/rfc1035 http://tools.ietf.org/html/rfc1034},
|
||||
year = 1987
|
||||
}
|
||||
|
||||
\begin{comment}
|
||||
@booklet{,
|
||||
author={},
|
||||
key={},
|
||||
title={},
|
||||
month={},
|
||||
year={},
|
||||
url={}
|
||||
@misc{rfc1035,
|
||||
added-at = {2009-03-12T15:42:50.000+0100},
|
||||
author = {Mockapetris, Paul},
|
||||
biburl = {http://www.bibsonomy.org/bibtex/2998727e8b957ed6a37d3435c412d28b3/lillejul},
|
||||
citeulike-article-id = {2443965},
|
||||
interhash = {1a093b389624051dd83e998f48efaab7},
|
||||
intrahash = {998727e8b957ed6a37d3435c412d28b3},
|
||||
keywords = {internet protocol rfc},
|
||||
month = {November},
|
||||
organization = {Internet Engineering Task Force},
|
||||
posted-at = {2008-02-28 15:36:27},
|
||||
priority = {0},
|
||||
timestamp = {2009-03-12T15:42:51.000+0100},
|
||||
title = {RFC 1035 Domain Names - Implementation and Specification},
|
||||
url = {http://tools.ietf.org/html/rfc1035},
|
||||
year = 1987
|
||||
}
|
||||
|
||||
@misc{rfc882,
|
||||
series = {Request for Comments},
|
||||
number = 882,
|
||||
author = {Mockapetris, Paul},
|
||||
howpublished = {RFC 882},
|
||||
publisher = {RFC Editor},
|
||||
doi = {10.17487/rfc882},
|
||||
url = {https://rfc-editor.org/rfc/rfc882.txt},
|
||||
title = {{Domain names: Concepts and facilities}},
|
||||
pagetotal = 31,
|
||||
year = 1983,
|
||||
month = nov,
|
||||
abstract = {This RFC introduces domain style names, their use for ARPA Internet mail and host address support, and the protocol and servers used to implement domain name facilities.},
|
||||
}
|
||||
|
||||
@misc{rfc1995,
|
||||
series = {Request for Comments},
|
||||
number = 1995,
|
||||
author = {Ohta, Masataka},
|
||||
howpublished = {RFC 1995},
|
||||
publisher = {RFC Editor},
|
||||
doi = {10.17487/rfc1995},
|
||||
url = {https://rfc-editor.org/rfc/rfc1995.txt},
|
||||
title = {{Incremental Zone Transfer in DNS}},
|
||||
pagetotal = 7,
|
||||
year = 1996,
|
||||
month = aug,
|
||||
abstract = {This document specifies an Internet standards track protocol for the
|
||||
Internet community, and requests discussion and suggestions for
|
||||
improvements. Please refer to the current edition of the "Internet
|
||||
Official Protocol Standards" (STD 1) for the standardization state
|
||||
and status of this protocol. Distribution of this memo is unlimited.},
|
||||
}
|
||||
|
||||
@misc{rfc2136,
|
||||
added-at = {2009-11-15T15:37:34.000+0100},
|
||||
author = {Vixie, P. and Thomson, S. and Rekhter, Y. and Bound, J.},
|
||||
biburl = {https://www.bibsonomy.org/bibtex/2a2c7e5c6947748b7f5fc96dd0db9debe/henkellermann},
|
||||
howpublished = {RFC 2136 (Proposed Standard)},
|
||||
interhash = {beafcca10ed6b4136f6e20d367050f60},
|
||||
intrahash = {a2c7e5c6947748b7f5fc96dd0db9debe},
|
||||
keywords = {imported},
|
||||
month = {April},
|
||||
note = {Updated by RFCs 3007, 4035, 4033, 4034},
|
||||
number = 2136,
|
||||
organization = {Internet Engineering Task Force},
|
||||
publisher = {IETF},
|
||||
series = {Request for Comments},
|
||||
timestamp = {2009-11-15T15:37:58.000+0100},
|
||||
title = {{Dynamic Updates in the Domain Name System (DNS UPDATE)}},
|
||||
url = {http://www.ietf.org/rfc/rfc2136.txt},
|
||||
year = 1997
|
||||
}
|
||||
|
||||
|
||||
|
||||
@book{mockapetris1988development,
|
||||
title={Development of the domain name system},
|
||||
author={Mockapetris, Paul and Dunlap, Kevin J},
|
||||
volume={18},
|
||||
number={4},
|
||||
year={1988},
|
||||
publisher={ACM}
|
||||
}
|
||||
\end{comment}
|
||||
@@ -24,6 +24,9 @@
|
||||
\newcommand{\fsAuthorName}[1]{\textsc{#1}}
|
||||
\newcommand{\fsAuthor}[1]{\fsAuthorName{\citeauthor{#1}}}
|
||||
|
||||
% tables (booktabs)
|
||||
\renewcommand{\arraystretch}{1.3}
|
||||
|
||||
% misc
|
||||
|
||||
\newcommand{\fsInput}[1]{\texttt{#1}}
|
||||
|
||||
@@ -1,10 +0,0 @@
|
||||
\chapter{\gls{DNS}}
|
||||
\label{cha:Feature_Extraction}
|
||||
|
||||
|
||||
\section{something interesting}
|
||||
\label{subsec:not_really}
|
||||
|
||||
foo
|
||||
bar
|
||||
|
||||
2
Thesis/content/Introduction/Challenges/Challenges.tex
Normal file
2
Thesis/content/Introduction/Challenges/Challenges.tex
Normal file
@@ -0,0 +1,2 @@
|
||||
\section{Challenges}
|
||||
\label{sec:challenges}
|
||||
2
Thesis/content/Introduction/Goals/Goals.tex
Normal file
2
Thesis/content/Introduction/Goals/Goals.tex
Normal file
@@ -0,0 +1,2 @@
|
||||
\section{Goals}
|
||||
\label{sec:goals}
|
||||
@@ -2,13 +2,13 @@
|
||||
\label{cha:Introduction}
|
||||
|
||||
|
||||
Lorem ipsum dolor sit amet, consetetur sadipscing elitr, sed diam nonumy eirmod tempor invidunt ut labore et dolore magna aliquyam erat, sed diam voluptua. At vero eos et accusam et justo duo dolores et ea rebum. Stet clita kasd gubergren, no sea takimata sanctus est Lorem ipsum dolor sit amet. Lorem ipsum dolor sit amet, consetetur sadipscing elitr, sed diam nonumy eirmod tempor invidunt ut labore et dolore magna aliquyam erat, sed diam voluptua. At vero eos et accusam et justo duo dolores et ea rebum. Stet clita kasd gubergren, no sea takimata sanctus est Lorem ipsum dolor sit amet. Lorem ipsum dolor sit amet, consetetur sadipscing elitr, sed diam nonumy eirmod tempor invidunt ut labore et dolore magna aliquyam erat, sed diam voluptua. At vero eos et accusam et justo duo dolores et ea rebum. Stet clita kasd gubergren, no sea takimata sanctus est Lorem ipsum dolor sit amet. \gls{API}
|
||||
Lorem ipsum dolor sit amet, consetetur sadipscing elitr, sed diam nonumy eirmod tempor invidunt ut labore et dolore magna aliquyam erat, sed diam voluptua. At vero eos et accusam et justo duo dolores et ea rebum. Stet clita kasd gubergren, no sea takimata sanctus est Lorem ipsum dolor sit amet. Lorem ipsum dolor sit amet, consetetur sadipscing elitr, sed diam nonumy eirmod tempor invidunt ut labore et dolore magna aliquyam erat, sed diam voluptua. At vero eos et accusam et justo duo dolores et ea rebum. Stet clita kasd gubergren, no sea takimata sanctus est Lorem ipsum dolor sit amet. Lorem ipsum dolor sit amet, consetetur sadipscing elitr, sed diam nonumy eirmod tempor invidunt ut labore et dolore magna aliquyam erat, sed diam voluptua. At vero eos et accusam et justo duo dolores et ea rebum. Stet clita kasd gubergren, no sea takimata sanctus est Lorem ipsum dolor sit amet. \gls{api}
|
||||
|
||||
Duis autem vel eum iriure dolor in hendrerit in vulputate velit esse molestie consequat, vel illum dolore eu feugiat nulla facilisis at vero eros et accumsan et iusto odio dignissim qui blandit praesent luptatum zzril delenit augue duis dolore te feugait nulla facilisi. Lorem ipsum dolor sit amet, consectetuer adipiscing elit, sed diam nonummy nibh euismod tincidunt ut laoreet dolore magna aliquam erat volutpat.
|
||||
|
||||
\lstinputlisting[language={java}, label=lst:sendImpliciteIntent,caption=Intent - Bild anzeigen]{res/src/sendImpliciteIntent.java}
|
||||
|
||||
Ut wisi enim ad minim veniam, quis nostrud exerci tation ullamcorper suscipit lobortis nisl ut aliquip ex ea commodo consequat. Duis autem vel eum iriure dolor in hendrerit in vulputate velit esse molestie consequat, vel illum dolore eu feugiat nulla facilisis at vero eros et accumsan et iusto odio dignissim qui blandit praesent luptatum zzril delenit augue duis dolore te feugait nulla facilisi. \fsCite{fritz2013highly}
|
||||
Ut wisi enim ad minim veniam, quis nostrud exerci tation ullamcorper suscipit lobortis nisl ut aliquip ex ea commodo consequat. Duis autem vel eum iriure dolor in hendrerit in vulputate velit esse molestie consequat, vel illum dolore eu feugiat nulla facilisis at vero eros et accumsan et iusto odio dignissim qui blandit praesent luptatum zzril delenit augue duis dolore te feugait nulla facilisi.
|
||||
|
||||
Nam liber tempor cum soluta nobis eleifend option congue nihil imperdiet doming id quod mazim placerat facer possim assum. Lorem ipsum dolor sit amet, consectetuer adipiscing elit, sed diam nonummy nibh euismod tincidunt ut laoreet dolore magna aliquam erat volutpat. Ut wisi enim ad minim veniam, quis nostrud exerci tation ullamcorper suscipit lobortis nisl ut aliquip ex ea commodo consequat.
|
||||
|
||||
@@ -24,4 +24,9 @@ Duis autem vel eum iriure dolor in hendrerit in vulputate velit esse molestie co
|
||||
|
||||
Ut wisi enim ad minim veniam, quis nostrud exerci tation ullamcorper suscipit lobortis nisl ut aliquip ex ea commodo consequat. Duis autem vel eum iriure dolor in hendrerit in vulputate velit esse molestie consequat, vel illum dolore eu feugiat nulla facilisis at vero eros et accumsan et iusto odio dignissim qui blandit praesent luptatum zzril delenit augue duis dolore te feugait nulla facilisi.
|
||||
|
||||
Nam liber tempor cum soluta nobis eleifend option congue nihil imperdiet doming id quod mazim placerat facer possim assum. Lorem ipsum dolor sit amet, consectetuer adipiscing elit, sed diam nonummy nibh euismod tincidunt ut laoreet dolore magna aliquam erat volutpat. Ut wisi enim ad minim veniam, quis nostrud exerci tation ullamcorper suscipit lobortis nisl ut aliquip ex ea commodo
|
||||
Nam liber tempor cum soluta nobis eleifend option congue nihil imperdiet doming id quod mazim placerat facer possim assum. Lorem ipsum dolor sit amet, consectetuer adipiscing elit, sed diam nonummy nibh euismod tincidunt ut laoreet dolore magna aliquam erat volutpat. Ut wisi enim ad minim veniam, quis nostrud exerci tation ullamcorper suscipit lobortis nisl ut aliquip ex ea commodo
|
||||
|
||||
\input{content/Introduction/Motivation/Motivation}
|
||||
\input{content/Introduction/Challenges/Challenges}
|
||||
\input{content/Introduction/Goals/Goals}
|
||||
\input{content/Introduction/Related_Work/Related_Work}
|
||||
2
Thesis/content/Introduction/Motivation/Motivation.tex
Normal file
2
Thesis/content/Introduction/Motivation/Motivation.tex
Normal file
@@ -0,0 +1,2 @@
|
||||
\section{Motivation}
|
||||
\label{sec:motivation}
|
||||
@@ -0,0 +1,2 @@
|
||||
\section{Related Work}
|
||||
\label{sec:related_work}
|
||||
240
Thesis/content/Technical_Background/DNS/DNS.tex
Normal file
240
Thesis/content/Technical_Background/DNS/DNS.tex
Normal file
@@ -0,0 +1,240 @@
|
||||
\section{\glsentrytext{dns}}
|
||||
\label{sec:DNS}
|
||||
|
||||
The \gls{dns} is one of the cornerstone of the internet as it is known today. \todo{statistic about usage}. Initial designs have been proposed in 1983 and evolved over the following four years into the first globally adapted standard RFC 1034 \fsCite{rfc1034} (RFC 1035 for implementation and specification details \fsCite{rfc1035}). The main idea of the \gls{dns} is translating human readable domain names to network addresses. There are many extensions to the initial design including many security related features and enhancements or the support for \gls{ipv6} in 1995.
|
||||
|
||||
In order to understand how the \gls{dns} is misused for hostile activities and how to prevent these attacks it is necessary to explain some basic mechanisms.
|
||||
|
||||
|
||||
\subsection{Basics}
|
||||
\label{subsec:basics}
|
||||
|
||||
In the early days of the internet the mapping between host names and ip addresses has been accomplished using a single file, \texttt{HOSTS.TXT}. This file was maintained on a central instance, the \gls{sri-nic}, and distributed to all hosts in the internet via \gls{ftp}. As this file grew and more machines got connected to the internet, the costs for distributing the mappings were increasing up to an unacceptable effort. Additionally, the initial trend of the internet, the \gls{arpanet} connecting multiple hosts together into one network, got outdated. The new challenge of the internet was to connect multiple local networks (which itself contain many machines) into a global, interactive and \gls{tcp/ip} based grid. With the amount of machines quickly increasing and the costs for distributing the \texttt{HOSTS.TXT} file exponentially rising, a new system for a reliable and fast resolution of addresses to host names had to be developed.
|
||||
|
||||
\citeauthor{mockapetris1988development} proposed five conditions that had to be met by the base design of \gls{dns} \fsCite[p. 124]{mockapetris1988development}:
|
||||
|
||||
\begin{itemize}
|
||||
\item Provide at least all of the same information as HOSTS.TXT.
|
||||
\item Allow the database to be maintained in a distributed manner.
|
||||
\item Have no obvious size limits for names, name components, data associated with a name, etc.
|
||||
\item Interoperate across the DARPA Internet as many other environments as possible.
|
||||
\item Provide tolerable performance.
|
||||
\end{itemize}
|
||||
|
||||
For the \gls{dns} to be globally acceptable, it should furthermore not give too many restrictions on how the distributed local networks and the hosts are designed and operated. This includes i.e. not limiting the system to work for a single \gls{os} or software architecture, backing different network topologies or the support of encapsulation of other name spaces.
|
||||
In general, avoid as many constraints and support as many implementation structures as possible.
|
||||
|
||||
|
||||
\subsubsection{Architecture}
|
||||
\label{subsubsec:architecture}
|
||||
|
||||
The \gls{dns} primarily builds on two types of components: name servers and resolvers. A name server holds information that can be used to handle incoming requests e.g. to resolve a domain name into an ip address. Although resolving domain names into ip addresses might be the primary use case, name servers can possess arbitrary information and provide service to retrieve this information. A resolver interacts with client software and implements algorithms to find a name server that holds the information requested by the client. Depending on the functionality needed, these two components may be split to different machines and locations or running on one machine. Where in former days the power of a workstation may not has been sufficient to run a resolver on, today it is more interesting to benefit from cached information for performance reasons. In a company network it is common to have multiple resolvers e.g. one per organizational unit.
|
||||
|
||||
|
||||
|
||||
\subsubsection{Name space}
|
||||
\label{subsubsec:name_space}
|
||||
|
||||
The \gls{dns} is based on a naming system that consists of a hierarchical and logical tree structure and is called the domain namespace. It contains a single root node and an arbitrary amount of nodes in subordinate levels in variable depths. Each node is uniquely identifiable through a \gls{fqdn} and usually represents a domain, machine or service in the network. Furthermore, every domain can be subdivided into more fine-grained domains. These can again be specific machines or domains, called subdomains. This subdividing is an important concept for the internet to continue to grow and each responsible instance of a domain (e.g. a company or cooperative) is responsible for the maintenance and subdivision of the domain.
|
||||
|
||||
|
||||
\subsubsection{\gls{dns} Resource Records}
|
||||
\label{subsubsec:dns_resource_records}
|
||||
|
||||
TODO blabla
|
||||
|
||||
\begin{table}[]
|
||||
\centering
|
||||
\caption{Common \gls{dns} Resource Record}
|
||||
\label{tab:dns_resource_record}
|
||||
\begin{tabular}{@{}cccc@{}}
|
||||
Value & Text Code & Type & Description \\
|
||||
1 & A & Address & Returns the 32 bit IPv4 address of a host. Most commonly used for name resolution of a host. \\
|
||||
28 & AAAA & IPv6 address & Similar to the A record, this returns the address of an host. For IPv6 this has 128 bit. \\
|
||||
2 & NS & \begin{tabular}[c]{@{}c@{}}Name\\ Server\end{tabular} & \begin{tabular}[c]{@{}c@{}}Specifies the name of a DNS name server that is authoritative for the zone.\\ Each zone must have at least one NS record that points to its primary name server.\end{tabular} \\
|
||||
5 & CNAME & \begin{tabular}[c]{@{}c@{}}Canonical\\ Name\end{tabular} & \begin{tabular}[c]{@{}c@{}}The CNAME records allows to define aliases that point to the real canonical name of the node. \\ This can e.g. be used to hide internal \gls{dns} structures and provide a stable interface for outside users.\end{tabular} \\
|
||||
6 & SOA & \begin{tabular}[c]{@{}c@{}}Start of\\ Authority\end{tabular} & \begin{tabular}[c]{@{}c@{}}The SOA record marks the start of a \gls{dns} zone and provides important information about the zone.\\ Every zone must have exactly one SOA records containing e.g. name of the zone, primary authoritative server name\\ and the administration email address.\end{tabular} \\
|
||||
12 & PTR & Pointer & Provides a pointer to a different record in the name space. \\
|
||||
15 & MX & Mail Exchange & Returns the host that is responsible for handling emails sent to this domain. \\
|
||||
16 & TXT & Text String & Record which allows arbitrary additional texts to be stored that are related to the domain.
|
||||
\end{tabular}
|
||||
\end{table}
|
||||
|
||||
|
||||
\subsubsection{Payload}
|
||||
\label{subsubsec:payload}
|
||||
|
||||
In this section we will introduce the actual payload a \gls{dns} request as well as the response is built on. The format of each message that is shared between a resolver and \gls{dns} server has been initially defined in RFC 1035 \fsCite{rfc1035} and consecutively extended with new opcodes, response codes etc. This general format applies to both requests as well as responses and consists of five sections:
|
||||
|
||||
\begin{enumerate}
|
||||
\item Message Header
|
||||
\item Question Section
|
||||
\item Answer Section
|
||||
\item Authority Section
|
||||
\item Additional Section
|
||||
\end{enumerate}
|
||||
|
||||
\paragraph{Message Header:}
|
||||
\label{par:message_header}with
|
||||
The Message Header is obligatory for all types of communication and may not be empty. It contains different types of flags that are used to control the transaction. The header specifies e.g. which further sections are present, whether the message is a query or a response and more specific opcodes.
|
||||
|
||||
\begin{table}[h!]
|
||||
\centering
|
||||
\caption{Message Header}
|
||||
\label{tab:message_header}
|
||||
\begin{tabular}{@{}cccccccccccccccc@{}}
|
||||
\toprule
|
||||
0 & 1 & 2 & 3 & 4 & 5 & 6 & 7 & 8 & 9 & 10 & 11 & 12 & 13 & 14 & 15 \\ \midrule
|
||||
\multicolumn{16}{c}{Message ID} \\
|
||||
QR & \multicolumn{4}{c}{OPCODE} & AA & TC & RD & RA & Z & AD & CD & \multicolumn{4}{c}{RCODE} \\
|
||||
\multicolumn{16}{c}{QDCOUNT} \\
|
||||
\multicolumn{16}{c}{ANCOUNT} \\
|
||||
\multicolumn{16}{c}{NSCOUNT} \\
|
||||
\multicolumn{16}{c}{ARCOUNT} \\ \bottomrule
|
||||
\end{tabular}
|
||||
\end{table}
|
||||
|
||||
Table~\ref{tab:message_header} shows the template of a \gls{dns} message header. In the following listing, an explanation for the respective variables and flags is given:
|
||||
|
||||
\begin{itemize}
|
||||
\item \textbf{Message ID:} 16 bit identifier supplied by the requester (any kind of software that generates a request) and resend back unchanged by the responder to identify the transaction and enables the requester to match up replies to outstanding request.
|
||||
|
||||
\item \textbf{QR:} Query/Response Flag – one bit field whether this message is a query(0) or a response(1)
|
||||
|
||||
\item \textbf{OPCODE:} Four bit field that specifies the kind of query for this message. This is set by the requester and copied into the response. Possible values for the opcode field can be found in Table~\ref{tab:message_header_opcodes}
|
||||
\begin{table}[h!]
|
||||
\centering
|
||||
\caption{Message Header Opcodes}
|
||||
\label{tab:message_header_opcodes}
|
||||
\begin{tabular}{@{}lll@{}}
|
||||
\toprule
|
||||
Opcode & Type & Description \\ \midrule
|
||||
0 & QUERY & Standard Query. \\ \midrule
|
||||
1 & IQUERY & \begin{tabular}[c]{@{}l@{}}Inverse Query: Find domain name by IP address. \\ Deprecated with RFC 3425 in favor of the more widely \\ used in-addr.arpa reverse lookup.\end{tabular} \\ \midrule
|
||||
2 & STATUS & Request server status. \\ \midrule
|
||||
3 & (reserved) & not in use \\ \midrule
|
||||
4 & NOTIFY & \begin{tabular}[c]{@{}l@{}}Server to server message type added by RFC 1996. \\ Primary servers (master, authoritative) notify secondary \\ servers to initiate a zone transfer due to updated records \\ in the zone.\end{tabular} \\ \midrule
|
||||
5 & UPDATE & \begin{tabular}[c]{@{}l@{}}Special message type to allow dynamic additions, updates \\ and removals of selected resource records. Basically \\ implements what is known as "dynamic DNS".\end{tabular} \\ \midrule
|
||||
6-15 & (reserved) & reserved for future use \\ \bottomrule
|
||||
\end{tabular}
|
||||
\end{table}
|
||||
|
||||
\item \textbf{AA:} Authoritative Answer – this flag is set to 1 by the responding server if it is an authority for the domain name in the question section. If set to 0 this usually means that a cached record is returned.
|
||||
|
||||
\item \textbf{TC:} The Truncated bit is set to 1 if the response is larger then the permitted transmission channel length and the message has been truncated therefore. This usually indicates that \gls{dns} over \gls{udp} is used and the response payload size increases the maximum 512 bytes. The client may either requery over \gls{tcp} (with no size limits) or not bother at all if the truncated data was part of the Additional section. Set on all truncated messages except for the last one.
|
||||
|
||||
\item \textbf{RD:} Recursion Desired – this bit may be set in a query and is copied into the response if the name server supports recursion. If recursion is refused by this name server, e.g. it has been configured as authoritative only, the response does not have this bit set. Recursive query support is optional.
|
||||
|
||||
\item \textbf{RA:} The recursion available flag can be set in responses by the server to denote whether it is capable of processing recursive queries (1) or not (0).
|
||||
|
||||
\item \textbf{Z:} One bit reserved for future extensions
|
||||
|
||||
\item \textbf{AD:} The authenticated data flag is used by \gls{dnssec} to indicate that the data returned has been verified by the providing server. Always 0 if \gls{dnssec} is not available on the server.
|
||||
|
||||
\item \textbf{CD:} Checking Disabled – also used by \gls{dnssec} and may be set in a requests to show that non-verified data is acceptable to the requester. If \gls{dnssec} is not available in the resolver, this is always set to 0.
|
||||
|
||||
\item \textbf{RCODE:} Response Code – only available in response messages, these four bits are used to reveal errors while processing the query. Available error codes are listed in Table~\ref{tab:message_header_response_codes}. Error codes 0 to 5 have been initially available whereas error codes 6 to 10 are used for dynamic \gls{dns} defined in RFC 2136 \fsCite{rfc2136}.
|
||||
|
||||
\begin{table}[h!]
|
||||
\centering
|
||||
\caption{Message Header Response Codes}
|
||||
\label{tab:message_header_response_codes}
|
||||
\begin{tabular}{@{}lll@{}}
|
||||
\toprule
|
||||
RCode & Type & Description \\ \midrule
|
||||
0 & No Error & Request was successful processed. \\ \midrule
|
||||
1 & Format Error & \begin{tabular}[c]{@{}l@{}}The server was unable to respond due to the format \\ of the request.\end{tabular} \\ \midrule
|
||||
2 & Server Failure & \begin{tabular}[c]{@{}l@{}}The server was unable to respond due to an internal \\ server error.\end{tabular} \\ \midrule
|
||||
3 & Name Error & \begin{tabular}[c]{@{}l@{}}The queried domain name could not be found on the \\ server.\end{tabular} \\ \midrule
|
||||
4 & Not Implemented & \begin{tabular}[c]{@{}l@{}}The name server does not support the requested kind \\ of query.\end{tabular} \\ \midrule
|
||||
5 & Refused & \begin{tabular}[c]{@{}l@{}}The server refused to answer the request, usually for \\ policy reasons. E.g. unauthorized zone transfer.\end{tabular} \\ \midrule
|
||||
6 & YX Domain & Domain name exists when it should not. \\ \midrule
|
||||
7 & YX RR Set & A resource record set exists that should not. \\ \midrule
|
||||
8 & NX RR Set & A resource record set that should exist does not. \\ \midrule
|
||||
9 & Not Auth & The server is not authoritative for the requested zone. \\ \midrule
|
||||
10 & Not Zone & \begin{tabular}[c]{@{}l@{}}A name specified in the request is not contained \\ within the zone declared in the message.\end{tabular} \\ \bottomrule
|
||||
\end{tabular}
|
||||
\end{table}
|
||||
|
||||
\todo{do something with this}
|
||||
There are more response codes available that could be added (due to size restrictions) after \gls{edns} has been introduced.
|
||||
|
||||
\item \textbf{QDCOUNT:} Unsigned 16 bit integer specifying the number of entries in the Question Section.
|
||||
|
||||
\item \textbf{ANCOUNT:} Unsigned 16 bit integer specifying the number of resource records in the answer section.
|
||||
|
||||
\item \textbf{NSCOUNT:} Unsigned 16 bit integer specifying the number of name server resource records in the authority records section.
|
||||
|
||||
\item \textbf{ARCOUNT:} Unsigned 16 bit integer specifying the number of resource records in the additional records section.
|
||||
\end{itemize}
|
||||
|
||||
|
||||
\paragraph{Question Section:}
|
||||
\label{par:question_section}
|
||||
|
||||
\begin{table}[]
|
||||
\centering
|
||||
\caption{Question Section}
|
||||
\label{tab_question_section}
|
||||
\begin{tabular}{@{}ccccccccc@{}}
|
||||
\toprule
|
||||
0 & 4 & 8 & 12 & 16 & 20 & 24 & 28 & 32 \\ \midrule
|
||||
\multicolumn{9}{c}{Question Name} \\
|
||||
\multicolumn{5}{c}{Question Type} & \multicolumn{4}{c}{Question Class} \\ \bottomrule
|
||||
\end{tabular}
|
||||
\end{table}
|
||||
|
||||
|
||||
\begin{itemize}
|
||||
\item \textbf{Question Name:} Contains a variably sized payload payload including the domain, zone name or general object that is subject of the query. Encoded using standard \gls{dns} name notation.
|
||||
\todo{\url{http://www.tcpipguide.com/free/t_DNSNameNotationandMessageCompressionTechnique.htm}}
|
||||
|
||||
\item \textbf{Question Type:} Specifies the type of question being asked. This field may contain a code number corresponding to a particular type of resource being requested, see Table~\ref{tab:dns_resource_record} for common resource types. TODO more blabla, the following special values blabla
|
||||
|
||||
\item \textbf{Question Class} \todo{TODO}
|
||||
\end{itemize}
|
||||
|
||||
\todo{all tables h!}
|
||||
|
||||
\begin{table}[h!]
|
||||
\centering
|
||||
\caption{Question Section Format}
|
||||
\label{tab:question_section_format}
|
||||
\begin{tabular}{@{}lll@{}}
|
||||
\toprule
|
||||
QType & Type & Description \\ \midrule
|
||||
251 & IXFR & Request for a incremental Zone transfer (RFC 1995 \fsCite{rfc1995}) \\
|
||||
252 & AXFR & Request for a Zone Transfer \\
|
||||
253 & MAILB & Request for mailbox like resources (obsolete now) \\
|
||||
254 & MAILA & Request for mail agent (obsolete, MX records used instead) \\
|
||||
255 & * & Request for all records \\ \bottomrule
|
||||
\end{tabular}
|
||||
\end{table}
|
||||
|
||||
|
||||
|
||||
|
||||
%\todo{remove?}
|
||||
%\subsubsection{Database distribution}
|
||||
%\label{subsubsec:database_distribution}
|
||||
|
||||
|
||||
|
||||
\subsection{Domain Names}
|
||||
\label{subsec:domain_names}
|
||||
|
||||
|
||||
|
||||
\subsection{Resolution}
|
||||
\label{subsec:resolution}
|
||||
|
||||
\subsubsection{Recursive}
|
||||
\label{subsubsec:recursive}
|
||||
|
||||
|
||||
\begin{figure}[htbp]
|
||||
\centering
|
||||
\includegraphics[scale=.5, clip=true]{content/Technical_Background/DNS/DNS_address-resolution.pdf}
|
||||
\caption{Address Resolution}
|
||||
\label{fig:address_resolution}
|
||||
\end{figure}
|
||||
Binary file not shown.
@@ -0,0 +1,10 @@
|
||||
\section{Detecting Malicious Domain Names}
|
||||
\label{sec:detecting_malicious_domain_names}
|
||||
|
||||
|
||||
\subsection{Domain Name Characteristics}
|
||||
\label{subsec:domain_name_characteristics}
|
||||
|
||||
|
||||
\subsection{Machine Learning Approaches}
|
||||
\label{subsec:machine_learning_approaches}
|
||||
@@ -0,0 +1,4 @@
|
||||
\chapter{Technical Background}
|
||||
\label{cha:technical_background}
|
||||
|
||||
\input{content/Technical_Background/DNS/DNS}
|
||||
@@ -1,11 +1,30 @@
|
||||
\newglossaryentry{API}
|
||||
\newglossaryentry{api}
|
||||
{
|
||||
name={API},
|
||||
description={Application Programming Interface: FooBar}
|
||||
description={An Application Programming Interface (API) is a particular set
|
||||
of rules and specifications that a software program can follow to access and make use of the services and resources provided by another particular software program that implements that API.}
|
||||
}
|
||||
|
||||
\newglossaryentry{DNS}
|
||||
{
|
||||
name={DNS},
|
||||
description={Domain Name System}
|
||||
}
|
||||
\newacronym{sri-nic}{SRI-NIC}{Stanford Research Institute - Network Information Center}
|
||||
|
||||
\newacronym{dns}{DNS}{Domain Name System}
|
||||
|
||||
\newacronym{ipv6}{IPv6}{Internet Protocol Version 6}
|
||||
|
||||
\newacronym{arpanet}{ARPANET}{Advanced Research Projects Agency Network}
|
||||
|
||||
\newacronym{tcp/ip}{TCP/IP}{Transmission Control Protocol/Internet Protocol}
|
||||
|
||||
\newacronym{udp}{UDP}{User Datagram Protocol}
|
||||
|
||||
\newacronym{tcp}{TCP}{Transmission Control Protocol}
|
||||
|
||||
\newacronym{os}{OS}{Operating System}
|
||||
|
||||
\newacronym{ftp}{FTP}{File Transfer Protocol}
|
||||
|
||||
\newacronym{fqdn}{FQDN}{Fully Qualified Domain Name}
|
||||
|
||||
\newacronym{dnssec}{DNSSEC}{Domain Name System Security Extensions}
|
||||
|
||||
\newacronym{edns}{EDNS}{Extension mechanisms for DNS}
|
||||
|
||||
@@ -7,7 +7,7 @@
|
||||
% ------------------------------------------------------------------------------
|
||||
\documentclass[
|
||||
11pt, % font size
|
||||
DIV10,
|
||||
DIV=10,
|
||||
ngerman, % for german language
|
||||
a4paper, % paper format
|
||||
oneside, % onepage document
|
||||
@@ -46,7 +46,7 @@
|
||||
\include{commands}
|
||||
|
||||
% Main document ----------------------------------------------------------------
|
||||
% The actual document. The different parts are included and themself defined in tex documents in the content directory.
|
||||
% The actual document. The different parts are included and themselves defined in tex documents in the content directory.
|
||||
% ------------------------------------------------------------------------------
|
||||
\begin{document}
|
||||
|
||||
@@ -88,8 +88,8 @@
|
||||
% Main content
|
||||
% include each chapter here
|
||||
%
|
||||
\input{content/Introduction}
|
||||
\input{content/DNS}
|
||||
\input{content/Introduction/Introduction}
|
||||
\input{content/Technical_Background/Technical_Background}
|
||||
|
||||
|
||||
\clearpage
|
||||
|
||||
16
data/pDNS.csv
Normal file
16
data/pDNS.csv
Normal file
@@ -0,0 +1,16 @@
|
||||
"request/response-timestamp.id?", "record to resolve", "record type", "resolved to", "TTL"
|
||||
|
||||
"1486020829.399833","mta33.email.ticketmaster.com","A","136.147.136.237","3600"
|
||||
"1486020829.400363","v-a1-apps-ap.southeastasia.cloudapp.azure.com","A","23.97.60.182","10"
|
||||
"1486020829.406346","mtad01.tricorn.net","A","210.129.210.12","600"
|
||||
"1486020829.406346","mtad01.tricorn.net","A","210.129.210.8","600"
|
||||
"1486020829.406346","mtad01.tricorn.net","A","210.129.210.9","600"
|
||||
"1486020829.406346","mtad01.tricorn.net","A","210.129.210.13","600"
|
||||
"1486020829.406346","mtad01.tricorn.net","A","210.129.210.10","600"
|
||||
"1486020829.406346","mtad01.tricorn.net","A","210.129.210.11","600"
|
||||
"1486020829.406346","mtad01.tricorn.net","A","210.129.210.7","600"
|
||||
"1486020829.406346","mtad01.tricorn.net","A","210.129.210.6","600"
|
||||
"1486020829.409976","mailserv.turbonett.com.ni","A","200.62.64.37","3600"
|
||||
"1486020829.410635","ns-734.awsdns-27.net","AAAA","2600:9000:5302:de00:0:0:0:1","60"
|
||||
"1486020829.410964","itwhitepapersbusiness.imgus1.com","A","67.228.130.130","300"
|
||||
"1486056521.976540","hiltonhonors.com","NS","ns1.nycl.twtelecom.net","11351"
|
||||
|
BIN
literature/Breaking Bad: Detecting malicious domains using.pdf
Normal file
BIN
literature/Breaking Bad: Detecting malicious domains using.pdf
Normal file
Binary file not shown.
Binary file not shown.
Reference in New Issue
Block a user