none
Odd DNS setup is [possibly] messing with my Zone Scope Policy RRS feed

  • Question

  • Hello --

    I just took over a network from someone who didn't document much of anything, and did some really odd things. This particular odd thing that I've never seen done before is this DNS hierarchy:

    DNSServer
     - Forward Lookup Zones
      - _msdsc.ad.fnd.co
     >> ad.fnd.co
          - _msdcs
          - _sites, etc
     >> fnd.co
          - ad
     - Reverse Lookup Zones...


    The primary AD domain is [ad.fnd.co]. I have no clue why he would've manually created [fnd.co], with the [ad] subdomain. Any guesses as to why someone would do that?

    To the headache-point, I'm trying to setup a Zone Scope Policy to direct anyone in a specific subnet to a particular webserver, but send everyone else to another webserver (same hostname, same domain). I've tested successfully in a testlab, but when I apply the same commands on-site, it's like the policy doesn't exist. This is the Powershell:

    Add-DnsServerClientSubnet -Name "WA01Subnet" -IPv4Subnet 10.4.16.0/23
    Add-DnsServerZoneScope -ZoneName "fnd.co" -Name "WAZoneScope"
    Add-DnsServerResourceRecord -ZoneName "fnd.co" -A -Name "mind" -IPv4Address "10.4.16.26" -ZoneScope "WAZoneScope”
    Add-DnsServerQueryResolutionPolicy -Name "WAPolicy" -Action ALLOW -ClientSubnet "eq,WA01Subnet" -ZoneScope "WAZoneScope,1" -ZoneName "fnd.co" –ProcessingOrder 1

    So from that, I create a scope in the [fnd.co] zone, create a host (A) record in the scope, and set a policy that anyone in the /23 subnet should be directed to [10.4.16.26]. Then in the parent (non-scoped) zone [fnd.co], there's an A record pointing to [10.4.5.26], which should be the catch-all response for anyone outside of the policy criteria.

    The same config works in testing, but fails in production, and the only difference I can see (besides a /23 vs /24 subnet) is that this production env has a seemingly conflicting zone structure. I'm able to add the policy to the [ad.fnd.co] zone/scope/policy and it works just fine, but the enduser wants to type "mind.fnd.co", not "mind.ad.fnd.co" (which is the only reason I can imagine for having the two zones).

    Can anyone offer any insight/opinions/points/thoughts? because i'm at a loss to why this rather simple config refuses to work.. :'(

    Thanks (and my apologies for the lengthy post)

    Wednesday, March 6, 2019 11:00 PM

All replies

  • Hi,

    Perhaps the AD domain [ad.fnd.co] is created after the fnd.co zone is created.

    If it is possible, I would suggest you move the records in fnd.co zone to ad.fnd.co zone and delete the fnd.co.

    Best regards,

    Travis


    Please remember to mark the replies as an answers if they help.
    If you have feedback for TechNet Subscriber Support, contact tnmff@microsoft.com

    Thursday, March 7, 2019 7:37 AM
    Moderator
  • The [ad.fnd.co] is the current primary, but I don't know what the previous admin started with. There are only a couple records in the [fnd.co] zone, so deleting the zone may be an option.  I'll have to check around to see if there's any necessary reason for keeping [fnd.co] around.

    I just noticed an odd thing..  From the DNS mmc, I deleted the subdomain [ad] under [fnd.co].  It goes away correctly, but when I try to Reload the [fnd.co] zone, I'll get a "Failed to reload zone. Failed to load zone scope" error popup.  Then a refresh will show the records slowly repopulate (I'm assuming from the other DNS servers at other sites).  So maybe the [fnd.co] zone is corrupt, but I ran the powershell Test-DnsServer and it was successful.  This is just weird.

    Thursday, March 7, 2019 6:09 PM
  • Hi,

     Then a refresh will show the records slowly repopulate (I'm assuming from the other DNS servers at other sites). 

    Is the [fnd.co] a AD-integrated zone? It seems that dns data is stored in AD database.

    Best regards,

    Travis


    Please remember to mark the replies as an answers if they help.
    If you have feedback for TechNet Subscriber Support, contact tnmff@microsoft.com

    Friday, March 8, 2019 9:52 AM
    Moderator
  • Yes, it's an AD-integrated zone.

    After talking with several employees at the company, I think the original admin first created the domain "ad.fnd.co", but then a user requested an internal webserver with address "host.fnd.co", so the admin created the new zone "fnd.co".  I'm guessing the DNS server is getting confused between the two zones.

    What's most frustrating is that I can create the policy in the "ad.fnd.co" zone and it works as it should, but running the same commands in the "fnd.co" zone doesn't.  I'm at a complete standstill right now, with no more ideas of how to proceed.

    Friday, March 8, 2019 4:09 PM
  • Hi,

    What about configure ZoneName as "ad"?

    If it doesn't work, I would suggest you create a new zone.

    Best regards,

    Travis


    Please remember to mark the replies as an answers if they help.
    If you have feedback for TechNet Subscriber Support, contact tnmff@microsoft.com

    Monday, March 11, 2019 7:41 AM
    Moderator
  • Hi,

    Just checking in to see if the information provided was helpful.

    Please let us know if you would like further assistance.

    Best Regards,

    Travis


    Please remember to mark the replies as an answers if they help.
    If you have feedback for TechNet Subscriber Support, contact tnmff@microsoft.com

    Wednesday, March 13, 2019 7:52 AM
    Moderator
  • (note: something in these forums screwed up and I had to create a new profile, so i'm replying as thatguy888)

    Thank you for your time, but this issue seems to be more complicated than communication thru a forum can solve.  I'll try to open a ticket with microsoft support instead, because this DNS/AD/Domain structure is just messed up.

    Thanks anyway.

    Wednesday, March 13, 2019 8:18 PM
  • Hi,

    It is a good idea that contact Microsoft Customer Support and Services, and more in-depth investigation can be done so that you would get a more satisfying explanation and solution to this issue.

    If there is anything else we can do for you, please feel free to post in the forum.

    Best regards,

    Travis


    Please remember to mark the replies as an answers if they help.
    If you have feedback for TechNet Subscriber Support, contact tnmff@microsoft.com

    Thursday, March 14, 2019 9:37 AM
    Moderator