new content!
This commit is contained in:
bert hubert
parent
c26bbac310
commit
695a97c65f
3
auth.md
3
auth.md
@ -1,7 +1,8 @@
|
||||
<meta charset="utf-8" emacsmode="-*- markdown -*-">
|
||||
**A warm welcome to DNS**
|
||||
|
||||
<link rel="stylesheet" href="https://casual-effects.com/markdeep/latest/apidoc.css?">
|
||||
<!-- <link rel="stylesheet" href="https://casual-effects.com/markdeep/latest/apidoc.css?">
|
||||
-->
|
||||
|
||||
Note: this page is part of the
|
||||
'[hello-dns](https://powerdns.org/hello-dns/)' documentation effort.
|
||||
|
||||
8
basic.md
8
basic.md
@ -1,21 +1,23 @@
|
||||
<meta charset="utf-8" emacsmode="-*- markdown -*-">
|
||||
**A warm welcome to DNS**
|
||||
<link rel="stylesheet" href="https://casual-effects.com/markdeep/latest/apidoc.css?">
|
||||
<!-- <link rel="stylesheet" href="https://casual-effects.com/markdeep/latest/apidoc.css?">
|
||||
-->
|
||||
|
||||
Note: this page is part of the
|
||||
'[hello-dns](https://powerdns.org/hello-dns/)' documentation effort.
|
||||
|
||||
# DNS Basics
|
||||
In this section we will initially ignore optional extensions that were added
|
||||
to DNS later, specifically EDNS and DNSSEC.
|
||||
|
||||
This file corresponds roughly to the fundamental parts of RFCs 1034, 1035,
|
||||
2181, 2308, 3596, 4343, 5452, 6604, 7766 and 8020.
|
||||
|
||||
**This file, which describes DNS basics, absolutely must be read from
|
||||
**This page, which describes DNS basics, absolutely must be read from
|
||||
beginning to end in order for the rest of the documents (or DNS) to make
|
||||
sense.**
|
||||
|
||||
# DNS Basics
|
||||
|
||||
DNS is mostly used to serve IP addresses and mailserver details, but it can
|
||||
contain arbitrary data. DNS is all about names. Every name can have data
|
||||
of several *types*. The most well known externally useful types are *A* for
|
||||
|
||||
72
resolver.md
72
resolver.md
@ -30,8 +30,76 @@ Excellent resolvers that are freely available and open source include:
|
||||
So in short, before attempting to write a DNS resolver, ponder if you really
|
||||
need to.
|
||||
|
||||
# Resolver algorithm
|
||||
As part of this project a [`teaching resolver`](tres.md.html) (or `tres`)is
|
||||
provided. Understanding `tres` and its source code is easier after reading
|
||||
this page.
|
||||
|
||||
# Resolver algorithm
|
||||
## In-zone nameservers, no CNAMEs
|
||||
There are various strategies to resolve names. The most basic form is to
|
||||
send the same query for the full query name to a series of ever more
|
||||
specific nameservers.
|
||||
|
||||
So, to resolve `www.powerdns.com`, send a query for that name to one of the
|
||||
26 root-server IP address. The root-servers will return a non-authoritative
|
||||
answer ('aa=0') with the NS records of the `COM` servers, and helpfully also
|
||||
provide IP addresses for those servers.
|
||||
|
||||
The resolver can believe these NS records and even the 'glue' - we trust the
|
||||
root-servers to serve the root and everything under it.
|
||||
|
||||
Based on the IP addresses provided in the glue, the same `www.powerdns.com`
|
||||
query can now be sent to one of the `COM` servers, which in turn replies
|
||||
with another non-authoritative answer that does however list the names & IP
|
||||
addresses for the `powerdns.com` zones.
|
||||
|
||||
Finally, the `www.powerdns.com` query can get sent to one of the
|
||||
`powerdns.com` nameserver IP addresses, and finally an answer arrives.
|
||||
|
||||
This is the simplest case where resolution can proceed iteratively - each
|
||||
response carries full information where the next query can get sent.
|
||||
|
||||
## Out-of-zone nameservers
|
||||
To resolve `www.powerdns.org`, the situation is more difficult. The
|
||||
root-servers again provide the first help by telling us about the `ORG`
|
||||
nameservers & their IP addresses.
|
||||
|
||||
When we then ask the `ORG` nameservers for `www.powerdns.org`, these return
|
||||
with a set of nameservers for `powerdns.org`.. but no IP addresses. This is
|
||||
because the `powerdns.org` nameservers do not reside in the `ORG` zone.
|
||||
|
||||
This means that the same algorithm we are using to resolve
|
||||
`www.powerdns.org` now needs to be started in parallel for finding the IP
|
||||
address of `ns1.ds9a.nl`. Luckily, resolving `ns1.ds9a.nl` proceeds as
|
||||
described in the previous section, without the need to resolve further
|
||||
nameserver names.
|
||||
|
||||
Once we have an IP address for a `powerdns.org` nameserver, we can ask it
|
||||
about `www.powerdns.org`.
|
||||
|
||||
## CNAMEs
|
||||
CNAMEs complicate this process slightly but not fundamentally. A CNAME
|
||||
redirects our query to a new name. This means that once a CNAME is hit, the
|
||||
initial algorithm terminates, and gets restarted for the new CNAME target.
|
||||
|
||||
Frequently, a CNAME points to a name that is also within the same zone, for
|
||||
example `www.powerdns.org. IN CNAME powerdns.org`. Authoritative servers
|
||||
then typically also include the requested type for `powerdns.org` in the
|
||||
same DNS response. As an optimization, a resolver can use this CNAME record
|
||||
and terminate the algorithm.
|
||||
|
||||
# Security
|
||||
At every point a resolver must be vigilant to not store data coming from an
|
||||
authoritative server that can not be trusted to provide that data.
|
||||
|
||||
In addition, if a cache is used, care must be taken that an authoritative
|
||||
server must not be allowed to 'extend its own authority' infinitely. This is
|
||||
a problem when a domain gets assigned new nameservers, but a resolver
|
||||
'sticks' to the old one.
|
||||
|
||||
There are many many other security pitfalls within a resolver, which is why
|
||||
we recommend not writing another one unless this is really really necessary
|
||||
somehow.
|
||||
|
||||
TBC..
|
||||
|
||||
<!-- Markdeep: --><style class="fallback">body{visibility:hidden;white-space:pre;font-family:monospace}</style><script src="ext/markdeep.min.js"></script><script>window.alreadyProcessedMarkdeep||(document.body.style.visibility="visible")</script>
|
||||
|
||||
7
stub.md
7
stub.md
@ -23,10 +23,11 @@ good care to fully randomize 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.
|
||||
|
||||
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 -
|
||||
even over TCP!
|
||||
|
||||
<!-- Markdeep: --><style class="fallback">body{visibility:hidden;white-space:pre;font-family:monospace}</style><script src="ext/markdeep.min.js"></script><script>window.alreadyProcessedMarkdeep||(document.body.style.visibility="visible")</script>
|
||||
|
||||
Loading…
Reference in New Issue
Block a user