To avoid issues with DNS blacklisting, I’ve setup a separate domain for my DNS seed.
Like #28936
I’ve chosen a domain name that is explicitly verbose about its purpose and the possibility of malware on resolved IPs, to go an extra mile in helping avoid any attempts to abuse it.
To avoid issues with DNS blacklisting, I've setup a separate domain for my DNS seed.
The following sections might be updated with supplementary metadata relevant to reviewers and maintainers.
For detailed information about the code coverage, see the test coverage report.
See the guideline for information on the review process.
| Type | Reviewers |
|---|---|
| Concept NACK | petertodd, 1440000bytes |
If your review is incorrectly listed, please react with 👎 to this comment and the bot will ignore it on the next update.
No conflicts as of last run.
131@@ -132,7 +132,7 @@ class CMainParams : public CChainParams {
132 // release ASAP to avoid it where possible.
133 vSeeds.emplace_back("seed.bitcoin.sipa.be."); // Pieter Wuille, only supports x1, x5, x9, and xd
134 vSeeds.emplace_back("dnsseed.bluematt.me."); // Matt Corallo, only supports x9
135- vSeeds.emplace_back("dnsseed.bitcoin.dashjr.org."); // Luke Dashjr
136+ vSeeds.emplace_back("dnsseed.bitcoin.dashjr-list-of-p2p-nodes-maybe-malware.us."); // Luke Dashjr
I am not sure why you got a domain with ‘malware’ in its name from namecheap for using as DNS seed in bitcoin core.
Related question (although out of scope for this PR): If there are so many issues with DNS seeds, why not disable dnsseed and fixedseeds? Instead 9 developers running DNS seeds can provide a node address which can be used for seednode to get node addresses using GETADDR. Or make bootstrapping work like tor nodes for all nodes.
There are advantages and disadvantages to both DNS seeds and fixed seeds. Having both is good.
Discussing this doesn’t need to happen here on this straightforward pull-req.
0.21.x and 22.x. I didn’t get a single result with a newer subversion.
Given the current composition of nodes on the network and that none of the other DNS seeds show a similar pattern, this seems unlikely to just be an unlucky result of a random selection. Could this be a bug in your seeder?
DNS points to the same host.
0dnsseed.bitcoin.dashjr.org. 40000 IN NS ipv4.jun.dashjr.org.
1dnsseed.bitcoin.dashjr-list-of-p2p-nodes-maybe-malware.us. 39994 IN NS ipv4.jun.dashjr.org.
So should be no difference is answers.
The main outcome I can see from this change is confusion from (maybe less-technical) users, when they see this unusual domain / maybe-malware printed to their console/logs:
02023-12-28T11:54:27.034530Z [dnsseed] Loading addresses from DNS seed dnsseed.bitcoin.dashjr-list-of-p2p-nodes-maybe-malware.us.
I don’t think we should ship software that will do that.
I agree with @fanquake, so NACK the choice of domain name.
Anyone who actually sees the domain name used and uses it for some purpose will very likely be able to understand that these IP addresses may be anything, so there is no need for this disclaimer. Meanwhile, putting malware in the name just invites confusion and unnecessary support requests from curious people who don’t understand what they are seeing.
NACK with this domain and I shared it in the first line of my last comment. I agree with fanquake although domain could even get suspended for such domain name and some of the IPs it gets resolved to.
This is important even if not directly related to PR but domain and author: #29145#pullrequestreview-1797445282
With these warnings on luke.dashjr.org I am not okay with author running a DNS seed for bitcoin core:
WARNING: In November and December 2022, this server was compromised twice. While known rootkits were promptly removed, it has not been entirely audited nor rebuilt yet. Be extra careful to verify OpenPGP signatures and not to trust anything you download.
Some content on my personal web directory (this site) is for my personal use only, and may not be legally distributable to other parties. I actively try to keep these properly secured so others cannot download them, but it is possible this might not work for whatever reason. If you are able to download anything that I shouldn’t be distributing, please contact me and I will gladly make sure access to it is restricted properly.
By downloading anything from my personal web directory here, you assume responsibility for ensuring the copy is in compliance with the laws of your jurisdiction, my jurisdiction (Florida, USA), and my server’s jurisdiction (New York, USA). If you do not agree to these terms, you are not authorized to access this website. Accessing this website implies you have accepted this agreement as a binding contract.
I don’t think author is following 0 and 1 shared in this policy: https://github.com/bitcoin/bitcoin/blob/master/doc/dnsseed-policy.md
I guess I need to open a new issue or pull request for it?
I’ve chosen a domain name that is explicitly verbose about its purpose
Er, how is “maybe malware” the purpose of the seeder? It seems like this would just confuse/alarm users, maybe choose something else instead. I don’t think adding a log filter makes sense either.
The DNS seeds resolve to IPs of random peers. It’s entirely possible (and apparently reality) that some of those host malware. Putting maybe-malware in the name cautions users who might put the domain in a browser, that whatever loads could be malicious.
It seems like a low-cost improvement to avoid abuse IMO, but if there’s a hard objection to it, I can come up with another domain for it.
The DNS seeds resolve to IPs of random peers. It’s entirely possible (and apparently reality) that some of those host malware.
It’s entirely possible that one could be hosting a nascent superintelligence that’s just escaped from a AI lab, but you’re not adding “maybe-superintelligence” to the name. Even more likely for some of them to be chainanalysis spy nodes, or any number of other potentially worrying things.
FWIW, knots hasn’t yet been updated to be malware adjacent: https://github.com/bitcoinknots/bitcoin/blob/aed49ce8989334c364a219a6eb016a3897d4e3d7/src/kernel/chainparams.cpp#L135
but if there’s a hard objection to it, I can come up with another domain for it.
I’d say objections to your current choice of domain name have been made clear from various contributors. Along with objection to changing any logging to accomodate it. Moved this to draft for now. Feel-free to undraft with a different domain etc.