### Summary

When modifying firewall rules with `iptables` module in ansible, the iptables tries to do reverse lookups for the IP addresses in some occasions, which can cause huge delays when the defined DNS server is unreachable for some reason. When working with iptables from the command line, one can just use the `-n` -switch (`--numeric`) of the iptables binary to disable DNS lookups altogether. However, when using the `ansible.builtin.iptables` module, such switch can not be set.

The delay problem of iptables has been known issue for long, but usually it can be bypassed with the trick mentioned above.

The` --numeric` only is available for the list (`-L`) command, and even though this module does not directly offer such functionality, internally it is using it for checking policies etc.

### Issue Type

Feature Idea

### Component Name

iptables

### Additional Information

For the sake of clarity: the problem is not about using hostnames for firewall rules (which is generally considered bad idea anyway), but the fact that iptables does the reverse lookup of the IP addresses too.

As for the question: why don't you just setup a working DNS?
- Some environments might not have DNS at all and still need firewall
- Not all machines need DNS, so no DNS for them
- DNS might not be available during the deployment when setting the initial firewall rules but will be around later on

### Code of Conduct

- [X] I agree to follow the Ansible Code of Conduct
this name will match.
      - If this option is omitted, any interface name will match.
    type: str
  out_interface:
    description:
      - Name of an interface via which a packet is going to be sent (for
        packets entering the C(FORWARD), C(OUTPUT) and C(POSTROUTING) chains).
      - When the C(!) argument is used before the interface name, the sense is inverted.
      - If the interface name ends in a C(+), then any interface which begins
        with this name will match.
      - If this option is omitted, any interface name will match.
    type: str
  fragment:
    description:
      - This means that the rule only refers to second and further fragments
        of fragmented packets.
      - Since there is no way to tell the source or destination ports of such
        a packet (or ICMP type), such a packet will not match any rules which specify them.
      - When the "!" argument precedes fragment argument, the rule will only match head fragments,
        or unfragmented packets.
    type: str
  set_counters:
    description:
      - This enables the administrator to initialize the packet and byte
        counters of a rule (during C(INSERT), C(APPEND), C(REPLACE) operations).
    type: str
  source_port:
    description:
      - Source port or port range specification.
      - This can either be a service name or a port number.