Making PFSENSE as DNS for Active Directory

edanpedragosa

It may be different in your scenario but I always notice that when I point my client to the AD for DNS, when the internet goes down, some of the clients need to flush their dns to reconnect to some sites. The AD is forwarding the request to the PFSENSE gateway fine after flushing the DNS.

Here's what's happening in my case before:

CLIENT –-> AD ---> PFSENSE GATEWAY

if for some reasons the internet gets cut in the PFSENSE GATEWAY, the CLIENT needs to flush the DNS to resolve again properly.

My setting now is:

CLIENT ---> PFSENSE

\ |
AD

and is now working fine as expected.

Sorry if it causes some confusion for some but this works for me.

Just sharing...

johnpoz

Well what are the ttls on the stuff that not requesting? What is in your clients cache? What is our neg cache setting? By default 300 seconds I do believe.. Do you understand what a neg cache is?

eNORm

Hi,

I've been running this setup for a month now. It worked nicely, but when I needed to join a computer to the domain it would not work. I had to manualy change the dns-server on the computer that I wanted to join to point to AD-DNS. Did not help that AD-DNS was the secondary DNS-server that the pfsens dhcp-server gave out.

Is there something missing form the advance settings in pfsense unbound dns resolver?


server:
local-data: "_ldap._tcp.oslo.expology.no. 600 IN SRV 0 100 389 elektron.oslo.expology.no."
local-data: "_ldap._tcp.Default-First-Site-Name._sites.oslo.expology.no. 600 IN SRV 0 100 389 elektron.oslo.expology.no."
local-data: "_ldap._tcp.pdc._msdcs.oslo.expology.no. 600 IN SRV 0 100 389 elektron.oslo.expology.no."
local-data: "_ldap._tcp.gc._msdcs.oslo.expology.no. 600 IN SRV 0 100 3268 elektron.oslo.expology.no."
local-data: "_ldap._tcp.Default-First-Site-Name._sites.gc._msdcs.oslo.expology.no. 600 IN SRV 0 100 3268 elektron.oslo.expology.no."
local-data: "_ldap._tcp.f8f5a2da-93c9-414a-9347-426c5b294d2f.domains._msdcs.oslo.expology.no. 600 IN SRV 0 100 389 elektron.oslo.expology.no."
local-data: "177ea4ed-fe67-4a10-bd07-b021feeae604._msdcs.oslo.expology.no. 600 IN CNAME elektron.oslo.expology.no."
local-data: "_kerberos._tcp.dc._msdcs.oslo.expology.no. 600 IN SRV 0 100 88 elektron.oslo.expology.no."
local-data: "_kerberos._tcp.Default-First-Site-Name._sites.dc._msdcs.oslo.expology.no. 600 IN SRV 0 100 88 elektron.oslo.expology.no."
local-data: "_ldap._tcp.dc._msdcs.oslo.expology.no. 600 IN SRV 0 100 389 elektron.oslo.expology.no."
local-data: "_ldap._tcp.Default-First-Site-Name._sites.dc._msdcs.oslo.expology.no. 600 IN SRV 0 100 389 elektron.oslo.expology.no."
local-data: "_kerberos._tcp.oslo.expology.no. 600 IN SRV 0 100 88 elektron.oslo.expology.no."
local-data: "_kerberos._tcp.Default-First-Site-Name._sites.oslo.expology.no. 600 IN SRV 0 100 88 elektron.oslo.expology.no."
local-data: "_gc._tcp.oslo.expology.no. 600 IN SRV 0 100 3268 elektron.oslo.expology.no."
local-data: "_gc._tcp.Default-First-Site-Name._sites.oslo.expology.no. 600 IN SRV 0 100 3268 elektron.oslo.expology.no."
local-data: "_kerberos._udp.oslo.expology.no. 600 IN SRV 0 100 88 elektron.oslo.expology.no."
local-data: "_kpasswd._tcp.oslo.expology.no. 600 IN SRV 0 100 464 elektron.oslo.expology.no."
local-data: "_kpasswd._udp.oslo.expology.no. 600 IN SRV 0 100 464 elektron.oslo.expology.no."
local-data: "_ldap._tcp.DomainDnsZones.oslo.expology.no. 600 IN SRV 0 100 389 elektron.oslo.expology.no."
local-data: "_ldap._tcp.Default-First-Site-Name._sites.DomainDnsZones.oslo.expology.no. 600 IN SRV 0 100 389 elektron.oslo.expology.no."
local-data: "_ldap._tcp.ForestDnsZones.oslo.expology.no. 600 IN SRV 0 100 389 elektron.oslo.expology.no."
local-data: "_ldap._tcp.Default-First-Site-Name._sites.ForestDnsZones.oslo.expology.no. 600 IN SRV 0 100 389 elektron.oslo.expology.no."
local-data: "oslo.expology.no. 600 IN A 192.168.123.1"
local-data: "oslo.expology.no. 600 IN A 192.168.123.2"
local-data: "DomainDnsZones.oslo.expology.no. 600 IN A 192.168.123.1"
local-data: "DomainDnsZones.oslo.expology.no. 600 IN A 192.168.123.2"
local-data: "ForestDnsZones.oslo.expology.no. 600 IN A 192.168.123.1"
local-data: "ForestDnsZones.oslo.expology.no. 600 IN A 192.168.123.2"
local-data: "gc._msdcs.oslo.expology.no. 600 IN A 192.168.123.1"
local-data: "gc._msdcs.oslo.expology.no. 600 IN A 192.168.123.2"

-eNORm-

johnpoz

Why would you do this??? Point your clients to your AD server!! If you want to use something other than MS AD for your dns - then use something like bind. Unbound is not really meant to be a authoritative server for any domain. Nor does it do any sort of zone transfers, etc.. etc..

It is not the correct choice to run active directory dns..

"Unbound is a validating, recursive, and caching DNS resolver"

Do you see authoritative listed there??

jahonix

People first have to fully understand the adjectives you listed before putting them into use. That's probably what most users lack.
I heard rumors that it's more than resolving a host name to an IP address. :o

gjaltemba

I would like to give this a try but my setup uses AD DHCP to register the leases into AD-DNS.

In this scenario, how does the AD-DNS get populated?

johnpoz

it DOESN'T there is NO POINT to this at ALL - NONE!! You have a freaking AD running with DC.. Run DNS on it - point your members to it.. There is ZERO benefit to trying to do with with a non authoritative caching resolver like unbound..

coachmark2

Agreed. Let AD do DNS. Seriously. There is no reason to have anything else doing DNS for your domain. AD relies HEAVILY on DNS to the point where it ceases to function without it. Adding computers to your domain, anything using netdom, any MMCs you use to manage things, and heck, even basic logons for your users! If you want to do this, you're introducing complexity where there is no reason.

The argument is slightly different for AD DHCP. That does integrate nicely with DDNS, but DDNS is not some special secret wizardry that only Microsoft can do.

jahonix

You're a bit late for the party but thanks for your contribution.

plaj

Great hackersoft !
You made my day.
I was googleing for a while for a way to authenticate AD sessions over an IPsec VPN with NAT-T, on a site without an AD DC.
Added the DNS lines in the Unbound DNS Resolver Advanced options as you described, and a Host Override for each of my DCs on their NATed IP address and it finally works !
My computers can now authenticate on a DC controller on the other side of my Ipsec tunnel…
Also tried to add a new computer to the domain, and it's working too.

Perhaps there's another way to perform that... but this way works great for me.
Why am I not fallen on it earlier ? :)
Many thanks for this sharing !