On 2010-01-04 at 06:08 -0800, The IESG wrote:
> The IESG has received a request from an individual submitter to consider
> the following document:
>
> - 'Nameservers for IPv4 and IPv6 Reverse Zones '
> <draft-jabley-reverse-servers-01.txt> as a Proposed Standard
First an editorial nit, there's an arithmetic error. Then a security
nit.
The non-compressed representation of A.IP6-SERVERS.ARPA fills (1 + 1)
+ (10 + 1) + (4 + 1) + 1 = 19 bytes.
"IP6-SERVERS" is 11 characters long. The encoded sequence is 20 octets,
not 19.
This then leads into adjustments to the relevant table below, with
{A-F}.IP6-SERVERS.ARPA totalling 40 octets.
Security nit: the Security Considerations section states that there are
no new security considerations. This is false. Currently, five diverse
names control the top-level delegation and in the event of a major
dispute, the geopolitical diversity of the chosen names means that one
rogue actor can be partially inhibited by a split -- the same protection
that was afforded by the original choice of root nameserver operators.
The draft centralises the naming and thus the choice of delegation and
so creates a new privileged operator. Changing the delegation would no
longer require update to the NS glue in the ARPA zone; instead in
practice a change could be imposed by the operator, provided they can
live with inconsistent A/AAAA glue until the topic of dispute is no
longer disputed; given the complete control, this would almost certainly
be settled in favour of the de facto new state of affairs.
For the root zone, the actual NS records and glue used are widely spread
amongst resolvers, so the same hijack is infeasible. For the GTLD
servers, there's one central registry in any case. For the current
IN-ADDR.ARPA. servers, the root-servers.net values are used, which are
the same hosts for which there is a widespread dispersal of the current
correct IP addresses and for which change comes very slowly.
This draft represents a change in the threat boundaries for a unilateral
future power-grab over the reverse DNS. I'm not deliberately impugning
any of the current operators, ICANN or anyone else who reads this and is
offended; organisations can be replaced, 5, 20 or 50 years from now and
the centralised control remains. Postel's dispersion of control should
not be so readily undone piecemeal.
At the very least, surely this warrants discussion in the Security
Considerations?
Regards,
-Phil
_______________________________________________
Ietf mailing list
Ietf@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf