Skip to content
GitLab
Projects
Groups
Snippets
/
Help
Help
Support
Community forum
Keyboard shortcuts
?
Submit feedback
Contribute to GitLab
Sign in / Register
Toggle navigation
Menu
Open sidebar
ISC Open Source Projects
BIND
Commits
5e371908
Commit
5e371908
authored
Aug 30, 2018
by
Evan Hunt
Committed by
Mark Andrews
Aug 31, 2018
Browse files
add documentation
parent
615ebc39
Pipeline
#4549
passed with stages
in 9 minutes
Changes
3
Pipelines
1
Hide whitespace changes
Inline
Side-by-side
CHANGES
View file @
5e371908
5029. [func] Workarounds for servers that misbehave when queried
with EDNS have been removed, because these broken
servers and the workarounds for their noncompliance
cause unnecessary delays, increase code complexity,
and prevent deployment of new DNS features. See
https://dnsflagday.net for further details. [GL #150]
5028. [bug] Spread the initial RRSIG expiration times over the
entire working sig-validity-interval when signing a
zone in named to even out re-signing and transfer
...
...
doc/arm/Bv9ARM-book.xml
View file @
5e371908
...
...
@@ -17139,7 +17139,58 @@ allow-query { !{ !10/8; any; }; key example; };
source of hints and information that can be used to figure out
what went wrong and how to fix the problem.
</para>
</section>
<section><info><title>EDNS compliance issues</title></info>
<para>
EDNS (Extended DNS) is a standard that was first specified
in 1999. It is required for DNSSEC validation, DNS COOKIE
options, and other features. There are broken and outdated
DNS servers and firewalls still in use which misbehave when
queried with EDNS; for example, they may drop EDNS queries
rather than replying with FORMERR. BIND and other recursive
name servers have traditionally employed workarounds in this
situation, retrying queries in different ways and eventually
falling back to plain DNS queries without EDNS.
</para>
<para>
Such workarounds cause unnecessary resolution delays,
increase code complexity, and prevent deployment of new DNS
features. As of February 2019, all major DNS software vendors
have agreed to remove these workarounds; see
<link xmlns:xlink="http://www.w3.org/1999/xlink"
xlink:href="https://dnsflagday.net">https://dnsflagday.net</link>
for further details. This change was implemented in BIND
as of release 9.14.0.
</para>
<para>
As a result, some domains may be non-resolvable without manual
intervention. In these cases, resolution can be restored by
adding <command>server</command> clauses for the offending
servers, specifying <command>edns no</command> or
<command>send-cookie no</command>, depending on the specific
noncompliance.
</para>
<para>
To determine which <command>server</command> clause to use,
run the following commands to send queries to the authoritative
servers for the broken domain:
</para>
<literallayout>
dig soa <zone> @<server> +dnssec
dig soa <zone> @<server> +dnssec +nocookie
dig soa <zone> @<server> +noedns
</literallayout>
<para>
If the first command fails but the second succeeds, the
server most likely needs <command>send-cookie no</command>.
If the first two fail but the third succeeds, then the server
needs EDNS to be fully disabled with <command>edns no</command>.
</para>
<para>
Please contact the administrators of noncompliant domains
and encourage them to upgrade their broken DNS servers.
</para>
</section>
</section>
<section><info><title>Incrementing and Changing the Serial Number</title></info>
...
...
doc/arm/notes.xml
View file @
5e371908
...
...
@@ -156,6 +156,47 @@
<section
xml:id=
"relnotes_removed"
><info><title>
Removed Features
</title></info>
<itemizedlist>
<listitem>
<para>
Workarounds for servers that misbehave when queried with EDNS
have been removed, because these broken servers and the
workarounds for their noncompliance cause unnecessary delays,
increase code complexity, and prevent deployment of new DNS
features. See
<link
xmlns:xlink=
"http://www.w3.org/1999/xlink"
xlink:href=
"https://dnsflagday.net"
>
https://dnsflagday.net
</link>
for further details.
</para>
<para>
In particular, resolution will no longer fall back to
plain DNS when there was no response from an authoritative
server. This will cause some domains to become non-resolvable
without manual intervention. In these cases, resolution can
be restored by adding
<command>
server
</command>
clauses for the
offending servers, specifying
<command>
edns no
</command>
or
<command>
send-cookie no
</command>
, depending on the specific
noncompliance.
</para>
<para>
To determine which
<command>
server
</command>
clause to use, run
the following commands to send queries to the authoritative
servers for the broken domain:
</para>
<literallayout>
dig soa
<
zone
>
@
<
server
>
+dnssec
dig soa
<
zone
>
@
<
server
>
+dnssec +nocookie
dig soa
<
zone
>
@
<
server
>
+noedns
</literallayout>
<para>
If the first command fails but the second succeeds, the
server most likely needs
<command>
send-cookie no
</command>
.
If the first two fail but the third succeeds, then the server
needs EDNS to be fully disabled with
<command>
edns no
</command>
.
</para>
<para>
Please contact the administrators of noncompliant domains
and encourage them to upgrade their broken DNS servers. [GL #150]
</para>
</listitem>
<listitem>
<para>
Previously, it was possible to build BIND without thread support
...
...
Write
Preview
Supports
Markdown
0%
Try again
or
attach a new file
.
Cancel
You are about to add
0
people
to the discussion. Proceed with caution.
Finish editing this message first!
Cancel
Please
register
or
sign in
to comment