Tweaks for DNSSEC docs

* powerdnssec.org was discontinued a while ago
* rst tweaks
* there do not appear to be tutorials available

diff --git a/docs/changelog/pre-4.0.rst b/docs/changelog/pre-4.0.rst
index 461eb9aa138e5cf1fd0a134768f5ed0c6b163e5a..8282b79e42c7723b0aa67941e8d9001cf01e5cc4 100644 (file)
--- a/docs/changelog/pre-4.0.rst
+++ b/docs/changelog/pre-4.0.rst
@@ -263,7 +263,7 @@ lot of improvements and bug fixes and tremendously increases compliance.
 We want to explicitly thank Kees Monshouwer for digging up all the
 DNSSEC improvements and porting them back to this release.
 
-When upgrading, please run "pdnssec rectify-all-zones" and trigger an
+When upgrading, please run ``pdnssec rectify-all-zones`` and trigger an
 AXFR for all DNSSEC zones to make sure you benefit from all the
 compliance improvements present in this version.
 
@@ -2748,13 +2748,10 @@ important protocol is among the easiest to use available. In addition,
 all important algorithms are supported.
 
 Complete detail can be found in `Serving authoritative DNSSEC
-data <../dnssec/intro.rst>`__. The goal of 'PowerDNSSEC' is to allow
-existing PowerDNS installations to start serving DNSSEC with as little
-hassle as possible, while maintaining performance and achieving high
-levels of security.
-
-Tutorials and examples of how to use DNSSEC in PowerDNS can be found
-linked from http://powerdnssec.org.
+data <../dnssec/intro.rst>`__. The goal of PowerDNS's DNSSEC support
+is to allow existing PowerDNS installations to start serving DNSSEC with
+as little hassle as possible, while maintaining performance and
+achieving high levels of security.
 
 PowerDNS Authoritative Server 3.0 development has been made possible by
 the financial and moral support of

diff --git a/docs/dnssec/advice.rst b/docs/dnssec/advice.rst
index 8f155e9533a48dff3dcc41c5ce7b71c67249c601..f43b1741e0fdf23f0111a58ba89179e86e392de8 100644 (file)
--- a/docs/dnssec/advice.rst
+++ b/docs/dnssec/advice.rst
@@ -4,7 +4,7 @@ DNSSEC advice & precautions
 DNSSEC is a major change in the way DNS works. Furthermore, there is a
 bewildering array of settings that can be configured.
 
-It is well possible to configure DNSSEC in such a way that your domain
+It is easy to (mis)configure DNSSEC in such a way that your domain
 will not operate reliably, or even, at all. We advise operators to stick
 to the keying defaults of ``pdnsutil secure-zone``.
 

diff --git a/docs/dnssec/intro.rst b/docs/dnssec/intro.rst
index 239b67460a8f5d02c3ce92fac7b8c9454e02ee4f..2b2a0fc0fef776a6ad922d583d9c48540508399a 100644 (file)
--- a/docs/dnssec/intro.rst
+++ b/docs/dnssec/intro.rst
@@ -4,9 +4,9 @@ A brief introduction to DNSSEC
 DNSSEC is a complicated subject, but it is not required to know all the
 ins and outs of this protocol to be able to use PowerDNS. In this
 section, we explain the core concepts that are needed to operate a
-PowerDNSSEC installation.
+PowerDNS installation with DNSSEC.
 
-Zone material is enhanced with signatures using 'keys'. Such a signature
+Zone material is enhanced with signatures using ``keys``. Such a signature
 (called an RRSIG) is a cryptographic guarantee that the data served is
 the original data. DNSSEC keys are asymmetric (RSA, DSA, ECSDA or GOST),
 the public part is published in DNS and is called a DNSKEY record, and
@@ -24,29 +24,29 @@ Once the parent zone has the DS, and the zone is signed with the DNSSEC
 key, we are done in theory.
 
 However, for a variety of reasons, most DNSSEC operations run with
-another layer of keys. The so called 'Key Signing Key' is sent to the
+another layer of keys. The so called ``Key Signing Key`` is sent to the
 parent zone, and this Key Signing Key is used to sign a new set of keys
 called the Zone Signing Keys.
 
 This setup allows us to change our keys without having to tell the zone
 operator about it.
 
-A final challenge is how to DNSSEC sign the answer 'no such domain'. In
-the language of DNS, the way to say 'there is no such domain' (NXDOMAIN)
+A final challenge is how to DNSSEC sign the answer *no such domain*. In
+the language of DNS, the way to say *there is no such domain* (``NXDOMAIN``)
 or there is no such record type is to send an empty answer. Such empty
 answers are universal, and can't be signed.
 
-In DNSSEC parlance we therefore sign a record that says 'there are no
-domains between A.powerdnssec.org and C.powerdnssec.org'. This securely
-tells the world that B.powerdnssec.org does not exist. This solution is
-called NSEC, and is simple but has downsides - it also tells the world
+In DNSSEC parlance we therefore sign a record that says *there are no
+domains between* ``A.powerdnssec.org`` *and* ``C.powerdnssec.org``. This securely
+tells the world that ``B.powerdnssec.org`` does not exist. This solution is
+called ``NSEC``, and is simple but has downsides - it also tells the world
 exactly which records DO exist.
 
 So alternatively, we can say that if a certain mathematical operation
-(an 'iterated salted hash') is performed on a question, that no valid
+(an *iterated salted hash*) is performed on a question, that no valid
 answers exist that have as outcome of this operation an answer between
-two very large numbers. This leads to the same 'proof of non-existence'.
-This solution is called NSEC3.
+two very large numbers. This leads to the same *proof of non-existence*.
+This solution is called ``NSEC3``.
 
-A PowerDNS zone can either be operated in NSEC or in one of two NSEC3
-modes ('inclusive' and 'narrow').
+A PowerDNS zone can either be operated in ``NSEC`` or in one of two ``NSEC3``
+modes (``inclusive`` and ``narrow``).