Project

General

Profile

Bug #8001

Invalid FQDN in alias causes alias table to fail *silently*

Added by Stuart Wyatt about 2 years ago. Updated about 1 year ago.

Status:
Closed
Priority:
High
Assignee:
Category:
FilterDNS
Target version:
Start date:
10/24/2017
Due date:
% Done:

100%

Estimated time:
Affected Version:
2.4
Affected Architecture:
All

Description

When you have a FQDN in an alias ans the FQDN does not resolve, the alias table creation will not happen and any other aliases that use the alias will be truncated or fail.

The root cause can be user error, but there's nothing in the system log or the firewall rebuild monitoring that indicates the failure.

This can cause a unexpected hole in the firewall, even though everything looks like it worked in the GUI.

History

#1 Updated by Luiz Souza about 2 years ago

  • Assignee set to Luiz Souza

#2 Updated by Stuart Wyatt about 2 years ago

More specifically, in this case, the FDQN timed out (DNS didn't respond).

#3 Updated by Jim Pingle about 2 years ago

  • Target version changed from 2.4.2 to 2.4.3

#4 Updated by Steve Beaver almost 2 years ago

  • Target version changed from 2.4.3 to 2.4.4

#5 Updated by Steve Beaver over 1 year ago

  • Target version changed from 2.4.4 to 48

#7 Updated by Luiz Souza about 1 year ago

  • Status changed from New to Feedback
  • % Done changed from 0 to 100

Should be fixed by the new filterdns (see #8758 too).

If you have issues, please let us know.

#8 Updated by Renato Botelho about 1 year ago

  • Target version changed from 48 to 2.4.4-p1

#9 Updated by Chris Linstruth about 1 year ago

Created host alias with these FQDNs

www.pfsense-bug-8001.com
www.google.com
www.yahoo.com
www.netgate.com
www.pfsense.org

pfsense-bug-8001.com was forwarded to an unresponsive address.

Alias populated with the rest of the names' corresponding A and AAAA records.

Looks OK to me.

#10 Updated by Luiz Souza about 1 year ago

  • Status changed from Feedback to Closed

Thanks!

#11 Updated by Stuart Wyatt about 1 year ago

Verified that the bad FQDN doesn't fail the tables any longer.

There's still no error. There should at least be a warning to help the user find the mistake.

Also available in: Atom PDF