[dnsop] thoughts about dnsop-ipv6-dns-issues document (fwd)

[Pekka Savola <pekkas@netcore.fi>]

FYI,

As concerns were raised whether DNS operational issues have been
considered well enough, and some generic work would be needed, the
following what I proposed as a tentative outline for the document.

Any omissions?  Thoughts?  Comments?

---------- Forwarded message ----------
Date: Thu, 20 Nov 2003 13:00:26 +0200 (EET)
From: Pekka Savola <pekkas@netcore.fi>
To: dnsop@cafax.se
Subject: [dnsop] thoughts about dnsop-ipv6-dns-issues document

Hi,

I had some conversation with Rob and Alain on how I felt 
draft-ietf-dnsop-ipv6-dns-issues-xx document (or something else) 
should be updated.  I've included a possible ToC below (note that it 
has been updated based on Rob's comments below).

I'd think that the document could, in many cases, just summarize and 
point to issues described in other documents, but might be useful as a 
place to bring together the issues and considerations that should be 
considered by DNS folks.

Feedback, ideas, etc. welcome!

NEW
===

Operational Considerations and Issues with IPv6 DNS

1. Introduction
1.1. Representing IPv6 addresses in DNS records
1.2. Difference of IPv6 DNS Transport and DNS Records
1.3. Avoiding IPv4/IPv6 Name Space Fragmentation
1.4. <something else, basic stuff>

3. DNS Considerations about Special IPv6 Addresses
3.1. Limited-scope addresses
3.2. Privacy (RFC3041) addresses
3.3. 6to4 addresses
  * other transmech's (e.g. teredo, isatap) don't require 
    special considerations

4. Observed DNS Implementation Misbehaviour
4.1. Misbehaviour of DNS servers and load-balancers
4.1.1. Against AAAA
 * (just summary and a pointer)
4.2. Misbehaviour of DNS resolvers

5. Recommendations for Service Provisioning using DNS
5.1. Use of Service Names instead of Node Names
5.2. Adding the Records only when Fully IPv6-enabled
5.2.1. Consequences of Poor IPv6 Performance
5.3. IPv6 Transport Guidelines for DNS servers
  * (just summary and a pointer)

6. Recommendations for DNS Resolver IPv6 Support
6.1. DNS Lookups May Query IPv6 Records Prematurely
6.1.1. Increased Latency
6.1.2. Address Selection with Multiple Addresses
6.2. Recursive DNS Server Discovery
6.3. IPv6 Transport Guidelines for Resolvers
  * (just summary and a pointer)

7. Considerations about Forward DNS Updating
7.1. Manual or Custom DNS updates
7.2. DDNS with Stateless Address Autoconfiguration
7.3. DDNS with DHCP
7.4. DDNS with Dynamic Prefix Delegation

8. Considerations about Reverse DNS Updating
8.1. Applicability of Reverse DNS
8.2. Manual or Custom DNS updates
8.2.1. Reverse DNS with Wildcard Records
8.3. DDNS with Stateless Address Autoconfiguration
8.4. DDNS with DHCP
8.5. DDNS with Dynamic Prefix Delegation

9. Miscellaneous DNS Considerations
9.1. NAT-PT with DNS-ALG
9.2. Renumbering Procedures
9.2.1. Applications Using Addresses Beyond Their TTL

Appendix A: Site-local Addressing considerations for DNS


OLD
===
IPv6 DNS transition issues

1. Representing IPv6 addresses in DNS records
2. IPv4/IPv6 name space
2.1 Terminology
2.2. Introduction to the problem of name space fragmentation:
2.3 Policy based avoidance of name space fragmentation.
3. Local Scope addresses.
3.1 Link local addresses
3.2 Site local addresses
3.3 Reverse path DNS for site local addresses.
4. Automatic population of the Reverse path DNS
5. Privacy extension addresses
6. 6to4
7. Recursive DNS server discovery
8.  DNSsec


On Wed, 19 Nov 2003, Rob Austein wrote:
> a) you should include my co-chair in this discussion.  you might even
>    want to ask the wg, this being a wg project :)

Ok, will send.
 
> b) current doc duplicates some text in the transport guidelines doc
>    (more precisely: transport guidelines started out as a separate
>    doc, which was merged into this one, then extracted from this one,
>    but the merged text is still present, so the merged text needs to
>    be removed).
> 
>    am not sure to what extent the doc you're proposing would need to
>    talk about the transport guidelines stuff given the existance of
>    the separate doc.  summary and pointer, perhaps.

I was thinking of summary and pointer.
 
> c) 6to4 addresss => ipv6 addresses containing embedded ipv4 stuff ?
>    ie, not just 6to4, also terado.  subsections on each ok.   others?
>    given that terado has already shipped, we probably can't ignore it,
>    this is operations, we deal with what's there, not with what we
>    wish were there.

6to4 is a special case because it embeds the network.  Just embedding 
the host address might also be fine, but ISATAP is the only thing that 
does that, and it's not interesting from this point of view.

Teredo identifies host *and* a UDP port.  So teredo is not useful for
this context.
 
> d) section (5) seems to beg for a corresponding section about
>    misbehaving resolvers viewed from the name server side.  this
>    overlaps with existing work (the larson/barber doc).   some
>    question of the degree to which either of these is really ipv6
>    specific, see ongoing mailing list discussion.

yep, but as these seem to bite you really hard with v6, I think they 
deserve to be mentioned explicitly.
 
>    might end up as another case of a seperate document (or documents)
>    with summary and pointer in this document.

yep.
 
> e) having some serious thought about dynamic update is very good.
>    don't want to tie it too closely to the reverse tree population
>    thing, since that's basicly an implementation botch in existing
>    software (an annoying one, to be sure, but we already know what the
>    long term fix is -- update all the whacky software that breaks when
>    there's no reverse tree -- no matter what else is going on,
>    breaking when the reverse tree isn't present is just plain wrong,
>    no matter how many os vendors have been shipping code that does
>    that for how many years).

Agreed, I was first thinking of separating forward/reverse updates, 
but there would probably have been overlap.  Maybe it would make 
sense because the problem spaces may be vastly different..
 
>    so anyway: am not sure whether this outline covers the update
>    space, but am very glad to see a start at it.  update in the
>    presence of dhcp address assignment is pretty much a no brainer.

yep

>    update in the case of stateless addrconf is hard because it's very
>    unclear who "owns" the addresses -- one can locate the name server
>    that owns the dns subtree corresponding to the prefix, but the
>    trust model between that server and the entity that's using an
>    address is very shakey.  the send wg's work might help here.

yep
 


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