[Dnssec-deployment] DNSSEC for IPv4 multicast addresses
marka at isc.org
Thu Jul 7 18:36:59 EDT 2011
In message <20110707161812.GW10707 at x27.adm.denic.de>, Peter Koch writes:
> On Thu, Jul 07, 2011 at 01:55:51PM +0100, Chris Thompson wrote:
> > The zones are actually empty except for 224.in-addr.arpa (which has
> > 177 PTRs with names in mcast.net - also ICANN's, and also signed).
> ICANN/IANA staff was so kind to implement what is described in
> <draft-ietf-mboned-mcast-arpa-03.txt>, which was only recently revived.
> > It occurs to me that there could be a problem in connection with
> > 239.in-addr.arpa. We have some organisationally scoped addresses
> > allocated from 184.108.40.206/14 (per RFC 2365), although I have never
> > got around to setting up reverse lookup for them. But if we did, then
> > I think we might now get into the same trouble as when the RFC 1918
> > reverse zones [16-31].172.in-addr.arpa & 168.192.in-addr.arpa lost
> > their (DS-less) delegations to blackhole-*.iana.org for a while earlier
> > this year. Using "type forward", "type stub" or "type static-stub"
> > for them in a validating BIND configuration failed because it could
> > not prove them unsigned.
> What is your alternative suggestion? 239/8 is administratively scoped,
> so the mapping will always be ambiguous. However, a delegation to AS112 or
> a similar project hasn't been felt necessary and the nature of AS112
> is what makes signing 10/8 (et al) reverse infeasible.
Just a unsigned delegations back to the same servers for the /16's which
make up the /14 would do.
> When you are using 239/8 reverse you either sign it and provide your
> own trust anchor or you teach the resolver (hear hear) that 239/8 is
> provably insecure. Do people feel that making 239/8 reverse provably
> insecure globally would be really preferrable?
> PS: the draft is in the MBONED wg of the IETF, so detailed discussion
> would best happen there
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: marka at isc.org
More information about the Dnssec-deployment