2

Is there a way to create a domain record that would function as an inbound IP allow list, to be used in firewalls? Essentially creating a HTTPS ingress proxy.

Example:

FQDN IP Range
allowlist.bob.com 103.102.101.100/19

I'm asking as we're updating our public IPs that our customers use in their allow lists. I thought it would be far easier if they could just add a domain to their allow list, then we could switch the IPs for them ourselves. Like the way that you may go about swapping a backend server that a customer accesses; you can just swap the IP in the A record they use.

Even though you can add multiple A records with the same name, the round robin nature would mean that only a single IP is allowed each time the FQDN is queried. It wouldn't correlate with the inbound origin IP.

Outbound connections through some firewalls are capable of filtering on domains, but I don't know much about the same filtering on inbound connections.

I thought something like this question already existed, but I can't seem to find it.

Improve this question
2
  • 2
    This is entirely dependent on what your customers use to manage inbound traffic. Do their firewalls support FQDN's in this manner?
    – joeqwerty
    Nov 8 at 13:09
  • @joeqwerty I should have said that I don't know much about this topic. I know that FQDNs can be used on outbound connections on some firewalls, but I'm not sure about inbound. I've updated the post to reflect this. In that way, this is more of a curiousity post. If there is a working answer for us and our customers, then it's likely we'll use it.
    – Rhys
    Nov 8 at 14:13

2 Answers 2

Reset to default
4

There's no standard for something like this - basically, you'd be defining your own protocol.

A common way for that is to use the rather generic TXT/16 record with a well-known resource name, e.g. _allowlist.domain.tld TXT "192.0.2.0/24;198.51.100.0/24".

An alternative way would be to repurpose a previously unused record type that fits your purpose, e.g. APL/42 which contains a list of CIDR prefixes (experimental, might be poorly supported).

This list of record types might be helpful.

Improve this answer
2
  • Thanks for the answer! Makes sense and thought the TXT looked most suited. I just couldn't find any resources on the topic, probably because I didn't know where to look.
    – Rhys
    Nov 9 at 8:50
  • 1
    @Rhys I've added a link to a comprehensive list of record types to the answer. ;-)
    – Zac67
    Nov 9 at 8:57
4

Yes you can publish IP-address ranges and subnets in DNS records but there is, as far as I know, not a dedicated and established DNS resource record type to represent IP-address ranges.

So people typically resort to using TXT records for that.

A common example of how that is done is how SPF uses TXT records to among others publish the IP’s and subnets that a domain owner expects to be used for sending their e-mail.
A good example is the _spf.google.com record that references _netblocks.google.com and several additional TXT records.

_spf.google.com.        300 IN  TXT "v=spf1 include:_netblocks.google.com include:_netblocks2.google.com include:_netblocks3.google.com ~all"

_netblocks.google.com.  300 IN  TXT "v=spf1 ip4:35.190.247.0/24 ip4:64.233.160.0/19 ip4:66.102.0.0/20 ip4:66.249.80.0/20 ip4:72.14.192.0/18 ip4:74.125.0.0/16 ip4:108.177.8.0/21 ip4:173.194.0.0/16 ip4:209.85.128.0/17 ip4:216.58.192.0/19 ip4:216.239.32.0/19 ~all"

_netblocks2.google.com. 300 IN  TXT "v=spf1 ip6:2001:4860:4000::/36 ip6:2404:6800:4000::/36 ip6:2607:f8b0:4000::/36 ip6:2800:3f0:4000::/36 ip6:2a00:1450:4000::/36 ip6:2c0f:fb50:4000::/36 ~all"

The difference with SPF is that all mail servers (that support SPF) understand and implement the same parsing rules for the policy that a domain owner publishes in DNS for their domain, and such a standard does not exist (yet) for firewall access rules.

Your suggestion of putting in several A and/or AAAA records as a round-robin record also has merit (although that becomes slightly cumbersome if you need to write out an entire subnet in its constituent IP-addresses)

The problem for both approaches is that firewalls don’t have built in support to properly load the IP’s you publish in DNS and when they do, they may not properly update their policy when you make changes to the DNS records.

Many firewalls already accept a FQDN but will only lookup the associated IP and/or IP-addresses once, when the rule is loaded. (Linux iptables for example will correctly load all IP’s when the FQDN is a round-Robin record.) The firewall will then internally continue to use the discovered IP-address(es). The firewall won’t do a new lookup until the firewall appliance gets restarted and or the rule base gets reloaded. Most current firewalls don’t honor the TTL on Dns records and when the FQDN gets updated the firewall won’t update the IP’s they use within a predictable interval

Doing DNS lookups is relatively slow and a firewall can’t perform a DNS lookup every time a packet / connection needs to be checked against an active firewall rule. Remember: that connection, that IP packet only contains numeric IP data i.e. the source & destination IP-address and Port numbers. hence that FQDN’s get stored as IP-addresses in the active rule set.

I was on mobile before and just tested a Linux firewall with iptables:

  • Adding rules with a FQDN is fully supported.

  • The FQDN gets resolved to an IP-address by iptables and the resolved IP is what will be used in the effective rule base.

  • When the FQDN is a round-robin DNS record, iptables will add several rules, one each for every one of the IP's in that round-robin DNS record.
    (so far so good, right)

  • Saving the firewall rule set with iptables-save does NOT revert the resolved IP-addresses back to a FQDN.

    That implies that after a reboot, my server will NOT pick any changes that were made in the FQDN. If gateway.example.com initially points to 192.0.2.1 and 192.0.2.2 and for example changes to 192.0.2.1 and 192.0.2.5 , my server will simply restore rules with the IP's 192.0.2.1 and 192.0.2.2. The new round-robin record in gateway.example.com 192.0.2.5 does not get added and 192.0.2.2 won't be removed.

Create the test records

round-robin.example.com. 349    IN  A   192.0.2.2
round-robin.example.com. 349    IN  A   192.0.2.1
round-robin.example.com. 349    IN  A   192.0.2.4

Followed by iptables -A INPUT -p tcp --dport 22 --source round-robin.example.com -j ACCEPT

iptables -L INPUT

Chain INPUT (policy ACCEPT)
target     prot opt source               destination
ACCEPT     all  --  anywhere             anywhere             
 ...
ACCEPT     tcp  --  192.0.2.4            anywhere             tcp dpt:ssh
ACCEPT     tcp  --  192.0.2.2            anywhere             tcp dpt:ssh
ACCEPT     tcp  --  192.0.2.1            anywhere             tcp dpt:ssh


iptables-save |grep 22

-A INPUT -s 192.0.2.4/32 -p tcp -m tcp --dport 22 -j ACCEPT
-A INPUT -s 192.0.2.2/32 -p tcp -m tcp --dport 22 -j ACCEPT
-A INPUT -s 192.0.2.1/32 -p tcp -m tcp --dport 22 -j ACCEPT
Improve this answer
4
  • This is super helpful for understanding how it works, thanks! In my case, we wouldn't change these IPs often, so a long update window would be fine. Either way, since it has intermittent support, I likely won't use it in my case. Would you imagine support growing for this in the future?
    – Rhys
    Nov 9 at 8:58
  • 1
    As a firewall admin I would find it somewhat convenient that I don't have to make any changes myself when a supplier / vendor / counterparty is making changes in their network and access policies wil update automatically when that counterparty publishes their changes. On the other hand: I don't want a mistake by that counter party, to effect me. Imagine that somebody accidentally at the vendor adds a CIDR mask of /2 rather than /32 to an IP-address 10.0.2.12 - then suddenly rather than only my counter party, half the world is allowed
    – HBruijn
    Nov 9 at 10:50
  • 1
    With that consideration I imagine that you won't get much traction for a mechanism to effectively give a third party the ability to modify your perimeter security
    – HBruijn
    Nov 9 at 11:02
  • Thanks for expanding further and showing examples @HBruijn! I think you have a really good point and that pretty much shuts down the idea. That may explain the behaviour on supported firewalls, where the IPs wont update even if the domain record does... Or maybe I'm looking too far into it. With the popularity of CDNs I imagine that sometime in the future, allow lists will be a thing of the past anyway. Either way, my curiosity here has been satisfied. I'm glad I asked and I've learnt a lot! Thanks :)
    – Rhys
    Nov 10 at 9:18

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .