[PATCH iptables]: xtables: tolerate DNS lookup failures

[PATCH iptables]: xtables: tolerate DNS lookup failures

[Guido Trentalancia]

libxtables: tolerate DNS lookup failures

Do not abort on DNS lookup failure, just skip the
rule and keep processing the rest of the rules.

This is particularly useful, for example, when
iptables-restore is called at system bootup
before the network is up and the DNS can be
reached.

Signed-off-by: Guido Trentalancia <guido@trentalancia.com>
---
 libxtables/xtables.c |   14 ++++++++++++--
 1 file changed, 12 insertions(+), 2 deletions(-)

diff -pru iptables-1.8.9-orig/libxtables/xtables.c iptables-1.8.9-new/libxtables/xtables.c
--- iptables-1.8.9-orig/libxtables/xtables.c	2023-01-12 11:27:35.000000000 +0100
+++ iptables-1.8.9-new/libxtables/xtables.c	2025-03-07 14:03:35.907011754 +0100
@@ -1710,7 +1710,8 @@ ipparse_hostnetwork(const char *name, un
 	if ((addrptmp = host_to_ipaddr(name, naddrs)) != NULL)
 		return addrptmp;
 
-	xt_params->exit_err(PARAMETER_PROBLEM, "host/network `%s' not found", name);
+	fprintf(stderr, "host/network `%s' not found - skipping rule\n", name);
+	return NULL;
 }
 
 static struct in_addr *parse_ipmask(const char *mask)
@@ -1788,6 +1789,8 @@ void xtables_ipparse_multiple(const char
 			strcpy(buf, "0.0.0.0");
 
 		addrp = ipparse_hostnetwork(buf, &n);
+		if (addrp == NULL)
+			continue;
 		if (n > 1) {
 			count += n - 1;
 			*addrpp = xtables_realloc(*addrpp,
@@ -1847,6 +1850,8 @@ void xtables_ipparse_any(const char *nam
 		strcpy(buf, "0.0.0.0");
 
 	addrp = *addrpp = ipparse_hostnetwork(buf, naddrs);
+	if (addrp == NULL)
+		return;
 	n = *naddrs;
 	for (i = 0, j = 0; i < n; ++i) {
 		addrp[j++].s_addr &= maskp->s_addr;
@@ -2005,7 +2010,8 @@ ip6parse_hostnetwork(const char *name, u
 	if ((addrp = host_to_ip6addr(name, naddrs)) != NULL)
 		return addrp;
 
-	xt_params->exit_err(PARAMETER_PROBLEM, "host/network `%s' not found", name);
+	fprintf(stderr, "host/network `%s' not found - skipping rule\n", name);
+	return NULL;
 }
 
 static struct in6_addr *parse_ip6mask(char *mask)
@@ -2084,6 +2090,8 @@ xtables_ip6parse_multiple(const char *na
 			strcpy(buf, "::");
 
 		addrp = ip6parse_hostnetwork(buf, &n);
+		if (addrp == NULL)
+			continue;
 		if (n > 1) {
 			count += n - 1;
 			*addrpp = xtables_realloc(*addrpp,
@@ -2137,6 +2145,8 @@ void xtables_ip6parse_any(const char *na
 		strcpy(buf, "::");
 
 	addrp = *addrpp = ip6parse_hostnetwork(buf, naddrs);
+	if (addrp == NULL)
+		return;
 	n = *naddrs;
 	for (i = 0, j = 0; i < n; ++i) {
 		for (k = 0; k < 4; ++k)

Re: [PATCH iptables]: xtables: tolerate DNS lookup failures

[Jan Engelhardt]

On Friday 2025-03-07 14:42, Guido Trentalancia wrote:

>libxtables: tolerate DNS lookup failures
>
>Do not abort on DNS lookup failure, just skip the
>rule and keep processing the rest of the rules.
>
>This is particularly useful, for example, when
>iptables-restore is called at system bootup
>before the network is up and the DNS can be
>reached.

Not a good idea. Given

	-F INPUT
	-P INPUT ACCEPT
	-A INPUT -s evil.hacker.com -j REJECT
	-A INPUT -j ACCEPT

if you skip the rule, you now have a questionable hole in your security.

Re: [PATCH iptables]: xtables: tolerate DNS lookup failures

[Reindl Harald]

Am 07.03.25 um 15:07 schrieb Jan Engelhardt:
> 
> On Friday 2025-03-07 14:42, Guido Trentalancia wrote:
> 
>> libxtables: tolerate DNS lookup failures
>>
>> Do not abort on DNS lookup failure, just skip the
>> rule and keep processing the rest of the rules.
>>
>> This is particularly useful, for example, when
>> iptables-restore is called at system bootup
>> before the network is up and the DNS can be
>> reached.
> 
> Not a good idea. Given
> 
> 	-F INPUT
> 	-P INPUT ACCEPT
> 	-A INPUT -s evil.hacker.com -j REJECT
> 	-A INPUT -j ACCEPT
> 
> if you skip the rule, you now have a questionable hole in your security.
just don't use hostnames in stuff which is required to be upo *before* 
the network to work properly at all

Re: [PATCH iptables]: xtables: tolerate DNS lookup failures

[Guido Trentalancia]

Nowadays FQDN hostnames are very often unavoidable, because in many
cases their IP addresses are allocated dynamically by the DNS...

The patch is very useful for a desktop computer which, for example,
connects to a wireless network only occasionally and not necessarily at
system bootup and which needs rules for IPs dynamically allocated to
FQDNs.

Guido

On Fri, 07/03/2025 at 15.48 +0100, Reindl Harald wrote:
> 
> Am 07.03.25 um 15:07 schrieb Jan Engelhardt:
> > 
> > On Friday 2025-03-07 14:42, Guido Trentalancia wrote:
> > 
> > > libxtables: tolerate DNS lookup failures
> > > 
> > > Do not abort on DNS lookup failure, just skip the
> > > rule and keep processing the rest of the rules.
> > > 
> > > This is particularly useful, for example, when
> > > iptables-restore is called at system bootup
> > > before the network is up and the DNS can be
> > > reached.
> > 
> > Not a good idea. Given
> > 
> > 	-F INPUT
> > 	-P INPUT ACCEPT
> > 	-A INPUT -s evil.hacker.com -j REJECT
> > 	-A INPUT -j ACCEPT
> > 
> > if you skip the rule, you now have a questionable hole in your
> > security.
> 
> just don't use hostnames in stuff which is required to be upo
> *before* 
> the network to work properly at all

Re: [PATCH iptables]: xtables: tolerate DNS lookup failures

[Reindl Harald]

Am 07.03.25 um 16:31 schrieb Guido Trentalancia:
> Nowadays FQDN hostnames are very often unavoidable, because in many
> cases their IP addresses are allocated dynamically by the DNS...

which makes rules with hostnames even more dumb

frankly you can't write useful rules for dynamic IPs at all

> The patch is very useful for a desktop computer which, for example,
> connects to a wireless network only occasionally and not necessarily at
> system bootup and which needs rules for IPs dynamically allocated to
> FQDNs.
> 
> Guido
> 
> On Fri, 07/03/2025 at 15.48 +0100, Reindl Harald wrote:
>>
>> Am 07.03.25 um 15:07 schrieb Jan Engelhardt:
>>>
>>> On Friday 2025-03-07 14:42, Guido Trentalancia wrote:
>>>
>>>> libxtables: tolerate DNS lookup failures
>>>>
>>>> Do not abort on DNS lookup failure, just skip the
>>>> rule and keep processing the rest of the rules.
>>>>
>>>> This is particularly useful, for example, when
>>>> iptables-restore is called at system bootup
>>>> before the network is up and the DNS can be
>>>> reached.
>>>
>>> Not a good idea. Given
>>>
>>> 	-F INPUT
>>> 	-P INPUT ACCEPT
>>> 	-A INPUT -s evil.hacker.com -j REJECT
>>> 	-A INPUT -j ACCEPT
>>>
>>> if you skip the rule, you now have a questionable hole in your
>>> security.
>>
>> just don't use hostnames in stuff which is required to be upo
>> *before*
>> the network to work properly at all

Re: [PATCH iptables]: xtables: tolerate DNS lookup failures

[Guido Trentalancia]

That's the way it is, I am personally against the practice of resolving FQDNs dynamically, but many commercial services do so and the only way of setting up iptables rules in that case is using FQDNs...

Iptables has always supported FQDNs, we are not talking here about removing that support or whether it should be used or not, the point is makjng that feature more robust and fault-tolerant.

I believe the patch improves the current situation for those that wish or simply must use FQDN-based rules.

Regards,

Guido

On the 7th march 2025 20:15:39 CET, Reindl Harald <h.reindl@thelounge.net> wrote:
>
>
>Am 07.03.25 um 16:31 schrieb Guido Trentalancia:
>> Nowadays FQDN hostnames are very often unavoidable, because in many
>> cases their IP addresses are allocated dynamically by the DNS...
>
>which makes rules with hostnames even more dumb
>
>frankly you can't write useful rules for dynamic IPs at all
>
>> The patch is very useful for a desktop computer which, for example,
>> connects to a wireless network only occasionally and not necessarily
>at
>> system bootup and which needs rules for IPs dynamically allocated to
>> FQDNs.
>> 
>> Guido
>> 
>> On Fri, 07/03/2025 at 15.48 +0100, Reindl Harald wrote:
>>>
>>> Am 07.03.25 um 15:07 schrieb Jan Engelhardt:
>>>>
>>>> On Friday 2025-03-07 14:42, Guido Trentalancia wrote:
>>>>
>>>>> libxtables: tolerate DNS lookup failures
>>>>>
>>>>> Do not abort on DNS lookup failure, just skip the
>>>>> rule and keep processing the rest of the rules.
>>>>>
>>>>> This is particularly useful, for example, when
>>>>> iptables-restore is called at system bootup
>>>>> before the network is up and the DNS can be
>>>>> reached.
>>>>
>>>> Not a good idea. Given
>>>>
>>>> 	-F INPUT
>>>> 	-P INPUT ACCEPT
>>>> 	-A INPUT -s evil.hacker.com -j REJECT
>>>> 	-A INPUT -j ACCEPT
>>>>
>>>> if you skip the rule, you now have a questionable hole in your
>>>> security.
>>>
>>> just don't use hostnames in stuff which is required to be upo
>>> *before*
>>> the network to work properly at all

Re: [PATCH iptables]: xtables: tolerate DNS lookup failures

[Reindl Harald]

Am 07.03.25 um 20:32 schrieb Guido Trentalancia:
> That's the way it is, I am personally against the practice of resolving FQDNs dynamically, but many commercial services do so and the only way of setting up iptables rules in that case is using FQDNs...

there is nothing qualified in a reverse-lookup
franklyi can place any reverse-name that i want for any IP i control
don't care really but using hostnames in a packet filter is dumb

> Iptables has always supported FQDNs, we are not talking here about removing that support or whether it should be used or not, the point is makjng that feature more robust and fault-tolerant.
> 
> I believe the patch improves the current situation for those that wish or simply must use FQDN-based rules.
> 
> Regards,
> 
> Guido
> 
> On the 7th march 2025 20:15:39 CET, Reindl Harald <h.reindl@thelounge.net> wrote:
>>
>>
>> Am 07.03.25 um 16:31 schrieb Guido Trentalancia:
>>> Nowadays FQDN hostnames are very often unavoidable, because in many
>>> cases their IP addresses are allocated dynamically by the DNS...
>>
>> which makes rules with hostnames even more dumb
>>
>> frankly you can't write useful rules for dynamic IPs at all
>>
>>> The patch is very useful for a desktop computer which, for example,
>>> connects to a wireless network only occasionally and not necessarily
>> at
>>> system bootup and which needs rules for IPs dynamically allocated to
>>> FQDNs.
>>>
>>> Guido
>>>
>>> On Fri, 07/03/2025 at 15.48 +0100, Reindl Harald wrote:
>>>>
>>>> Am 07.03.25 um 15:07 schrieb Jan Engelhardt:
>>>>>
>>>>> On Friday 2025-03-07 14:42, Guido Trentalancia wrote:
>>>>>
>>>>>> libxtables: tolerate DNS lookup failures
>>>>>>
>>>>>> Do not abort on DNS lookup failure, just skip the
>>>>>> rule and keep processing the rest of the rules.
>>>>>>
>>>>>> This is particularly useful, for example, when
>>>>>> iptables-restore is called at system bootup
>>>>>> before the network is up and the DNS can be
>>>>>> reached.
>>>>>
>>>>> Not a good idea. Given
>>>>>
>>>>> 	-F INPUT
>>>>> 	-P INPUT ACCEPT
>>>>> 	-A INPUT -s evil.hacker.com -j REJECT
>>>>> 	-A INPUT -j ACCEPT
>>>>>
>>>>> if you skip the rule, you now have a questionable hole in your
>>>>> security.
>>>>
>>>> just don't use hostnames in stuff which is required to be upo
>>>> *before*
>>>> the network to work properly at all

Re: [PATCH iptables]: xtables: tolerate DNS lookup failures

[Guido Trentalancia]

Apart from the case of DNS Round-robin, quite often an hostname (for
example, a server hostname) is DNS-mapped to a static IP address, but
over the time (several months or years) that IP address might change,
even though it's still statically mapped.

In that case, if a client behind an iptables packet filter does not use
hostname-based rules, it won't be able to connect to that server
anymore.

So, there are cases where hostname-based rules give an advantage.

Of course, it is out of discussion that rules based on IP addresses are
always preferable when it can certainly be excluded that IP addresses
are going to change over time, for example, if the rules refer to hosts
in the same network or in a network managed by the same entity.

Guido

On Fri, 07/03/2025 at 21.07 +0100, Reindl Harald wrote:
> 
> Am 07.03.25 um 20:32 schrieb Guido Trentalancia:
> > That's the way it is, I am personally against the practice of
> > resolving FQDNs dynamically, but many commercial services do so and
> > the only way of setting up iptables rules in that case is using
> > FQDNs...
> 
> there is nothing qualified in a reverse-lookup
> franklyi can place any reverse-name that i want for any IP i control
> don't care really but using hostnames in a packet filter is dumb
> 
> > Iptables has always supported FQDNs, we are not talking here about
> > removing that support or whether it should be used or not, the
> > point is makjng that feature more robust and fault-tolerant.
> > 
> > I believe the patch improves the current situation for those that
> > wish or simply must use FQDN-based rules.
> > 
> > Regards,
> > 
> > Guido
> > 
> > On the 7th march 2025 20:15:39 CET, Reindl Harald <h.reindl@theloun
> > ge.net> wrote:
> > > 
> > > 
> > > Am 07.03.25 um 16:31 schrieb Guido Trentalancia:
> > > > Nowadays FQDN hostnames are very often unavoidable, because in
> > > > many
> > > > cases their IP addresses are allocated dynamically by the
> > > > DNS...
> > > 
> > > which makes rules with hostnames even more dumb
> > > 
> > > frankly you can't write useful rules for dynamic IPs at all
> > > 
> > > > The patch is very useful for a desktop computer which, for
> > > > example,
> > > > connects to a wireless network only occasionally and not
> > > > necessarily
> > > 
> > > at
> > > > system bootup and which needs rules for IPs dynamically
> > > > allocated to
> > > > FQDNs.
> > > > 
> > > > Guido
> > > > 
> > > > On Fri, 07/03/2025 at 15.48 +0100, Reindl Harald wrote:
> > > > > 
> > > > > Am 07.03.25 um 15:07 schrieb Jan Engelhardt:
> > > > > > 
> > > > > > On Friday 2025-03-07 14:42, Guido Trentalancia wrote:
> > > > > > 
> > > > > > > libxtables: tolerate DNS lookup failures
> > > > > > > 
> > > > > > > Do not abort on DNS lookup failure, just skip the
> > > > > > > rule and keep processing the rest of the rules.
> > > > > > > 
> > > > > > > This is particularly useful, for example, when
> > > > > > > iptables-restore is called at system bootup
> > > > > > > before the network is up and the DNS can be
> > > > > > > reached.
> > > > > > 
> > > > > > Not a good idea. Given
> > > > > > 
> > > > > > 	-F INPUT
> > > > > > 	-P INPUT ACCEPT
> > > > > > 	-A INPUT -s evil.hacker.com -j REJECT
> > > > > > 	-A INPUT -j ACCEPT
> > > > > > 
> > > > > > if you skip the rule, you now have a questionable hole in
> > > > > > your
> > > > > > security.
> > > > > 
> > > > > just don't use hostnames in stuff which is required to be upo
> > > > > *before*
> > > > > the network to work properly at all

Re: [PATCH iptables]: xtables: tolerate DNS lookup failures

[Reindl Harald]

Am 07.03.25 um 21:37 schrieb Guido Trentalancia:
> Apart from the case of DNS Round-robin, quite often an hostname (for
> example, a server hostname) is DNS-mapped to a static IP address, but
> over the time (several months or years) that IP address might change,
> even though it's still statically mapped.
> 
> In that case, if a client behind an iptables packet filter does not use
> hostname-based rules, it won't be able to connect to that server
> anymore.
> 
> So, there are cases where hostname-based rules give an advantage.
sorry, but hostanme based access lists are even on a webserver a bad 
idea and on a packet filter it's unacceptable

if a host changes it's IP rules have to be adjusted - it's as simple as 
that for the past 20 years in networking and will continue so the next 
20 years

------------

and frankly if a service partner can't assign a static IP it's the wrong 
partner to begin with - we are talking about security

either you have a static ip or there is a vpn-tunnel with certificates 
done within seconds with wireguard - the dynamic host is the one to 
build up the tunnel, case closed

Re: [PATCH iptables]: xtables: tolerate DNS lookup failures

[Guido Trentalancia]

The support for hostname-based rules (including multiple resolutions of
an hostname) has been there at least since the following commit:

commit 2ad8dc895ec28a173c629c695c2e11c41b625b6e
Date:   Mon Feb 21 19:10:10 2011 -0500

but probably much earlier, so it's been there for more than 20 years !

Security (and software in general) should not be viewed in absolutistic
terms, I believe, which is why software has features and options, it
depends on different circumstances, if an option is there, the user has
the choice on whether it needs it or not, on whether is convenient or
not, on whether is safe or not.

It's just a very simple patch to improve an existing feature. It's up
to you whether to merge it or not, I can't add much more to this
discussion at this point because it's just looping...

Guido

On Fri, 07/03/2025 at 21.48 +0100, Reindl Harald wrote:
> 
> Am 07.03.25 um 21:37 schrieb Guido Trentalancia:
> > Apart from the case of DNS Round-robin, quite often an hostname
> > (for
> > example, a server hostname) is DNS-mapped to a static IP address,
> > but
> > over the time (several months or years) that IP address might
> > change,
> > even though it's still statically mapped.
> > 
> > In that case, if a client behind an iptables packet filter does not
> > use
> > hostname-based rules, it won't be able to connect to that server
> > anymore.
> > 
> > So, there are cases where hostname-based rules give an advantage.
> 
> sorry, but hostanme based access lists are even on a webserver a bad 
> idea and on a packet filter it's unacceptable
> 
> if a host changes it's IP rules have to be adjusted - it's as simple
> as 
> that for the past 20 years in networking and will continue so the
> next 
> 20 years
> 
> ------------
> 
> and frankly if a service partner can't assign a static IP it's the
> wrong 
> partner to begin with - we are talking about security
> 
> either you have a static ip or there is a vpn-tunnel with
> certificates 
> done within seconds with wireguard - the dynamic host is the one to 
> build up the tunnel, case closed

Re: [PATCH iptables]: xtables: tolerate DNS lookup failures

[Jozsef Kadlecsik]

Hello Guido,

On Fri, 7 Mar 2025, Guido Trentalancia wrote:

> The support for hostname-based rules (including multiple resolutions of
> an hostname) has been there at least since the following commit:
> 
> commit 2ad8dc895ec28a173c629c695c2e11c41b625b6e
> Date:   Mon Feb 21 19:10:10 2011 -0500
> 
> but probably much earlier, so it's been there for more than 20 years !
> 
> Security (and software in general) should not be viewed in absolutistic
> terms, I believe, which is why software has features and options, it
> depends on different circumstances, if an option is there, the user has
> the choice on whether it needs it or not, on whether is convenient or
> not, on whether is safe or not.
> 
> It's just a very simple patch to improve an existing feature. It's up
> to you whether to merge it or not, I can't add much more to this
> discussion at this point because it's just looping...

Yes, because it seems you assume hostnames are stored in the iptables 
rules when it's not. When the rule is entered, hostnames are resolved 
*once* to IP addresses, and the rules with the IP addresses are 
transferred to the kernel and used there. Simple example:

# iptables -A FORWARD -d smtp.google.com -j ACCEPT

Does it mean it's a single rule in the kernel with the hostname 
smtp.google.com? No, not at all:

# iptables -L
Chain INPUT (policy ACCEPT)
target     prot opt source               destination         

Chain FORWARD (policy ACCEPT)
target     prot opt source               destination         
ACCEPT     all  --  anywhere             eg-in-f26.1e100.net 
ACCEPT     all  --  anywhere             ef-in-f26.1e100.net 
ACCEPT     all  --  anywhere             ed-in-f27.1e100.net 
ACCEPT     all  --  anywhere             ef-in-f27.1e100.net 
ACCEPT     all  --  anywhere             eg-in-f27.1e100.net 

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination    

At the time when the command was entered smtp.google.com could be resolved 
into five IPv4 addresses and that resulted not a single rule with a 
hostname, but five rules with IP addresses. The "iptables -L" simply 
translates back the IP addresses to the corresponding names in the DNS.

If the name resolution of smtp.google.com *changes* after the rule was 
entered, it has no effect whatsoever.

Hostnames in iptables/nftables rules should be avoided, especially for 
dynamically changed hostnames.

Best regards,
Jozsef

> On Fri, 07/03/2025 at 21.48 +0100, Reindl Harald wrote:
> > 
> > Am 07.03.25 um 21:37 schrieb Guido Trentalancia:
> > > Apart from the case of DNS Round-robin, quite often an hostname
> > > (for
> > > example, a server hostname) is DNS-mapped to a static IP address,
> > > but
> > > over the time (several months or years) that IP address might
> > > change,
> > > even though it's still statically mapped.
> > > 
> > > In that case, if a client behind an iptables packet filter does not
> > > use
> > > hostname-based rules, it won't be able to connect to that server
> > > anymore.
> > > 
> > > So, there are cases where hostname-based rules give an advantage.
> > 
> > sorry, but hostanme based access lists are even on a webserver a bad 
> > idea and on a packet filter it's unacceptable
> > 
> > if a host changes it's IP rules have to be adjusted - it's as simple
> > as 
> > that for the past 20 years in networking and will continue so the
> > next 
> > 20 years
> > 
> > ------------
> > 
> > and frankly if a service partner can't assign a static IP it's the
> > wrong 
> > partner to begin with - we are talking about security
> > 
> > either you have a static ip or there is a vpn-tunnel with
> > certificates 
> > done within seconds with wireguard - the dynamic host is the one to 
> > build up the tunnel, case closed
> 
> 

-- 
E-mail : kadlec@netfilter.org, kadlec@blackhole.kfki.hu, kadlecsik.jozsef@wigner.hu
Address: Wigner Research Centre for Physics
         H-1525 Budapest 114, POB. 49, Hungary

Re: [PATCH iptables]: xtables: tolerate DNS lookup failures

[Guido Trentalancia]

Of course, if the DNS is not available the "evil hacker" rule is
skipped when this patch is merged.

However the drawbacks of not applying this patch are far worse, because
 if the DNS is not available and some rules in the table contain domain
names, then all rules are skipped and the operation is aborted even for
numeric IP addresses and resolvable names.

Finally, consider that nowadays many host names are allocated
dynamically and therefore for several hosts it is not possible to enter
their numeric IP address.

I hope this helps...

Guido

On Fri, 07/03/2025 at 15.07 +0100, Jan Engelhardt wrote:
> On Friday 2025-03-07 14:42, Guido Trentalancia wrote:
> 
> > libxtables: tolerate DNS lookup failures
> > 
> > Do not abort on DNS lookup failure, just skip the
> > rule and keep processing the rest of the rules.
> > 
> > This is particularly useful, for example, when
> > iptables-restore is called at system bootup
> > before the network is up and the DNS can be
> > reached.
> 
> Not a good idea. Given
> 
> 	-F INPUT
> 	-P INPUT ACCEPT
> 	-A INPUT -s evil.hacker.com -j REJECT
> 	-A INPUT -j ACCEPT
> 
> if you skip the rule, you now have a questionable hole in your
> security.
> 

Re: [PATCH iptables]: xtables: tolerate DNS lookup failures

[Guido Trentalancia]

I can give you quick example of an hostname which is allocated
dynamically in DNS: www.google.com.

If you perform:

  # nslookup www.google.com

then you will obtain a different IP address (or different multiple IP
addresses) each time you run the command.

Given the above, any iptables rule for such kind of host will need to
use its FQDN instead of a statically allocated numeric IP address.

I hope this clarifies the matter.

Regards,

Guido

On Fri, 07/03/2025 at 16.24 +0100, Guido Trentalancia wrote:
> Of course, if the DNS is not available the "evil hacker" rule is
> skipped when this patch is merged.
> 
> However the drawbacks of not applying this patch are far worse,
> because
>  if the DNS is not available and some rules in the table contain
> domain
> names, then all rules are skipped and the operation is aborted even
> for
> numeric IP addresses and resolvable names.
> 
> Finally, consider that nowadays many host names are allocated
> dynamically and therefore for several hosts it is not possible to
> enter
> their numeric IP address.
> 
> I hope this helps...
> 
> Guido
> 
> On Fri, 07/03/2025 at 15.07 +0100, Jan Engelhardt wrote:
> > On Friday 2025-03-07 14:42, Guido Trentalancia wrote:
> > 
> > > libxtables: tolerate DNS lookup failures
> > > 
> > > Do not abort on DNS lookup failure, just skip the
> > > rule and keep processing the rest of the rules.
> > > 
> > > This is particularly useful, for example, when
> > > iptables-restore is called at system bootup
> > > before the network is up and the DNS can be
> > > reached.
> > 
> > Not a good idea. Given
> > 
> > 	-F INPUT
> > 	-P INPUT ACCEPT
> > 	-A INPUT -s evil.hacker.com -j REJECT
> > 	-A INPUT -j ACCEPT
> > 
> > if you skip the rule, you now have a questionable hole in your
> > security.
> > 
> 
> 

Re: [PATCH iptables]: xtables: tolerate DNS lookup failures

[Jan Engelhardt]

On Friday 2025-03-07 16:46, Guido Trentalancia wrote:

>I can give you quick example of an hostname which is allocated
>dynamically in DNS: www.google.com.
>
>If you perform:
>
>  # nslookup www.google.com
>
>then you will obtain a different IP address (or different multiple IP
>addresses) each time you run the command.
>
>Given the above, any iptables rule for such kind of host will need to
>use its FQDN instead of a statically allocated numeric IP address.

In that case of multiple queries returning multiple results (DNS
roundrobing), using hostnames in firewall rules (with or without
ignoring lookup errors) is even more wrong than before!

Because

	-s google.com -j ACCEPT/REJECT

only performs one lookup, it leads to

* accepting _too few_ hosts, meaning you erroneously reject some
  google.com connections in subsequent rules,
* or rejecting *too few* hosts, meaning you erroneously let some
  connections through in subsequent rules.

So now we've gone from 100% of the time google.com is not reachable
to randomly failing half the time attempting to load a search page.

Re: [PATCH iptables]: xtables: tolerate DNS lookup failures

[Guido Trentalancia]

No, I don't get that behaviour, at least with iptables 1.8.9 to 1.8.11.

I have just checked with "iptables -L".

Allowing or rejecting a given FQDN results in iptables generating as
many allow or reject rules as the number of results returned by the DNS
lookup for that FQDN.

Guido

On Fri, 07/03/2025 at 18.02 +0100, Jan Engelhardt wrote:
> On Friday 2025-03-07 16:46, Guido Trentalancia wrote:
> 
> > I can give you quick example of an hostname which is allocated
> > dynamically in DNS: www.google.com.
> > 
> > If you perform:
> > 
> >  # nslookup www.google.com
> > 
> > then you will obtain a different IP address (or different multiple
> > IP
> > addresses) each time you run the command.
> > 
> > Given the above, any iptables rule for such kind of host will need
> > to
> > use its FQDN instead of a statically allocated numeric IP address.
> 
> In that case of multiple queries returning multiple results (DNS
> roundrobing), using hostnames in firewall rules (with or without
> ignoring lookup errors) is even more wrong than before!
> 
> Because
> 
> 	-s google.com -j ACCEPT/REJECT
> 
> only performs one lookup, it leads to
> 
> * accepting _too few_ hosts, meaning you erroneously reject some
>   google.com connections in subsequent rules,
> * or rejecting *too few* hosts, meaning you erroneously let some
>   connections through in subsequent rules.
> 
> So now we've gone from 100% of the time google.com is not reachable
> to randomly failing half the time attempting to load a search page.
> 

Re: [PATCH iptables]: xtables: tolerate DNS lookup failures

[Jan Engelhardt]

On Friday 2025-03-07 16:24, Guido Trentalancia wrote:

>Of course, if the DNS is not available the "evil hacker" rule is
>skipped when this patch is merged.
>
>However the drawbacks of not applying this patch are far worse, because
> if the DNS is not available and some rules in the table contain domain
>names, then all rules are skipped and the operation is aborted even for
>numeric IP addresses and resolvable names.

A silent/ignored error is much worse than an explicit error;
the latter you can at least test for, scripting or otherwise.

Re: [PATCH iptables]: xtables: tolerate DNS lookup failures

[Guido Trentalancia]

When using the patch, the error is not silent, it's properly logged on
stderr.

The patch solves a well defined problem: when iptables are loaded
(usually at system bootup) the network might not be available (e.g.
laptop computer with wireless connectivity), so iptables should be
tolerant to DNS unavailability, while keeping producing an error, but
not aborting the rest of iptables rules (which might be needed for
local network connectivity, for example).

Please consider that if DNS is not available, then the "evil hacker"
host that needs to be rejected in your previous example is also most
likely unreachable.

Consider that iptables can always be loaded again when Internet
connectivity becomes available (for example, by a script used to turn
the wireless connection up).

Regards,

Guido

On Fri, 07/03/2025 at 17.51 +0100, Jan Engelhardt wrote:
> On Friday 2025-03-07 16:24, Guido Trentalancia wrote:
> 
> > Of course, if the DNS is not available the "evil hacker" rule is
> > skipped when this patch is merged.
> > 
> > However the drawbacks of not applying this patch are far worse,
> > because
> > if the DNS is not available and some rules in the table contain
> > domain
> > names, then all rules are skipped and the operation is aborted even
> > for
> > numeric IP addresses and resolvable names.
> 
> A silent/ignored error is much worse than an explicit error;
> the latter you can at least test for, scripting or otherwise.
> 

Re: [PATCH iptables]: xtables: tolerate DNS lookup failures

[Jan Engelhardt]

On Friday 2025-03-07 18:09, Guido Trentalancia wrote:
>
>The patch solves a well defined problem: when iptables are loaded
>(usually at system bootup) the network might not be available (e.g.
>laptop computer with wireless connectivity)
>
>Consider that iptables can always be loaded again when Internet
>connectivity becomes available (for example, by a script used to turn
>the wireless connection up).

When you add/edit rules in Networkmanager hooks (or whatever the
software in use is), i.e. response to network events,
then you can just as well use a *deterministic* ruleset during early
boot.

Re: [PATCH iptables]: xtables: tolerate DNS lookup failures

[Guido Trentalancia]

I am not familiar with the application layer tools such as
NetworkManager.

The point is that the underlying issue does not change with auxiliary
tools: I believe iptables should not abort setting up all rules, just
because one or more of them fail to resolve in DNS.

As already said, if one or more rules fail then those specific hosts
are most likely unreachable anyway.

Guido

On Fri, 07/03/2025 at 18.21 +0100, Jan Engelhardt wrote:
> On Friday 2025-03-07 18:09, Guido Trentalancia wrote:
> > 
> > The patch solves a well defined problem: when iptables are loaded
> > (usually at system bootup) the network might not be available (e.g.
> > laptop computer with wireless connectivity)
> > 
> > Consider that iptables can always be loaded again when Internet
> > connectivity becomes available (for example, by a script used to
> > turn
> > the wireless connection up).
> 
> When you add/edit rules in Networkmanager hooks (or whatever the
> software in use is), i.e. response to network events,
> then you can just as well use a *deterministic* ruleset during early
> boot.

Re: [PATCH iptables]: xtables: tolerate DNS lookup failures

[Phil Sutter]

On Fri, Mar 07, 2025 at 06:40:31PM +0100, Guido Trentalancia wrote:
> I am not familiar with the application layer tools such as
> NetworkManager.
> 
> The point is that the underlying issue does not change with auxiliary
> tools: I believe iptables should not abort setting up all rules, just
> because one or more of them fail to resolve in DNS.

There is consensus amongst Netfilter developers that skipping rules or
even parts of them when loading a ruleset is a critical flaw in the
software because loaded ruleset behaviour is not deterministic anymore.
The usual security context demands that behaviour is exactly as
requested by the user, any bit flipped could disable the whole security
concept. "We printed a warning" is not an excuse to this.

In order to implement the desired behaviour, just call iptables
individually for each rule and ignore failures. You could also cache IP
addresses, try a new lookup during firewall service startup and fall
back to the cached entry if it fails.

My personal take is this: If a DNS reply is not deterministic, neither
is a rule based on it. If it is, one may well hard-code the lookup
result.

> As already said, if one or more rules fail then those specific hosts
> are most likely unreachable anyway.

No, it just means DNS has failed. The resulting rules use IP addresses
and there is no guarantee these are not reachable. You are making
assumptions based on your use-case, but the proposed behaviour will
affect all use-cases (and there is always that special one ... ;).

Cheers, Phil

Re: [PATCH iptables]: xtables: tolerate DNS lookup failures

[Guido Trentalancia]

Hello and thanks for your feedback.

On Thu, 20/03/2025 at 16.39 +0100, Phil Sutter wrote:
> On Fri, Mar 07, 2025 at 06:40:31PM +0100, Guido Trentalancia wrote:
> > I am not familiar with the application layer tools such as
> > NetworkManager.
> > 
> > The point is that the underlying issue does not change with
> > auxiliary
> > tools: I believe iptables should not abort setting up all rules,
> > just
> > because one or more of them fail to resolve in DNS.
> 
> There is consensus amongst Netfilter developers that skipping rules
> or
> even parts of them when loading a ruleset is a critical flaw in the
> software because loaded ruleset behaviour is not deterministic
> anymore.

It's the Internet and DNS connectivity that are inherently not
deterministic. The Internet is a best-effort network or in other words
non-deterministic, so any network filter for the Internet can only be
best-effort.

The patch simply makes the netfilter behaviour adaptive to that
inherent principle and fault-tolerant.

> The usual security context demands that behaviour is exactly as
> requested by the user, any bit flipped could disable the whole
> security
> concept. "We printed a warning" is not an excuse to this.

Priting a warning and recoverying in a best-effort manner from an
unrecoverable failure is the best a network filter can do.

A partial failure is always better than a total failure.

> In order to implement the desired behaviour, just call iptables
> individually for each rule and ignore failures. You could also cache
> IP
> addresses, try a new lookup during firewall service startup and fall
> back to the cached entry if it fails.

The former is just an expensive trick. The latter might be an
alternative solution to the problem, but it is more complex than just
rescheduling netfilter setup after network (or DNS) comes up again.

You need quite a lot of C code in order to cache DNS lookups, while you
only need a script to reload the netfilter.

> My personal take is this: If a DNS reply is not deterministic,
> neither
> is a rule based on it. If it is, one may well hard-code the lookup
> result.

There is no prescription on being deterministic, when the underlying
network is inherently non-deterministic.

It has already been discussed that even when DNS Round-Robin is not
being used for a specific host, the host might still change its IP
address on a slowly-varying timescale: in such scenario hostname-based
filtering rules significantly simplify network management and minimize
network downtimes.

In any case, hostname-based rules are optional and using or not using
them is entirely discretional, the patch does not force the use of
hostname-based rules, it just makes them fault-tolerant.

> > As already said, if one or more rules fail then those specific
> > hosts
> > are most likely unreachable anyway.
> 
> No, it just means DNS has failed. The resulting rules use IP
> addresses
> and there is no guarantee these are not reachable. You are making
> assumptions based on your use-case, but the proposed behaviour will
> affect all use-cases (and there is always that special one ... ;).

If a DNS lookup fails, it can be due to a DNS failure as you said but
also to a completely unreachable DNS server or a completely unreachable
network (no connectivity at all): so circumstances might vary.

In the case of an Internet client such as a workstation, most Internet
connectivity happens through DNS lookups: you generally don't type IP
addresses in your web browser or ftp client.

So, if the DNS lookup fails, no matter what the reason actually is (DNS
failure or network failure), the client request will also most probably
fail, no matter whether its resolved IP address is actually reachable
or not, because the request is most likely based on an hostname.

Static IP addresses are normally only used for connectivity between
servers: in that case, the code in the patch is not used and things
stay as they are.

> Cheers, Phil

I hope this helps...

Cheers, Guido

Re: [PATCH iptables]: xtables: tolerate DNS lookup failures

[Phil Sutter]

Hi,

On Fri, Mar 21, 2025 at 12:21:27PM +0100, Guido Trentalancia wrote:
[...]

Sorry for skipping all your points. I didn't see any new data in them so
no point in repeating what others have commented already.

> I hope this helps...

It does not. Applying a ruleset partially due to failures is not an
acceptable behaviour, so this is a NACK to your patch from my side.

Cheers, Phil