From a3dc5e77d3dc9a521dfc90161b697ff605911c66 Mon Sep 17 00:00:00 2001 From: bert hubert Date: Thu, 29 Mar 2018 02:25:27 +0200 Subject: [PATCH] some more content in stub --- README.md | 12 ++++++------ stub.md | 31 +++++++++++++++++++++++++++++++ 2 files changed, 37 insertions(+), 6 deletions(-) diff --git a/README.md b/README.md index 25c5028..9232c9d 100644 --- a/README.md +++ b/README.md @@ -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. diff --git a/stub.md b/stub.md index e69de29..ded8665 100644 --- a/stub.md +++ b/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. +