comments on -ietf-dnsop-ipv6-dns-issues-02

[Pekka Savola <pekkas@netcore.fi>]

Hi,

A few comments on dnsop-ipv6-dns-issues.

non-editorial
-------------

Abstract

   This memo summarizes DNS related issues when transitioning a network
   to IPv6. Consensus and open issues are presented.

==> note: it is very, very dangerous to say "Consensus and open issues" when
they aren't clearly separated in the text.  There certainly is consensus for
some issues, but certainly not all..

   This rules out IPv6-only recursive DNS servers and DNS zones served
   only by IPv6-only DNS servers. This approach could be revisited
   if/when translation techniques between IPv4 and IPv6 were to be
   widely deployed.

==> recursive v6-only servers could also recurse from dualstack recursive
servers, right?  As long as the recursive DNS server chain leads to a
non-recursive dual-stack server, the first point is moot.  (Performance,
reliability, etc. are another issues entirely :-).

   As the number of possible PTR records would be huge (2^80) for a /48
   prefix, a possible solution would be to use wildcards entries like:

      *.0.1.2.3.4.5.6.7.8.9.a.b.c.ip6.arpa. IN PTR customer-42.local-
      ISP.net

==> note: that reverse entry corresponds to a /52, not /48.

9. Security considerations

   Using wildcard DNS records in the reverse path tree may have some
   implication when used in conjunction with DNSsec.  Security
   considerations for referenced documents are described in those memos
   and are not replicated here.

==> one might note that in the case of reverse DNS lookup where a wildcard
would be returned (the lazy/pragmatic ISP scenario), the result would be
worthless anyway (ie. not useful as a security mechanism).  So this may be
a protocol concern, but not really an operational one as far as I can see.

mostly editorial
----------------

Status of this memo

   This memo provides information to the Internet community. It does not
   specify an Internet standard of any kind. This memo is in full
   conformance with all provisions of Section 10 of RFC2026

==> nontypical boilerplate ordering.

   expected to have several addresses with different scopes. [ADDRSELEC]
   recommends to use the lowest possible scope possible for
==> s/possible for/for/ (seems mostly redundant)

3.3 Reverse path DNS for site local addresses.
==> the section titles should be mostly uppercase, no periods necessary


   may require cooperation from the upstream IPSs. The problem here is
==> s/IPS/ISP/

   that, especially in the case of home usage of 6to4, the entity being
   delegated the x.y.z.t.2.0.0.2.ip6.arpa. zone (the ISP) may not be the

==> better use x.x.y.y.z.z.t.t.2.0.0.2.ip6.arpa ?


10. Author addresses
==> s/Author/Authors'/

11. References
==> split refs, put the authors (surname, initial) first

   [RFC1918] Address Allocation for Private Internets. Y. Rekhter, B.
             Moskowitz, D. Karrenberg, G. J. de Groot, E. Lear. February
             1996.

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

#----------------------------------------------------------------------
# To unsubscribe, send a message to <dnsop-request@cafax.se>.