@stewart it shouldn't - resolver would have nothing to do with those.

@jgauthier There are some DHCP-client settings that might be useful here : These : [image: 1632751693954-679bda3d-cc95-4d9e-956c-c4c8c55c2866-image.png] Check the 'Advanced Configuration' to see them. Click on the blue "here" link for guidance. Strange that, after a interface UP event on "09:35:34", more then 3 minutes later, on "09:38:52" there is still no answer. The DHCP client assigns a previous used IP 47.77.33.59. It would be better if it assigned itself a NaN IP like "0.0.0.0".

@1ntr0v3rt3ch said in Unable to resolve opensuse.org with pfSense DNS resolver: https://forum.netgate.com/topic/166780/add-dns-in-dhcp-server-settings-required/8 When you set up pfSense, there is no need to enter any where '8.8.8.8' or '8.8.4.4'. These two - or any others - are mentioned no where in the Pfsense manual. Again : the default Resolver doesn't need any setting to be altered : it works out of the box. But : if you have some sort of contract with Alphabet cooporation - (aka Google) that you have to hand over all your 'private' DNS request, then, ok, why not. I don't think an ISP exists that actually blocks you from accessing basic Internet servers like the 13 root servers. And even if they exist, because, after all, it's a free world, so why not. It will be the ISP without clients, that's for sure.

@mr_jinx The "value", according https://developer.apple.com/news/?id=q78sq5rv must be a JSON API file. This file shows an example how the connection phase works. As you can see, this file doesn't contain a static value. An non logged in device would retrieve : { "captive": true, "user-portal-url": "https://example.org/portal.html" } After login, the same JSON API file could show : { "captive": false, "user-portal-url": "https://example.org/portal.html", "venue-info-url": "https://flight.example.com/entertainment", "seconds-remaining": 326, "can-extend-session": true } The good new : IPv4 and IPv6 ready. This will simplify the "get the login page shown to the client" a lot. 'https' isn't an option here : your portal will need valid certificates. From what I understood, IPv6 is still optional. I played with this 'DHCP 14' option, and it worked well. Dono / didn't test any Android devices .... edit : this is still 'draft' .....

@viragomann Thank you it works, actually remote site DNS server was on another VLAN, when i give static route of the dns server, it resolve.

@cubeyglyph no problem.. Its not that I hate the idea of doh or dot.. What I don't like is things like browsers doing it on their own without explicit direction from the user to do such a thing. And until such time that sni are not in the clear - its pretty pointless anyway. Its more of companies to draw dns traffic to their services and circumvent filtering on the local side.. Its all really bad news if you ask me.. I block that shit for sure.. And also not a fan of applications or devices doing any sort of hard coding of which dns to use even if just normal udp 53, A device or application should use what is set on the the device or parent OS be static or via dhcp - period!! If stuff like browsers want to offer doh or dot as an option - great do that.. But you better not do it without explicit freaking permission from the person running the running the browser.. I don't care how stupid you think the user is ;) You shouldn't be doing anything other than using what the OS says to use for dns without specific OK and setting from the operator of said software..

@kidwell220 When you connect it to the switch do you see it come up with link, do you get lights? What speed does it come up.. While its rare - have seen issues with specific nics and switches, etc. But if you sniff or watch the log on pfsense - if it doesn't see the discover/request - there is nothing it can do.. So this is first thing to validate - that pfsense is indeed seeing the request/discover - and what does it answer? Maybe the switch is dying - if your saying works fine with port X and downstream switch 2.. Plug this device into that port.. Does that work?

@schneizel1208 Not really. The dyndns scripts use a classic 'curl' call - this simulates a web browser request. The answer comes back as the return header, that should indicate "Response Header: HTTP/2 200" where "200" means : all ok. "401", a well error result, indicates : the page you requested doesn't exist on the server. Check the /etc/inc/dyndns.class - line 575 and afterwards. This is this part of the 'code' where noip and noip-free is handled. This is the URL : https://dynupdate.no-ip.com/nic/update To this URL are you added your user credentials. You can use this URL in your browser : I saw : [image: 1632134905550-1d0406c7-2a5b-456e-8a2a-225d58ec4602-image.png] Keep in mind : if you - or some automated scrypt like dyndns.class, visits dynupdate.no-ip.com to often then that is considered as 'abusive' and your IP is blokced by their firewall. You couldn't connect to "dynupdate.no-ip.com" any more for a while. That would explain your issue. Use another IP(WAN) and retest https://dynupdate.no-ip.com/nic/update

Ok, it does the trick. I guess it will be ok for what I have to do. Thanks.

Awesome, thanks. Do I need to do anything like flush the DNS cache by restarting unbound?

this seems to have done the trick! I haven't gotten any watchdog alerts since toggling off Register DHCP leases in the DNS Resolver. thanks again!

I've come up with a solution (I hope!) I've created a subdomain on the domain that I have a wildcard certificate for. This is set to the IP address of the interface. i.e portalabc.domain.co.uk > 192.168.200.1 I'm not really fussed about anyone trying to visit portalabc.domain.co.uk outside of the network. I did notice though, using either the DNS Forwarder or Resolver on the admin LAN, I have to add it as a host override, otherwise ping returns "host not found" for a subdomain pointing to an rfc 1819 IP. Is this setup likely to cause issue somewhere?

@averyfreeman said in Forward DNS queries to Active directory DNS Server: @bmeeks Why not use forwarders from AD DNS instead of root hints? Root hints are really just meant as a fallback... Not 100% true. The root hints are in fact the root DNS servers. So they are the true authority. And you can talk to them using DNSSEC. When you forward, you lose the benefit of DNSSEC as you have no control over what the forwarder is doing on your behalf. It may be using DNSSEC, or it may not. (Note: assuming we are talking about an external forwarder here and not unbound on pfSense). You can certainly forward to another intermediate server, though, if you wish. And there is probably something to be said for being a thoughtful netizen and not overloading the roots. But one thing you get by directly querying the roots and not using a forwarder is you deprive the marketing folks at that forwarder of their data to target ads or otherwise snoop on you.

I'm facing exactly the same problem. I'd like to provide custom configuration location for PXE (pxelinux.0). Isc Dhcp server does support this feature, but pfsense doesn't. How can I add this feature? Here is the full description in german: https://www.german-syslinux-blog.de/synology-dsm-6-0-syslinux-6-04-pxetftpdhcp-server-einrichten/ I'm happy with pfsense as my dhcp server, so i don't want to have my synology to provide ip addresses.

Update: Found the issue, the pfSense was using a old theme not the newest one coming with the new +. After changing the theme to default everything back to normal. solved