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

[Mark Andrews <[e-mail]>]

In message <[e-mail]>, Ran Atkinson write
s:
> 
> On 09  Dec 2011, at 01:49 , Sheng Jiang wrote:
> > 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.
> 
> BIND is quite common with ISPs and content providers, 
> but Microsoft Server might well be the majority for 
> *enterprise* sites.  Since this document is focused 
> on renumbering situations, Microsoft Server's DNS 
> might well be the majority for the renumbering situation.
> 
> Unlike UNIX deployments of BIND, which stand alone, 
> Microsoft reportedly has fully integrated DNS with 
> other services (e.g. DHCP, Windows Work groups) inside 
> the Microsoft Windows Server.  
> 
> So reports say that there is no "flat file" with DNS entries.
> Reportedly, there is also no "loading of the DNS entries".  
> Instead, there is full integration of DNS with the 
> other services, and things are GUI-based and systemic
> for the whole deployment.
> 
> I'm told that Apple's MacOS X Server takes a very
> similar approach to Microsoft Windows Server, with
> integration and a GUI front-end for the whole deployment.
> Apple apparently does use BIND code behind-the-scenes,
> but system administrators never interact with BIND
> directly and again there are no "flat files" to load
> because everything is behind a common server GUI.
> 
> > We will contact Cricket Liu for the detail and
> > how common this is. We will update our text accordingly.
> 
> Why not start first by reading his book (which is quite clear) ?
> It is a published O'Reilly book and should be readily available.
> 
> According to the book, Microsoft Windows Server automatically
> enables Dynamic DNS Update between the Windows clients and
> the Windows server in a number of situations.  So deployment
> of Dynamic DNS UPdate is proportional to deployments of
> Microsoft Windows server, which ought to be pretty common
> in an enterprise scenario.

Windows uses GSS-TSIG to secure the updates.

Mac OS uses TSIG to secure the updates.  You turn it on via sharing
presumable as Apple decided that you only need this if you need to
reach the machine by name.

> >> 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.
> 
> I do not think that ignoring the issue or declaring it
> out-of-scope is a legitimate position to take for this
> document.
> 
> IETF rules require that ALL documents must fully address
> Security Considerations *within their own document*.
> 
> Ignoring that topic -- or shunting it off to other
> documents -- will result in a Last Call objection from me 
> and possibly others on the very solid technical grounds
> that the Security Considerations are known to be deficient.

With Windows you add the machine to the domain.  This is a
one off procedure and the last time I did it this it needed
a domain administrators password if my memory is correct.

Initial registration doesn't necessarially need to be standardised.
It can be ad-hoc.  Log into a web page and it can return a TSIG 
which is configured into the nameserver and the client machine.

That's done all the time to secure zone transfers.

What need to be standardised is what goes on the wire and that
was done years ago.  The rest really is implementation detail.

> >> 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.
> 
> I did.  It is not nearly clear enough.  
> 
> More text is needed -- and since it is a Security 
> Consideration it also needs to be referenced in the 
> Security Considerations section of the document.
> 
> Last, it is very very rude and offensive to take any 
> private email and post it to any public mailing list
> without prior permission of the author -- as you
> have done today.  
> 
> Yours,
> 
> Ran
> 
> _______________________________________________
> renum mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/renum
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: [phone]                 INTERNET: [e-mail]