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

Various minor corrections to the text

Browse Source
This commit is contained in:
Michał Kępień
2018-10-17 06:41:36 +02:00
parent e7530032d4
commit 87e6e2ce81
4 changed files with 18 additions and 18 deletions
Download Patch File Download Diff File Expand all files Collapse all files

4
README.md
View File

@ -67,12 +67,12 @@ laid out. This part is required reading for anyone ever wanting to query a
nameserver or emit a valid response.
We then specialize into what applications can expect when they send
questions to a resolver, or what a stub-resolver can expect.
questions to a resolver, or what a stub resolver can expect.
The next part is about what an authoritative server is supposed to do. On
top of this, we describe in slightly less detail how a resolver could
operate. Finally, there is a section on optional elements like EDNS, TSIG,
Dynamic Updates and DNSSEC
Dynamic Updates and DNSSEC.
RFCs, especially earlier ones, tend to describe servers that perform both
authoritative and resolver functions. This turns out to make both code and

6
auth.md
View File

@ -10,7 +10,7 @@ Note: this page is part of the
The basics of DNS Authoritative operation have already been described in the
[Basic DNS](index.html) document. In this file, we delve deeper into zone
transfers and and notifications.
transfers and notifications.
This document covers RFCs 1982, 1995, 1996 (all three related to zone
transfers), 4592 (Wildcards), 5936 (again zone transfers) and 7766 (TCP).
@ -96,7 +96,7 @@ that are only applicable to resolvers, with new instructions in **bold**.
if the addresses are not available from authoritative
data ~~or the cache~~. Go to step 4.
3. If at some label, a match is impossible (i.e., the
corresponding label does not exist), look to see if a
corresponding label does not exist), look to see if
the * label exists.
If the * label does not exist, check whether the name
we are looking for is the original QNAME in the query
@ -127,7 +127,7 @@ This is effectively the same thing but implemented on a regular key/value
lookup engine.
## Wildcards
The algorithm as described in the previous session does mention wildcards,
The algorithm as described in the previous section does mention wildcards,
but not in great detail, and not coherently. [RFC
4592](https://tools.ietf.org/html/rfc4592) by comparison discusses wildcards
in exhaustive detail.

20
basic.md
View File

@ -36,7 +36,7 @@ A DNS message has:
* An authority section
* An additional section
In basic DNS, query messages should have empty answer, authority or
In basic DNS, query messages should have empty answer, authority and
additional sections.
The header has the following fields that are useful for queries and
@ -202,7 +202,7 @@ In addition, ANCOUNT is now set to '1', indicating a single answer is to be
found in the message, immediately after the original question, which has been
repeated from the query message.
To recognize the right response, check that the ID field is the same as the
To recognize the right response, check that the ID field is the same as in the
query, make sure the answer arrives on the right source port and that the
query name and type match up with the original query. In addition, make sure
not to send out more than one equivalent query when still waiting for the
@ -280,7 +280,7 @@ these sections later.
## RRSETs
In the example above, the question for the AAAA record of 'www.ietf.org' had
exactly one corresponding resource record. In a human readable 'zone file',
this would stored as:
this would be stored as:
```
www.ietf.org IN AAAA 3600 2400:cb00:2048:1::6814:55
@ -495,7 +495,7 @@ response with AA=0, indicating that the 'org' servers know they aren't
### Glue records
The astute reader will have spotted a chicken and egg problem here. If
ns1.ietf.org is the nameserver for ietf.org.. where do we get the IP
ns1.ietf.org is the nameserver for ietf.org... where do we get the IP
address of ns1.ietf.org?
To solve this problem, the parent zone can provide a free chicken. In the
@ -535,7 +535,7 @@ www IN CNAME www.ietf.org.cdn.cloudflare.net.
This is frequently used to redirect to a Content Distribution Network. The
CNAME is for a name, and not for a type. This means that *any* query for
www.ietf.org is sent to cloudflare. This simultaneously means that what
www.ietf.org is sent to Cloudflare. This simultaneously means that what
everyone wants is impossible:
```
@ -568,7 +568,7 @@ A query for the A record of 'smtp.ietf.org' will return 192.0.2.222. A query
for 'www.ietf.org' however will return 192.0.2.1.
Interestingly, as another example of how DNS really is a tree, a query for
the AAAA record of smtp.ietf.org will return.. nothing. This is because
the AAAA record of smtp.ietf.org will return... nothing. This is because
the node 'smtp.ietf.org' does exist, and processing ends there. The
wildcard match will not proceed to the '*' entry.
@ -650,8 +650,8 @@ server is supposed to prefer. This list becomes a lot simpler when split up
between pure authoritative and pure resolver functions.
### RFC 2308: "Negative caching of DNS Queries (NCACHE)
This [rfc](https://tools.ietf.org/html/rfc2308) describes how negative
responses are to be cached. The details matter for both authoritative and
This [RFC](https://tools.ietf.org/html/rfc2308) describes how negative
responses are to be cached. The details matter for both authoritative servers and
resolvers. Of specific note are the parts that dwell on CNAME chains which
lead to a 'no data' or 'NXDOMAIN' situation.
@ -659,7 +659,7 @@ As with 2181, this RFC speaks about an earlier version of DNSSEC, and these
parts should be fully ignored.
### RFC 3596: "DNS Extensions to Support IP Version 6"
This [rfc](https://tools.ietf.org/html/rfc3596) describes the AAAA record,
This [RFC](https://tools.ietf.org/html/rfc3596) describes the AAAA record,
which is core to DNS as it is required to look up addresses of nameservers.
### RFC 4343: "Domain Name System Case Insensitivity Clarification"
@ -683,7 +683,7 @@ an earlier version of DNAMEs, these parts are best ignored in lieu of
### RFC 7766: DNS Transport over TCP - Implementation Requirements
[This RFC](https://tools.ietf.org/html/rfc7766.txt) updates 1034/1035 to
state that TCP is a mandatory part of DNS and a first class citizen It also
state that TCP is a mandatory part of DNS and a first class citizen. It also
updates timeout rules, recommending rather brief timeouts compared to the
'minutes' noted in the original DNS standard.

6
optional.md
View File

@ -4,7 +4,7 @@
# EDNS, Dynamic Updates, TSIG, DNAME, DNS Cookies & more
So far we've focussed on the simplest possible form of DNS that is
interoperable with today's internet. Over the past 3 decades however, a lot
has been added to DNS however.
has been added to DNS.
Items relevant for authoritative servers and resolvers:
@ -12,7 +12,7 @@ Items relevant for authoritative servers and resolvers:
including arbitrary options. The main use of EDNS today is specifying a
larger supported UDP packet size, indicating DNSSEC support and carrying
Client Subnet information. Defined in [RFC
6891](https://tools.ietf.org/html/rfc2671).
6891](https://tools.ietf.org/html/rfc6891).
* EDNS Client Subnet: Convey (part) of client addresses to authoritative
resolvers. Defined in [RFC 7871](https://tools.ietf.org/html/rfc7871).
* DNAME: Domain redirection [RFC 6672](https://tools.ietf.org/html/rfc6672)
@ -26,7 +26,7 @@ Relevant for authoritative servers:
* TSIG: Secret Key Transaction Authentication for DNS. A way to sign DNS
messages or a list of DNS messages with a secret key. Used to authenticate
AXFR requests and to guarantee zone integrity during AXFR. Defined in
[RFC 2845](https://tools.ietf.org/html/rfc2136).
[RFC 2845](https://tools.ietf.org/html/rfc2845).
## Extended DNS (EDNS or EDNS(0))