Subject: [dnsop] WGLC for draft-ietf-dnsop-ipv6-dns-issues-06.txt

From: David Meyer <[email-masked]>
Date: Wed, 28 Apr 2004 14:32:16 -0700

Folks,

This note starts the WG Last Call (WGLC) for comments on
draft-ietf-dnsop-ipv6-dns-issues-06.txt, "Operational
Considerations and Issues with IPv6 DNS". It can be found on

http://www.ietf.org/internet-drafts/draft-ietf-dnsop-ipv6-dns-issues-06.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.  

This WGLC will end on 12 May 2004 at 1500 PDT (UTC/GMT-7). 

Thanks,

Dave & Rob

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

---

From: Edward Lewis <[email-masked]>
Date: Thu, 29 Apr 2004 15:21:09 -0400

>http://www.ietf.org/internet-drafts/draft-ietf-dnsop-ipv6-dns-issues-06.txt

Section 1.3

Besides maintaining "at least one...IPv4", the section should also 
recommend making "at least one" available for IPv6 once v6 is 
available.  I think that would even it out.

I'd also like to see some statement regarding what happens when IPv4 
dies.  (Okay, y'all can stop laughing now.)  Maybe like "maintain v4 
until there's a recommendation to retire it.  This kind of issue (an 
exit strategy) seems to be quite often glossed over.  It's not that I 
want to see an exit strategy, but to at least mention in the document 
that a reader 15 years from now ought to be planning for one, whether 
it comes or not.

But to draw a finer and more sane point, DNS really isn't about 
servers, it's about zones.  I would recommend stating that each zone 
be made available authoritatively (master or slave) on each (v4, v6) 
transport.

Section 2.3

When you say "challenge" in the first paragraph, do you mean tedious or tricky?
I.e., is it just a pain because of the volume of octets or is it not 
straightforward?

Section 4.1

One pothole I stepped into falls roughly in this category.  I have a 
name server running on a section of network that is IPv4 only.  To 
bring the server's zones up on IPv6, I used another machine on a 
different section of network.  The A record for the name pointed to 
one machine, the AAAA to the other.  This works okay for DNS, but I 
had a problem when I did an "ssh" to the box.  Instead of winding up 
at the A box, I was on the AAAA box.  I nearly edited the wrong 
/etc/named.conf.

The recommendation is that, if you use service names in addition to 
host names, you only use the service names within the service 
mentioned.  And - use the host name when ssh'ing.

Top of page 17 (second line), grammer error:

"However, when stronger form of security is used"

-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                            +1-703-227-9854
ARIN Research Engineer

If time travel were ever to be realized, public key crypto is toast.
.
dnsop resources:_____________________________________________________
web user interface: http://darkwing.uoregon.edu/~llynch/dnsop.html
mhonarc archive: http://darkwing.uoregon.edu/~llynch/dnsop/index.html

---

From: Alain Durand <[email-masked]>
Date: Thu, 29 Apr 2004 13:14:50 -0700

> available.  I think that would even it out.

Actually, the whole section 1.2 and 1.3 are a repeat of  
draft-ietf-dnsop-ipv6-transport-guidelines-02
that is now in the RFCeditor queue, so we might as well delete those  
two sections and simply
point to the RFC to be.

	- Alain.

.

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Thu, 29 Apr 2004 23:59:07 +0200

On 29-apr-04, at 21:21, Edward Lewis wrote:

> dies.

How is v4 ever going to die when everyone is forced to keep running v4 
nameservers?

> (Okay, y'all can stop laughing now.)  Maybe like "maintain v4 until 
> there's a recommendation to retire it.  This kind of issue (an exit 
> strategy) seems to be quite often glossed over.  It's not that I want 
> to see an exit strategy, but to at least mention in the document that 
> a reader 15 years from now ought to be planning for one, whether it 
> comes or not.

I think we all agree that flag day approaches on a network that has the 
scale of the internet aren't going to fly. But in reality, requiring v4 
nameservers now and at some time reversing this and requiring v6 
nameservers instead is a flag day approach. As long as there is a 
single IPv6-holdout somewhere on the net, this isn't going to work.

The inevitable conclusion is that the only people who really know 
whether a zone should be served by IPv4 nameservers, IPv6 nameservers 
or both, are the people running that zone. So they should be the ones 
making this decision. Sure, some dire "without v4 servers bad things 
will happen" warnings are in order, but DNS administrators are supposed 
to be adults and as such have the inalienable right to make their own 
mistakes.

But I'm not in a hurry, all of this will work out in due course.

.

---

From: Edward Lewis <[email-masked]>
Date: Thu, 29 Apr 2004 22:34:32 -0400

The issue I'm picking on here is rather small.  Perhaps what I should 
suggest is wording that says "regardless of what is in a zone, there 
should be a server for it available on all network layers in common 
use."  "In common use" is to be left open to interpretation.
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                            +1-703-227-9854
ARIN Research Engineer

---

From: Pekka Savola <[email-masked]>
Date: Fri, 30 Apr 2004 09:41:40 +0300 (EEST)

Thanks for the feedback -- inline..

> Section 1.3
[on the summary of transport guidelines]

Omitted for now; please bring this up about the transport guidelines 
document, and let's then reflect that in here.

> I.e., is it just a pain because of the volume of octets or is it not 

It is not straightforward because the users who are using 6to4
probably don't have ISPs which would be willing to do anything to
provide delegation path delegation, so alternative means would have to
be used.

I reworded "challenge" to "not straightforward and pracically 
impossible".  Or would you suggest something else?
 
> mentioned.  And - use the host name when ssh'ing.

This seems so obvious to me that I'm having trouble figuring out how 
to put it :) .. but I added at the end of the second paragraph:

                          (Obviously, when wanting to reach
a specific node, one should use the hostname rather than a service 
name.)
 
> "However, when stronger form of security is used"

What was the error?  I added "a" in front of "stronger".  Not sure if 
that was it..

-- 
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: Pekka Savola <[email-masked]>
Date: Fri, 30 Apr 2004 09:30:28 +0300 (EEST)

> that is now in the RFCeditor queue, so we might as well delete those  

It's still in IETF Last Call, so would probably change.

Ed, can you suggest an appropriate change to the 
draft-ietf-dnsop-ipv6-transport-guidelines-02 and let's reflect that 
accordingly in draft-ietf-dnsop-ipv6-dns-issues-06.txt.

(IMHO, it's still worth keeping in a summary of
draft-ietf-dnsop-ipv6-transport-guidelines-02 in
draft-ietf-dnsop-ipv6-dns-issues-06.txt, because let's be honest -- an
average john doe isn't going to read it in any case :)

.

---

From: Edward Lewis <[email-masked]>
Date: Fri, 30 Apr 2004 10:20:39 -0400

>accordingly in draft-ietf-dnsop-ipv6-dns-issues-06.txt.

In another reply I had (part of) this, which I think is balanced as 
far as v4-v6, doesn't mandate "v4 forever", and is fuzzy enough to be 
re-interpreted later:

# Regardless of what is in a zone, there should be a server for it available
# on all network layers, e.g., IPv4 and IPv6, in common use.  A zone's contents
# should appear the same on all servers, hence, no matter what network layer
# used to query the servers, the contents of the answer is substantially the
# same.

"In common use" - means that even if you don't have a v4 
infrastructure anymore, you should consider asking someone with one 
to server your zones for you on a v4-enabled server.

"Substantially" - because of the glue question and the truncation 
issue in DNS, you can't specify that the answer "is" the same.

Another case to consider is the the query type any.  If my v4 
recursive server does not share the same memory (RAM) as my v6 
server, chances are strong that the caches in the two will differ 
over time.  QTYPE ANY queries ask for "what you have" about a name, 
not the complete data at the name (as far as an authoritative server 
is concerned).  It's reasonable to consider that the exact responses 
from the two servers will differ, regardless of the fact that they 
are on different network layers.

>average john doe isn't going to read it in any case :)

I've got the feeling I'm going to need to try again at the wording, 
I'm running up on a meeting deadline.
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                            +1-703-227-9854
ARIN Research Engineer

---

From: Alain Durand <[email-masked]>
Date: Fri, 30 Apr 2004 08:55:13 -0700

On Apr 30, 2004, at 7:20 AM, Edward Lewis wrote:

> infrastructure anymore, you should consider asking someone with one to 
> server your zones for you on a v4-enabled server.

I think this is already covered in the current text which does not say 
that you need to 'own' all DNS servers for your zone.

> recursive server does not share the same memory (RAM) as my v6 server, 
> chances are strong that the caches in the two will differ over time.  
> QTYPE ANY queries ask for "what you have" about a name, not the 
> complete data at the name (as far as an authoritative server is 
> concerned).  It's reasonable to consider that the exact responses from 
> the two servers will differ, regardless of the fact that they are on 
> different network layers.

Thank you for this clarification I now understand you point.  We might 
want to add text that only focus on those issues.
This is an operational issue that is somehow different from the one 
described in the transport guideline document.
I think it should go into the ipv6-dns-issues document, which is the 
one you commented on first,
so I withdraw my previous comment.

	- Alain.

.