Bug #16710
closed
Firewall host aliases with duplicate FQDN will only populate one table
0%
Description
I discovered that if you have firewall host aliases using FQDN that CNAME which then rotate between two A records where the A records are duplicates across both aliases than the table will be missing one of the IP. This results in firewall rules failing as they are missing IP that should be present as each alias is used for different firewall rules. While they currently resolve to the same A records the initial FQDN is different with one being used for a client to access a hosted service and the other for the device to talk to backend servers so they could change. While this unique scenario revealed this behavior this appears to be a bug that could impact other legitimate needs.
Alias1
alias1.contoso.com
;; QUESTION SECTION: ;alias1.contoso.com. IN A ;; ANSWER SECTION: alias1.contoso.com. 1027 IN CNAME prd.trafficmanager.contoso.com. prd.trafficmanager.contoso.com. 39 IN CNAME prd-a.east.contoso.com. prd-a.east.contoso.com. 10 IN A 1.1.1.1
This will also intermittently resolve to
prd-b.east.contoso.com. 10 IN A 2.2.2.2
Alias 2
alias2.contoso.com
;; QUESTION SECTION: ;alias2.contoso.com. IN A ;; ANSWER SECTION: alias2.contoso.com. 905 IN CNAME prd-api.trafficmanager.contoso.com. prd-api.trafficmanager.contoso.com. 59 IN CNAME prd-b.east.contoso.com. prd-b.east.contoso.com. 9 IN A 2.2.2.2
This will also intermittently resolve to
prd-a.east.contoso.com. 10 IN A 1.1.1.1
Updated by Zetto Null 4 days ago
The expected result is that you end up with a table with the following.
Alias1 1.1.1.1 2.2.2.2
Alias2 1.1.1.1 2.2.2.2
What you actually end up with is
Alias1 1.1.1.1
Alias2 2.2.2.2
Updated by Jim Pingle 4 days ago
- Status changed from New to Not a Bug
That is just a part of how DNS works, there is no way for it to tell a change of address from a random response for such hostnames.
For it to pick up all addresses, all addresses must be included in every response.
It's a known and documented limitation.
https://docs.netgate.com/pfsense/en/latest/firewall/aliases-features.html#hostnames-in-aliases
Updated by Zetto Null 4 days ago
Jim Pingle wrote in #note-2:
That is just a part of how DNS works, there is no way for it to tell a change of address from a random response for such hostnames.
For it to pick up all addresses, all addresses must be included in every response.
It's a known and documented limitation.
https://docs.netgate.com/pfsense/en/latest/firewall/aliases-features.html#hostnames-in-aliases
I ended up deleting Alias2 assuming it was causing problems. I then updated Alias1 to reflect the following.
alias1.contoso.com prd.trafficmanager.contoso.com prd-a.east.contoso.com prd-b.east.contoso.com
The expected result is that you end up with a table with the following and initially that was the case.
Alias1 1.1.1.1 2.2.2.2
After some amount of time one of the records was removed from the table and now I just have one causing the firewall rule to intermittently block access that should be allowed.
Alias1 2.2.2.2
The More Information box above the table shows the following.Date of last update of table is unknown. 1 records.
I think this may be related to https://redmine.pfsense.org/issues/9296.
Updated by Zetto Null 3 days ago
I removed the first two entries leaving just the A records.
prd-a.east.contoso.com prd-b.east.contoso.com
Now the table is empty and shows.
No entries exist in this table.
Updated by Zetto Null 3 days ago
Even though I have Aliases Hostnames Resolve Interval set to 30 I waited 15 minutes and the table continues to show.
No entries exist in this table.
I performed a filter reload and waited another 15 minutes with no change.
I then cleared out both entries and saved the blank alias. Then added back the entries and both are resolving again.
Updated by Patch Public about 7 hours ago
Sound like a duplicate of https://redmine.pfsense.org/issues/13792
In pfsense it is currently the users responsibility to ensure any FQDN in aliases remain always non intersecting.
If the user fails to do this any transiently over lapping IP address will be permanently deleted from the alias.
It's a long time limitation, which probably requires refactoring Filterdns to resolve https://forum.netgate.com/post/1231744