[dnsop] Re: WGLC for draft-huston-6to4-reverse-dns-04.txt

[Peter Koch <[e-mail]>]

> draft an committed to a review, the WGLC will be extended and shall end
> 
> 	Friday, 2006-04-07 24:00 UTC

/* no hats, still not contributing to the 'head count' */

some comments inline, some nit comments will go directly to the author.

>    using provider-based IPv4 addresses.  In the IPv4 "in-addr.arpa"
>    domain the local site would have an entry in the upstream's reverse
>    DNS zone file, or would have authoritative local name servers that
>    are delegated from the upstream's DNS zone.  In the case of the

not necessarily the upstream, but also RIRs (maybe even NIRs)

> 4.  Delegation Administration
[...]
>    The zone files containing the end site delegations are proposed to be
>    operated with a TTL (configured to be a time value in the scale of

with a _low_ TTL?

[...]

>    The delegation system is proposed to be self-driven by clients
>    residing within 6to4 networks.  The server's delegation function is

Which server's? Suggest to explicitly say 'web server' or similar to avoid
confusion with name servers.

[...]

>    allowing the client to enter the details of a number of DNS servers
>    for the corresponding reverse domain.  The delegation servers are
>    checked by the delegation manager to ensure that they are responding,

"delegation servers" => "targets of the delegation"

Are they checked via both v4 and v6, where applicable?

[...]

>    Scenarios that would motivate this concern would include situations
>    when the IPv4 provider is also offering an IPv6 service, and native
>    IPv6 should be deployed instead of 6to4.  In such circumstances the
>    2002 zone operator should allow for such a delegation blocking
>    function upon application to the delegation zone operator.

Is this function actually available? Who is to block and what?

>    For a delegation to be undertaken the following must hold:
>    o  The 6to4 site must have connectivity to the global IPv6 network
>    o  The 6to4 site must have configured a minimum of one primary and
>       one secondary server for the 6to4 IPv6 reverse address zone.
>    o  At the time of the delegation request, the primary and secondary
>       servers should be online, reachable, correctly configured, and in

s/should/must/ because of the above "must".

>       a mutually consistent state with respect to the 6to4 reverse zone.

What does "mutually consistent" mean? Same SOA-RR, same SOA# or also consistent
NS RRSets?

>    The management system also undertakes a periodic sweep of all active
>    delegations, so that each delegation is checked every 30 days.  If
>    the delegation fails this integrity check the email contact point is
>    informed of the problem, and a further check scheduled in a further
>    14 days.  If this second check fails, the delegation is automatically
>    removed, and a further notice is issued to the contact point.

What checks, if any, are applied to those delegation changes submitted
via DNS Dynamic Updates?
What's the reason for the web interface?
Is there a special "undelegate" request -- or should that happen via dynupd?

[Just curious, are there any stats on automated undelegations?]

> 5.  Security Considerations

>    Address-based authentication is not useful in a security sense.
>    Accordingly, reverse delegation information does not provide useful
>    information in either validating a domain name or in validating an IP
>    address, and that no conclusions should be drawn from the presence or
>    otherwise of a reverse mapping for any IP address.

Olaf already mentioned it -- this wording collides with the 'Encouraging
IN-ADDR' draft. Also, although the reverse mapping should not be used for
authentication, it might still be. We need to find some words that express
that the actual value of this particular reverse mapping is low and thus
this pragmatic approach is considered sufficient.
It might actually help to require that at least one of the name servers
actually has an address within the address space under consideration.
With the consistency requirements it's then not sufficient to spoof
DynUpd packets' source addresses, the attacker would also have to redirect
the probes to his systems.

> 7.  References

The references need to be split into normative/informative and RFCs 1034
and 1035 as well as the v6 addressing architecture and the IP6.arpa documents
should be added.

-Peter
.
dnsop resources:_____________________________________________________
web user interface: http://darkwing.uoregon.edu/~llynch/dnsop.html
mhonarc archive: http://darkwing.uoregon.edu/~llynch/dnsop/index.html