On 23 Jul 2018, at 23:40, Pedro David Marco wrote:
On Tuesday, July 24, 2018, 12:07:52 AM GMT+2, David B Funk
<dbf...@engineering.uiowa.edu> wrote:
What kind of 'calculations with that IP' ?
Thanks Dave... calculations are complex and done with a an external
script that reads some files parsing them...
Depending on how you intend your service to work, you could be creating
a trap for your users. Feel free to fill the gaps in my understanding of
what you intend, as after all I'm only working with the little you have
shared in this thread so far.
Normally, content scanners / MTAs will perform their DNS queries from
behind a caching name server. The idea is that once a response to a
particular question is known, that information can be kept around and
reused at a much faster rate. This is (and has been) the recommended
architecture since forever, with minor variations on where / how many
caching name servers to deploy.
On 23 Jul 2018, at 13:49, Pedro David Marco wrote:
i am planning to run my own RBL with a nameserver, that when queried
for an IP that is not in its database, does some calculations with
that IP and replies accordingly [⋯]
This means that the caching name server that is querying you will have
to wait for _most_ answers. Without a way to know how long that process
will take, it's possible that DNS clients will retry their questions,
caching name server will as well and the whole thing becomes a tarpit
that ends up wasting DNS resolver resources and generally slowing down
mail delivery. Under that scenario, I would not recommend usage of the
service you propose, but again feel free to any gaps in the above
reasoning.
The reason that in the traditional DNS list model you do all your
calculations in advance and produce a zone is precisely to ensure that
your service can respond quickly. Also note that DNS is designed to
aggressively cache responses, so that repeated queries can be satisfied
from a nearby cache. Wildcard DNS records could be leveraged to some
extent, so as to have better control over caching of results.
There are variations to the DNS list architecture that include pushing
dynamic updates to keep the zone data updated as more / newer data is
available. This could work for your use case -- you could consume a
query log from your authoritative DNS servers, perform the required
calculations and then push the updated response when the results are
available. In the meantime, the DNS server would return NXDOMAIN (or
perhaps something else if wildcard records are an option).
Without knowing more about these calculations you intend to perform,
this dynamic update approach would seem like a workable plan which might
or might not fall within your expertise.
In a distant past I built something like what you're describing although
for a very different purpose. I ended up writing a name server in Perl
(https://metacpan.org/release/Net-DNS-Method). This won't come near the
required performance or behavior for a public facing DNS list with any
sort of meaningful usage. Also consider that your DNS traffic will only
go up, because if your DNS list gets mentioned around, people is going
to add it to their configuration and forget about it.
So, while this is likely not an ideal forum for this topic, I don't mind
beating this horse for a little while.
Best regards
-lem
