none
Found a bug in Server 2008 R2 DNS. it will NOT resolve a valid entry that all other DNS implementations do ust fine.

    Question

  • I have tested this against multiple DNS servers.  2008, 2003, 2000, several versions of Bind, fastpipe, etc.  They all work for this one particular domain until you query against a 2008 R2 Domain.

    Attempt to resolve www.superfisheye.com on a 2008 R2 DNS server and we get back no value.  All other DNS systems work fine.

    Here is how they have it setup.

    www.superfisheye.com is a cname to superfisheye.com which is a cname to shopping.netsuite.com and this currently has an A record pointing to 167.216.129.13.

    I've checked it against out 2008 R2 DNS that has our AD on it, I've also built two clean new installs of DNS and only updated the root hints to the latest.  It still fails.

    I'd love to get a few others also to verify that it fails for them.

    Thanks.

    Friday, February 17, 2012 7:31 PM

Answers

  • Hi fskrotzki,

    To point out what's going on, in the query results below, www..superfisheye.com and superfisheye.com are CNAMES with TTLs of 3585 seconds (actually according to zone records, they are 3600 sec, or 1 hour), and the A record it points to, is 285 seconds (according to records, it's 300 seconds, or 15 minutes).  

    So what happens is the resolver will query the www.superfisheye.com CNAME, which then it finds it points to superfisheye.com, another CNAME that it has to resolve, and eventually it will resolve it the A record, shopping.netsuite.com. That's a triple resolution requirement. That's truly poorly designed.

    The client side resolver will query and resolve both CNAMEs and the A record that it points to in one query process, but all three records will be cached separately with their own TTLs. Obviously, and the problem with this, is the A record will expire way before the CNAMES. So if you were to use the CNAME again, it will not re-query the CNAMEs because they are both in the resolver cache, and because it's in cache,  it will not query for the A record. Why should it? The client side resolver is satisfied and won't send a query because it thinks it's already in cache, but in reality it's not, and the resolution fails. 

    .

    ; <<>> DiG 9.8.0 <<>> www.superfisheye.com
    ;; global options: +cmd
    ;; Got answer:
    ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 32679
    ;; flags: qr rd ra; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 0

    ;; QUESTION SECTION:
    ;www.superfisheye.com.          IN      A

    ;; ANSWER SECTION:
    www.superfisheye.com.   3585    IN      CNAME   superfisheye.com.
    superfisheye.com.       3585    IN      CNAME   shopping.netsuite.com.
    shopping.netsuite.com.  285     IN      A       167.216.129.13

    ;; Query time: 39 msec
    ;; SERVER: 199.191.128.103#53(199.191.128.103)
    ;; WHEN: Sat Feb 18 00:48:56 2012
    ;; MSG SIZE  rcvd: 100

    .

    There's not much you can do about the record, since that's on their end. It's just the records design wasn't really thought through.

    .

    There are a couple workarounds.

    Option 1. If you need to access this record on a regular basis, you can create the zone on your DNS server, and create two CNAMES as the following. And notice I pointed each individually to shopping.netsuite.com, not the way the actual record is, to reduce the resolution hop. And when you create the CNAMES, something way lowere than the actual TLLs, wihch make the TTL 60 seconds.

    superfisheye.com
    (same as parent )   CNAME       shopping.netsuite.com
    www                      CNAME       shopping.netsuite.com

    .

    Option 2. Change your DNS server MaxCacheTTL to 0. This will stop the server caching the actual record, but I'm not totally convinced that it will help the client side resolver, since the record and it's associated TTL will be returned to the client, whether the DNS server will cache it or not. I haven't tested this yet, but this issue seems to warrant a little playing around with, if you know what I mean, and may devote a little time to test it in the next couple of weeks.

    .

    I like Option 1.

    Ace


    Ace Fekay
    MVP, MCT, MCITP Enterprise Administrator, MCTS Windows 2008 & Exchange 2007 & Exchange 2010, Exchange 2010 Enterprise Administrator, 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 posting is provided AS-IS with no warranties or guarantees and confers no rights.

    FaceBookTwitterLinkedIn



    Saturday, February 18, 2012 6:25 AM
  • Btw. if you are looking for explanation of the behavior you are seeing, this might result from deficiencies of CNAME records - as described in more details in http://social.technet.microsoft.com/Forums/en-US/winserverDS/thread/102388eb-b673-4cb8-8cec-4a4f587ef34e 

    In particular, read through the response from Ace:

    "And other caveats (these are based on internet resolution, but it applies to CNAMES in general if misconfigured).

    CNAME and A record have different TTLs. Which one will be cached?
    http://serverfault.com/questions/123663/cname-and-a-record-have-different-ttls-which-one-will-be-cached

    CNAME Lookup/Cache Failing - This was a previous thread I was involved in trying to help a couple years back regarding a CNAME issue with Google, but I don't know if the person ever resolved it. I understand Google does things a little different, so it may have been specific to Google.
    http://www.eggheadcafe.com/software/aspnet/32932411/cname-lookupcache-failin.aspx "

    hth
    Marcin


    Friday, February 17, 2012 8:31 PM

All replies

  • This works for me. Btw. in general, referencing CNAME by another CNAME is not a good idea...

    hth
    Marcin

    Friday, February 17, 2012 7:43 PM
  • Btw. if you are looking for explanation of the behavior you are seeing, this might result from deficiencies of CNAME records - as described in more details in http://social.technet.microsoft.com/Forums/en-US/winserverDS/thread/102388eb-b673-4cb8-8cec-4a4f587ef34e 

    In particular, read through the response from Ace:

    "And other caveats (these are based on internet resolution, but it applies to CNAMES in general if misconfigured).

    CNAME and A record have different TTLs. Which one will be cached?
    http://serverfault.com/questions/123663/cname-and-a-record-have-different-ttls-which-one-will-be-cached

    CNAME Lookup/Cache Failing - This was a previous thread I was involved in trying to help a couple years back regarding a CNAME issue with Google, but I don't know if the person ever resolved it. I understand Google does things a little different, so it may have been specific to Google.
    http://www.eggheadcafe.com/software/aspnet/32932411/cname-lookupcache-failin.aspx "

    hth
    Marcin


    Friday, February 17, 2012 8:31 PM
  • In addition, here's more info and a couple of threads on the subject, if you would like to read up on it. 

    DNS Server service does not resolve some external DNS names after it works for a while in Windows Server 2008 R2
    (released 4/15/2011)
    http://support.microsoft.com/kb/2508835

    Technet Forum Thread: CNAME caching problem on Windows Server 2003 R2:
    http://social.technet.microsoft.com/Forums/en-US/winserverNIS/thread/97dcc9cd-76c3-4813-80a0-4173c0030319

    Technet Forum Thread: Windows 2008 DNS caching being wonky
    http://social.technet.microsoft.com/Forums/en-US/winserverNIS/thread/a4e58fdf-fb3f-451e-b85a-247365df6b8d/

    CNAME and A record have different TTLs. Which one will be cached?
    http://serverfault.com/questions/123663/cname-and-a-record-have-different-ttls-which-one-will-be-cached

    Reference link:

    http://social.technet.microsoft.com/Forums/en-US/winserverNIS/thread/bfe3a89f-7ff6-43c9-b387-0a240d891283/

    Hope this helps


    Best Regards,

    Sandesh Dubey.

    MCSE|MCSA:Messaging|MCTS|MCITP:Enterprise Adminitrator | My Blog

    Disclaimer: This posting is provided "AS IS" with no warranties or guarantees , and confers no rights.


    Saturday, February 18, 2012 1:21 AM
  • Hi fskrotzki,

    To point out what's going on, in the query results below, www..superfisheye.com and superfisheye.com are CNAMES with TTLs of 3585 seconds (actually according to zone records, they are 3600 sec, or 1 hour), and the A record it points to, is 285 seconds (according to records, it's 300 seconds, or 15 minutes).  

    So what happens is the resolver will query the www.superfisheye.com CNAME, which then it finds it points to superfisheye.com, another CNAME that it has to resolve, and eventually it will resolve it the A record, shopping.netsuite.com. That's a triple resolution requirement. That's truly poorly designed.

    The client side resolver will query and resolve both CNAMEs and the A record that it points to in one query process, but all three records will be cached separately with their own TTLs. Obviously, and the problem with this, is the A record will expire way before the CNAMES. So if you were to use the CNAME again, it will not re-query the CNAMEs because they are both in the resolver cache, and because it's in cache,  it will not query for the A record. Why should it? The client side resolver is satisfied and won't send a query because it thinks it's already in cache, but in reality it's not, and the resolution fails. 

    .

    ; <<>> DiG 9.8.0 <<>> www.superfisheye.com
    ;; global options: +cmd
    ;; Got answer:
    ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 32679
    ;; flags: qr rd ra; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 0

    ;; QUESTION SECTION:
    ;www.superfisheye.com.          IN      A

    ;; ANSWER SECTION:
    www.superfisheye.com.   3585    IN      CNAME   superfisheye.com.
    superfisheye.com.       3585    IN      CNAME   shopping.netsuite.com.
    shopping.netsuite.com.  285     IN      A       167.216.129.13

    ;; Query time: 39 msec
    ;; SERVER: 199.191.128.103#53(199.191.128.103)
    ;; WHEN: Sat Feb 18 00:48:56 2012
    ;; MSG SIZE  rcvd: 100

    .

    There's not much you can do about the record, since that's on their end. It's just the records design wasn't really thought through.

    .

    There are a couple workarounds.

    Option 1. If you need to access this record on a regular basis, you can create the zone on your DNS server, and create two CNAMES as the following. And notice I pointed each individually to shopping.netsuite.com, not the way the actual record is, to reduce the resolution hop. And when you create the CNAMES, something way lowere than the actual TLLs, wihch make the TTL 60 seconds.

    superfisheye.com
    (same as parent )   CNAME       shopping.netsuite.com
    www                      CNAME       shopping.netsuite.com

    .

    Option 2. Change your DNS server MaxCacheTTL to 0. This will stop the server caching the actual record, but I'm not totally convinced that it will help the client side resolver, since the record and it's associated TTL will be returned to the client, whether the DNS server will cache it or not. I haven't tested this yet, but this issue seems to warrant a little playing around with, if you know what I mean, and may devote a little time to test it in the next couple of weeks.

    .

    I like Option 1.

    Ace


    Ace Fekay
    MVP, MCT, MCITP Enterprise Administrator, MCTS Windows 2008 & Exchange 2007 & Exchange 2010, Exchange 2010 Enterprise Administrator, 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 posting is provided AS-IS with no warranties or guarantees and confers no rights.

    FaceBookTwitterLinkedIn



    Saturday, February 18, 2012 6:25 AM
  • I fully understand how DNS works, cnames and TTL's.  The real problem here is the following:  It ALWAYS fails with Microsoft’s DNS from 2008 R2 but on any other version it works just fine always.  If you start testing from a clean install with a purged cache then the TTL values do not come into play for at least 15 minutes as it needs to start by querying all records from the root to start and nothing takes longer then one or two seconds so the TTL's don't come into play yet.

    This is NOT a problem with any other DNS server implementation when we use Microsoft DNS on Windows 2000, 2003, 2003, 2008 standard, or Bind 8, Bind 9, Fastpipe, Comcast DNS, Road Runner, Fronternet.net, TWtelecom.net, etc.  Just with 2008 R2 on a clean install and clean start or one that has been running for weeks (flushed cache or not).  I can duplicate the problem if the cache has already been preloaded a second before or never loaded.

    What I'm really looking for is somebody else with a 2008 R2 server to try it and confirm that it is not something inside our standard setup procedures that are causing the problem.   I'm expecting everybody will find the same result as all I did was take a new 2008 R2 server, added the DNS role, and then pointed one workstation at this dns server for testing purposes and watched it fail just like our two AD servers with DNS already running.

    I understand that linking cname records is a bad process as it makes the server work more then needed.  In that we don't control the site we are trying to get to it's not something I can address.

    Unfortunately your proposed hacking of the DNS is really a bad solution as they can update thier records at any time and we'd never know or follow the changes as we'll have created static internal records that will never change. As it always happens sometime down the road a move likethat come back and bite you in the butt when they update thier records.

     

    A better and moer proper solution is to stand up a caching DNS server (pick you favorite linux distro most are free) and have that become listed as the primary DNS for everything while at the same time it then can act as a secondary for our AD DNS.  That way Bind just works and provides the correct solution no matter what without us having to hack around a problem with 2008 R2 DNS implementation issue.

    Wednesday, February 22, 2012 4:58 PM
  • Marcin,

    You have a 2008 R2 server running DNS and can get it to return values ok?  Are you using root hints or forwarders to your ISP's DNS server?  If you have forwarders enabled it will work as your ISP is doing all the work probably on a unix Bind implementation which does not have a problem.

    Wednesday, February 22, 2012 4:59 PM
  • Windows DNS was born basd on BIND v4 from long ago that tolerated CNAME redirection. The CNAME to CNAME redirect feature was tolerated and allowed, however this also allows the possibility of cache poisoning - redirecting you elsewhere with a properly crafted packet. So up until Windows 2008, it tolerated and supported redirection. Windows 2008 R2 was vastly re-written that deprecated the CNAME to CNAME redirection to properly protect it's cache, and the result of this is it doesn't tolerate badly designed records very well. It's that many domain owners haven't caught up with the times.

    I'll tell you what, read Obi's explanations in his posts in the following thread for a greater understanding. He's a DNS engineer/developer who wrote Treewalk.
    http://social.technet.microsoft.com/Forums/en-US/winserverNIS/thread/3f5a0947-f2a7-4d59-9eed-9fcea1df5558

    I don't know if you've tried the latest BIND build, and I haven't yet, but I have a feeling that it may also curb redirection. I have to test it to find out.

    And I agree manually creating a zone is not the best solution. You never do know when they change records, even if I suggested to create the zone, and create a www delegation to their NS servers, but the same token applies, they may even change their nameservers, so we're out of luck there, too. It was just a workaround thought.

    Ace


    Ace Fekay
    MVP, MCT, MCITP Enterprise Administrator, MCTS Windows 2008 & Exchange 2007 & Exchange 2010, Exchange 2010 Enterprise Administrator, 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 posting is provided AS-IS with no warranties or guarantees and confers no rights.

    FaceBook Twitter LinkedIn

    Thursday, February 23, 2012 1:58 AM
  •  

    I have read the links.  Here is the root issue.

    IT works on all  versions of BIND.  including the latest 9.8.1.  The intentions at ISC it to NOT break backwards compatibility unless it poses a direct security risk.  So it's MS who has broken things (RFC's right or wrong).  In the link you provided you can also see that almost a year later Verizon has NOT fixed the problem and I can find several others that are set the same way.  Mostly when there is a linked list of DNS providers.  Company A is told by company B to use x.companyB.com as a cname.  While their provider is company C who says they should cname to y.companyC.com.  So Company B stuck in the middle does what it has been told and it works.  Well up until you find a customer using MS DNS on a 2008 R2 box.

     

    But nobody would use that as an external DNS source for the many reasons we'll not get into here.  So while they might be right by the RFC's everybody else has dealt with it and it works fine.  Heck Google's own DNS handles it just fine.  I can list thousands of others.

    I'm trying to get an environment up to even test the not yet released version of Bind 10.  But I'll BET that it works there also as the goal from the ISC is to provide all 100% working drop in replacement.

    Monday, February 27, 2012 5:58 PM
  • Do you have a link for that ISC statement? Due to this coming up a few times in the past, I'm trying to gather information. I am posting a request in our private channels to see what I can find, unless one of the engineers monitoring the forum may have something for us.

    Thank you,
    Ace


    Ace Fekay
    MVP, MCT, MCITP Enterprise Administrator, MCTS Windows 2008 & Exchange 2007 & Exchange 2010, Exchange 2010 Enterprise Administrator, 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 posting is provided AS-IS with no warranties or guarantees and confers no rights.

    FaceBook Twitter LinkedIn

    Tuesday, February 28, 2012 4:08 AM
  • Attempt to resolve www.superfisheye.com on a 2008 R2 DNS server and we get back no value.  All other DNS systems work fine.

    All other systems are probably configured to be "poisonable"; let's look at the above; querying the DNS we see that www.superfisheye.com is A CNAME pointing to "superfisheye.com", now, if we try to resolve "superfisheye.com" we'll see that it's another CNAME pointing to "shopping.netsuite.com" and the latter is, finally an A record resolving to 167.216.129.13

    Now, the RFCs state that a CNAME can NEVER point to another CNAME; this was possible with the ancient BIND v4 (and it's still possible if you change some config parameters in newer DNS resolvers ... and screw the config) but as of today it's considered BAD practice and it isn't just a source of issues (as you noticed) but also a potential security flaw

    Tuesday, February 28, 2012 9:23 AM
  • Ace; first of all, I'm for your option #1 too, since the 2nd option won't probably solve the issue given that the DNS will still use the "cache protection" mechanism and discard those screwed CNAME records and... disabling the cache protection isn't a good idea :D

    Then, as for CNAME to CNAME, I think that reading this document may help clearing things a bit; basically, while pointing a CNAME to another CNAME was accepted; as of today it's considered very bad practice and is highly discouraged; basically, what the Windows DNS is doing is totally correct from the security/efficiency standpoint, so I won't call it "a bug"; notice that the "unbound" resolver (see here) which is, as of today, considered the most solid/secure DNS resolver, will REFUSE to return an answer in such a situation and this is totally correct imVVHo; sure, one may alter the config to a point where it will return an answer but doing so we'll just open up the resolver to a number of potential security issues (poisoning being one)

    My 2 cents.


    • Edited by ObiWan Tuesday, February 28, 2012 9:40 AM
    Tuesday, February 28, 2012 9:39 AM
  • Do you have a link for that ISC statement ?

    No, but if you look at this excerpt from Cricket Liu's book, you'll see that at 16.1.2 he clearly states that pointing a CNAME to another CNAME isn't a wise thing and that while it's "tolerated" by BIND, there's NO warranty that such a config will keep working in time and especially it isn't warranted to work with other resolvers; the fact that, to mantain backward compatibility BIND may allow such a bad practice, doesn't mean nor imply that people should use it; on the contrary, it should be avoided and such records should be corrected as soon as possible.

    Tuesday, February 28, 2012 9:59 AM
  • Let me start off by saying I agree a chain of cnames is bad it creates work for the resolver and should be avoided.  Yes it also opens multiple attack points for possible poisoning.  But many people have done it, people still do it and in many cases it's out of your/their control.  Hosting Company Z say's create a cname pointing to name xxx which happens to be a real A record the day they tell you.  4 months later they consolidate servers and now that A record you are pointing to becomes a cname pointing to it's consolidated location without you knowing about it.  It's out of your control and you'll not know it because it's somebody else DNS, stuff happens.  That's WHY ISC and Bind will not fail it. It's only Microsofts Windows 2008 R2 DNS resolver that is now having an issue with it and without any standing in the RFC's that I can find.

    ObiWan,

    Quoting somebodys book is nice, it's published, but his book is not a part of the RFC's. It's just his published opinion.  Which we all agree should not happen in a perfect world.

     

    So I spent the time digging into the RFC's to find where it say's to not resolve it and return an error. Guess what it does NOT exist.

    Actually the RFC's DO state that it should keep working as long as the server is in recursive mode.  If it is not in recursive mode then when quering a name and it finds a cname if should return that result.  When in recursive mode it should follow the link/alias until it can return valid response or determine it has formed a loop or non-resolvable name and only for those two conditions return an error.

     

     Here are some of the references for you.

    Take a look at RFC 1034 Section 3.6.2, Last paragraph states:

    "Domain names in RRs which point at another name should always point at the primary name and not the alias.  This avoids extra indirections in accessing information.  For example, the address to name RR for the above host should be:

        52.0.0.10.IN-ADDR.ARPA  IN      PTR     C.ISI.EDU

    rather than pointing at USC-ISIC.ARPA.  Of course, by the robustness principle, domain software should not fail when presented with CNAME chains or loops; CNAME chains should be followed and CNAME loops signalled as an error."

    Yes this is for RR records but you'll find this theme in all responses.

    The only thing is says is is an error is the "loops signalled as an error".  It also says it "should not fail".  That is exactly my point.  All currently released versions of Bind up to and including 9.9 DO NOT FAIL!

     

    Section 4.3.2 is the name server algorithm.

    Step 3 explains that a cname record generates response records for the partial found information and repeats the query to resolve the next cname if it exists (unless the type requested is a cname record).

    Section 5 is the Resolver description.

    See Section 5.3.2:

    Third Paragraph:

    Several special conditions can occur with aliases.  Multiple levels of aliases should be avoided due to their lack of efficiency, but should not be signalled as an error.  Alias loops and aliases which point to non-existent names should be caught and an error condition passed back to the client.

    Section 5.3.3  discusses the Resolver algorithm.  Once you read all of it and get to the last paragraph.  It states:

    If the response contains a CNAME, the search is restarted at the CNAME unless the response has the data for the canonical name or if the CNAME is the answer itself.

    So Ace the RFC's do NOT support Microsofts current implementation of how it has handled this and this is a BUG.

    Monday, March 05, 2012 11:13 PM
  • See if these list of post SP1 DNS hotfixes may help - there are a couple that may address this, but I haven't tested them yet, so I am not sure.

    List of DNS related hotfixes post SP1 for Windows Server 2008 R2 SP1
    YongRhee [MSFT] 18 Feb 2012 4:12 PM
    http://blogs.technet.com/b/yongrhee/archive/2012/02/18/list-of-dns-related-hotfixes-post-sp1-for-windows-server-2008-r2-sp1.aspx

    .

    Ace

    .


    Ace Fekay
    MVP, MCT, MCITP Enterprise Administrator, MCTS Windows 2008 & Exchange 2007 & Exchange 2010, Exchange 2010 Enterprise Administrator, 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 posting is provided AS-IS with no warranties or guarantees and confers no rights.

    FaceBookTwitterLinkedIn


    Tuesday, March 06, 2012 1:14 AM
  • Nope none of the patches seems to have fixed our issue.

    FOR THE RECORD.  you ever do a query for www.microsoft.com.  You'll love it.  Currently it is failing on our Microsoft DNS server for this exact same reason and BUG.

    Query a 2k8R2 Server DNS.

    C:\Users\fskrotzki>dig @wolverine www.microsoft.com

    ; <<>> DiG 9.7.0-P1 <<>> @wolverine www.microsoft.com
    ; (1 server found)
    ;; global options: +cmd
    ;; Got answer:
    ;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 48046
    ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0

    ;; QUESTION SECTION:
    ;www.microsoft.com.             IN      A

    ;; Query time: 89 msec
    ;; SERVER: 172.31.x.x#53(172.31.x.x)
    ;; WHEN: Wed Apr 18 16:44:57 2012
    ;; MSG SIZE  rcvd: 35

    Query a Bind DNS server

    C:\Users\fskrotzki>dig @blink www.microsoft.com

    ; <<>> DiG 9.7.0-P1 <<>> @blink www.microsoft.com
    ; (1 server found)
    ;; global options: +cmd
    ;; Got answer:
    ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 56804
    ;; flags: qr rd ra; QUERY: 1, ANSWER: 4, AUTHORITY: 10, ADDITIONAL: 0

    ;; QUESTION SECTION:
    ;www.microsoft.com.             IN      A

    ;; ANSWER SECTION:
    www.microsoft.com.      2595    IN      CNAME   toggle.www.ms.akadns.net.
    toggle.www.ms.akadns.net. 165   IN      CNAME   g.www.ms.akadns.net.
    g.www.ms.akadns.net.    165     IN      CNAME   lb1.www.ms.akadns.net.
    lb1.www.ms.akadns.net.  165     IN      A       207.46.19.254

    ;; AUTHORITY SECTION:
    akadns.net.             5070    IN      NS      ns3-129.akadns.net.
    akadns.net.             5070    IN      NS      ns3-131.akadns.org.
    akadns.net.             5070    IN      NS      ns20-131.akadns.org.
    akadns.net.             5070    IN      NS      ns14-130.akadns.org.
    akadns.net.             5070    IN      NS      ns6-131.akadns.org.
    akadns.net.             5070    IN      NS      ns8-200.akadns.net.
    akadns.net.             5070    IN      NS      ns6-129.akadns.net.
    akadns.net.             5070    IN      NS      ns1-129.akadns.net.
    akadns.net.             5070    IN      NS      ns2-129.akadns.net.
    akadns.net.             5070    IN      NS      ns2-131.akadns.org.

    ;; Query time: 10 msec
    ;; SERVER: 172.31.x.x#53(172.31.x.x)
    ;; WHEN: Wed Apr 18 16:45:12 2012
    ;; MSG SIZE  rcvd: 355

    C:\Users\fskrotzki>

    So complain all you want about a linked chain of CNAME records and how wrong it is but Microsoft is doing it!

    Wednesday, April 18, 2012 8:55 PM
  • Query a 2k8R2 Server DNS.

    C:\Users\fskrotzki>dig @wolverine www.microsoft.com

    Query a Bind DNS server

    C:\Users\fskrotzki>dig @blink www.microsoft.com

    Is wovlerine or blink using a forwarder?

    .

    And honestly, if not using a forwarder, my best suggestion at this point is to contact Microsoft support to see if they have anything specific they may offer that we're not aware of at this point.
    http://support.microsoft.com/default.aspx?scid=fh;EN-US;PHONENUMBERS 

    .


    Ace Fekay
    MVP, MCT, MCITP Enterprise Administrator, MCTS Windows 2008 & Exchange 2007 & Exchange 2010, Exchange 2010 Enterprise Administrator, 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 posting is provided AS-IS with no warranties or guarantees and confers no rights.

    FaceBook Twitter LinkedIn

    Wednesday, April 18, 2012 9:36 PM
  • Blink is a Linux Bind DNS Server and Wolverine is a 2008 R2 Server.  NOT using Fowarders configured to only use root hints.

    I just wanted to Point out that while I know that a chain of CNAMES is not good for performance way back you were saying it was now not allowed to work in DNS and all I was pointing out was if that was the case then Micrisoft broke it's own rules.

    This happens about 1 in 10000 times so about onces every two weeks do we get a complaint that something that shoudl work does not.

    Our Ultimiate solution was to replace the Primary DNS server that client workstations hit with a Linux box and make it a secondary for our internal DNS.  Now the only time we get a complaint is the few boxes that have hard coded statics that we have not touched to update the DNS records on.

    Wednesday, April 18, 2012 9:48 PM
  • I understand. Instead of using secondaries and complicating the design, why not simply jsut use a forwarder to the linux BIND box? That should overcome it.

    Ace Fekay
    MVP, MCT, MCITP Enterprise Administrator, MCTS Windows 2008 & Exchange 2007 & Exchange 2010, Exchange 2010 Enterprise Administrator, 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 posting is provided AS-IS with no warranties or guarantees and confers no rights.

    FaceBook Twitter LinkedIn

    Wednesday, April 18, 2012 10:08 PM
  • FWIW, for anyone interested, here's a hotfix that should address this issue. If you install it, please post back with your results.

    .

    DNS Server service does not use root hints to resolve external names in Windows Server 2008 R2 - HOTFIX available.
    Article ID: 2616776 - Last Review: October 12, 2011, APPLIES TO •Windows 2008 R2 Datacenter •Windows 2008 R2 Ent •Windows 2008 R2 Std
    "Consider the following scenario:
    •You install the Domain Name System (DNS) Server role on a computer that is running Windows Server 2008 R2.
    •You configure the DNS server to use root hints to resolve external names.
    In this scenario, the DNS server does not use root hints to resolve external names and causes name resolution issues.
    This issue occurs because the DNS Server service in Windows Server 2008 R2 does not allow CNAME records and NS records to coexist. When the DNS Server service receives a response that has two kinds of records, it ignores the CNAME record.
    In lieu of installing the HOTFIX: "To work around the issue, configure the DNS server to use forwarders instead of root hints to resolve external names."
    http://support.microsoft.com/kb/2616776

    .


    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

    Thursday, July 12, 2012 11:54 PM
  • Ok, I know its an old thread, but the problem still persists:

    psx.partner.microsoft.com. 3600 IN CNAME psx.partners.extranet.microsoft.com.

    psx.partners.extranet.microsoft.com. 10 IN CNAME psxcname.partners.extranet.microsoft.com.

    psxcname.partners.extranet.microsoft.com. 10 IN A 65.55.29.

    As Ace pointed out, as soon as the Host A and the second CNAME times out name resolution will fail.

    The Update mentioned in KB2616776 is not adding any good.

    Last chance would be to set the maxcachettl to 0 [Option 2 discussed earlier], which should result in excessive DNS Traffic

    Option 1 (creating a zone) would result in sites not being accessable anymore since we don`t know all other records microsoft.com holds.

    Tuesday, February 05, 2013 10:29 AM
  • Ok, I know its an old thread, but the problem still persists:

    psx.partner.microsoft.com. 3600 IN CNAME psx.partners.extranet.microsoft.com.

    psx.partners.extranet.microsoft.com. 10 IN CNAME psxcname.partners.extranet.microsoft.com.

    psxcname.partners.extranet.microsoft.com. 10 IN A 65.55.29.

    As Ace pointed out, as soon as the Host A and the second CNAME times out name resolution will fail.

    The Update mentioned in KB2616776 is not adding any good.

    Last chance would be to set the maxcachettl to 0 [Option 2 discussed earlier], which should result in excessive DNS Traffic

    Option 1 (creating a zone) would result in sites not being accessable anymore since we don`t know all other records microsoft.com holds.

    Old and unresolved doesn't mean "don't care" :) at any rate, a quick eyeball at the lookup results you posted shows a CNAME pointing to another CNAME and, pardon me, but this is NOT a good thing; it could have been ok in the "old times", when the ARPAnet was young and everyone was a friend, but, as of today, in the age of the "World Wild Web" (also known as WWW) such a thing isn't good and it doesn't matter that a resolver which crashes if you look at it badly (like the ISC BIND) follows such a link; a serious one won't and then, if my brain is serving me correctly (didn't check), the RFCs don't state that, in case an external CNAME lookup fails, the DNS should restart the lookup (and that for a good reason)

    Tuesday, February 05, 2013 1:54 PM
  • I agree with Obi. There are just too many lookups occurring with multiple CNAMES. The client side reaolver is what will time out first. It's like calling a credit card company customer service. They keep transferring your call.

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

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

    FaceBook Twitter LinkedIn

    Tuesday, February 05, 2013 1:58 PM
  • I fully agree with the both of you, but unfortunately I am not able to change the Microsoft DNS.

    Have you got any other ideas regarding a possible solution?

    Otherwise I am going to disable DNS Caching on all DCs.

    Tuesday, February 05, 2013 2:04 PM
  • Create zones for those specific FQDNs with blank hostname A records. And just monitor for any changes, if they occur.

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

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

    FaceBook Twitter LinkedIn

    Tuesday, February 05, 2013 2:11 PM
  • Create zones for those specific FQDNs with blank hostname A records. And just monitor for any changes, if they occur.

    Or create "conditional forwards" or (as I did looong ago); place your windows DNS servers (whatever version) behind your firewall and install this (a couple, to keep on the safe side) in DMZ; then configure the Windows DNS to use them as forwarders (as a note I use it as my frontend resolver and this one as my auth - in DMZ as well... oh and one can install BOTH on the same box, just bind the resolver to the "internal IP" and the authoritative to the external and there ye go :D !)

    Tuesday, February 05, 2013 2:17 PM
  • @Ace:If I got your answer correct, I think that would result in Microsoft.com not being forwarded since our DNS holds the Zone?!

    @ObiWAN: We got the following Scenrio in place: 3 MS DNS Servers (LAN) forwarding to 2 (DMZ) Resolvers running Bind9 (which are able to resolve properly). Still the Windows DNS are not resolving. One way to force them is to manually delete the records, resulting in a succesful NSLookup.

    • Edited by GunniO Tuesday, February 05, 2013 2:27 PM
    Tuesday, February 05, 2013 2:19 PM
  • @Ace:If I got your answer correct, I think that would result in Microsoft.com not being forwarded since our DNS holds the Zone?!

    @ObiWAN: We got the following Scenrio in place: 3 MS DNS Servers (LAN) forwarding to 2 (DMZ) Resolvers running Bind9 (which are able to resolve properly). Still the Windows DNS are not resolving. One way to force them is to manually delete the records, resulting in a succesful NSLookup.

    Uh... wrong; you shouldn't create a "microsoft.com" zone but a zone called exactly like the hostname (e.g. "psx.partner.microsoft.com" or just "partner.microsoft.com"); as for your scenario, since your 3 MS DNS servers are forwarding to BIND resolvers, the issue is NOT related to the MS DNS servers but to the BIND resolvers since THOSE are the ones carrying over the external resolution and running queries to the authoritative DNS servers for whatever domain (then, ok, I'd drop BIND and use "unbound" but that's a totally different kind of topic/issue) oh... and as for the "not resolving"; did you check if DNSSEC is properly configured ? See, MS DNS only implements a stub resolver, but it may be quite "picky" in case the "external resolver" doesn't return all the infos or "correct" ones


    • Edited by ObiWan Tuesday, February 05, 2013 2:44 PM
    Tuesday, February 05, 2013 2:42 PM
  • to clarify this further:

    On the Windows DNS Servers I  can monitor the DNS Cache. Once the first request is send, both CNAMES and the Host Records are stored in the Cache. Clients are able to resolve the entry above. After 10 Seconds (Host Record and one CNAME TTL) those entries dissapear from the DNS Cache, but since the first CNAME (TTL 3600) is still valid the Microsoft DNS is not trying to resolve that entry (again). So I think setting the maxcachettl to 0 should solve it?

    Tuesday, February 05, 2013 2:59 PM
  • to clarify this further:

    On the Windows DNS Servers I  can monitor the DNS Cache. Once the first request is send, both CNAMES and the Host Records are stored in the Cache. Clients are able to resolve the entry above. After 10 Seconds (Host Record and one CNAME TTL) those entries dissapear from the DNS Cache, but since the first CNAME (TTL 3600) is still valid the Microsoft DNS is not trying to resolve that entry (again). So I think setting the maxcachettl to 0 should solve it?

    Expand the above a bit, please; when you refer to "DNS cache" are you referring to the DNS server "cache folder" or to the "DNScache" service (aka client cache - you can see them by running an "ipconfig /displaydns" at the command prompt) contents ? See, BOTH play a role here and it would be interesting and useful to understand what you're referring to; not just that; I suspect (ok, it's more than just a suspect) that when the cache expires, the MS DNS tries to re-query the BIND resolver and the latter returns an NXDOMAIN

    Tuesday, February 05, 2013 3:14 PM
  • I was refering to the DNS Lookup Cache on the DNS Server.

    Since I was testing with nslookup against the server i thought that the client cache is not used?

    nslookup result & DNS Cache on the server:

    waited some minutes..

    DNS Cache on the server:

    Obviously the entries are gone since ttl is onyl 10 seconds, this resulted in the entry no being resolved.

    While researching I disabled the option to "use root hints if no forwarders are available". I did this since we have 3 forwarders in place and roots hints should not be needed. For some reason (which I don`t understand atm) the behaviour I tried to described above is not reproducable anymore!

    nslookup works all the time now.

    *confused*



    • Edited by GunniO Tuesday, February 05, 2013 3:48 PM
    Tuesday, February 05, 2013 3:43 PM
  • I was refering to the DNS Lookup Cache on the DNS Server.

    Since I was testing with nslookup against the server i thought that the client cache is not used?

    nslookup result & DNS Cache on the server:

    waited some minutes..

    DNS Cache on the server:

    Obviously the entries are gone since ttl is onyl 10 seconds, this resulted in the entry no being resolved.

    While researching I disabled the option to "use root hints if no forwarders are available". I did this since we have 3 forwarders in place and roots hints should not be needed. For some reason (which I don`t understand atm) the behaviour I tried to described above is not reproducable anymore!

    nslookup works all the time now.

    *confused*



    Ok... first of all, let me state that this whole thread falls into the kind of case discussed in KB-555375 that is, lack of details about the setup which brought to a "try and check" approach (which, as you discovered means ... more time to a solution/answer)

    Second; given that what you wrote means that you really solved your issue, then there may be an explanation for such a behaviour... see, you have your LAN resolvers configured to forward queries to some BIND9 boxes... all ok, also, I guess that DNS traffic going to server sitting OUTSIDE your LAN is only allowed from the BIND9 boxes and NOT from the Windows DNS servers (all ok again); but now... let's say you have the "use root hints if no forwarders are available" option checked; a client sends out a query (to your Windows DNS) to resolve "example.com"; the Windows DNS, in turn, forwards such a query to your BIND9 resolvers, gets back an answer and returns the desired info to the client... all ok (till now); but then, for after a while, the client sends out another query, the Windows DNS, in turn, tries to contact the BIND9 resolvers but the resolvers don't answer (or don't answer in a timely fashion)... so, the Windows DNS tries to contact the root servers and carry on the resolution process on its own... but since the firewall blocks outgoing DNS queries, the windows resolver won't be able to reach the root-DNS (or any other external DNS) so, the resolution fails

    Now... what we'll need (ok YOU'll need) to know, is why, under some circumstances, queries from your Windows DNS to the BIND9 resolvers fail (or timeout) :)

    Tuesday, February 05, 2013 4:08 PM

  • Ok... first of all, let me state that this whole thread falls into the kind of case discussed in KB-555375 that is, lack of details about the setup which brought to a "try and check" approach (which, as you discovered means ... more time to a solution/answer)


    As you may have noticed, I was referring to an proposed answer which obviously was leading me in a wrong direction. No need for nagging.

    I really appreciate your help and effort, but I think all the answers were provided in a timely manner.

    Regarding "second": I will investigate this further tomorrow, but I think the question is why root hints are used while forwarders are available.

    Thanks!

    Tuesday, February 05, 2013 5:01 PM
  • As you may have noticed, I was referring to an proposed answer which obviously was leading me in a wrong direction. No need for nagging.


    I really appreciate your help and effort, but I think all the answers were provided in a timely manner.

    Regarding "second": I will investigate this further tomorrow, but I think the question is why root hints are used while forwarders are available.

    Wasn't trying to "nag", just ... well ... forgot to add a "smile" :)

    Anyhow... as for the "use hints", that basically means that, for whatever reason, your windows DNS server(s) were unable to contact (or, if you prefer to receive a timely answer from) your BIND9 resolvers so, since the "use root hints..." option was enabled, they tried to carry on a regular "recursive" resolution (RRR :-D) which failed due to the fact that (I'm guessing it) they weren't allowed to "go out and contact external DNS servers"

    As for the why the "try root hints" mechanism kicked in, I think that it could be a good idea to check your connectivity and ensure that there weren't "glitches" (congestions or connectivity loss) also, and since you're at it; it would be a good idea to ensure that DNS and NTP (time sync) protocols are configured in whatever traffic shaper or QoS to have very high priority over other traffic

    What else... uh yes, you stated you're using BIND9 for your frontline... well, if, by chance, you'll have some spare minutes, please, give "unbound" a spin and, to speed things up, have a look at this site which lists some tips and tricks to help setting up the resolver (oh and avoid getting distracted by those blue eyes :D)

    Tuesday, February 05, 2013 5:14 PM
  • I going to give unbound a try tomorrow ;)

    Thanks for your help!

    Tuesday, February 05, 2013 6:46 PM