Hello,
I'm playing a little with NSD. The setup I have is that NSD
is configured as a slave. I've used 'nsdc patch' to write a
zone file.
I'm looking at this file right now and DS records with algorithm
5 are written like:
IN DS 10240 RSASHA1 2 <hash>
In stead of:
IN DS 10240 5 2 <hash>
Other DS records with algorithms 7 and 8 are correct.
A little test show that BIND9 can at least read such a zone, but it
seems a little inconsistent.
Can someone verify this?
grtz,
Hello Miek,
RFC4034 5.3 (http://tools.ietf.org/html/rfc4034#section-5.3) says this is allowed, pointing to a list in appendix A.1 (http://tools.ietf.org/html/rfc4034#appendix-A.1).
The appendix lists RSASHA1 but not 7 and 8 - so it looks like NSD uses the mnemonic when 4034 allows it, and uses the number otherwise.
Additionally, http://www.iana.org/assignments/dns-sec-alg-numbers/dns-sec-alg-numbers.xml lists mnenomics for the newer algorithms.
Kind regards,
Peter van Dijk
[ Quoting <peter.van.dijk@netherlabs> at 21:42 on Feb 27 in "Re: [nsd-users] DS a..." ]
Hello Miek,
> Can someone verify this?
RFC4034 5.3 (http://tools.ietf.org/html/rfc4034#section-5.3) says this is allowed, pointing to a list in appendix A.1 (http://tools.ietf.org/html/rfc4034#appendix-A.1).
The appendix lists RSASHA1 but not 7 and 8 - so it looks like NSD uses the mnemonic when 4034 allows it, and uses the number otherwise.
I only read 3658, which is indeed obsoleted by those RFCs. Thanks for the
clarification.
Mental note to self: pay more attention to the first page of an RFC.
grtz,
Hi Miek,
This is correct. NSD only had up to RSASHA1 in its dns algorithm
table. Newer algorithms were never added due to backwards
incompatibility concerns.
However, we could allow newer mnemonics when reading in a zone (more
user friendly), and when writing always print the unsigned integer
value (more consistent, backwards compatible).
Best regards,
Matthijs
This is correct. NSD only had up to RSASHA1 in its dns algorithm
table. Newer algorithms were never added due to backwards
incompatibility concerns.
strictly speaking, section 5.3 of RFC 4034 limits the mnemonic
representation to those present in that RFC's appendix and does
not extend it to future (including those defined in 5702 and 5933)
code point assignments. From the point of view of an authoritative
server this makes sense since it doesn't have to understand (or
recognize) the algorithm used to properly serve the correct
DNSKEY and RRSIG RRs.
However, we could allow newer mnemonics when reading in a zone (more
user friendly), and when writing always print the unsigned integer
value (more consistent, backwards compatible).
+1 for the latter and 'not sure' about the former. Another potential
abuse of the robustness principle at the horizon ...
-Peter
[ Quoting <pk@denic.de> at 11:19 on Feb 28 in "Re: [nsd-users] DS a..." ]
> However, we could allow newer mnemonics when reading in a zone (more
> user friendly), and when writing always print the unsigned integer
> value (more consistent, backwards compatible).+1 for the latter and 'not sure' about the former. Another potential
abuse of the robustness principle at the horizon ...
+1 from me too. Makes the zone also slightly smaller when written down to disk.
grtz,
it would be consistent to always write numbers out; also easier to compare with dig output.
Writing new names can cause problems with parsing of zone by other tools.
for reading, understanding of entire set of IANA-regjstered mnemonics feels like a right thing.
"Be liberate in what you accept..."