none
DNSSEC trust anchor

    Question

  • Hi,

    I'm having trouble configuring DNSSEC on my 2008 R2 server. I don't want to sign a zone, just provide the clients with the option to use DNSSEC in their queries. As I understand it, all I have to do is insert the trust anchor for the root zone.  But I can't even get past that:

    - I could not find any documentation on how to enter the trust anchor. I have the trust anchor here (retrieved with BIND dig.exe), and I know the dialog in DNS manager it should go into - what I don't know and can't find any mention about is what format to use, how to convert the key, or how to set the "name" (a single dot to designate "root zone", right?) and rest of the options.

    - If I paste the key into the dialog and restart DNS service, it won't respond any more. NSLOOKUP (on the server) reports "server fail" and timeout after two seconds. I don't understand this either - shouldn't the server return a response in any case, even if a wrong trust anchor leads to a invalid result? Isn't it the client who's supposed to accept or reject the result as it sees fit?

    Any help would be apreciated.

    Regards,

    AngusMac

    lundi 27 septembre 2010 21:43

Toutes les réponses

  • Hi AngusMac,

    Have you followed the deployment guide? The link is below in my notes. Are there any event log or other errors?

    ==================================================================
    DNSSEC and TrustedAnchors

    Basically, it's a new feature that associates a certificate (or key) to a zone in DNS. The feature is optional during DNS installation, which will then allow DNS security, which then you have to setup a trustedanchor.

    The following paragraph was quoted from:

    DNS Security Extensions (DNSSEC), 10/21/2009
    Support for Domain Name System Security Extensions (DNSSEC) is introduced in Windows Server® 2008 R2 and Windows® 7. With Windows Server 2008 R2 DNS server, you can now sign and host DNSSEC-signed zones to provide security for your DNS infrastructure.
    http://technet.microsoft.com/en-us/library/ee683904(WS.10).aspx

    "In short, DNSSEC allows for a DNS zone and all the records in the zone to be cryptographically signed. When a DNS server hosting a signed zone receives a query, it returns the digital signatures in addition to the records queried for. A resolver or another server can obtain the public key of the public/private key pair and validate that the responses are authentic and have not been tampered with. In order to do so, the resolver or server must be configured with a trust anchor for the signed zone, or for a parent of the signed zone."

    Trustedanchors and DNSSEC (DNS security) is a new industry implementation that was implemented in Windows 2008 R2 based on the Internet-standard "DNS Security Extensions" (DNSSEC) that are defined in RFCs 4033, 4034, and 4035, all of which were released in March, 2005, which were updated from the previous but now defunct RFC 2535. Windows 2003 and 2008 are not compatible with the 2008 R2 extensions.

    At present, the ICANN DNS root zone doesn't support DNSSEC, but eventually it will be updated because DNSSEC is being mandated by many governments around the world. Look for more info in 2011 or 2012.

    As mentioned, there is limited DNSSEC support in Windows Server 2003 or 2008 DNS. Windows 2003 can act as a secondary DNS server for an existing DNSSEC-compliant zone. Windows clients will cache DNSSEC resource records, but perform no cryptography, authentication, or verification. Perhaps to get full functionality in Windows 2003 or Windows 2008. you can implementing DNSSEC running BIND on Windows. For full Windows native functionality, you would have to upgrade to Windows 2008 R2 to get full DNSSEC support.

    See the following links for more information.


    ======
    Related Links:

    The Official, Unofficial, DNS Security Extensions (DNSSEC) Blog (Good article on DNSSEC and Trusted Anchors):
    DNSSEC: Securing Domain Name System Infrastructure (for Windows 2008 R2, 7/27/2010:
    http://dnssec.blogspot.com/2010/07/dns-enhancements-in-windows-server-2008.html

    Windows 2008 R2 and Windows 7 DNSSEC Deployment Guide
    http://www.microsoft.com/downloads/details.aspx?displaylang=en&FamilyID=7a005a14-f740-4689-8c43-9952b5c3d36f

    DNS Security Extensions (DNSSEC), 10/21/2009
    Support for Domain Name System Security Extensions (DNSSEC) is introduced in Windows Server® 2008 R2 and Windows® 7. With Windows Server 2008 R2 DNS server, you can now sign and host DNSSEC-signed zones to provide security for your DNS infrastructure.
    http://technet.microsoft.com/en-us/library/ee683904(WS.10).aspx

    DNSSECDNSSEC: What Is It?
    Good article with lots of information and links, however it's publication date is 3/22/2007, therefore there is no info on Windows 2008 R2.
    https://spaces.internet2.edu/display/securityweir/DNSSEC

    Microsoft Technet Appendix C: DNSSEC PowerShell Scripts, Published 2010
    Checklist: Configuring and Distributing Trust Anchors
    http://technet.microsoft.com/en-us/library/ff608237(WS.10).aspx

    Using DNS Security Extensions (DNSSEC) Windows 2003
    http://technet.microsoft.com/en-us/library/cc728328(WS.10).aspx

    Distribute Trust Anchors
    http://technet.microsoft.com/en-us/library/ee649280(WS.10).aspx

    Configure DNSSEC. Applies To: Windows Server 2003, Windows Server 2003 R2, ...
    http://technet.microsoft.com/en-us/library/cc784518(WS.10).aspx

    Modify DNSSEC configuration: (DNS). Applies To: Windows Server 2003, Windows Server 2003 R2, ...
    http://technet.microsoft.com/en-us/library/cc779943(WS.10).aspx

    TrustAnchor zone created when using Windows 7 to configure the DNS zones with RSAT in Windows server 2003 domains without any Windows Server 2008.
    Scroll down to the comments in:
    http://blogs.technet.com/sseshad/archive/2008/10/30/dnssec-in-windows-7.aspx

    DNSSEC Presentations (DNSSEC - DNS Security Extensions)NLnet Labs for CENTR, Sep 2003. Changes to DNS in Windows Server 2003 (Powerpoint) ... Paul Wouters, Aug 2003. DNSSEC and Zone Enumeration (Powerpoint) ...
    http://www.dnssec.net/presentations

    ======
    Errors with DNSSEC:

    Error: "The request subject name is invalid or too long. 0x80094001"

    Request for Certificate Is Denied and a "The Request Subject Name ...The request subject name is invalid or too long. 0x80094001. In addition, the following message may be logged in the event log: ...
    http://support.microsoft.com/kb/312344

    Windows Server 2003 Does Not Use the DNS Name as Certificate Subjec. In Windows 2000, the Domain Name System (DNS) name of a computer is embedded as
    the ... (0x80094001) The request subject name is invalid or too long. ...
    http://support.microsoft.com/kb/275528
    ==================================================================


    Ace Fekay
    MVP, MCT, MCITP EA, MCTS Windows 2008 & Exchange 2007, MCSE & MCSA 2003/2000, MCSA Messaging 2003, Microsoft Certified Trainer, Microsoft MVP - Directory Services.

    This posting is provided AS-IS with no warranties or guarantees and confers no rights.

    lundi 27 septembre 2010 23:18
  • Hi,

    I found this guide, but it was of no use to me: First, it basically talks about concepts, not the process of configuration itself (e.g. it says "paste the key..." - which key, where to get it, what format, what characterizations, how to verify?) Second, it's focussing on signing your zone, not to add DNSSEC to a resolver.

    What would help me would be a simple screenshot of the trust anchor's dialogue with the details filled in. From that I could not only verify if I made wrong selections, but also deduct key format and similar formalities that are currently eluding me.

    To answer your question: No, there are no error messages in the event log. The query simply times out after (any) anchor has been configured. Remove the anchor, and it starts working again.

     

    Regs,

    AngusMac

    mardi 28 septembre 2010 07:42
  • Hi AngusMac,

    There are some screenshots in the following blog:

    The Official, Unofficial, DNS Security Extensions (DNSSEC) Blog (Good article on DNSSEC and Trusted Anchors):
    DNSSEC: Securing Domain Name System Infrastructure (for Windows 2008 R2, 7/27/2010:
    http://dnssec.blogspot.com/2010/07/dns-enhancements-in-windows-server-2008.html

    Also to note, there are numerous DNSSEC presentations and how-tos at http://www.dnssec.net/presentations. One of which I was looking at may be helpful:

    DNSSEC Deployment: A Tutorial (PDF from PPT)
    http://nsrc.org/tutorials/2009/apricot/dnssec/dnssec-tutorial.pdf

    I haven't read through all of them, but it appears there is lots of good info there.

     


    Ace Fekay
    MVP, MCT, MCITP EA, MCTS Windows 2008 & Exchange 2007, MCSE & MCSA 2003/2000, MCSA Messaging 2003, Microsoft Certified Trainer, Microsoft MVP - Directory Services.

    This posting is provided AS-IS with no warranties or guarantees and confers no rights.

    mardi 28 septembre 2010 14:09
  • When I do "dig dnskey .", I get the following:

    ;; ANSWER SECTION:
    . 86398 IN DNSKEY 256 3 8 AwEAAb1gcD...

    . 86398 IN DNSKEY 257 3 8 AwEAAagAIKl...

    . 86398 IN DNSKEY 256 3 8 AwEAAcAPhP...

     

    Edit:

    I just tried entering a trust anchor for the TLD "se.". This worked fine, my server now does supply DNSSEC-data to the clients. While working with the key for se I noticed that it was specified differently then the key for root:

    ;; ANSWER SECTION:
    se. 3586 IN DNSKEY 256 3 5 AwEAAbczY...
    se. 3586 IN DNSKEY 257 3 5 AwEAAeeGE...
    se. 3586 IN DNSKEY 256 3 5 AwEAAc/2D...
    se. 3586 IN DNSKEY 257 3 5 AwEAAbaxTu...

    The algorithm here is "5". For the root zone, it is specified as "8". Is this a problem for 2008 R2?

     

    Edit #2: (deleted some of the above)

    Looks like I've hit bull's eye here... Looking around has confirmed that 2008 R2 can only use algorithm #5 (RSA/SHA-1). Since the root zone is signed with algorithm #8 (RSA/SHA-256), the resolver won't work.

    This obviously - of course I still may be wrong, but it looks pretty solid to me - makes 2008 R2 unusable as an DNSSEC resolver. Will this issue be addressed by Microsoft? Is there a patch to add algorithm #8, perhaps as a component of the upcoming service pack?

     

    mardi 28 septembre 2010 20:08
  • I see you did a little research and found out about the different algorithm. Interesting. I found the Wikipedia article on it explaining the current algorithms used. It states the Roots have been configured with algorithm 8, RSA/SHA-256, but was just done recently and 2008 R2 doesn't yet support it.
    http://en.wikipedia.org/wiki/Domain_Name_System_Security_Extensions

    I also found the following doc about DNSSEC and 2008 R2 stating, "The only algorithm supported is RSA/SHA-1."
    www.fbiic.gov/public/2009/feb/DNS_SVR2008R2_DNSSEC.doc

    As far as when it will be addressed, we would need that question addressed to one of the Microsoft engineers monitoring this thread, but my best guess it will be available either as a hotfix or in the next service pack.


    Ace Fekay
    MVP, MCT, MCITP EA, MCTS Windows 2008 & Exchange 2007, MCSE & MCSA 2003/2000, MCSA Messaging 2003, Microsoft Certified Trainer, Microsoft MVP - Directory Services.

     

     

    This posting is provided AS-IS with no warranties or guarantees and confers no rights.

    mercredi 29 septembre 2010 05:11
  • Hi,

     

    If there is any update on this issue, please feel free to let us know.

     

    We are looking forward to your reply.


    Please remember to click “Mark as Answer” on the post that helps you, and to click “Unmark as Answer” if a marked post does not actually answer your question. This can be beneficial to other community members reading the thread.
    jeudi 30 septembre 2010 07:15
    Modérateur
  • As far as when it will be addressed, we would need that question addressed to one of the Microsoft engineers monitoring this thread, but my best guess it will be available either as a hotfix or in the next service pack.

    Do we need to take extra steps to bring this to someone's attention or can we rely on a MS employee monitoring this thread by default?

    And actually, yes, there is an update: I looked into the algorithms the various zones are signing with and met a healthy diversity of algorithms used. The most common seem to be #7 and #8. An update to Windows would need to address all of these algorithms if 2008 R2 wants to carry the "supporting DNSSEC" mark.

     


    Regards,

    AngusMac

    vendredi 1 octobre 2010 16:52
  • Hi,

     

    If there is any update on this issue, please feel free to let us know.

     

    We are looking forward to your reply.


    Please remember to click “Mark as Answer” on the post that helps you, and to click “Unmark as Answer” if a marked post does not actually answer your question. This can be beneficial to other community members reading the thread.


    Hi Miles,

    Do you know if there will be an update or some setting to be changed in Windows 2008 R2 to allow it to support the algorithms being currently used?

    Thank you,

    Ace


    Ace Fekay
    MVP, MCT, MCITP EA, MCTS Windows 2008 & Exchange 2007, MCSE & MCSA 2003/2000, MCSA Messaging 2003, Microsoft Certified Trainer, Microsoft MVP - Directory Services.

    This posting is provided AS-IS with no warranties or guarantees and confers no rights.

    vendredi 1 octobre 2010 18:45
  • Are there any updates to this problem?

     


    Regards, AngusMac
    samedi 11 décembre 2010 10:03
  • Bump, would be nice not to have to dump Windows if my customer suddenly wanted to go with DNSSEC... 

    Matt W. CCNP, CCDA, CCNA-S, RHCT, MCSE, MCSA, MCP+I, A+
    vendredi 31 décembre 2010 17:42
  • As far as I know, there are no updates, otherwise I believe it would have been posted or announced. Hang in there.

    Ace


    Ace Fekay
    MVP, MCT, MCITP EA, MCTS Windows 2008 & Exchange 2007, MCSE & MCSA 2003/2000, MCSA Messaging 2003
    Microsoft Certified Trainer
    Microsoft MVP - Directory Services

    This posting is provided AS-IS with no warranties or guarantees and confers no rights.

    vendredi 31 décembre 2010 17:59
  • Has anything changed here with the new SP1?

     


    Regards, AngusMac
    samedi 19 février 2011 16:35
  • After having installed the SP myself I was not able to locate any difference, apparently the SP did not add the missing algorithms.

    This means 2008 R2 can still not be used for DNSSEC enabled operations. Congratulations, Microsoft.


    Regards, AngusMac
    jeudi 3 mars 2011 14:19
  • Hi, AngusMac. My approach to this problem so far has been to set up a BIND 9.8.0 recursive resolver, which does fully support DNSSEC queries, and to configure my Windows Server 2008 R2 SP1 DNS servers to use it as a forwarder.

    The Microsoft DNSSEC documentation is pretty inadequate. The article "Understanding DNSSEC in Windows" at http://technet.microsoft.com/en-us/library/ee649277(WS.10).aspx states "Forwarding and recursion: Non-authoritative DNS servers are typically configured to either forward queries to other DNS servers or to recurse queries to the Internet root servers. A Windows Server 2008 R2 DNS server deployed as a forwarder or a recurser will retrieve the additional resource records required to perform DNSSEC validation based on configured trust anchors and will validate responses received."

    This seems to sugest that the forwarded queries automatically request DNSSEC processing. I can't find any configuration settings related to this. I think my next step will be to do some packet tracing to see wheter or not the DO flag is actually set in the DNS requests from the Windows server.

    I would not be surprised to find that the MS DNSSEC implementation is not fully baked, but we shall see.

    Regards, Jeff.


    Jeffry A. Spain Network Administrator Cincinnati Country Day School
    samedi 19 mars 2011 20:59
  • Based on packet tracing analysis, our Windows Server 2008 R2 DNS servers are forwarding DNS queries to our BIND 9.8.0 recursive resolver with the Checking Disabled (CD) bit set in the DNS header along with the OPT pseudo-RR DO bit set in the EDNS data. The DO bit set means that the Windows DNS server wants the BIND resolver to return DNSSEC-related records, e.g RRSIG records, and the CD bit set means that the Windows DNS server will handle authentication of the response according to its internal policies.

    In its default configuration, the Windows DNS server is not authenticating the responses, so the task now becomes how to configure it to do so. You can see this by looking up the address of badsign-A.test.dnssec-tools.org. Opening a web browser to http://badsign-A.test.dnssec-tools.org will accomplish this.

    The DNS record for badsign-A.test.dnssec-tools.org is deliberately configured with a bad signature in its RRSIG record. Thus the query "dig @your.DNSSEC-aware.resolver badsign-A.test.dnssec-tools.org +dnssec +cdflag", which is what the Windows DNS servers are sending, returns the IPv4 address 75.119.216.33 along with the bad RRSIG record. On the other hand, "dig @your.DNSSEC-aware.resolver badsign-A.test.dnssec-tools.org +dnssec +nocdflag" causes the recursive resolver to do the authentication check, and so returns a SERVFAIL status and no answer, as is appropriate given the bad signature.

    Thus another approach to the problem would be to try to make the Windows DNS servers send their queries with the CD bit clear.

    The next step is to figure out how configure the Windows DNS servers for either one of these alternatives.


    Jeffry A. Spain Network Administrator Cincinnati Country Day School
    dimanche 20 mars 2011 22:16
  • I found a third alternative that works with Windows 7 clients and Windows 2008 R2 DNS servers. Refer to the Windows Server 2008 R2 DNSSEC Deployment guide at http://www.microsoft.com/downloads/en/details.aspx?FamilyID=7a005a14-f740-4689-8c43-9952b5c3d36f&displaylang=en. The document is mostly about IPSEC and zone signing, but there is a section "Deploy Name Resolution Policy to Client Computers" starting on page 36. With this you can define a group policy that will enable DNSSEC validation on the stub resolvers in Windows 7 clients. I set up a policy to enable DNSSEC validation without using IPSEC for the entire DNS name space. Here are the resulting registry settings:

    Windows Registry Editor Version 5.00

    [HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows NT\DNSClient]

    [HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows NT\DNSClient\DnsPolicyConfig]

    [HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows NT\DNSClient\DnsPolicyConfig\Rule1]
    "Version"=dword:00000001
    "ConfigOptions"=dword:00000002
    "Name"=hex(7):2e,00,00,00,00,00
    "IPSECCARestriction"=""
    "DNSSECValidationRequired"=dword:00000001
    "DNSSECQueryIPSECRequired"=dword:00000000
    "DNSSECQueryIPSECEncryption"=dword:00000000

    With these settings in place, the attempt to open http://badsign-a.test.dnssec-tools.org/ in Internet Explorer fails where it has always succeeded before.

    Looking at a packet capture, the Windows 7 stub resolver is sending the query with the CD bit clear and the DO bit set. The Windows 2008 R2 DNS server is still responding with the A record and its RRSIG record. Based on my reading of RFC 4035 "Protocol Modifications for the DNS Secuity Extensions" at http://www.rfc-archive.org/getrfc.php?rfc=4035, this is not what should be happening. Under these conditions the DNS server should be doing its own DNSSEC validation, and in the case of this record with a bad signature, it should be returning a SERVFAIL status.

    While this provides a solution for Windows 7 clients, downlevel clients are out of luck. I still think that a more effective approach would be to find a way to get the Windows Server 2008 R2 DNS recursive resolver to forward its queries to BIND 9.8.0 with the CD bit clear. I have seen that BIND 9.8.0 does return a SERVFAIL status when DNSSEC validation fails, and this would obviously be independent of the Windows client originating the query.

    I'll keep looking for a way to do this.

     


    Jeffry A. Spain Network Administrator Cincinnati Country Day School
    lundi 21 mars 2011 00:53
  • I think I have a simple solution to this problem based on a Microsoft support case that I have just concluded. The original goal was to provide DNSSEC-validated responses to Windows clients from a Windows DNS server. The fundamental roadblock is that Windows Server 2008 R2 DNS servers cannot be configured as DNSSEC-validating recursive resolvers. The reason for this is that the root DNS zone is signed using the RSA/SHA-256 encryption algorithm (algorithm 8), and Windows DNS supports only RSA/SHA-1 (algorithm 5). My solution starts with configuring Windows DNS to forward queries to a BIND 9.8.0 DNSSEC-validating recursive resolver. This is done using the Forwarders tab of the DNS server properties page. Note that it is important to clear the checkbox "Use root hints if no forwarders are available." This prevents Windows DNS from issuing its own recursive queries that would bypass DNSSEC validation by the BIND server.

    An additional problem with the Windows DNS server is that it forwards all queries with the CD (checking disabled) flag set in the DNS query flags field, as well as setting the DO (DNSSEC OK) bit in the EDNS OPT pseudo-resource record. Setting the CD flag, with our without the DO bit set, causes the BIND resolver not to perform DNSSEC validation and to return address answers, valid or no, to the Windows DNS server. This defeats the purpose of using DNSSEC in the first place.

    It turns out to be easy to change this behavior by running the following command on the Windows DNS server:

    dnscmd /config /EnableEDnsProbes 0

    See the document "Dnscmd" at http://technet.microsoft.com/en-us/library/cc772069(WS.10).aspx for more information. The result of this is that the Windows DNS server no longer includes the OPT pseudo-RR in its queries, and as a side effect, clears the CD flag as well. With the CD flag clear, the BIND forwarder returns a proper SERVFAIL response code and no address answers whenever DNSSEC validation fails. The Windows DNS server returns the SERVFAIL response back to the Windows client. Ultimately the user of the Windows client sees a message such as "This web page cannot be displayed", which is the desired outcome.

    For anyone who wishes to work with this further, BIND is available from the Internet Systems Consortium at http://www.isc.org/, and there are versions for Windows and Linux. The DNSSEC-Tools project has a test DNS zone available with a variety of valid and invalid records. See http://www.dnssec-tools.org/testzone/index.html. For example, looking up the address of badsign-a.test.dnssec-tools.org should return a SERVFAIL response due to the invalid digital signature on this record.

    Ultimately the Windows developers will need to enhance the Windows DNS service so that trust anchors using the RSA/SHA-256 encryption algorithm can be configured. Only then will it be possible configure the DNSKEY of the root zone and so use a Windows DNS server as a DNSSEC-validating recursive resolver. We can hope that this happens sooner rather than later, but I believe that the above is an effective workaround that can be put into operation now.

     


    Jeffry A. Spain Network Administrator Cincinnati Country Day School
    vendredi 22 avril 2011 02:11
  • Is this issue STILL not fixed after all this time???? I haven't seen anything that states that Windows 2008 R2 Server can now support Trust Anchors with RSA/SHA-256, dnscmd help and the GUI only show SHA-1 as an option.
    lundi 14 novembre 2011 17:16
  • Is there any progress on this issue? While the workaround posted here before might work (thanks go to Jeffry for describing it in detail!), it quite obviously is no solution.

    The fact remains that the top Server OS from Microsoft _still_ (!) cannot handle DNSSEC.

    Is this something MS is proud of? So proud in fact, that iPhone-playgrounds get priority before this essential fix?

    Excuse me for getting slightly polemic here, but MS' handling of this defect is decidedly pitiful indeed.


    Regards, AngusMac



    • Modifié AngusMac vendredi 11 mai 2012 13:20
    jeudi 10 mai 2012 11:21
  • Is there any progress on this issue? While the workaround posted here before might work (thanks go to Jeffry for describing it in detail!), it is quite obviously is no solution.

    The fact remains that the top Server OS from Microsoft _still_ (!) can not handle DNSSEC.

    Is this something MS is proud of? So proud in fact, that iPhone-playgrounds get priority before this essential fix?

    Excuse me for getting slightly polemic here, but MS' handling of this defect is decidedly pitiful indeed!


    Regards, AngusMac

    Have you considered contacting Microsoft Support for assistance? If they can't help, they will refund the charge.

    .


    Ace Fekay
    MVP, MCT, MCITP EA, MCTS Windows 2008/R2, Exchange 2007 & Exchange 2010, Exchange 2010 EA, MCSE & MCSA 2003/2000, MCSA Messaging 2003
    Microsoft Certified Trainer
    Microsoft MVP - Directory Services
    Complete List of Technical Blogs: http://www.delawarecountycomputerconsulting.com/technicalblogs.php

    This post is provided AS-IS with no warranties or guarantees and confers no rights.

    FaceBook Twitter LinkedIn

    jeudi 10 mai 2012 16:11
  • Still no news about implementation of SHA-256 to Windows Server 2008 R2?
    dimanche 28 juillet 2013 06:58
  • No change at all.

    After Snowden, one might even venture a guess as to why this is the case. Of course, that's pure speculation. :-(



    Regards, AngusMac


    • Modifié AngusMac mercredi 31 juillet 2013 13:14
    mercredi 31 juillet 2013 13:14
  • Amusingly enough, I have spent over a month on a support ticket with Microsoft dealing with these exact problems with DNSSEC in Windows 2008 R2, and they have finished by forwarding me a link to this discussion thread.  *Facepalm*
    jeudi 1 août 2013 19:52
  • Hi,

    Please see the DNSSEC guide for Windows Server 2012 (and 2012 R2).

    http://technet.microsoft.com/en-us/library/dn593694.aspx

    As mentioned in this thread, the implementation of DNSSEC in Windows Server 2008 R2 was quite limited. The support in Server 2012 is much better.

    Thanks,

    -Greg

    mercredi 26 février 2014 23:59