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

From: Pekka Savola <[email-masked]>
Date: Sun, 16 Mar 2003 14:05:56 +0200 (EET)

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 <[email-masked]>.

---

From: Måns Nilsson <[email-masked]>
Date: Mon, 17 Mar 2003 15:34:01 +0100

> a protocol concern, but not really an operational one as far as I can see.

But handing out a reverse answer is sometimes a performance boost, keeping
old broken (but v6-aware) servers from timing out on a DNS reverse query. 
Sounds operational to me. 

-- 
Måns Nilsson            Systems Specialist
+46 70 681 7204         KTHNOC  MN1334-RIPE

We're sysadmins. To us, data is a protocol-overhead.

---

From: Pekka Savola <[email-masked]>
Date: Mon, 17 Mar 2003 18:12:39 +0200 (EET)

> Sounds operational to me. 

I agree with you on this aspect of operational.

I should have been more verbose.

What I was mainly referring to was the argument why a wildcard reverse DNS 
would not cut it: it doesn't work with DNSsec, or that it's operationally 
"evil".

My counter-argument are that:
 1) DNSsec is unnecessary, even dangerous, with dummy records which have 
no security properties.  If those *were* securable, people would just 
misuse them.  Remember, we're discussing something with a poiinter to
a.b.c.d.dynrev.arpa or a.b.c.d.foo.com, where a.b.c.d is the IP address.
(PTR to bar.foo.com would be different, but *real* population of reverse 
records was an entirely differnet issue.)

 2) operators who don't provide reverse-IP records, or don't delegate 
them, can be considered evil anyway.  They're lazy/pragmatic/what have 
you; you just have to pick between two evils, and a wildcard one may be a 
lesser one (but this probably should be analyzed a bit more).

---

From: Mans Nilsson <[email-masked]>
Date: Mon, 17 Mar 2003 17:56:26 +0100

> I agree with you on this aspect of operational.

Good. 
 
> would not cut it: it doesn't work with DNSsec, or that it's operationally 

I think we agree here too. There should be a report on wildcard and
DNSSEC interaction from the pre-IETF workshop soon, at a dnsop
meeting mear here ;-)
 
+46 70 681 7204         KTHNOC
                        MN1334-RIPE

Where's the Coke machine?  Tell me a joke!!
#----------------------------------------------------------------------
# To unsubscribe, send a message to <[email-masked]>.