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

From: David Meyer <[email-masked]>
Date: Tue, 23 Mar 2004 10:05:41 -0800

All,

[First, please excuse the previous note on this document (sent
too soon)] 

This is a WG Last Call (WGLC) for comments on "Operational
Considerations and Issues with IPv6 DNS", 
                
http://www.ietf.org/internet-drafts/draft-ietf-dnsop-ipv6-dns-issues-04.txt

Please review the document carefully, and send your feedback to
the list.  Please also indicate whether or not you believe that
this document is ready to go to the IESG for Informational.

The WGLC will end on Wednesday, 07 April 2004, at 1500 PST.

Thanks, 

Rob and Dave

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

---

From: Ralph Droms <[email-masked]>
Date: Wed, 24 Mar 2004 16:47:05 -0500

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.

.

---

From: Pekka Savola <[email-masked]>
Date: Thu, 25 Mar 2004 17:18:33 +0200 (EET)

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

> Substantive

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

>      addresses [21] and the use of Router Advertisements to convey the

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.

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

> 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>
 
> 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>
 
> draft-ietf-dnsext-dhcid-rr-07.txt.

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

> updates rather than DHCP servers.  

Yep.

> Note that the discussion in Baker,

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

> 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

Secure DDNS :-).
 
> 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.
 
> to the use of DHCPv6 being centralized registration and accounting for

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>

> use more detail and a couple of examples.  I can supply some text if

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>

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

OK.
 
>     only minimal security, so the loss of this capability is not

This was already changed, above.

>     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

.

---

From: "Eric A. Hall" <[email-masked]>
Date: Sat, 27 Mar 2004 15:59:53 -0600

> this document is ready to go to the IESG for Informational.

I disagree with the implication of section 4.5, but only mildly:

| 4.5 Behaviour of Glue in Mixed IPv4/IPv6 Environments
|
|  In the previous section, we discussed the effect of impartial data
|  returned from the caches when the TTLs are not kept the same.  Now,
|  we present another problem highlighted in the mixed IPv4/IPv6
|  environments.
|
|  Consider the case where the query is so long or the number of the
|  additional ("glue") records is so high that the response must either
|  be truncated (leading to a retry with TCP) or some of the additional
|  data removed from the reply.  Further, resource record sets are never
|  "broken up", so if a name has 4 A records and 5 AAAA records, you can
|  either return all 9, all 4 A records, all 5 AAAA records or nothing.
|
|  In the case of too much additional data, it might be tempting to not
|  return the AAAA records if the transport for DNS query was IPv4, or
|  not return the A records, if the transport was IPv6.  However, this
|  breaks the model of independence of DNS transport and resource
|  records, as noted in Section 1.2.
|
|  This temptation would have significant problems in multiple areas.
|  Remember that often the end-node, which will be using the records, is
|  not the same one as the node requesting them from the authorative DNS
|  server (or even a caching resolver).  So, whichever version the
|  requestor ("the middleman") uses makes no difference to the ultimate
|  user of the records.  This might result in e.g., inappropriately
|  returning A records to an IPv6-only node, going through a
|  translation, or opening up another IP-level session (e.g., a PDP
|  context [31]).

The "best" scenario is for additional-data associated with DNS-specific
RRs (such as NS RRs) to give preference to the current network type, and
for additional-data associated with application RRs (such as MX RRs) to
interleave a randomized subset of network type addresses.

Short of going into all of that, however, the default position should be
to favor the network type in use, since that is likely to be the network
type in use for followup queries. If the data is *really* important, it
will be explicitly requested anyway, so there is no loss no matter what.

-- 
Eric A. Hall                                        http://www.ehsco.com/
Internet Core Protocols          http://www.oreilly.com/catalog/coreprot/
.
dnsop resources:_____________________________________________________
web user interface: http://darkwing.uoregon.edu/~llynch/dnsop.html
mhonarc archive: http://darkwing.uoregon.edu/~llynch/dnsop/index.html

---

From: Peter Koch <[email-masked]>
Date: Mon, 29 Mar 2004 13:18:29 +0200

> |  additional ("glue") records is so high that the response must either

there's a difference between "glue" and "additional data". "glue" ist where the
data originates from and "additional data" is where it's carried in.

> |  data removed from the reply.  Further, resource record sets are never

Section 9 of RFC 2181 stronly recommends against setting the TC bit just if
the response couldn't be optimally populated. If there's legitimate glue, than
it's needed in the response. Everything else is just courtesy information.

> interleave a randomized subset of network type addresses.

What about not sending any of A or AAAA unless both RRSets fit or "glue"
is really necessary? That will add another round-trip, but the end system
can choose (of course prep'ing its closest cache for the TTL to come).

-Peter
.

---

From: "Eric A. Hall" <[email-masked]>
Date: Mon, 29 Mar 2004 08:20:55 -0600

On 3/29/2004 5:18 AM, Peter Koch wrote:

> What about not sending any of A or AAAA unless both RRSets fit or
> "glue" is really necessary? That will add another round-trip, but the
> end system can choose (of course prep'ing its closest cache for the TTL
> to come).

Omitting all additional-data is not helpful.

http://www.ietf.org/internet-drafts/draft-hall-qtype-addr-01.txt says:

|  4.1.    Truncated Additional-Data
|
|     In those cases where all of the A and AAAA resource records will
|     not fit within a response message, the responder MUST truncate the
|     message according to the following rules.
|
|     Incomplete resource record sets MUST NOT be provided. If this
|     means that only one or the other resource record types can be
|     provided as additional data, then only one of those resource
|     record sets are to be provided. Both resource record sets MAY be
|     omitted from the additional-data section if necessary or desired.
|
|     If a responder wishes to include one of the resource record sets
|     (and assuming that there is room in the response message for that
|     data), the responder SHOULD give a preference to the network type
|     which was used to transport the original query. For example, if
|     the original query was received over an IPv6 network interface,
|     the responder SHOULD give preference to the AAAA resource records
|     in the response message.

That's still the best strategy, IMO, since it prevents incomplete RRsets
from being transmitted and cached, and leans towards improving the DNS
navigation pointer data that is necessary to locate all other data.

In the case of other-application pointers (like MX addresses), it is far
better to omit the additional-data than it is to provide and cache
incomplete RRsets.

---

From: Peter Koch <[email-masked]>
Date: Mon, 29 Mar 2004 17:51:58 +0200

> Omitting all additional-data is not helpful.

could you elaborate, please? My intent was to shift the choice from the
server, who can guess at best, to the client or the resolver acting on
behalf of it, respectively.

Even the draft you cite

> better to omit the additional-data than it is to provide and cache

Incomplete RRSets are no option anyway.

-Peter
.