Monitoring Hosts and Domains for RBL Listing Using Azure - Part 1: Design
The thing that prompted the publishing of this series of posts is a recent case of a customer with a large mail platform. The Mail Transfer Agents handling the internet mail flow for such a platform are usually susceptible to being flagged as malicious on RBLs, causing issues with mail flow. The solution described in these posts helps monitor the status on the RBLs and trigger alerts in service management systems, using modern cloud application development techniques.
But wait, what is an RBL? A Real Time Block list is a service that keeps track of the domain and/or the IP address of the hosts reported to be sending SPAM or malicius messages. RBLs are actual DNS zones where IP addresses or domain names are represented by A records.
Let's take a list, say rbl.example.net, for example. To check if the host with IP 100.101.102.103 is listed we have to query the DNS for the host 103.102.101.100.rbl.example.net. If there is no such host known (the responce is NXDOMAIN) the host is not listed. If there is an A record, the host is listed. Many RBLs provide more information on why the host was listed in the address returned or a TXT record for the same host. You may find more details on this on the RBL's website.
Now that we know what a RBL is and how it works, let's design the solution that will monitor our servers and domains for blacklisting.
First of all, our solution has to be easy to access and interface with any monitoring system. This is why I've selected Azure Functions. They provide compute on demand, they can be accessed using HTTP plus the cost of the consumption plan is really low.
First of all, our solution has to be easy to access and interface with any monitoring system. This is why I've selected Azure Functions. They provide compute on demand, they can be accessed using HTTP plus the cost of the consumption plan is really low.
We also need some kind of storage to store the information about our hosts, domains and lists that we are going to check against. For this we are going to use Azure Table storage.
The key solution components are depicted on the below diagram:
Starting with the easiest part, the storage, we need a storage account with three tables named "Hosts", "Domains" and "RBLs". The hosts table will contain the information about our hosts. The partition key will be the IP of the host and the row key the it's name.
The domains table will contain the information about the domains we want to keep an eye on, where the partition and row keys are the domain name.
The rbl table is a bit more complicated, the partition key is the name of the RBL, the row key is the address of the rbl, and the type column contains the type of the rbl that can be either domain or IP.
Moving on to the functions, I've decided to create a function for each operation, such as adding a domain, host or RBL to keep the source code simple to use and understand.
The domains table will contain the information about the domains we want to keep an eye on, where the partition and row keys are the domain name.
The rbl table is a bit more complicated, the partition key is the name of the RBL, the row key is the address of the rbl, and the type column contains the type of the rbl that can be either domain or IP.
Moving on to the functions, I've decided to create a function for each operation, such as adding a domain, host or RBL to keep the source code simple to use and understand.
At this time, the solution has the below functions:
This concludes the design on the solution, stay tuned for the next post of the series that's going to be on how to deploy it on your subscription!
- get, add, remove and check a domain
- get, add, remove and check a host
- get, add and remove a list
This concludes the design on the solution, stay tuned for the next post of the series that's going to be on how to deploy it on your subscription!
