discuss AT lists.opennicproject.org
Subject: Discuss mailing list
List archive
- From: Jonah Aragon <jonah AT triplebit.net>
- To: discuss AT lists.opennicproject.org
- Subject: Re: [opennic-discuss] botnets mitigation
- Date: Sun, 10 Jun 2018 16:27:32 -0500
Katie,
I think you misunderstood his second proposal, he wants to only whitelist Tier 1 servers, and then the Tier 2 resolvers will slave from them (which is current functionality on the srvzone script most people use anyways, as far as I know) rather than Emercoin’s own servers. That seems like a much more reasonable request, since Tier 1 servers are generally unchanging, and as such the whitelist would be relatively manageable.
Jonah
On Sun, Jun 10, 2018 at 2:43 PM Katie Holly <opennic AT lists.dedilink.eu> wrote:
Hi Oleg,
OpenNIC has an active agreement with Spamhaus that they are allowed to feed one of our blacklists (see [0] for more information) that Tier 2 operators can use to block domains solely used for botnet control or other bad things. This was done for other .bit domains that were used for controlling botnets (see [1} for example)
Tier 1 servers are, as far as I know, under no circumstances allowed to block any kind of domain or IP address. Such censorship would immediately cause your Tier 1 server to be removed from the root zone and replaced by another volunteers server.
If do not want to or, more specifically, can not continue serving an uncensored view of the Emercoin zones, please let us know and we'll find a volunteer to run a Tier 1 server as a replacement to yours. This is, at least from what I can see, the only viable solution.
1. Wouldn't be a good solution IMHO - Yes, it would decentralize the network a bit but block Tier 2 operators from continuing to run their root-hint-only servers from which there are many. Example for our anycast network: Servers do not store any information on hard disks other than static files pushed into Docker container images on build time and they are not allowed to write to disk and have to use a small (10MB size) tmpfs directory to keep their dynamic data stored.
2. DNS resolvers do not always use the same IP address for backend queries and frontend service. A DNS server might be reachable at 8.8.8.8 or 185.121.177.177 but whenever it needs to query an authoritative DNS server for more information, it used a backend IP address, for 8.8.8.8 that would be a lot of /24 networks [2], for 185.121.177.177 that would be a lot of IP addresses, fast moving IP addresses since we utilize cloud services a lot and you wouldn't be able to keep up with the amount of IP address changes involved in this, this is a problem specific to how anycast works and we have seen a couple users hopping onto that anycast service train recently to host their Tier 2.
Another "solution" I see, which wouldn't be very viable, is to drop the requirement for Tier 2 servers to resolve any crypto domains and allow them to use your suggested solution in point 1 if they want to offer crypto TLDs for their users.
Best regards
Katie Holly
[0] https://wiki.opennic.org/api/blacklist
[1] https://www.spamhaus.org/sbl/query/SBL325026
[2] https://developers.google.com/speed/public-dns/faq#locations_of_ip_address_ranges_google_public_dns_uses_to_send_queries
On 06/10/2018 08:21 PM, Oleg Khovayko wrote:
> Hi,
>
> I am representing Emercoin, which has successful peering with OpenNIC for years.
>
> However, recently I see, our servers seed1 and seed2, where OpenNIC requests info about zones .coin/.emc/.bazar/.lib, started used to control botnets.
> There is many requests from different IPs for same domain name, fields A/TXT.
> I analyzed field TXT in some EmerDNS recors, for example: dns:refereefitter.lib
> And found there - there is some encrypted strings, seems like command to botnet.
> This article contains more information:
> https://www.fireeye.com/blog/threat-research/2018/04/cryptocurrencies-cyber-crime-blockchain-infrastructure-use.html
>
> I would like continue peering, but do not want to serve a criminal botnets.
>
> I see 2 ways, how to mitigate this issue:
>
> 1. Each Tier1 OpenNIC will setup local Emer node, and perform peering to the localhost. And we will just discontinue our peering services.
> Pros: Quick resolving, best security
> Cons: Needed ~1G HDD and 300MB RAM to running process.
>
> 2. We can add IP filters to our seed1/seed2, and ban all IPs, but 10 Tier 1 OpenNIC servers.
> Pros: Nothing needed to do on OpenNIC side
> Cons: Dependence on network, bigger latencies.
>
> So, I have questions:
> 1. If we will add DNS-filters, which includes Tier1 servers - is this enough to continue peering with option 2?
> 2. Is this possible to move to option 1, when OpenNIC keeps local resolver?
>
> Thanks,
> Oleg
>
>
>
>
>
> --------
> You are a member of the OpenNIC Discuss list.
> You may unsubscribe by emailing discuss-unsubscribe AT lists.opennicproject.org
>
--------
You are a member of the OpenNIC Discuss list.
You may unsubscribe by emailing discuss-unsubscribe AT lists.opennicproject.org
- [opennic-discuss] botnets mitigation, Oleg Khovayko, 06/10/2018
- Re: [opennic-discuss] botnets mitigation, William Weber, 06/10/2018
- Re: [opennic-discuss] botnets mitigation, Oleg Khovayko, 06/10/2018
- Re: [opennic-discuss] botnets mitigation, Katie Holly, 06/10/2018
- Re: [opennic-discuss] botnets mitigation, Jonah Aragon, 06/10/2018
- Re: [opennic-discuss] botnets mitigation, Jacob Bachmeyer, 06/11/2018
- Re: [opennic-discuss] botnets mitigation, Jonah Aragon, 06/11/2018
- Re: [opennic-discuss] botnets mitigation, Oleg Khovayko, 06/11/2018
- Re: [opennic-discuss] botnets mitigation, Jeff Taylor, 06/19/2018
- Re: [opennic-discuss] botnets mitigation, Jonah Aragon, 06/19/2018
- Re: [opennic-discuss] botnets mitigation, Jeff Taylor, 06/19/2018
- Re: [opennic-discuss] botnets mitigation, Oleg Khovayko, 06/11/2018
- Re: [opennic-discuss] botnets mitigation, Jonah Aragon, 06/11/2018
- Re: [opennic-discuss] botnets mitigation, Jacob Bachmeyer, 06/11/2018
- Re: [opennic-discuss] botnets mitigation, Jonah Aragon, 06/10/2018
- Re: [opennic-discuss] botnets mitigation, William Weber, 06/10/2018
Archive powered by MHonArc 2.6.19.