Re: [dnsop] WG Last Call: draft-ietf-dnsop-ipv6-dns-issues-04.txt

[Ralph Droms <[e-mail]>]

Here are some comments on draft-ietf-dnsop-ipv6-dns-issues-04.txt.

- Ralph

=====

Substantive
-----------

Section 2.3, first paragraph: I don't understand the text in
parentheses; does "does not seem reasonable" mean that providing
reverse DNS information for Teredo is feasible or not?

Section 4.1: I don't think this section describes a problem or
scenario at all specific or dependent on IPv6.  Other sections of the
document explicitly avoid discussing issues that are not specific to
IPv6, so I don't think this section is necessary.

Section 5.2, first paragraph:  I think the current situation regarding
DNS resolver configuration would be more accurately reflected by the
following paragraphs:

   5.2 Obtaining a list of DNS Recursive Resolvers

     A host can be configured with a list of DNS recursive resolvers
     through the DHCPv6 "DNS Recursive Name Server" option [RFC3646].
     This option can be passed to a host through a subset of DHCPv6
     [draft-ietf-dhc-dhcpv6-stateless-04.txt].  Two alternative
     mechanisms are under consideration: the use of well-known
     addresses [21] and the use of Router Advertisements to convey the
     information [22].

     Note that a dual stack host need not use DNS over IPv6 to query
     IPv6 DNS records, which can be queried over IPv4 as well as IPv6.

   References 21 and 22 are both out of date (both drafts are currently
   at revision -01)

Section 6, last paragraph: I disagree that the problem of adding a
whole new name to a DNS zone is out-of-scope.  While it is technically
not specific to IPv6, I think that, because of SLAAC, hosts using IPv6
will be much more likely to add new names to a DNS zone than hosts
using IPv4.  In the case of IPv4, the names are much more likely to be
preconfigured or added by a DHCP server.

Section 6.2, first paragaph: If IP source address authentication is
not available or appropriate (why not?), is there a recommendation for
what should be used as an alternative?

Section 6.2, second paragraph: I don't think ths issue with
DHCP-initiated updates through DDNS is specific to IPv6.  This issue
is addressed in draft-ietf-dhc-fqdn-option-06.txt,
draft-ietf-dhc-ddns-resolution-06.txt, and
draft-ietf-dnsext-dhcid-rr-07.txt.

Section 6.4, fourth paragraph: Managing the TTL has no effect on stale
information unless the information about autoconfigured addresses is
somehow purged when the preferred lifetime for the address expires.
This is an issue that is more specific to IPv6 because it
is, I think, more likely that hosts using IPv6 will perform DDNS
updates rather than DHCP servers.  Note that the discussion in Baker,
et al., focuses on admin management of DNS TTLs, not management by the
individual hosts.

Section 7.1: Seems like this paragraph applies to IPv4 and IPv6
equally; as the issue is addressed in more detail elsewhere, perhaps
the entire section could be replaced with the reference to [29]?

Section 7.2: The use of wildcard records wasn't obvious to me at first
glance; perhaps an example would help?

Section 7.3: Is the problem for the reverse zone more difficult
because of the increased frequency of name insertions as opposed to
updates in the forward zone?  If the source IP address does not
provide sufficiently strong authentication, what can be used instead?

Section 7.4, first paragraph: Does this paragraph describe common
usage for DHCPv4 or DHCPv6?  Does it describe that the DHCP server
creates the PTR record at the same time it assigns the address, or
that all possibile PTR records are preconfigured in the DNS service?

Section 7.4, second paragraph: What is a "denser address assignment
policy"?  As we have little or no experience with address assignment
through DHCPv6, I think it is premature to anticipate how DHCPv6 will
be used.  I can imagine, for example, that DHCPv6 might be used to
assign addresses that look just like SLAAC addresses - the advantage
to the use of DHCPv6 being centralized registration and accounting for
addresses and devices.

Section 7.5: This section just didn't make any sense to me.  It could
use more detail and a couple of examples.  I can supply some text if
desired.

Editorial
---------

Section 5.1, next to last paragraph: add reference to RFC3315 for
DHCPv6.

Section 6.2, first paragraph: for clarity and precision, change last
sentence to:

    However, checking the IP source addresses for Dynamic DNS provides
    only minimal security, so the loss of this capability is not
    significant.

Section 7: for clarity and precision, change the sentence to:

    Updating the reverse DNS zone may be difficult because of the split
    authority over an address.

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