[Dnssec-deployment] DNSSEC for IPv4 multicast addresses
pk at ISOC.DE
Thu Jul 7 12:18:12 EDT 2011
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 22.214.171.124/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?
PS: the draft is in the MBONED wg of the IETF, so detailed discussion
would best happen there
More information about the Dnssec-deployment