Cannot resolve Front End firewall hostname
-
"What would be the best way to leverage just one internal DNS server?"
Point your clients to it, create whatever records you wan in it.. Allow for dynamic registration for devices that support that. Now sure what your not understanding? You don't know how to create a A record in MS dns? You don't know how to allow registration from non ad members?
Your only thing is stuff in your dmz and or edge normally would not need to resolve any of these devices I would think, since they are in dmz really wouldn't have access to them anyway. If you have rules between your vlans you would have to allow for dns between the vlans to your dns.
-
"What would be the best way to leverage just one internal DNS server?"
Point your clients to it, create whatever records you wan in it.. Allow for dynamic registration for devices that support that. Now sure what your not understanding? You don't know how to create a A record in MS dns? You don't know how to allow registration from non ad members?
Your only thing is stuff in your dmz and or edge normally would not need to resolve any of these devices I would think, since they are in dmz really wouldn't have access to them anyway. If you have rules between your vlans you would have to allow for dns between the vlans to your dns.
I know how to add an A record in MS DNS. I'm not sure how to allow dynamic registration from non-ad members but I'm sure I could figure that out.
So for the fe fw, be fw, and edge fw I just need to add static records on the AD DNS server? The HUB and EDGE mail servers do need to resolve each other's hostnames.
And for the fe and be fw, I don't need to change anything in their DNS servers?
Yes, the creation of rules between vlan's is just an easy step using UDP 53.
-
Well I wouldn't want stuff in dmz going to my AD dns.. So you would have to use some other dns for them.. Why would stuff in your dmz need to resolve your internall stuff?
-
Well I wouldn't want stuff in dmz going to my AD dns.. So you would have to use some other dns for them.. Why would stuff in your dmz need to resolve your internall stuff?
The only DMZ server that needs to resolve the an internal server (Hub Transport) is the Edge Transport, that's how Exchange works as you may have known.
-
well then punch a pinhole in your dmz and have it query your AD dns.
-
Now, there's another weird thing that's going on with my DNS. There's nothing wrong with the setup in the dropbox picture I've posted here. Computers in the testlab LAN, when used with nslookup can properly resolve, say, www.google.com.
On my other pfsense box, in another home, when I do nslookup on one of the computers in its LAN it appends the connection-specifc DNS suffix that its LAN connection has. Of course, if the computer gets its DHCP assignment from pfsense, pfsense will assign a connection-specific DNS suffix to it. So let's say, I do "nslookup www.google.com" it returns the result for www.google.com.domain.com, domain.com being my domain. I know that that happens when the address you query is unqualified. So if I query the complete FQDN with the "." in the end, "nslookup www.google.com.", then it gives me a good result. I thought there was nothing wrong with this but why is it not giving me the same behavior as the one above? Take note, the computers in the testlab LAN in the situation above is not in any domain and so they have the exact same setup as the situation in this paragraph.
What gives?
-
I don't know what gives, but all my Windows clients have this behavior. I can:
ping www.google.comAnd underneath the ping resolves an IP address for a real public www.google.com - somehow ordinary programs that want name resolution do it OK.
But if I
nslookup www.google.comSomehow nslookup always sticks on the domain name suffix/es and tries for www.google.com.mycompany.example.com.
So in nslookup I always put the root domain dot at the end:nslookup www.google.com.A quick search found this Microsoft article on how their nslookup works: nslookup www.google.com
Nslookup will always devolve the name from the current context. If you fail to fully qualify a name query (that is, use trailing dot), the query will be appended to the current context. For example, the current DNS settings are att.com and a query is performed on www.microsoft.com; the first query will go out as www.microsoft.com.att.com because of the query being unqualified. This behavior may be inconsistent with other vendor's versions of Nslookup, and this article is presented to clarify the behavior of Microsoft Windows NT Nslookup.exe
-
I don't know what gives, but all my Windows clients have this behavior. I can:
ping www.google.comAnd underneath the ping resolves an IP address for a real public www.google.com - somehow ordinary programs that want name resolution do it OK.
But if I
nslookup www.google.comSomehow nslookup always sticks on the domain name suffix/es and tries for www.google.com.mycompany.example.com.
So in nslookup I always put the root domain dot at the end:nslookup www.google.com.A quick search found this Microsoft article on how their nslookup works: nslookup www.google.com
Nslookup will always devolve the name from the current context. If you fail to fully qualify a name query (that is, use trailing dot), the query will be appended to the current context. For example, the current DNS settings are att.com and a query is performed on www.microsoft.com; the first query will go out as www.microsoft.com.att.com because of the query being unqualified. This behavior may be inconsistent with other vendor's versions of Nslookup, and this article is presented to clarify the behavior of Microsoft Windows NT Nslookup.exe
Ping works in every situation as it seems that it does not work the same way as nslookup.
That's exactly the behavior I notice in the network in my home. I expect it to work that way (it will append the suffix) as what I've read in several websites say the same thing you layed out in your reply.
This means that my test setup (the network diagram in dropbox) does not work right. Anybody have an idea what's going on here?
EDIT: Oh and by the way, the cause for this issue is definitely not because of the nslookup version as I've used the same test machine on both networks in question as to avoid component differences.
-
BUMP!
-
So if you don't like your machine doing suffix search etc.. change the setup do do the correct order or not do it at all.
Still not grasping what you feel is not working? Again I will say this, members of domain should only point to authoritative dns for the AD domain.. Quite often that is the DC of the domain.. Pointing to pfsense be it running unbound, or dnsmasq, a bind derver, some other forwarder like your soho router, googledns directly is going to cause you grief.
Doing such a setup other than pointing to AD dns is for advanced use and need only..
-
Sorry, I think you were referring to the first question in this thread. My main issue now (in this same thread) starts from reply # 18 and a few posts after that. Can you give that a quick read for me?
Thanks.
-
Don't be hijacking threads… Create your own.
-
Don't be hijacking threads… Create your own.
This is MY thread and I thought my question is related to DNS, so I posted here. Anyway, I'll just transfer the contents of this thread to a new thread.
