On 8/4/16, 10:16, "DNSOP on behalf of Paul Hoffman" <[email protected] on
behalf of [email protected]> wrote:
Greetings again. There are six terms that are commonly used when we talk
about DNSSEC:
- validation and validate
- authentication and authenticate
- verification and verify
Are they defined in any RFCs that we can use for the terminology-bis
document? As far as I can see (but I could be blinded), they are not
defined in RFC 403[3-5].
Suggestions?
Writing based on possibly undocumented (read: oral) history, those terms fell
under the category of "local policy" in the earlier DNSSEC documents (such as
"Domain Name System Security Extensions" [RFC 2535]).
When the first proof-of-concept DNSSEC validator was written there was a
definite and deterministic set of tests implemented but there was no intention
to codify that into an IETF document for a number of reasons. At the time the
documents had a goal of defining what was needed for interoperability, as
opposed to be prescriptive. And it wasn't clear that local matters of what an
instantiation would trust would necessarily be significant to what another
instantiation would choose.
There once was a long thread on whether an authoritative server should perform
cryptographic checking of all loaded signature before adding in the AD bit.
Ultimately it was decided to not require that (because, for one, load time was
too long for large zones). Authenticated Data meant "the server is happy with
the data" and not that any level of computation (signature checking) had been
done. The result of this is in "Redefinition of DNS Authenticated Data (AD)
bit".
--- Begin Message ---
Terry Manderson <[email protected]> writes:
> Hi Spencer,
>
> On 14/07/2016, 12:57 PM, "Spencer Dawkins at IETF"
> <[email protected]> wrote:
>>
>>Terry, I like where you're headed, but just to ask the obvious question,
>>are you thinking the draft would, or would not, also contain something
>>like "at the time this document was approved, a domain used for this test
>>was $someactualworkingdomain.com <http://someactualworkingdomain.com>"?
>
> Sorry I didn't make it obvious, yes I would like to see text like this,
> and I think it makes an easy path for the less adventurous in addition to
> supplying more in depth guidance.
How does this text work to be dropped into the end of the
"Implementation experiences" section (1.3):
<section title="Test Zone Implementation">
<t>In this document, the "test.example.com" domain is
used to refer to DNS records which contain test records
that have known DNSSEC properties associated with them.
For example, the "badsign-a.test.example.com" domain is
used below to refer to a DNS A record where the
signatures published for it are invalid (i.e., they are
"bad signatures" that should cause a validation
failure).</t>
<t>At the time of this publication, the
"test.dnssec-tools.org" domain implements all of these
test records. Thus, it may be possible to replace
"test.example.com" in this document with
"test.dnssec-tools.org" when performing real-world
tests.</t>
</section>
And then everywhere that test.dnssec-tools.org exists in the document,
I'll replace it with "test.example.com".
--
Wes Hardaker
Parsons
_______________________________________________
DNSOP mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dnsop
--- End Message ---
_______________________________________________
DNSOP mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dnsop
