flush your cache… Remember your still going to see NS listed with IPv6 for domains that have IPv6 NS... But if pfsense has no IPv6 address that unbound can use for outbound queries then there would be no way for pfsense to talk to them... So in the cache you will see none have been talked too..

:-[ :-[ :-[ Me ask,  me answer  :-[ :-[ :-[

As it turned out, I was over-engineering approximately thirteenfold or so.
Of course, it would be nice to master all these bloody DHCP details, but.
The actual solution to replace CPE by pfSense was much easier.

It turns out (in this particular configuration) [b]the WAN interface does not need any IPv6 global address on it.
An IPv4 address together with a link-local address will do.
Very counter-intuitive from ppl coming from v4 world, eh?

As one of the ways of mitigation, the previous dhcp v6 client file could be copied off the /var/etc/ directory. Then an alternative DHCPv6 configuration should built up elsewhere (e.g. below /root/) based on its example. The main reason to do so was the limitless love towards the old style CLI and debug cycle. The secondary reason was the necessity to correct the script name that GUI has kindly offered during the previous experiments.

#      script "/var/etc/dhcp6c_wan_dhcp6withoutra_script.sh"; # This default remnant is WRONG
        script "/var/etc/dhcp6c_wan_script.sh"; # We need to go with RA

Afterwards, the alternative DHCP v6 file should be activated via Interfaces/WAN GUI and LAN/OPTX interfaces made "tracking" WAN as usual.

This particular configuration dictates we'll forget about IA-NA:

#      send ia-na 0;  # NO global IPv6 addr on WAN. Link-local only.

id-assoc na 0 {}; # Thrown off. (We don't speak, you don't ask.)

Last but not least, with Linux clients, I was able chose "Unmanaged" as the "router type" (on RA page). DHCP server could still be useful for entertainment purposes (communicating any dynamic value to hosts) but Global Scope addresses will now just appear from nowhere, via PD and RA mechanisms. Sic the v6 magic!

Perfect. Thanks!

@johnpoz:

hehehe Your almost on the neg side ivor ;)  I will be sure to throw you some applauds to get you leaning more on the + side…

Working hard on my smites!

I want to know how to block the dhcp traffic from my Lan to the ISP modem.

???

If you have pfSense between your LAN and the modem, then what happens WRT DHCP on the WAN side shouldn't appear on the LAN.  Also, consider how DHCP works.  A client REQUESTS and a server provides an address.  Any DHCP request on your LAN will not make it past pfSense.  So, any device using DHCP on your LAN should get an address from pfSense and not the ISP.  The only exception is if you configured pfSense as a DHCP relay.

Bottom line, it's unlikely you're seeing DHCP addresses from your ISP on your LAN.  Why do you think that's happening?

Confirmed that disabling Avahi fixed this problem. Thank you!

@KOM:

Diagnostics - ARP Table will give you a list of clients that pfSense has seen lately, and compare that against your dynamic range.

Arp caches delete entries in a fairly short time.  Also, it requires the pfSense computer to actually receive frames from the devices.

A reverse proxy like HAproxy package can do that, I believe.

https://doc.pfsense.org/index.php/Haproxy_package

@johnpoz:

dnsmasq has an option domain-needed

Exactly. This is what I had in my mind, I was using it on my openwrt travel box in the past.

Definitely it will be not a big deal to always use host.domain, today it just popped up during some troubleshooting where it was just quicker to type ping gw

Thanks for all the suggestions!

This is just happened:

C:\Users\Hitech95>ping google.it Impossibile trovare l'host google.it. Verificare che il nome sia corretto e riprovare. C:\Users\Hitech95>ping 8.8.8.8 Esecuzione di Ping 8.8.8.8 con 32 byte di dati: Risposta da 8.8.8.8: byte=32 durata=15ms TTL=56 Risposta da 8.8.8.8: byte=32 durata=15ms TTL=56 Risposta da 8.8.8.8: byte=32 durata=15ms TTL=56 Statistiche Ping per 8.8.8.8:     Pacchetti: Trasmessi = 3, Ricevuti = 3,     Persi = 0 (0% persi), Tempo approssimativo percorsi andata/ritorno in millisecondi:     Minimo = 15ms, Massimo =  15ms, Medio =  15ms Control-C ^C C:\Users\Hitech95>ping google.it Impossibile trovare l'host google.it. Verificare che il nome sia corretto e riprovare. C:\Users\Hitech95>ping google.com Esecuzione di Ping google.com [216.58.205.142] con 32 byte di dati: Risposta da 216.58.205.142: byte=32 durata=9ms TTL=54 Risposta da 216.58.205.142: byte=32 durata=10ms TTL=54 Statistiche Ping per 216.58.205.142:     Pacchetti: Trasmessi = 2, Ricevuti = 2,     Persi = 0 (0% persi), Tempo approssimativo percorsi andata/ritorno in millisecondi:     Minimo = 9ms, Massimo =  10ms, Medio =  9ms Control-C ^C C:\Users\Hitech95>ping google.it Impossibile trovare l'host google.it. Verificare che il nome sia corretto e riprovare. C:\Users\Hitech95>ping google.it Impossibile trovare l'host google.it. Verificare che il nome sia corretto e riprovare. C:\Users\Hitech95>ping 8.8.8.8 Esecuzione di Ping 8.8.8.8 con 32 byte di dati: Risposta da 8.8.8.8: byte=32 durata=15ms TTL=56 Risposta da 8.8.8.8: byte=32 durata=15ms TTL=56 Risposta da 8.8.8.8: byte=32 durata=15ms TTL=56 Statistiche Ping per 8.8.8.8:     Pacchetti: Trasmessi = 3, Ricevuti = 3,     Persi = 0 (0% persi), Tempo approssimativo percorsi andata/ritorno in millisecondi:     Minimo = 15ms, Massimo =  15ms, Medio =  15ms Control-C ^C C:\Users\Hitech95>ping google.it Impossibile trovare l'host google.it. Verificare che il nome sia corretto e riprovare. C:\Users\Hitech95>ping google.com Esecuzione di Ping google.com [216.58.205.142] con 32 byte di dati: Risposta da 216.58.205.142: byte=32 durata=9ms TTL=54 Risposta da 216.58.205.142: byte=32 durata=10ms TTL=54 Statistiche Ping per 216.58.205.142:     Pacchetti: Trasmessi = 2, Ricevuti = 2,     Persi = 0 (0% persi), Tempo approssimativo percorsi andata/ritorno in millisecondi:     Minimo = 9ms, Massimo =  10ms, Medio =  9ms Control-C ^C C:\Users\Hitech95>ping google.it Impossibile trovare l'host google.it. Verificare che il nome sia corretto e riprovare. C:\Users\Hitech95>

Sorry my OS is in italian language.
As you can see sometims something get stuck resolving some DNS.
And than all start working again.

Thw WAN is a PPPoE connection and according to the infos on the dashboard the wan is UP.

This is the last 50 entry in he log:

Jan 27 18:15:01 unbound 56015:0 info: 0.131072 0.262144 27 Jan 27 18:15:01 unbound 56015:0 info: 0.262144 0.524288 8 Jan 27 18:15:01 unbound 56015:0 info: 0.524288 1.000000 1 Jan 27 18:15:01 unbound 56015:0 info: server stats for thread 1: 3 queries, 0 answers from cache, 3 recursions, 0 prefetch, 0 rejected by ip ratelimiting Jan 27 18:15:01 unbound 56015:0 info: server stats for thread 1: requestlist max 0 avg 0 exceeded 0 jostled 0 Jan 27 18:15:01 unbound 56015:0 info: average recursion processing time 0.074612 sec Jan 27 18:15:01 unbound 56015:0 info: histogram of recursion processing times Jan 27 18:15:01 unbound 56015:0 info: [25%]=0 median[50%]=0 [75%]=0 Jan 27 18:15:01 unbound 56015:0 info: lower(secs) upper(secs) recursions Jan 27 18:15:01 unbound 56015:0 info: 0.016384 0.032768 1 Jan 27 18:15:01 unbound 56015:0 info: 0.032768 0.065536 1 Jan 27 18:15:01 unbound 56015:0 info: 0.131072 0.262144 1 Jan 27 18:15:01 unbound 56015:0 info: server stats for thread 2: 148 queries, 24 answers from cache, 124 recursions, 0 prefetch, 0 rejected by ip ratelimiting Jan 27 18:15:01 unbound 56015:0 info: server stats for thread 2: requestlist max 3 avg 0.379032 exceeded 0 jostled 0 Jan 27 18:15:01 unbound 56015:0 info: average recursion processing time 0.081790 sec Jan 27 18:15:01 unbound 56015:0 info: histogram of recursion processing times Jan 27 18:15:01 unbound 56015:0 info: [25%]=0.0170394 median[50%]=0.0415902 [75%]=0.131072 Jan 27 18:15:01 unbound 56015:0 info: lower(secs) upper(secs) recursions Jan 27 18:15:01 unbound 56015:0 info: 0.000000 0.000001 18 Jan 27 18:15:01 unbound 56015:0 info: 0.000128 0.000256 1 Jan 27 18:15:01 unbound 56015:0 info: 0.000512 0.001024 1 Jan 27 18:15:01 unbound 56015:0 info: 0.002048 0.004096 1 Jan 27 18:15:01 unbound 56015:0 info: 0.004096 0.008192 5 Jan 27 18:15:01 unbound 56015:0 info: 0.008192 0.016384 4 Jan 27 18:15:01 unbound 56015:0 info: 0.016384 0.032768 25 Jan 27 18:15:01 unbound 56015:0 info: 0.032768 0.065536 26 Jan 27 18:15:01 unbound 56015:0 info: 0.065536 0.131072 12 Jan 27 18:15:01 unbound 56015:0 info: 0.131072 0.262144 20 Jan 27 18:15:01 unbound 56015:0 info: 0.262144 0.524288 11 Jan 27 18:15:01 unbound 56015:0 info: server stats for thread 3: 87 queries, 12 answers from cache, 75 recursions, 0 prefetch, 0 rejected by ip ratelimiting Jan 27 18:15:01 unbound 56015:0 info: server stats for thread 3: requestlist max 3 avg 0.333333 exceeded 0 jostled 0 Jan 27 18:15:01 unbound 56015:0 info: average recursion processing time 0.074287 sec Jan 27 18:15:01 unbound 56015:0 info: histogram of recursion processing times Jan 27 18:15:01 unbound 56015:0 info: [25%]=0.0197973 median[50%]=0.0401408 [75%]=0.0868352 Jan 27 18:15:01 unbound 56015:0 info: lower(secs) upper(secs) recursions Jan 27 18:15:01 unbound 56015:0 info: 0.000000 0.000001 11 Jan 27 18:15:01 unbound 56015:0 info: 0.000256 0.000512 1 Jan 27 18:15:01 unbound 56015:0 info: 0.001024 0.002048 1 Jan 27 18:15:01 unbound 56015:0 info: 0.004096 0.008192 2 Jan 27 18:15:01 unbound 56015:0 info: 0.016384 0.032768 18 Jan 27 18:15:01 unbound 56015:0 info: 0.032768 0.065536 20 Jan 27 18:15:01 unbound 56015:0 info: 0.065536 0.131072 10 Jan 27 18:15:01 unbound 56015:0 info: 0.131072 0.262144 8 Jan 27 18:15:01 unbound 56015:0 info: 0.262144 0.524288 2 Jan 27 18:15:01 unbound 56015:0 info: 0.524288 1.000000 2 Jan 27 18:15:01 unbound 56015:0 notice: Restart of unbound 1.6.6. Jan 27 18:15:01 unbound 56015:0 notice: init module 0: validator Jan 27 18:15:01 unbound 56015:0 notice: init module 1: iterator Jan 27 18:15:01 unbound 56015:0 info: start of service (unbound 1.6.6). Jan 27 18:15:10 unbound 56015:1 info: failed to prime trust anchor -- DNSKEY rrset is not secure . DNSKEY IN

:P Looks complicated.

What about thsi one : forget about passing your DNS info to big brother (8.8.8.8) - forget about your resolver. Remember : they both resolve for you, and you have to pass the info first - and they give the final answer back to you.

Activate de Resolver - the one that speaks directly to the root DNS …... and your done. Having DNSSEC enforced for free.
It's activated by default - the guys who build pfSense figured out that this was the best thing to have.

@cmb:

Two, if you enable forwarding mode to something that doesn't support DNSSEC like OpenDNS, then you must disable DNSSEC in Resolver if you enable forwarding mode.

Spot on: It had me baffled for quite some time, but this post gave the right solution.

"Before you start implementing DNSSEC"

You mean on your own domain?  Yeah there is a bit of learning curve there - there is a easy to follow write up on digital ocean.. to get you started
https://www.digitalocean.com/community/tutorials/how-to-setup-dnssec-on-an-authoritative-bind-dns-server–2

The hardest part said to say is actually finding a registrar for your domains that supports it.. I had fired this up on a test domain of mine years ago - and hopefully now more registrars support it.. But I found dynadot supported it.. https://www.dynadot.com

If I recall there was a bit of snafu back in early 2015 but they corrected it with a couple emails to their support. Ah looked up the email thread... Yeah back in 2015 they had some issues to work through..

" It seems to be an issue/bug at the central registry. We have asked them to create the records for your domain in their system"
"This should be an isolated issue. Not many of our customers have actually used DNSSEC yet, but this was the only issue thus far."

And yes the links for testing dns for dnssec are great - but looks like dnsviz is currently offine
"Sorry, we are currently working on some improvements, and DNSViz is currently unavailable. Please check back soon. Thanks! "

There are legit reasons to use a public domain.. But seems like he is trying to use machines that match up with public names.. Which could cause problems - my guess is if he has the clients registered he is having is clients point outside and not pfsense.

"Description explicitly says not to name domain local"

It states not to use .local as the TLD… That is not what I am doing my tld is .lan  And I agree using a tld of .local would be a bad idea.

Unless you have a specific reason to use your public domain name internally - like portal you want to put a acme cert on.. Your better off using a non public domain internally..  You can also just use a signed cert and have your clients trust your CA to get trusted.. So unless you have clients you do not control access stuff via this fqdn that you use https then you don't need to go that route either.. My browsers trust names in local.lan because my browsers trust my CA that created the certs.  No random box would ever have need to access my pfsense web gui, etc.  And not using the captive portal.

You can always just manually create host override entries if your having a problem with registration of clients in dhcp.. If your reserving a client an IP with static then its a given you would know that its IP is going to be so just put it in overrride.

For clients that just get an IP out of the pool - you sure your doing a query direct to your unbound to see if it resolves?