mirrors/hello-dns
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity

some more content in stub

Browse Source
This commit is contained in:
bert hubert 2018-03-29 02:25:27 +02:00
parent 2f7a80edcb
commit a3dc5e77d3
2 changed files with 37 additions and 6 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

12
README.md
View File

@ -38,10 +38,10 @@ The content is spread out over several documents:
* The core of DNS
* [Relevant to stub resolvers and applications](stub.md)
* Relevant to authoritative servers
* Relevant to resolvers
* Optional elements: EDNS, TSIG, Dynamic Updates, DNSSEC, DNAME, DNS
Cookies
* [Relevant to authoritative servers](auth.md)
* [Relevant to resolvers](resolvers.md)
* Optional elements: [EDNS, TSIG, Dynamic Updates, DNSSEC, DNAME, DNS
Cookies](optional.md)
We start off with a general introduction of DNS basics: what is a resource
record, what is an RRSET, what is a zone, what is a zone-cut, how are packets
@ -62,7 +62,7 @@ sense.
## DNS Basics
In this section we will initially ignore optional extensions that were added
to DNS later, specifically EDNS and DNSSEC which requires EDNS to function.
to DNS later, specifically EDNS and DNSSEC.
This file corresponds roughly to the fundamental parts of RFCs 1034, 1035,
1982, 2181, 2308, 3596, 4343, 5452, 6604.
@ -422,7 +422,7 @@ $origin www.ietf.org
A zone always starts with a SOA or Start Of Authority record. A SOA record
is DNS metadata. It stores various things that may be of interest about a
zone, like the email address of the maintainer, the name of the most
authoritative server. It also has vales that describe how or if a zone
authoritative server. It also has values that describe how or if a zone
needs to be replicated. Finally, the SOA record has a number that
influences TTL values for names that do not exist.

31
stub.md
View File

@ -0,0 +1,31 @@
# Stub resolvers, applications
As a client of DNS, life is relatively easy. You can use operating system
functions like `gethostbyname()` or `getaddrinfo()`, and these will take
care of everything for you, including applying local overrides and policy.
This may not always be what you want, or you may in fact be reading this
because you need to implement those functions.
In either case, what you are attempting to become is called a 'stub
resolver'. This is assumed to be a very simple DNS client that sends out DNS
queries and receives ready to use answers in response.
And this is indeed true. A stub resolver should not do anything exciting
beyond sending queries and parsing responses.
It should specifically not process any NS records or even chase CNAMEs. The
resolver a stub talks to should take care of everything.
XXX - where does it say so?
A few things do matter. For security purposes, the stub resolver must take
good care to fully randomise source port and ID fields. It must also guard
against sending out multiple equivalent queries at the same time as this
would allow a 'birthday attack' that could spoof in harmful answers.
If a resolver sends out two different questions in parallel, like for A and
AAAA of a name, it should be prepared to receive responses out of order.
It is also important to actually test the TC=1 response path, something that
may be triggered when sending queries that lead to huge answers.