DNS Black Hole
-
You just told me that you installed via the GUI!!! Argh.
-
You just told me that you installed via the GUI!!! Argh.
I've done it every way… I've cloned the VM so I can start over every time.
I've tried a sytem with bind installation via gui, other via terminal. other with the terminal 1st and then gui, other with gui and then terminal... you name it and i've tried it... -
Dude. Pick ONE way. Debug it. Post your problems and findings (like, is bind running, can you query it, what do the queries return, logs.)
This chaos leads nowhere.
-
Dude. Pick ONE way. Debug it. Post your problems and findings (like, is bind running, can you query it, what do the queries return, logs.)
This chaos leads nowhere.
well. when i install it form the console i think it is not working. i get no response when i start it "name -u bind" but i guess that's normal, but if I try to kill it "killall -9 bind" i get "no matching processes were found" so… maybe it's not running?!
Once again this is all new to me so forgive me if this are all newb questions...
-
1/ Output of
ps ax | egrep "unbound|dnsmasq|named"2/ Output of
netstat -an | grep .53 -
1/ Output of
ps ax | egrep "unbound|dnsmasq|named"2/ Output of
netstat -an | grep .53$ ps ax | egrep "unbound|dnsmasq|named" 25106 - Is 0:00.14 /usr/local/sbin/unbound -c /var/unbound/unbound.conf 26609 - S 0:00.00 sh -c ps ax | egrep "unbound|dnsmasq|named" 2>&1 26881 - R 0:00.00 egrep unbound|dnsmasq|named 51024 - Is 0:00.04 named -u bind 51372 - Is 0:00.04 named -u bind 71067 - Is 0:00.04 named -u bind$ netstat -an | grep .53 tcp4 0 0 127.0.0.1.53 *.* LISTEN tcp4 0 0 127.0.0.1.953 *.* LISTEN tcp6 0 0 *.53 *.* LISTEN tcp4 0 0 *.53 *.* LISTEN udp4 0 0 127.0.0.1.53 *.* udp6 0 0 *.53 *.* udp4 0 0 *.53 *.* c4830560 stream 0 0 c53526a8 0 0 0 /tmp/php-fastcgi-hotspot_portal.socket-2 c48306b8 stream 0 0 c53527c4 0 0 0 /tmp/php-fastcgi-hotspot_portal.socket-1 c4830810 stream 0 0 c53376a8 0 0 0 /tmp/php-fastcgi-hotspot_portal.socket-0 c4831204 dgram 0 0 c539f000 0 c4830e1c 0 /var/dhcpd/var/run/log c4831408 dgram 0 0 c539f238 0 c4831000 0 /var/run/logpriv c483135c dgram 0 0 c539f354 0 0 0 /var/run/logI can't make sense of any of it…
-
You need to disable the DNS Resolver. Otherwise it will never work.
-
You need to disable the DNS Resolver. Otherwise it will never work.
I've tried that, but when i do it, not only the dns still resolves to the correct sites, but I loose access to the web gui.
-
1/ You cannot have two DNS servers listen on the same port. End of story. You have already 3 instanced of bind running, starting more of them won't exactly help until you make sure they can use port 53 which is already in use by unbound.
2/ Resolved from where? This needs to be tested from the clients, which need to point to pfSense for DNS.
3/ No idea what you mean by "loose access" -
1/ You cannot have two DNS servers listen on the same port. End of story. You have already 3 instanced of bind running, starting more of them won't exactly help until you make sure they can use port 53 which is already in use by unbound.
2/ Resolved from where? This needs to be tested from the clients, which need to point to pfSense for DNS.
3/ No idea what you mean by "loose access"3 sorry for the mistake, English is not my 1st language. I meant to say that after I disable DNS Resolver I can no longer access the web gui
2 I'm trying to resolve it from the terminal from the pfSense vm itself as it shows here (under Initial Testing): https://doc.pfsense.org/index.php/Creating_a_DNS_Black_Hole_for_Captive_Portal_Clients
1 I had too many instances of it because I was unsure if they where running or not. now i know and I only have one. -
How you cannot access the web GUI? Are you using FQDN that no longer resolves? Or you cannot access it using IP?
You cannot meaningfully test anything from pfSense itself unless you point it to 127.0.0.1 as DNS server – which is extremely stupid idea if all the DNS server does is a blackhole.
-
This is all moot anyway. No matter what you do with DNS if the client web browser is asking for an https connection and the captive portal gets in the middle, a certificate error must be displayed.
We, as IP networking professionals, should never, ever, EVER implement anything that, by design, will present certificate errors to users. Connections to https sites before captive portal is negotiated should simply hang. Don't like it? Don't use a captive portal.
