some more content in stub
This commit is contained in:
parent
2f7a80edcb
commit
a3dc5e77d3
12
README.md
12
README.md
@ -38,10 +38,10 @@ The content is spread out over several documents:
|
|||||||
|
|
||||||
* The core of DNS
|
* The core of DNS
|
||||||
* [Relevant to stub resolvers and applications](stub.md)
|
* [Relevant to stub resolvers and applications](stub.md)
|
||||||
* Relevant to authoritative servers
|
* [Relevant to authoritative servers](auth.md)
|
||||||
* Relevant to resolvers
|
* [Relevant to resolvers](resolvers.md)
|
||||||
* Optional elements: EDNS, TSIG, Dynamic Updates, DNSSEC, DNAME, DNS
|
* Optional elements: [EDNS, TSIG, Dynamic Updates, DNSSEC, DNAME, DNS
|
||||||
Cookies
|
Cookies](optional.md)
|
||||||
|
|
||||||
We start off with a general introduction of DNS basics: what is a resource
|
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
|
record, what is an RRSET, what is a zone, what is a zone-cut, how are packets
|
||||||
@ -62,7 +62,7 @@ sense.
|
|||||||
|
|
||||||
## DNS Basics
|
## DNS Basics
|
||||||
In this section we will initially ignore optional extensions that were added
|
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,
|
This file corresponds roughly to the fundamental parts of RFCs 1034, 1035,
|
||||||
1982, 2181, 2308, 3596, 4343, 5452, 6604.
|
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
|
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
|
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
|
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
|
needs to be replicated. Finally, the SOA record has a number that
|
||||||
influences TTL values for names that do not exist.
|
influences TTL values for names that do not exist.
|
||||||
|
|
||||||
|
31
stub.md
31
stub.md
@ -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.
|
||||||
|
|
Loading…
Reference in New Issue
Block a user