Table of Contents
Advertisement
qip-syncexternal CLI command (that is, the Polling method). The former is discussed in
detail in Solution 1 on page 5; the latter is discussed in Solution 2 on page 12.
DNS data security needs
The DNS and DHCP design needs to ensure that the data gets into DNS, but that criti-
cal resource records don't get deleted or overwritten with incorrect information from
unauthorized sources. With a classical VitalQIP design, this is simple matter of VitalQIP
administrator rights, but it is more complicated once dynamic updates are involved. This
can be handled by an Access-Control List for allow-update (discussed in detail in Solu-
tion 1), or by GSS-TSIG secure updates (discussed in detail in Solution 2). In brief, either
security system will prevent DHCP clients from accidentally "hijacking" the hostnames of
critical systems in DNS; for example preventing a user's computer named "www" from
replacing the corporate web server. Hackers who do address spoofing can circumvent
Access Control Lists, but not GSS-TSIG secure updates. On the other hand, GSS-TSIG
secure updates are far more complicated to implement and administer. Also, though they
are interoperable, there are some differences between Alcatel-Lucent's implementation
of secure updates and Microsoft's. These will be discussed in more detail in later sec-
tions.
I
mplementation of special underscore domains in VitalQIP
As mentioned in "SRV records and special underscore domains" above, Microsoft net-
working uses special child domains with names that start with underscores. You should
see which of these are required for your particular implementation, and consider defin-
ing them as separate domains within VitalQIP. Then you can assign the appropriate
primary and secondary DNS servers to them, and set up the allowupdate permissions
with an Access Control List (ACL) that includes the VitalQIP Enterprise servers, VitalQIP
administrators, and also Domain Controllers. Defining the underscore zones as separate
domains rather than just dotted hostnames within the parent domain allows better secu-
rity – the domain controllers need to have allow-update permissions to the underscore
zones but not necessarily to the parent zones. For example, "_ldap._tcp.example.com"
might be considered as the "_ldap._tcp" dotted hostname in the "example.com" domain,
or as "_ldap" in the "_tcp.example.com" domain. In addition, defining the underscore
domains as separate from the parents allows more efficient data transfer from DNS to
VitalQIP.
DHCP clients in child domains
You might also wish to define a "DHCP" sub-domain to hold only the DHCP clients in
that sub-domain. In this way, the Windows 2003 clients can be allowed to put their host-
names into DNS without fear of hijacking the hostnames of critical servers in the parent
domain. For example, you can allow updates from any client to the child domain "dhcp.
example.com", and then a client called "www" would create an A record named "www.
dhcp.example.com" which would not have any conflict with "www.example.com". This
improves security, especially if neither an allow-update ACL nor a Microsoft secure zone
has been implemented. A second major benefit is that qip-syncexternal will be more ef-
ficient for a small, more focused zone in which only A records need to be compared to
VitalQIP, not other Resource Record types.
The downside of having DHCP clients broken out into a separate child domain is that
users may need to adjust the way that they perform DNS lookups of these names. For
example, if a DHCP client named "client" is in "example.com", a user can do "nslookup
3
Alcatel-Lucent | Integration of VitalQIP® with Microsoft Windows 2003 Networking/Active Directory
Advertisement
Table of Contents
