Re: [renum] draft-liu-6renum-gap-analysis-03

[Sheng Jiang <[e-mail]>]

Hi, Ran,

Thanks for your comments. They are quite helpful. See our replies in lines.

Sheng & Bing

> -----Original Message-----
> From: Ran Atkinson [mailto:[e-mail]]
> Sent: Friday, December 09, 2011 12:20 AM
> To: Brian E Carpenter
> Cc: Sheng Jiang; Randall Atkinson
> Subject: draft-liu-6renum-gap-analysis-03
> 
> Hi,
> 
> 
> The above I-D in part says in Section 6.1:
> > For DNS records update, most sites will achieve it by
> > maintaining a DNS zone file and loading this file into the
> > site's DNS server(s).  Synchronization between host renumbering
> > and the updating of its A6 or AAAA record is hard. [RFC5887]
> > mentioned that an alternative is to use Secure Dynamic DNS
> > Update [RFC3007], in which a host informs its own DNS server
> > when it receives a new address.
> 
> That description is really only true for sites that
> are using BIND as their DNS server on a UNIX server,
> including Linux.
> 
> That description, however, is NOT accurate for the
> many sites that are using a Microsoft Windows Server
> for their DNS service or are using an Apple MacOS X
> Server for their DNS service.  Many many enterprises
> use the Microsoft Windows Server for their DNS services;
> a smaller number, but still a non-trivial number,
> are using the Apple MacOS X Server for their DNS
> service.
> 
> So the quoted text above is NOT *generally* true,
> and ought to be edited and corrected either to cover
> the several different deployment models or to provide
> a description that is generally true.

Yes, our statement above is mainly based on BIND implementations. We think most of DNS servers are BIND-based, 80% and above (unverified estimation). So, Bind itself is the majority.

We do not have much knowledge for Microsoft DNS or Apple DNS. Could you point out the details how they are different from our description? If the differences are magnificent, we'd like to update our description. :)
 
> > Secure Dynamic DNS Update has been widely supported by the major
> > DNS systems, but it hasn't been widely deployed, especially in
> > the host. Current practices mainly involve the DHCP servers
> > which act as clients to request the DNS server to update
> > relevant records. Normal hosts are not suitable to do this
> > mainly because of the complexity of key management issues
> > inherited from secure DNS mechanisms.
> 
> Cricket Liu appears to disagree about the deployment claim
> above.  His O'Reilly book "DNS & BIND" reports that Microsoft
> Windows server will silently (i.e. no human involved)
> ENABLE Dynamic DNS Update in a number of situations
> (e.g. when that server has both DHCP and DNS services
> enabled or when "Active Directory" (sic) is enabled).
> 
> The combination of Microsoft Server (with DHCP and DNS
> services enabled or "Active Directory" (sic) enabled)
> with a set of Microsoft Windows clients actually is
> quite common around the world in enterprise networks.
> 
> So the claim that Secure Dynamic DNS Update is not widely
> deployed seems incorrect -- primarily because many sites
> have deployed it without realising they have done so.
> 
> I would urge that the quoted text above be edited
> with respect to that claim.

We will contact Cricket Liu for the detail (do you have his email address?) and how common this is. We will update our text accordingly.
 
> In Section 10, the above draft in part says:
> > In the LAN, Secure DHCPv6 ([I-D.ietf-dhc-secure-dhcpv6]) or
> > SeND ([RFC3971], Secure Neighbor Discovery) deployment
> > may need to validate prefixes.
> 
> 
> If one thinks that configuring keys for Secure Dynamic
> DNS Update is difficult or challenging, then it is
> unavoidable to conclude that neither Secure DHCPv6
> nor SEND are actually deployable at present.
> 
> I think the problems with key management deserve their
> own subsection in Section 10 -- as a category of "gap"
> that ought to be addressed.  That new subsection ought
> to note the operational issues with key provisioning
> and key management for Secure Dynamic DNS Update
> (at least for non-MS nodes) and equally or more so
> for Secure DHCPv6 and SEND.  One would hope these
> would not fall into the "unsolvable gap" category,
> but in any event these gaps do need to be clearly
> documented.

The key management is a complicated issue. It is worth a separated draft. It is relevant. However, we don't think it is a renumbering specific issue. We will add some new text for it. But we would like to leave it out of scope.
 
> Similarly, there is a practical operational "gap" in
> that we have no way to automatically update ACLs during
> a renumbering event.  This also needs to be documented
> as a gap.

We did list ACL as part of filter, see Section 6.3.

Best regards,

Sheng
 
> Yours,
> 
> Ran