DNS troubleshooting

I have several VLANs that are routing to one another and to the internet.



I have a local server doing DHCP/DNS, and a different local server acting as a proxy/RRAS gateway to the internet.



In the VLANs, the IPs are assigned dynamically via a DHCP relay function in our L3 switch. that works fine. the DNS address that is provided via DHCP is pointing correctly to the local DNS server.



Now here is the weird part-



The DNS is "working" for all of the nodes in the VLANs, that is, they can resolve hostnames on the internet into IP addresses and surf the web just fine. but the problem is that some of the clients are unable to ping other internal clients and servers by their respective hostnames- they can only ping them by ip address. i know for sure that they are resolving DNS from that local DNS server because thy are not provided any additional DNS servers by DHCP- they only have one possible DNS server and that is our local one.



so, for example, we have a workstation in one VLAN that can not ping the DNS/DHCP or RRAS box's (which are in a different VLAN) by name, but, they can ping them just fine by IP.



As of current there is no reverse lookup zone, only a forward lookup zone, and some of the entries in the forward lookup zone do not appear to be updating as they should (the hostnames do not match the new IP addresses from certain nodes being moved into a different VLAN with a different numbering scheme). In fact, it appears to me that many new workstations that are placed onto a VLAN do not get an "a" host record associated with their respective information at all automatically in the forward lookup zone.





Any ideas at all would be very appreciated

I'm thinking that there may be a problem with the clients' primary DNS suffix or DNS suffix search list as these would affect client DNS registration and name resolution.

So my questions are:
Are you trying to ping the hosts by just their host names or their FQDN?

For the computers that aren't registering themselves in DNS, are they part of the AD domain? Silly question that's probably not applicable here, but if those computers are
not part of the domain, then they wouldn't get the domain name as a suffix and not be able to register themselves in DNS. They would also not have that suffix to append to client host names when trying to resolve host names.

How about DNS suffix search lists, are you providing any to the clients?

I'm making the assumption that you have an AD-integrated DNS zone or a primary zone configured with "secure and non-secure" dynamic DNS.

As a last resort for fixing the DDNS, you can set DHCP to update the client records rather than the clients trying. You shouldn't need to do this, bu it's a thought in case you're desperate.

Hope this helps

im starting to realize what happened.

we just created these vlans about a week ago, before this the entire network was flat.

we have alot of students with laptops, many of which do not run an OS that is capable of joining the domain. so here is somewhat of the conclusion ive come to so far --

when they (everyones computers) were on the same subnet as the DNS/DHCP/AD and RRAS/Proxy box, they were able to resolve their internal hostnames because it was a layer 3 broadcast packet that was asking every node on the same subnet "who has this hostname/netbios name?"

but when i moved those laptops and (domain joined) workstations to a new vlan and subnet, they were no longer able to get a response from their IP layer broadcast asking for a response to their hostname queries.-- however, this explains my confusion as to why in the world the (domain joined) workstations were still able to ping the servers by hostname, while the other (non domain joined) computers on the exact same subnet were not able to.

so heres my question: how do we best resolve this issue?


do we allow the vlans to "forward net directed broadcasts", in essence undoing alot of the layer 3 segmentation by allowing IP layer broadcasts to flow across subnets

or

do we somehow find a different way to put hosts like the servers in the path of the net directed broadcasts (for example, by multihoming them and placing them physically in each VLAN/Subnet, or, with an 802.1q NIC)

or

do we find someway of allowing laptops that arent joined to the domain to authenticate the same way as domain joined computers in DNS and thus get added to the DNS servers host records?

----

How about DNS suffix search lists, are you providing any to the clients?

im not entirely sure what that means. sorry im not very well versed on DNS. can you explain?

I'm making the assumption that you have an AD-integrated DNS zone or a primary zone configured with "secure and non-secure" dynamic DNS.

it is an AD-integrated DNS zone with 'secure only' dynamic updates

As a last resort for fixing the DDNS, you can set DHCP to update the client records rather than the clients trying. You shouldn't need to do this, bu it's a thought in case you're desperate.

how would that effect computers that arent joined to the domain? we're trying to figure out the best route to handle this. right now we are going to try simply adding the computers hostnames to AD as computer/objects. as of now, none of the student non-authenticated computers were added in AD at all, they were only given DHCP reservations.

thanks again for your help[/quote]

So there's two problems: hostnames not resolving and non-domain clients not registering/updating their records in DNS...

Regarding the name resolution problem…
By the sounds of it, when the non-domain workstations try to ping hostnames, the domain suffix isn't appended to the hostname (since the computers aren't in the domain), so the name isn't resolved by DNS. I explain below how to solve that.

Regarding the computer account registration/update problem...
With your DNS setup (secure only dynamic updates), the non-domain computers won't be able to register their accounts in DNS (or else it wouldn't be 'secure only' ). This explains why they aren't updating their records or registering their records in DNS.

To fix this, you'll have to do two things. You'll essentially be achieving the third solution you mentioned.

On the DHCP server:
1. Right-click the DHCP server node on the DHCP MMC and choose Properties
2. On the Properties window, click the DNS tab
3. On the DNS tab, place the radio on "Always dynamically update DNS A and PTR records" and check "Dynamically update DNS A and PTR records for DHCP clients that do not request updates"
4. Click the Advanced tab, click the Credentials button, and enter a domain username and password (for now, a user with domain admin rights), and click OK
5. Then click OK

Since the non-domain computers can't update their own records or create their own records in DNS, you're basically setting up the DHCP server to do so on their behalf. The credentials that you specified are the credentials that the DHCP server will use to perform those DNS updates. But you still have to do the below step as well.

On the non-domain computer:
You'll have to ask the students to go to the properties of their NIC, then go to TCP/IP Properties, then click the Advanced button, then the DNS tab, then check the last box on the bottom that says "use this connection's DNS suffix in DNS registration." Then OK to finish, but while you're in this window, look where it says "append these DNS suffixes (in order)." That's the DNS suffix search list, but that question is no longer applicable now that I better understand your situation.

By the way, I'm assuming that the either a DHCP scope option or server option specifies the DNS domain name option.

Hope this gives you an idea of where to go

thanks for the response it is very helpful


as far as

By the way, I'm assuming that the either a DHCP scope option or server option specifies the DNS domain name option.

well, when i go to the MMC DHCP snap in, i see that the server itself (the furthest top listed item) is

(servername).(domain).local

but im guessing that really isnt what you are saying?

if i go to the scope options, the only thing we have set are the standard "003 router" and "006 DNS servers"

to do what you are suggesting would i have to add the "015 DNS Domain Name", set to our (domain).local, or am i barking up the wrong tree?


thanks again

to do what you are suggesting would i have to add the "015 DNS Domain Name", set to our (domain).local, or am i barking up the wrong tree?

You're looking at the right place.

Yes, add that option to the server options and all the scopes will get that option. Then anytime a client gets an IP address, their "Connection-specific DNS Suffix" on ipconfig will read (domain).local. This means that when they try to ping a hostname (as opposed to a fully-qualified domain name), that suffix will be appended to the hostname and DNS will resolve it.

This same option, in combination with everything else I said, will allow the non-domain clients to register their records in DNS as well