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

[Pekka Savola <[e-mail]>]

Thank a lot for very good comments, Ralph -- thoughts and new text
inline.

For up-to-date copies, see:
http://www.netcore.fi/pekkas/ietf/temp/draft-ietf-dnsop-ipv6-dns-issues-05pre.txt
http://www.netcore.fi/pekkas/ietf/temp/draft-ietf-dnsop-ipv6-dns-issues-05pre-diff.html

On Wed, 24 Mar 2004, Ralph Droms wrote:
> 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?

It means that reverses don't seem feasible.  That's because of the 
brittleness of the UDP mappings at the NAT box: they're likely to 
change more often than e.g. IPv4 addresses on which you base your 6to4 
address.

Tried to clarify:

[...] Note that similar difficulties don't surface with the other
automatic tunneling mechanisms. In particular, providing reverse DNS
information for <xref target="I-D.huitema-v6ops-teredo">Teredo</xref>
hosts does not seem feasible; the IPv6 address is based on the IPv4
address and UDP port of the current NAT mapping which is likely to be
relatively short-lived.</t>
 
> 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.

This is described mainly as background for sections 4.2 and 4.3, and
seems appropriate for better management disjunct A/AAAA records for a
name.

I've added a clarifying note in the first paragraph:

This operational technique is not specific to IPv6, but required to
understand the considerations described in <xref
target="separate_vs_same"/> and <xref target="premature1"/>.

> 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].

This seems to give too much weight to the DHCPv6 solution, and I do
not want to go to that debate here.

However, I added a reference to RFC3646 just to make sure the reader 
is aware of it.

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

Made that:

        <t>Note that IPv6 DNS resolver discovery is not required for
dual-stack nodes in dual-stack networks as IPv6 DNS records can be
queried over IPv4 as well as IPv6.</t>

(It seems important to point the discovery part in this.) 

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

Note that this paragraph is about *forward* DNS updates.  Adding new 
forward zones is a manual process even today w/ IPv4.  (Reverses are 
an entirely different ballgame.)

I totally agree that it's not out of scope.  It's just a much more 
difficult problem, which is out of scope for *this* document.  
Clarified by making it:

        <t>A more complex form of DNS updates -- adding a whole new
name into a DNS zone, instead of updating an existing name -- is
considered out of scope for this memo.  Adding a new name in the
forward zone is a problem which is still being explored with IPv4, and
IPv6 does not seem to add much new in that area.</t>
 
> 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?

Secure DDNS updates -- [26].  It's not appropriate in SLAAC at least, 
and as it's too weak form of authentication in any case, it should 
never be relied on.  I'm not sure if the new DNSSEC architecture 
brings anything new to this picture; probably not.

Clarified:

[...] The only (minor) twist is that with SLAAC, the DNS server cannot
tie the authentication of the user to the IP address, and stronger
mechanisms must be used <xref target="RFC3007"/>.  As relying on IP
addresses for Dynamic DNS is rather insecure at best, stronger
authentication should always be used; however, this requires that the
authorization keying will be explicitly configured using 
unspecified operational methods.</t>
 
> 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.

It's there for completeness; thanks for the pointers, I'm adding them 
in the document.
 
> 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.

True.  Clarified:

<t>Care should be observed when updating the addresses not to use
longer TTLs for addresses than are preferred lifetimes for the
autoconfigured addresses, so that if the node is renumbered in a
managed fashion, the amount of stale DNS information is kept to the
minimum. That is, if the preferred lifetime of an address expires, the
TTL of the record needs be modified unless it was already done before
the expiration. [...]


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

Yep.

> Note that the discussion in Baker,
> et al., focuses on admin management of DNS TTLs, not management by the
> individual hosts.

Right, clarified:

 Some discussion on how an administrator could manage the DNS TTL is
included in <xref target="I-D.baker-ipv6-renumber-procedure"/>; this
could be applied to (smart) hosts as well.</t>
 
> 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]?

It has been requested to include some discussion about this in the
memo, so that people wouldn't automatically start to think that
(requiring) reverse DNS is a good idea, so I'm reluctant to trim it
down like that.  (This is basically just trying to give a summary of 
the situation.)
 
> Section 7.2: The use of wildcard records wasn't obvious to me at first
> glance; perhaps an example would help?

OK, added:

As a concrete example, a site (or the site's ISP) could configure
the reverses of the prefix 2001:db8:f00::/48 to point to one name
using a wildcard record like "*.0.0.f.0.8.b.d.0.1.0.0.2.ip6.arpa. IN
PTR site.example.com."

> 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?  

I do not think the frequency is an issue (but it does bring out the 
need for janitorial process as mentioned in the section).

It's more difficult because if you want to update your forward DNS 
name, you know what it is, and can be assumed to have at least *SOME* 
kind of association with that name (and the administrator of that 
name).

On the other hand, with reverses, you can't assume that. (E.g., if you 
roam somewhere, e.g. WLAN hotspot).

However, reverse-based mechanisms are *easier* in a sense because you 
can authorize the hosts to make the updates (if you want to trust them 
to do it, that is -- some certainly don't).  I.e., there is clear 
connection between the updater and the record (which is not clear with 
forward DNS).

So, it's both more difficult and easier.

... reworded the start of the section to:

        <t>Dynamic DNS with SLAAC simpler than forward DNS updates in
some regard, while being more difficult in another.</t>
        <t>The address space administrator decides whether the hosts
are trusted to update their reverse DNS records or not.  If they are,
a simple address-based authorization is typically sufficient (i.e.,
check that the DNS update is done from the same IP address as the
record being updated);  stronger security can also be used <xref
target="RFC3007"/>.  If they aren't allowed to update the reverses, no
update can occur.</t>
        <t>Address-based authorization is simpler with reverse DNS (as
there is a connection between the record and the address) than with
forward DNS.  However, when stronger form of security is used, forward
DNS updates are simpler to manage because the host knows the record
it's updating, and can be assumed to have an association with the
domain. Note that the user may roam to different networks, and does
not necessarily have any association with the owner of that address
space -- so, assuming stronger form of authorization for reverse DNS
updates than an address association is generally unfeasible.</t>

> If the source IP address does not
> provide sufficiently strong authentication, what can be used instead?

Secure DDNS :-).
 
> 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?

It describes what I believe is common usage for DHCPv4, and would 
likely be common for DHCPv6 as well.  All the records would be 
preconfigured.

Is this a realistic assumption -- you probably disagree? :-)

Clarified to:

All of these mappings are pre-configured, and require no updating.
 
> 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.

Well -- looking at those that seem to want to use DHCPv6, their main
point appears to continue doing what they're doing with v4.  The
logical conclusion of that is that using relatively dense allocations
(though not necessarily every address sequentially, until running out,
as with v4) is something they're familiar with and want to go on 
doing.

But as said, it's difficult to know that.  But we have to say 
something :-).

I softened this a bit, to:

        <t>If a more explicit control is required, similar
considerations as with SLAAC apply, except for the fact that typically
one must update a reverse DNS record instead of inserting one (if a
denser address assignment policy than with SLAAC is adopted) and
updating a record seems like a slightly more difficult thing to
secure. However, it is yet uncertain how DHCPv6 is going to be used
for address assignment.</t>

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

It was indeed rather confusing.  I've straightened it out a bit.  
Suggestions are still welcome, of course...

        <t>In cases where a prefix, instead of an address, is being
used and updated, one should consider what is the location of the
server where DDNS updates are made. That is, whether the DNS server is
managed by the same entity as the prefix delegator, at the site where
the prefixes are delegated, or elsewhere (which is typically
equivalent to the latter).</t>
        <t>On one hand, securing the DDNS relationship for prefix
delegation is simpler if DNS server and the prefix delegator are in
the same administrative domain, and may be more difficult
otherwise.</t>
        <t>On the other hand, if the DNS server resides where the
prefixes are delegated to, it is easier to manage reverse DNS updates
as they can be done within a single administrative entity.  
Similarly, then configuring the reverse DNS is typically simpler as
well (e.g., if one wanted to insert a wildcard record).</t>

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

OK.
 
> 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.

This was already changed, above.

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

Great.

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings




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