Pfsense 2.3 DNS replication options
-
Hi,
I was using Bind for my DNS until I upgraded to pfsense 2.3 where that package is no longer available. I would like to know what options are available now that would be included in pfsense 2.3.
I have two sites linked by VPN with a pfsense box at each site. Site A has address range 192.168.0.0/24 and site B has 192.168.1.0/24 served from each pfsense DHCP respectively. I would like each site to register DHCP leases to a DNS included with pfsense and replicate the DNS entry to the other site.
Example:
hostname1 or hostname1.internal.foo.com resolves to 192.168.0.123
hostname2 or hostname2.internal.foo.com resolves to 192.168.1.123Under Bind, I was using the same sub-domain for all leases from sites A and B (<hostname>.internal.foo.com) and there for could resolve any hostname independently of the site only by hostname. Is anything still possible with Unbound, dnsmasq, etc with automatic DHCP leases registering to the DNS service?
Thanks!</hostname>
-
run bind on something other than pfsense if you want run a full authoritative server with zone transfers.
Your other easier option and better one if you ask me is your sites should have their own subdomain.
hostname1 or hostname1.sitea.internal.foo.com resolves to 192.168.0.123
hostname2 or hostname2.siteb.internal.foo.com resolves to 192.168.1.123then you just need to create a domain override pointing to the other pfsense server for the domain being used on that site.
-
How would I setup the DNS search list with the different site-specific sub-domain.
From Site A, I want to connect to hostname2 without using the FQDN which is located at site B.
Under the DHCP server, would I be added DNS suffixes in the Domain search list? Listing both sitea.internal.foo.com;siteb.internal.foo.com and using the domain override for each site so it would search both sites before going out to a public DNS.
-
yeah add it to your clients search list.. not sure I understand the question, clearly you understand suffix search from your question. What is your clients windows or linux and I can show you how to set it up.
But sure you can hand it out via dhcp.. if you client pays attention to that would be up to the client.
On a side note using hostname is a really bad practice, you should always use fqdn, I would just train your users to start using fqdn all the time.
-
It's a mix of Linux, Mac and Windows client machines so pushing out a search list from the DHCP server would be ideal. I completely agree best practices would be using the fqdn instead of the hostname.
The issue I face is some clients will be connecting from either site A or site B, a site specific fqdn is a little more confusing to the users instead of global fqdn like hostname1.internal.foo.com. Users tend to make local shares between each other's computers and I don't want to increase support calls because a site specific fqdn worked one day but not the next.
-
" Users tend to make local shares between each other's computers"
Wow!!! Your kidding… I have been in the field for many years.. This has never been allowed or even discussed to be allowed.. There are HUGE security concerns with such a setup.. Is this some sort of school or co-op thing where users just byod.. And have full admin, etc.. I don't see how user level shares between machines in a corp would ever be allowed.
In the options sections of pfsense dhcp is where you would send out the dhcp search list.
Normally the client would auto search the domain they are in.. And then go through additional search list.. So you really should only have to add the other site in the search list at each site... So sitea would have siteb, and siteb dhcp wuld have sitea in the search list.
I could fire that up and see what a windows and linux client do with it.. I don't have any mac to test with.
So users are smart enough to create and share their own stuff, but can not figure out how to use a fqdn?? that they use pretty much any website they ever go to ever... I really don't see how telling user to use a fqdn should be an issue. Do these sites have names.. Not like my example sitea and siteb... Call them what they are - like if cities chicago.domain.tld or newyork.domain.tld etc.. So these users don't know what site they are in or what site the other one is? And they don't know if the person they want to share files with is even in the same building as them?
-
Yes it's a boyd, it's kind of like a community organisation with get together at two different sites. Servers are the only static devices that don't change sites. The users have been used to using the generic fqdn *.internal.foo.com and I was asked to come up with an equivalent solution. Security is very low on the list as their goal is to encourage collaboration and ease of use for everyone. I have a different point of view but it's not my call at the end of the day.
I'll see how feasible it would be to implement the site specific fqdn but may temporarily set things up with short hostnames and transition over to proper site fqdn over the coming weeks/months.
You screenshot is exactly what I was thinking. Thank you very much for your help!
-
No problem.. Let us know how it works out or if you have more question.. So your working in the wild wild west of networking ;)
I can for sure see it when you have tech based users.. But in your typical company setup, byod would be a help desk nightmare….
You could always just extend your networks across the vpn at Layer 2 and let them broadcast for host names ;) hehehe
