Microsoft Windows Server DNSSEC Support - Clever or Cumbersome?
Microsoft Windows Server 2008 R2 supports DNSSEC[bis] for both signing zones (for authoritative servers) and for validating DNSSEC responses (for recursive servers). Zone signatures for authoritative servers must be configured and performed using the dnscmd command line interface. While at first blush, it may seem inconvenient not to enable DNSSEC via the graphical interface of the Microsoft Management Console (MMC), this is actually a legitimate and even ingenious implementation approach.
How many organizations' IPAM configuration teams also manage network security? In small organizations, certainly these and all IT functions for that matter could fall into the lap of a single person or team. But for modest to larger organizations, who may in fact be more amenable to using Microsoft Windows Server products, the network security function is typically an independent function by design, even if the rest of IT falls within another single group.
Not to stereotype network security personnel, but they tend to want sole control over security policies and implementations. This "necessary paranoia" actually makes for solid security policy. Security professionals may prefer to control the configuration of DNS security policies, keys and signatures under the sole authority of the security team, obscured from the DNS configuration team which uses the MMC interface on a day-to-day basis. You wouldn't want an IPAM/DNS engineer to view and/or edit an RRSIG or DNSKEY record out of curiosity would you?
So is it clever or cumbersome? Does your network security team trust your IP network engineers to configure and managed DNSSEC? If so, perhaps the Micorosoft approach is cumbersome and a solution giving IPAM engineers control of DNSSEC policies is in order. But if not, having a separate user interface outside of the normal day-to-day DNS/IPAM workflow is downright clever if not ingenious!
The Microsoft approach is not without its limitations however. For example, Windows Server 2008 R2 supports signing of static zones only (dynamic zones are not dynamically signed) and limited support of NSEC3 record processing, but I'll address these topics is in a future post.
How many organizations' IPAM configuration teams also manage network security? In small organizations, certainly these and all IT functions for that matter could fall into the lap of a single person or team. But for modest to larger organizations, who may in fact be more amenable to using Microsoft Windows Server products, the network security function is typically an independent function by design, even if the rest of IT falls within another single group.
Not to stereotype network security personnel, but they tend to want sole control over security policies and implementations. This "necessary paranoia" actually makes for solid security policy. Security professionals may prefer to control the configuration of DNS security policies, keys and signatures under the sole authority of the security team, obscured from the DNS configuration team which uses the MMC interface on a day-to-day basis. You wouldn't want an IPAM/DNS engineer to view and/or edit an RRSIG or DNSKEY record out of curiosity would you?
So is it clever or cumbersome? Does your network security team trust your IP network engineers to configure and managed DNSSEC? If so, perhaps the Micorosoft approach is cumbersome and a solution giving IPAM engineers control of DNSSEC policies is in order. But if not, having a separate user interface outside of the normal day-to-day DNS/IPAM workflow is downright clever if not ingenious!
The Microsoft approach is not without its limitations however. For example, Windows Server 2008 R2 supports signing of static zones only (dynamic zones are not dynamically signed) and limited support of NSEC3 record processing, but I'll address these topics is in a future post.
Comments
Post a Comment