In message <20090310041105.ga4...@vacation.karoshi.com.>, bmann...@vacation.kar
oshi.com writes:
> On Tue, Mar 10, 2009 at 08:35:40AM +1100, Mark Andrews wrote:
> >
> > In message <200903091515.n29ffetp055...@stora.ogud.com>, Olafur Gudmundsson
> wri
> > tes:
> > > --===============0733757033==
> > > Content-Type: multipart/alternative;
> > > boundary="=====================_777355448==.ALT"
> > >
> > > --=====================_777355448==.ALT
> > > Content-Type: text/plain; charset="us-ascii"; format=flowed
> > >
> > > At 13:46 06/08/2008, Paul Hoffman wrote:
> > > >Greetings again. The end of section 2 of this document says:
> > > > Another advantage of configuring a trust anchor using a DS record is
> > > > that the entire hash of the public key in the DS RDATA need not
> > > > necessarily be specified. A validating resolver MAY support
> > > > configuration using a truncated DS hash value as a human-factors
> > > > convenience: shorter strings are easier to type and less prone to
> > > > error when entered manually. Even with a truncated hash configured,
> > > > a validating resolver can still verify that the corresponding DNSKEY
> > > > is present in the trust anchor zone's apex DNSKEY RRSet. RFC 2104
> > > > [RFC2104] offers guidance on acceptable truncation lengths.
> > > >
> > > >This is not correct. You cannot say "here is the SHA-256 hash of a
> > > >value" and then give less than 256 bits of the hash. If you wanted
> > > >to do this, you need to define the truncated hash and use that new
> > > >hash algorithm. So far, none of these truncated hashes have been
> > > >defined for DNSSEC, although ones could be defined.
> > > >
> > > >Further, it is somewhat optimistic (and possibly sadistic) to think
> > > >that a user can type Base64 by hand for more than maybe ten
> > > >characters. This document should assume that the user is using
> > > >copy-and-paste, and therefore using the full 256 bits of the hash is
> > > >just as easy as using a truncated hash. If not, new, inherently
> > >weaker, truncated hash algorithms need to be defined.
> > > >
> > > >--Paul Hoffman, Director
> > > >--VPN Consortium
> > > >_
> > >
> > > You are not the first person to bring this issue up, and upon reflection
> > > we have dropped truncation discussion.
> > >
> > > Olafur
> >
> > On a related issue DS -> DNSKEY translations cannot be
> > performed until the DNSKEY is published in the zone. The
> > use of DS prevents pre-publishing of keys.
> >
> > I can see no real reason to recommend that DS records be
> > published in preference to DNSKEY records.
> >
> > DNSKEY -> DS is a conversion that can be at anytime.
> >
> > This make DNSKEY a better manditory record to publish.
> >
> > Mark
> > --
> > Mark Andrews, ISC
> > 1 Seymour St., Dundas Valley, NSW 2117, Australia
> > PHONE: +61 2 9871 4742 INTERNET: mark_andr...@isc.org
> > _______________________________________________
> > DNSOP mailing list
> > DNSOP@ietf.org
> > https://www.ietf.org/mailman/listinfo/dnsop
>
>
> if the child produces the DS, then the TTL is preserved.
> if the parent produces the DS, then the TTL is not.
That depends on the processes used. There is no reason a
parent can't produce a DS with a specified TTL. There is
also no requirement for the parent to honour the ttl, if
any, passed to the parent.
> i'd think that would be a reason to use DS as the record to
> publish.
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: mark_andr...@isc.org
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
