Well you going too have to show us what you added, and how you think it didn't work..

Use these all day every day - clicky clicky works..

Thanks ryanborstelmann!

Indeed, a CenturyLink issue that they have now corrected.

Hi,

Add this info to the equation :
8.8.8.8 is a huge DNS cache with some additional functionalities **.
If "8.8.8.8" doesn't know the answer, it will behave exactly like the pfSense Resolver : it will ask the 13 root server, and drill downwards.

The Resolver can only work. If it doesn't, two things might happen :

Resolver can't connect to at least one root DNS server => bad connection ? Your ISP (or VPN) is playing tricks on you ? You mentioned "well known sites" so I can rule out faulty DNS name servers I guess.
(third option : your "well known sites" do not like your VPN IP, sites like Netflix blacklisted most of them already.)

If asking the root servers (directly) doesn't work well, consider the Internet as broken …. and that did not happens up until today.

** like Google knowing what your are doing, where, with who and when.

If you don't "feel" it, there's not really anything to do.

@johnpoz:

You setup a in-addr.arpa domain, ie reverse zone.

0.168.192.in-addr.arpa

if your using 192.168.0, etc..

Thank you johnpoz.
The reverse dns zone is configured on the AD DNS.
You mean configure it in the pfsense as well?
It has to be in sync with the ad dns to be up to date.

EDIT: Got it. I entered the reverse zone in domain overrides. Thanx!

Hi!

Thanks for your answers, you were very kind!

So, it seems to me that my solution does not work and I have to think something else.

I would like to ask you if you had, based on your experience, any suggestion to achieve my goal, which is: have a software router which detect when there is a new VM inside a VPC.

@Derelict:

I wonder if your host is looking up IPv6/AAAA or something that isn't present so you get NODATA or NXDOMAIN for that since you have the zone set to static.

This definitely seems plausible, how would I check this?

Nevermind, I found the option to set the Root Path for individual static dhcp entries.

Thank you @jahonix - that's exactly what I needed.  :D

@Grimson - sorry, your post does not answer my question. Directing a newb with a specific question to the whole user manual is not helpful.  ???

That would be good advice for specific guidance on a pfSense issue.  I've been in networking for many years and I've never heard of smart DNS either, and we get a lot of newbies here who sometimes use bizarre terms or mix-up their jargon.

Not at this time.

The Cache/Proxy forum is the best place for squid & squidguard questions.

When you make any changes to squidguard, are you going back to the General Settings tab, and then clicking Save - Apply?

No issues last night - thanks for the help!

@kpa:

@behemyth:

Is there any kind of security worry if you take the internal-ca cert off the pfsense box and import it into a computer for example, so that the machine trusts anything presenting a cert that is issued by the pfsense box? Wouldn't generating a new cert thats issued by the internal-ca for the web-url (for example) to access the pfsense gui and trusting it be better then just installing the primary ca cert and trusting everything? Seems like someone could use this to generate new possibly fake certs.

Sorry for the newbish questions - I'm fairly new to doing this whole cert thing, and learning as I go. This is for my home, we have people at work that issue them for me :)

No, the CA certificate is a public key, meant to be copied and transferred to anyone who wants to verify the authenticity of any certificate generated by that particular CA. The only entity that can generate certificates is that one that possesses the secret key of the CA, that's you on your pfSense system.

Ahh ok, Thanks. That explains it a lot better.

A bit late here, so I read quickly.

How do I set it to start manually? I think it is set to start manually though. If i uncheck enable DNS BIND server, uncheck resolver (which it also has been) and uncheck forwarder (which it also has been) a named daemon starts and runs on boot.

This is strange. Probably manually starting isn't a good idea.
So, unbound (Resolver) and dnsmasq (the forwader) should be shut down - and bind enabled.

Also, if one of the packages changes the config (by you in the GUI) it's oftens seen that most services restart.
If bind didn't get restarted, install "Service Watchdog", he will take care f it.

If you want to used bind for internal and external resolution - as a name server for a public domain - it better be always up.

Nice touch !

The DHCPDISCOVER means that an initial UDP packet came through, because logged and answered as such on pfSEnse.
One tends to say that the "data path" = the connection works.

The DHCPOFFER uses the same path back and probably never made it.

(or : worse : the mobile device didn't understand the "DHCPOFFER"  from pfSense, and then you're out of business right away, mobile device are hard to debug  ;)).

Your welcome - so why exactly do you prefer the forwarder over the resolver.  I personally much rather resolve and have full dnssec support..