[Dnssec-deployment] DNSSEC for IPv4 multicast addresses

[Peter Koch]

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 239.192.0.0/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.

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?

-Peter

PS: the draft is in the MBONED wg of the IETF, so detailed discussion
    would best happen there