Unexpected Alias behavior with FQDN
-
I have noticed that if you create an alias using an FQDN, that if you have are running dual stack (both A and AAAA records) you get a result that was unexpected, at least to me.
My setup:
I have a domain with CloudFlare, example.com
I have my local pfsense setup with lab.example.com for the domain.
I register a static ipv6 AAAA record in Cloudflare for a local host called isaacfl.lab.example.com
Since it is dual stack I have a static DHCP reservation for isaacfl to 10.23.10.10.
I have the pfsense resolver (in resolver mode) with System Domain Local Zone Type to "Type Transparent". My understanding is that "Type transparent" should provide record request if it is local or it will go out and look it up if it doesn't find the record locally.
This seems to work as when I do a DNS lookup for isaacfl.lab.iznmort.com it resolves both the A record (10.23.10.100 and the AAAA record with the ipv6 as entered in Cloudflare.
However, when I create an alias using the FQDN and then a rule to pass the Alias, the Diagnostics/Tables only shows the entry for the A record.
Here is the WAN rules so you understand what I am doing:
If I create a host override in the resolver with the same ipv6 record then the table shows both entries.
It seems that even though the DNS is able to resolve both an A and an AAAA record for a FQDN, the Alias function will only get both if they are in the local Host Overrides of the Resolver.
-
As part of my testing, I also created another Alias, HOST_ISAACFL_v6, and used it for the ipv6 firewall rule. Even with a different alias it still did not get the AAAA record in Diagnostics \ Tables.
I verified with a port scanner that the traffic did not get through.
Since I have only the one host, I just created a duplicated AAAA record in my local Host Overrides, so that is as far as I went with it.
-
Are you using 2.4.4_p2 ?
FQDN-Alias Support is broken, see Bug
https://redmine.pfsense.org/issues/9296Try to revert to 2.4.4
-
has this been fixed in _p3? can't find the info anywehere, or at least not very explicitly. thx for confirmation.
also, can anyone confirm, if the FQDNs need the trailing dot, or not? -
As you can read in the Ticket mentioned above it is not resolved in _p3 but tested for 2.4.5 so either you can install the Release Candidate for 2.4.5 or wait for the release. Otherwise you could use the method near the end of the topic to patch the filterdns part.
