Bug #13282
open
FQDN Aliases Break if an Invalid Domain is Present in the Chain
0%
Description
If an invalid FQDN is present in an alias before a valid one, the entire table will be empty.
For an example, if I create an Alias with
windowsupdate.com
google.com
It will be an empty table even when loaded into a rule.
If I create an Alias with the domains in the reverse order, everything works fine.
It seems that in the processing order, there is no handling for if one of the domains in the list is invalid.
See attached screenshot showing an active rule, alias, and an empty, broken table.
May be related to redmine 9296 as it also results in empty tables.
Files
Updated by 
Updated by Reid Linnemann about 1 month ago
There must be something else to this than just the unresolvable host, I've tried several times to replicate this and have been unsuccessful.
When you tested this, was there anything special about your resolver? Did you use dnsmasq or unbound, or were you configured to query name servers assigned manually or via DHCP?
Updated by Kris Phillips about 1 month ago
Reid Linnemann wrote in #note-2:
There must be something else to this than just the unresolvable host, I've tried several times to replicate this and have been unsuccessful.
When you tested this, was there anything special about your resolver? Did you use dnsmasq or unbound, or were you configured to query name servers assigned manually or via DHCP?
Reid,
I was testing with unbound and DNS resolution was functional.
However, I just tried to recreate this on a fresh install of 22.05 RELEASE and I cannot. Last when I was testing this I was on RC4 or 5 and could reproduce it regularly. Not sure what changed or if there was some other circumstance to this that I'm no longer hitting (maybe a package or another remnant of my testing). Where there any changes between the RC and release to the functions here or PHP?
Updated by Reid Linnemann about 1 month ago
No, none that I am aware of. I know that filterdns has been untouched for a few months now. I'll look for changes elsewhere that could be related.
Updated by Chris Linstruth about 1 month ago
This has been squirreley for a long time and has been very difficult to reliably duplicate but it is very real. #9296 as stated earlier.
Updated by Reid Linnemann about 1 month ago
I trust that it is definitely real and not a false or misinterpreted report. There's a reason for it and with enough tenacity I'll find it.