FQDN names resolved with duplicated DNS suffix

Hi All,

I have a quick question I hope you can help me to fix.

Environment: I have an environment where I have installed a new AD and the domain name is something like corp.example.com

As a NETBIOS name during the AD install wizard I did choose "example" to make things easier and consistent with the public DNS name. The public DNS registered is example.com and there is public website running with example.com already hosted by WordPress and DNS registrar is GoDayddy.

Issue: Internal host names are not resolved properly with NSLOOKUP

1. Hostnames are working fine

2. IP Addresses are working fine

3. FQDN are NOT working fine. They are resolved with internal domain appended to external domain name.

eg. "VM1.CORP.EXAMPLE.COM" returns VM1.CORP.EXAMPLE.COM.EXAMPLE.COM and public IP Address registered with the website DNS Provider

4. FQDN with a trailing "." are working fine

eg. "VM1.CORP.EXAMPLE.COM." returns the correct IP Address as expected

Configuration: AD/DNS server is pointing at itself. NO forwarders configured. AD is pointing at an internal Gateway. This gateway is configured to talk with the internet using a different network through a separate Router connected to the internet.

My question: It's obviously not a question of routing but I dont understand why DNS forwards queries for FQDN names to external DNS servers considering that "A" and respective "PTR" records are fully registered and working on the builtin DNS? Of course this is affecting ANY operation you can think of from joining machines to domain to leverage network services through FQDN names! What am I missing here?

Any help is greatly appreciated!

Thanks,
Mike DomaAsked:
Who is Participating?
 
DrDave242Connect With a Mentor Commented:
3. FQDN are NOT working fine. They are resolved with internal domain appended to external domain name.

eg. "VM1.CORP.EXAMPLE.COM" returns VM1.CORP.EXAMPLE.COM.EXAMPLE.COM and public IP Address registered with the website DNS Provider

4. FQDN with a trailing "." are working fine

eg. "VM1.CORP.EXAMPLE.COM." returns the correct IP Address as expected

This is normal behavior for nslookup. If you add the trailing dot, you're telling it not to append any DNS suffixes, just attempt to resolve the name as supplied. Otherwise, it will append whatever DNS suffixes are in that machine's suffix search list. It may also devolve those suffixes, depending on the policies present in your environment.

If nslookup is responding with a public IP address to these queries with appended suffixes, it most likely indicates the presence of a wildcard record somewhere. If you query for blahblahblahblahblah.example.com or some other nonsense name in example.com, does it return the same address? If so, there's definitely a wildcard record present.
1
 
Shawn StewartIT ManagerCommented:
If your entering vm1 in your internal dns the hostname should just be "vm1" under the reverse lookup directory for "corp.example.com"

Anything you put in the a record shows up before "corp.example.com" so if you put "vm1.corp.example.com" it will be "vm1.corp.example.com.example.com"
0
 
Mike DomaAuthor Commented:
Hi Shaun,
thanks for coming back to me.

Issue is "application services" use FQDN names and they are not resolved properly as duplicated suffix is returned.
So for example if I run NSLookup on vm1.corp.example.com the result is vm1.corp.example.com.example.com.
This of course is not working for application when connecting to other hosts..
Also only when adding a trailing dot to the FQDN then the resolution is correct AND i do NOT get NON-Authoritative answers!

I cannot run other tests at the moment but is there a way to make sure FQDNs are resolved as expected?

Thanks
0
Has Powershell sent you back into the Stone Age?

If managing Active Directory using Windows Powershell® is making you feel like you stepped back in time, you are not alone.  For nearly 20 years, AD admins around the world have used one tool for day-to-day AD management: Hyena. Discover why.

 
Mike DomaAuthor Commented:
to clarify the following happens:

1. Ping to hostname is ok

2. Ping to IP Address is ok

3. Ping to FQDN returns duplicated DNS suffix as in hostname.corp.example.com.example.com

4. lookup to FQDN returns duplicated DNS suffix as in hostname.corp.example.com.example.com

5. lookup to FQDN with trailing "dot" returns answers as expected

Name registrar is with GoDaddy

DNS Hosting is with WordPress

Any clue on how I can solve this? Thanks a lot for your help and attention

Thanks,
0
 
David FavorLinux/LXD/WordPress/Hosting SavantCommented:
If you still require assistance, past the above answers...

1) include your entire zone file

2) include your actual domain name

Then likely many people can rapidly assist you with fixes.
0
 
DrDave242Connect With a Mentor Commented:
My question: It's obviously not a question of routing but I dont understand why DNS forwards queries for FQDN names to external DNS servers considering that "A" and respective "PTR" records are fully registered and working on the builtin DNS?

Just realized I didn't actually answer this question. Your internal servers are authoritative for the corp.example.com domain, but the queries being forwarded are queries for names in the example.com domain as a result of the example.com suffix being appended. That's why they're being forwarded and queries with the trailing dot aren't.
1
 
Mike DomaAuthor Commented:
Great stuff DrDave242! and thanks to David Favor as well.

You are right. If I check WordPress domain configuration there is a CNAME *.example.com and cannot be removed. I need to check this with WordPress support. So knowing this is there a sensible workaround? Am I missing anything?
0
 
Mike DomaAuthor Commented:
Hi David,

here you are the info requested. I have removed all hosts and left a couple as example plus the results of nslookup and ping as stated earlier

Thanks
DNS-01.PNG
DNS-02.PNG
DNS-03.PNG
export.xlsx
0
 
DrDave242Commented:
Are you sure that FQDNs are having suffixes appended (outside of nslookup, which will always do that)? As far as I know, the Windows resolver will only append suffixes to single-label names, and this seems to be backed up by DNS-02.PNG. I just did some testing in my own environment, and any DNS name with more than one label didn't get anything appended to it. There could be a policy that controls this behavior, though; I'll see if I can find more info on that.
0
 
Mike DomaAuthor Commented:
Yes parent DNS suffix is appended. It's the default property in the advanced TCP connection DNS tab
0
 
DrDave242Connect With a Mentor Commented:
Ah, I found something. There is in fact a Group Policy setting that affects this behavior, and it's here:

Computer Configuration/Policies/Administrative Settings/Network/DNS Client

The setting is called Allow DNS suffix appending to unqualified multi-label name queries, and if it's enabled, it will result in the Windows resolver appending suffixes to names that have more that one label, but only if a query for the original name fails. (This is stated in the description of the setting, which is a bit too long to post here.)

Please run ping foo.bar at a command prompt and let me know the result. I'm curious to see if example.com gets appended to the name.
0
 
Mike DomaAuthor Commented:
Hi DrDave,
sorry just seen this one now..
here you are the screenshot
DNS-04.PNG
0
 
Mike DomaAuthor Commented:
BTW just checked and the policy is not configured as per screenshot
DNS-05.PNG
0
 
DrDave242Commented:
OK, it appears to be working as expected with that policy not configured. Notice in DNS-04.PNG that there was no suffix appended to any of those two-label names.
0
 
DrDave242Commented:
No further response from asker.
0
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

All Courses

From novice to tech pro — start learning today.