@benam

They stick all for me :

c05bd838-2560-4197-b019-3312a91724c7-image.png

@benam said in DNS hostname disappears after input:

Version 2.5.2-RELEASE

That's 5 or 6 versions in the past .... The issue was fixed.

@viragomann
What a straight-forward solution! Thanks!
It works as expected now.

@bob-dig @johnpoz I tried starting in Firefox Safe Mode with all add-ons disabled... same problem

However, creating an entirely new profile restored the correct behavior. So it's something in my default profile, but I can't imagine what would cause FF to remove the value= attribute from an input tag.

Thanks for the help.

@swami_ you can setup haproxy to use your wan or you lan interface. Comes down to where the traffic is going to hit.

Even if you ha proxy listens on you wan IP, unless you open a firewall rule on the wan that would not be available to internet IPs. But your wan IP is still going to be able to be hit via your lan devices.

Comes down to where you want to point the fqdn you want to use to point to - if all your going to want it for is lan, then just use your lan IP and point all your fqdn you want to use to your pfsense lan IP.

@provels Thanks!! Happy Holidays I created two text files from the above URLs to use with Squidguard without the # and the text

DNS over HTTPS "DoH" server text files for use with Squid Guard:

Smaller Lists made from URLS above: dnsdoh.txt

Large List from bulk URL list: DoH DNS List.txt

Combined Lists: CombinedDOHlist.txt

@bingo600
A quick fix. It is working now.

Thank you!

@rcoleman-netgate
yaya ^^ that thing.

Yes, there are VLANs at play here.

The device is on wifi, though it hasn't moved and a new identical device newly installed right next to it is not exhibiting this issue. The logs from my wireless infrastructure don't suggest any major connection blips either.

I also don't believe the device rebooted, though that is possible.

I ended up, rather than setting up a static IP on the lease (that particular vlan is for IoT stuff and has no extra room on its subnet that isn't allocated to the DHCP pool), just setting a static lease that overrides the DHCP lease time to one day. And now I see daily DHCP renewals with no problems.

Odd though that this worked fine with hourly lease renewals for a couple of years before this problem arose.

@johnpoz said in Unable to illegal DNS record from pfsense (DNS-resolver corruption):

@asadz said in Unable to illegal DNS record from pfsense (DNS-resolver corruption):

with backhole address.

of 100.1.2.4 ? that is a HORRIBLE blackhole choice that is for sure..

A simple wireshark would of seen right away that answer was coming from a different mac address, etc.

Again if the DC was putting traffic on the wire, would of seen that and know from upstream something was returning the 100.x address.

Glad you found it.. but using a valid public IP, ie 100.1.2.4 is horrible horrible choice of blackhole address.. Maybe it was a typo and was suppose to be 10.1.2.4?

Yes I share your concerns, this IP made it first appearance in var/log of pfsense of 14th same day we enabled new snort rules
The DNS reply logs

Dec 14 14:31:08,reply,A,A,Unk,sb.scorecardresearch.com,192.168.3.6,100.2.3.4,USDNS-reply,Dec 14 14:31:08,reply,A,A,Unk,sb.scorecardresearch.com,192.168.4.9,100.2.3.4,USDNS-reply

Suggest sunnyvalley providing black hole response. I still think black hole address should be private to be safe and esp should not resolve or routable to www.

Also the MAC address lookup shows 0050560B0310 -> 00005E000101
One is register with VMware other is IANA. Most probably sunnyvalley cloud app is running over VMware.

I guess, those are normal and unbound is the source?

Although I haven't noticed blocking has had any unwanted effect to anything, at least info TLD would probably be better to be allowed?

It turns out that I had a brain fart and misconfigured DHCP guarding in the UniFi OS Console for my access points. Rather than using the gateway address of the WiFi network’s subnet as the DHCP server address, I used the address of the Netgate box. With that fixed, everything works.

Thanks for all who made suggestions! I am learning from each of your contributions.

@rchiocchio Keep that NAT disabled, you don't need that.

You are allowing only TCP traffic, DNS most of the times uses UDP, try to change that rule from the IPsec tab to TCP/UDP and test again.

@gertjan hello there

Yeah, I'm puzzled too. I just can't prove if its from our huawei core switch or from pfsense itself.
But I don't see any documentation regarding huawei having that domain.. I already escalate it to huawei TAC and they just said this "if 172.1.83.10 is the address of HW switch, switch just replay a icmp packet, will not take these information (lightspeed.moblal.sbcglobal.net), and it is the behavior of PC."

and base from this forum, I think no-one yet encountered this ghost domain with their pfsense, so I think its not really the pfsense causing

@juergenbrandstaetter said in How to configure Dynamic DNS with unsupported DNS provider:

In my case I my providers router works in bridge mode, and my WAN interface is configured as DHCP -> so I guess it should recognize, if the IP changes

Not recognize 😊
If you use a DHCP client on your WAN interface, this client will initiate a DHCP lease request as soon as the WAN interface comes 'UP'.
The ISP, with it's DHCP server, will give the client an IP (your WAN IP), a gateway, maybe a DNS or two.
A DHCP lease has always a duration, like 24 hours. So, half way that duration, the DHCP client will wake up, and request for an DHCP lease 'extension'. It will of course suggest that it likes to keep the actual (WAN) IP.
The ISP DHCP server can grant that lease extension, or so, "NO, now you get a new IP (WAN)".

The WAN IP changes (or not) a "interface event" is fired, and this will affect all processes that are "bound to" these interfaces, so that these process can be made aware that an IP on some interface changed (or not).
On of these process is : the DynDNS. It has stored the (now past) WAN IP in a file, it will compare it with the actual WAN IP, and fire up a dyndns update if the tow are different. And it will update the file with the current WAN IP for future events.

@viragomann Yes, the same chip celeron N3060.
By default pfsense listen in all interfaces under DNS Resolver.
Them I'm not alone.
My felling is that is related to N3060 electronics.
Them have discover something else about this issue?

@viper_rus Close thread, problem solved

@mctechsolutions
pfSense on its own can only redirect IPs and ports. It cannot read a host header in a HTTP request if that's what you're purpose.

If you want to redirect traffic on host name basis you need to install and configure the HAproxy package.

@adamitj
DoT requests which are redirected to another server won't work anyway, because the SSL verification will fail.

Therefore I simply block all DoT and DoH in my network. Hence the clients have to do unencrypted DNS requests, which I can redirect as needed.

@bingo600 The issue was your first quote...
I feel dumb right now, I'm highly appreciated for your help.

@nhscan
My best suggstions are :

1:
Create a dedicated IoT Lan/Vlan , and do the Internet Access , blockking there.

2:
Make your IoT "Internet Access" block rule, use an Alias for the matching source IP's.
Then it's just a matter of adding the newly created IoT IP, to the Alias.

I would recommend 1 , as you can do a Lan/Vlan wide block.
And it doesn't matter if the IoT "thingy" pull's another DHCP IP by "mistake".

/Bingo

@thisisme
I did some tests and these are the results:

Unbound will look up all configured DNS Server in parallel. So it also uses the DNS Server configured with the WAN Gateway.

If I use package capture there is no traffic for port 53 on my WAN Interface.

If if disable forwarding mode in unbound I pass the dns leak test.

Can I assume that's still safe to use forwarding mode, because the traffic seems to be on VPN Interface only?

Issue reported on redmine: https://redmine.pfsense.org/issues/13719

Figured out what was causing the error. It seems to be caused by the pfBlockerNG-devel package. I had a second router I was setting up and checked the DHCP server functionality after every change. Everything worked fine until I installed the pfBlockerNG-devel package. Uninstalling it does not remedy the issue either. A full factory reset is required.

Package specifics
pfBlockerNG-devel
Version: 3.1.0_11

Workaround
You can reconfigure the interfaces and DHCP Servers via console to the box. Had no issues making changes via console and all of them took.

@camg
If you can run your own Unbound DNS on separate machine you will not be having all these issues.
I have Synology NAS and I compile and build my Unbound straight from Unbound repo. Current version 1.17.
It is a solid solution is you can do this.

Problem with pfsense including Unbound is that there is no way a user can update just Unbound itself. Over this year Unbound released 4 version. You are always behind if you use supplied Unbound binaries with pfsense.

I have used that typo of architecture (separating Unbound DNS) for years. Never had any issues. For these people that use pfBlocker - you can do all domain blocking just using Unbound RPZ. Its easy .

@ahking19 said in PFSense DNS cannot resolve outlook.ha.office365.com properly:

@tdixler

Check Domain name outlook.ha.office365.com, and type as HTTPS<<

HTTPS is not a valid DNS query type. Valid query types are - A, AAAA, CNAME, MX, NS, etc)

Are you confusing with DNS-over-HTTPS (DoH)?

Hmmm ... See:
https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-svcb-https-01#section-12.2

Right now it seems like Apple IOS > 14.x, is using this type of queries.

Yddrfff .... DoH bypassing (resolver selection) 😠
https://support.opendns.com/hc/en-us/articles/360049861971-DNS-Resolver-Selection-in-iOS-14-and-macOS-11

Thanks all.
So my solution is to know that my workaround was the solution :)

@crichmon I do not know how to convert. Only GUI interface.

@csit-0
If you have DNSBL on in pfBlockerNG try to disable it. Disabling pfBlockerNG is not sufficient.

@gertjan said in DNS reslution error just on pfsense box:

ort the config back in, and one reboot later you're back at square 1.

I reinstalled pfsense, left everything as default. It still couldn't resolve DNS.
Ended up upgrading installation boot usb from 2.5 to 2.6, re-installed pfsense once again with all default settings, changed the NIC and it resolved the issue.

I am still unsure what caused the issue though.

Thanks for all your input Gertjan :)