Cannot resolve Front End firewall hostname
-
and what does the frontend do? Seems pretty simple to just query it - does it know its own name?
C:>dig @192.168.1.253 pfsense.local.lan
; <<>> DiG 9.10-P2 <<>> @192.168.1.253 pfsense.local.lan
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 8830
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;pfsense.local.lan. IN A;; ANSWER SECTION:
pfsense.local.lan. 3600 IN A 192.168.1.253;; Query time: 4 msec
;; SERVER: 192.168.1.253#53(192.168.1.253)
;; WHEN: Thu Feb 05 22:50:41 Central Standard Time 2015
;; MSG SIZE rcvd: 62So query the front and for its name??
-
This may sound obvious, but have you tried entering an A record for your frontend firewall on the DNS service running on your choke (backend) firewall?
-
and what does the frontend do? Seems pretty simple to just query it - does it know its own name?
C:>dig @192.168.1.253 pfsense.local.lan
; <<>> DiG 9.10-P2 <<>> @192.168.1.253 pfsense.local.lan
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 8830
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;pfsense.local.lan. IN A
;; ANSWER SECTION:
pfsense.local.lan. 3600 IN A 192.168.1.253
;; Query time: 4 msec
;; SERVER: 192.168.1.253#53(192.168.1.253)
;; WHEN: Thu Feb 05 22:50:41 Central Standard Time 2015
;; MSG SIZE rcvd: 62So query the front and for its name??
It does know its name. My servers in the DMZ (LAN side of frontend) can query the frontend just fine. Heck when you do a Diagnostics -> DNS Lookup in the backend firewall, it can even resolve the hostname of the frontend firewall.
This may sound obvious, but have you tried entering an A record for your frontend firewall on the DNS service running on your choke (backend) firewall?
Well, that will definitely work. But my goal here is not to do that because my understanding is that if a client on the LAN side of the choke firewall queries for the hostname of the frontend, the choke DNS server will try to look that entry in its local database/cache first and if it doesn't find it will forward that query of the frontend. Now the frontend definitely has that entry in its local database/cache and should return an answer back to the choke firewall and ultimately to the end client. Does that make sense?
-
But your problem could be that the backend is in yourdomain.tld and sees no record for frontend.yourdomain.tld so never forwards it. As you stated they are in the same domain.
-
What Johnpoz said.
If both your firewalls are nameservers for the same domain, then the choke will never forward the request onto the other firewall since the choke will consider itself to be the SOA for that domain. Just add the entry for the outside firewall to your choke and you're there.
-
Ahh, got it! So the only requests that the backend will forward are those outside of its domain since it is the SOA for the domain, correct?
-
Yes
-
Now one of the networks behind the choke firewall has a domain controller in place which of course in itself is a DNS server. It is set to forward DNS requests to the choke firewall also. From a client in that same domain, it cannot resolve both be and fe hostnames and I'm assuming it's because of the same reason you guys stated.
The other networks behind the choke are only in a workgroup and they use the choke as their preferred DNS and DHCP servers and so their hostnames get registered in the cache of the choke.
Now how do I make the computers connected to the domain controller resolve the computers in the other workgroups? Should I manually add them as individual A records in the internal domain DNS server? That would be cumbersome if there are several other workgroup computers. Is there any other way?
-
let me guess this AD dns is the same domain name?
This seems really flawed.. If your going to have authoritative domain nameserver. All clients need to query this, or the nameserver they query should know to ask that nameserver for that domain. Conditional forwarder, ns record, something.
You should never have 3 different nameserver that don't contain the same data think they are authoritative for the same domain.
why don't you just create other domains or subdomains for these different groups of devices. Or just leverage 1 nameserver, say your AD dns to maintain all records. You can setup AD dns to allow for registration of clients that are not members of the domain for dynamic clients no matter where they get dhcp from. Anything else that is static could have A records created in your ad nameserver.
I would suggest rethink your nameservices. More than happy if you draw it out so we can get the big picture of how your attempting to do it.
-
let me guess this AD dns is the same domain name?
This seems really flawed.. If your going to have authoritative domain nameserver. All clients need to query this, or the nameserver they query should know to ask that nameserver for that domain. Conditional forwarder, ns record, something.
You should never have 3 different nameserver that don't contain the same data think they are authoritative for the same domain.
why don't you just create other domains or subdomains for these different groups of devices. Or just leverage 1 nameserver, say your AD dns to maintain all records. You can setup AD dns to allow for registration of clients that are not members of the domain for dynamic clients no matter where they get dhcp from. Anything else that is static could have A records created in your ad nameserver.
I would suggest rethink your nameservices. More than happy if you draw it out so we can get the big picture of how your attempting to do it.
That's what I thought. I'm just looking for a way on how to integrate everything so that everything resolves properly with each other automatically. Leveraging the AD DNS seems to be a very good idea but I'm not sure where to start. Here's a quick maps view of my test network in VMWare ESX:
https://www.dropbox.com/s/9sybazk7sesg5br/Capture.JPG?dl=0
Basically, the production, test laboratory, and guest lan's are separated by VLAN's and go through the trunk connected to the backend fw. Everything else seems to be self-explanatory.
Prod LAN has the AD DNS and all clients in that LAN are pointed to the AD DNS as their preferred DNS server. The AD DNS is setup to forward to the backend fw DNS.
The clients in the test laboratory and guest LAN's are pointed to the backend fw DNS as their preferred DNS server.
The backend fw is setup to forward to the frontend fw.
The client in the DMZ network (EDGE) is pointed to the frontend fw DNS as its preferred DNS server.
The frontend fw is setup to forward to the Google DNS servers.
What would be the best way to leverage just one internal DNS server?
-
"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..
