Merge pull request #5 from chbruyand/fix-typos

Fix typos
This commit is contained in:
bert hubert 2018-03-29 14:46:17 +01:00 committed by GitHub
commit c1bdb73731
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
3 changed files with 4 additions and 4 deletions

View File

@ -358,7 +358,7 @@ should never happen.
## Zone files
Zone files are one way of storing DNS data, but these are not integral to
the operation of a nameserver. The zone file format is standardised, but it
the operation of a nameserver. The zone file format is standardized, but it
is highly non-trivial to parse. It is entirely possible to write useful
nameserver that does not read or write DNS zone files. When embarking on
parsing zonefiles, do not do so lightly. As an example, various fields
@ -614,7 +614,7 @@ record is created on the fly.
## Truncation
Without implementing the optional EDNS protocol extension, all UDP responses
must fit in 512 bytes of payload. If on writing an answer a server finds
itself exceding this limit, it must truncate the packet and set the TC bit
itself exceeding this limit, it must truncate the packet and set the TC bit
to 1.
The originator of the query will then resend the query over TCP.

View File

@ -6,7 +6,7 @@ There are now between 1500 and 3000 pages of RFC documents describing DNS,
containing around 1700 'MUST' statements.
Not only are there a lot of documents, the earlier ones are not that easy to
read for newcomers, and contain a lot of obsoleted bagage that new readers
read for newcomers, and contain a lot of obsoleted baggage that new readers
do not know they can skip.
Inspired by the wonderful books by W. Richard Stevens (like [TCP

View File

@ -19,7 +19,7 @@ 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
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.