Moving to forwarder with a domain override seems to solve the issue.

@johnpoz said in DNS configuration:

So yeah back at the birth... So how is some 25-30 years later just now getting around to figuring out how dns works.

As someone else mentioned, you can't know everything and I hadn't focused on DNS. I am aware of how it works, with root servers etc., but my attention was elsewhere. All I was doing the other day is seeing how pfSense matched up with what was in the book and used Wireshark to see what was happening, as I often do.

@webdawg said in Is pfSense DHCP Server NON RFC Compliant:

Over the last two years MikroTik has been very good to me

For what it's worth, I also use Mikrotik at home, and our ISP uses them for their business customers. At my company, I have pfSense connecting my LAN to my ISP's Mikrotik. While I've been satisfied with the hardware and RouterOS, I'm a little disappointed that their support is not being straight-forward with you.

@kcallis said in Using Dynamic DNS service to host local host names:

NAT for both port 443 and 80

On NAT rule for NATting incoming connection on WAN - port 80 (VLAN, whatever - at this point VLAN is just a LAN) device - web server.
And another NAT rule for port 443
Both TCP-only, probably.

@kcallis said in Using Dynamic DNS service to host local host names:

if I need to make use of 443 to the (for instance) mail host and 443 for my web server which is another host?

Ah, welcome the the club !
A NAT rule includes a port - and taht port will get Network Address translated to another device, some where on LAN.
But, guess what, NAT is PAT most of the time, so, PAT port 444 on WAN to port 443 on LAN (your web mail server).
Inform users that they should use http://your-dyndns.tld:444 and they see the login screen of the web mail web server.

Any is deprecated and really shouldn't be used any more. Many a site will not respond when asked for that.

But yeah I would think something really major would have to be going on for them not to be working.. Its an anycast address so even if one region of the world was down you should get an answer from another location, etc.

We really need some useful info from the OP if he wants our help.

@tomstephens89 I will love it too!! it is very important today to have such a implementation while layer 3 switch are more chip and networks grow up!

Yes it started to work but I wanted to understand why. So I was changing some options and I found out that it won't be fixed for default protocol timings in advanced options of WAN interface.

To solve it is enough to set timeout to higher value like below
fedad313-5538-4b2d-b3f6-e510782574b8-image.png
I had it like that from the start.

... and now I don't understand it at all :)

I use this method to block adult websites: http://www.google.com/preferences.

@johnpoz Back from a long break.

I think I can explain what's happening in terms of 160.x resolution. I used to own a domain that I let expire. I bet some entitiy in HK bought that domain for reselling or nefarious purposes ;). Now, since I no longer own that domain, but some of my internal lan hosts still references to that FQDN, the name resolution requests get sent out to the forwarder as configured on the pfSense which return 160x address. So, there we have it..

Thanks for your help, @johnpoz !

if he is saying NOTHING at .dev resolves he prob having a hard time talking to the NS for that .tld

;; QUESTION SECTION:
;dev. IN NS

;; ANSWER SECTION:
dev. 21600 IN NS ns-tld1.charlestonroadregistry.com.
dev. 21600 IN NS ns-tld2.charlestonroadregistry.com.
dev. 21600 IN NS ns-tld3.charlestonroadregistry.com.
dev. 21600 IN NS ns-tld4.charlestonroadregistry.com.
dev. 21600 IN NS ns-tld5.charlestonroadregistry.com.

You would need to be able to talk to them to find the NS for git or get.dev

Do a simple dig +trace to validate where its failing in your resolving.

[2.4.4-RELEASE][admin@sg4860.local.lan]/: dig get.dev +trace ; <<>> DiG 9.12.2-P1 <<>> get.dev +trace ;; global options: +cmd . 66288 IN NS c.root-servers.net. . 66288 IN NS k.root-servers.net. . 66288 IN NS g.root-servers.net. . 66288 IN NS i.root-servers.net. . 66288 IN NS f.root-servers.net. . 66288 IN NS j.root-servers.net. . 66288 IN NS a.root-servers.net. . 66288 IN NS e.root-servers.net. . 66288 IN NS b.root-servers.net. . 66288 IN NS d.root-servers.net. . 66288 IN NS m.root-servers.net. . 66288 IN NS l.root-servers.net. . 66288 IN NS h.root-servers.net. . 66288 IN RRSIG NS 8 0 518400 20190610050000 20190528040000 25266 . 0H4mdqwNzsPc9zj1uE2ibA5aq7uQfushwBzqoGyZ8xfdo6TvP/QOOdLr JDd5mOKyAPxcSE3BbzmrXehBGma2NtXLKtfj3lrJskAU6N0EFPUcuVzr fAlv0SoB2XiE5Edt804/3xAaplTzHFpBcrZ55yJAmC74R1F0M7EDlJva 6qcPdbY8gatOdKgEbERfhic5JPqMd3MbVkCOnuddfbABCKXBmT/UqRDQ yHAF8sgBsQVC0AjDKXA40lazzJL4G66fBFDWYCox4bUuI6hECgOvR9DQ 8rSqkrDfiJLGSzjlSwBEjL2We3jrPZBsEF6c+VgZCsNh4F/BuEJDrR9p zgjYtw== ;; Received 525 bytes from 127.0.0.1#53(127.0.0.1) in 0 ms dev. 172800 IN NS ns-tld3.charlestonroadregistry.com. dev. 172800 IN NS ns-tld4.charlestonroadregistry.com. dev. 172800 IN NS ns-tld5.charlestonroadregistry.com. dev. 172800 IN NS ns-tld1.charlestonroadregistry.com. dev. 172800 IN NS ns-tld2.charlestonroadregistry.com. dev. 86400 IN DS 60074 8 2 B942E2CE5AEBF62FCA59D05707E6DBB795211D540D8ADBA02E9E89E8 33424785 dev. 86400 IN RRSIG DS 8 1 86400 20190610170000 20190528160000 25266 . oJCQxMsllCe0xNwvMe7/5iBx/iLMufP+n4mwf11MDmgOcme/Eb9a2/Xe NWkpUqnTWHkZgNapX5bTDQv0Yjn4FFL4z68nM/Y9+8xeJnPB9s5ILogL AkJSVEA9dR9WM/AdMdZljg8YztIckFrrIdYoO6f+AZICV60hvOPtPZ9w OCGhMn9Y972OcON1R3eYqchLrftJN+mX6yer+DYR3vUP5PU6Syh9rUYy dNFbRD0VAK2kntM46iNv/QnC2IjaM6Lz6DnuMiWuTzLqNZkxF8UDOmDG mHFj3dfJFCRFUg6H7scvJD4q9ZJqz5ed8XYJw8PBzFVe3aCVeT6JnqA0 4b6Wlg== ;; Received 727 bytes from 2001:dc3::35#53(m.root-servers.net) in 78 ms get.dev. 180 IN NS ns1.zdns.google. get.dev. 180 IN NS ns2.zdns.google. get.dev. 180 IN NS ns3.zdns.google. get.dev. 180 IN NS ns4.zdns.google. ;; Received 119 bytes from 216.239.34.105#53(ns-tld2.charlestonroadregistry.com) in 116 ms get.dev. 300 IN A 216.239.32.29 get.dev. 300 IN RRSIG A 8 2 300 20190627160939 20190528160939 18228 get.dev. g2I2US1nIcPKuadX58qSW5O1RKTKRGxh8xIyFS/EdYFbktjSytQmWgbc 4s0IbkWmkFvYYpIchd2UdaOYz+NoImEaztC9pTy6ohXRId1EmPIzkK4R sCGE7Y7zEtLUmYSB7B6EzQGKTEsXL3n//74NI05CNUHQu9Dpz8q1Zhx5 gWA= ;; Received 219 bytes from 216.239.38.114#53(ns4.zdns.google) in 23 ms [2.4.4-RELEASE][admin@sg4860.local.lan]/:

The script there helped me mitigate the renew issue.

This accomplished exactly what I was after... I didn't event think about putting in a top-level domain.

Thanks for the help!

@kdi-isusovci said in Wrong DHCP subnet:

Sorry, I found the solution. It was one of AP's that I accidentally typo, I setup it's IP as 10.100.0.12 and I needed 10.100.100.12, and also it was DHCP turned on.

Is there any solution to stop users to connect their AP's and setup it without me? It shows that all internet can crash cuz of that.

Thanks!

Some managed switches will allow only specified MAC addresses on each port.

UPDATE

Apparently OpenDNS is using a different encryption library.

https://www.opendns.com/about/innovations/dnscrypt/

Can't help you with DNSBL - don't use it myself, so no experience.

Amazing.

Sorry, the other DNS seems to be broken. It can be pinged but pfSense cannot get a response from it when trying a DNS lookup.
Thanks, Mike

PfSense version: 2.4.4-RELEASE-p2 at both side.

Please consider this closed. Compression option on the vpn connecting was wrong.