14:33:36 > <@longtermwhale:matrix.org> Njalla is the first to kick your domain + they legally own it. Its weird that you mention them, while you previously correctly say "register domain directly" 14:33:36 In my experience, Tucows is the least susceptible to social engineering and false subpoenas. However, you can't register a domain with them directly, you have to use one of their partners, and one of them is Njalla. And it's not true that Njalla throws out domains for no reason, where did you hear that? 14:33:36 The suggestion to have an additional service provider (for nameservers, for example) is not only due to the risk of attack. Nameservers can also temporarily fail due to technical problems at Cloudflare, which just happen, they don't guarantee their 100% availability. Using only one nameserver provider introduces a single point [... too long, see https://mrelay.p2pool.observer/e/l-Pd2rcKWFg3eUx2 ] 14:34:08 If not Njalla, then Enom is also a good one. 14:37:29 Temporary means as long as it takes. It's also the quickest implementation for the interim measures. If it fails, with some sort of temporary DDoS, the situation reverts to what we have now, in interim. So all fine and dandy. There's no better provider than Cloudflare for DDoS mititation, and they're exceedingly good at it through redundancy proxies. 14:41:23 Njalla will absolutely fuck customers that they don't like. If they like you, you're usually good. 14:42:19 Since I mentioned Tor, I have a question about Tor's compatibility with MoneroPulse. There are many Monero users who have their Monero wallets (often running full nodes) in torified environments like Whonix or Tails. In that case, retrieving TXT records is, as far as I know, not supported because DNS resolving in Tor works dif [... too long, see https://mrelay.p2pool.observer/e/6un92rcKbGtBdVZt ] 14:45:19 @fartbubbler:matrix.org: By not liking you likely mean phishing/malware/botnet operators and illegal drug or pharmacy shops. Yes, they also do not agree for any far right websites, but they do state that in their ToS. I am not aware of any other cases. 14:45:52 Allowing such domains would risk of losing ICANN accreditation. 14:47:37 @alfieedwards: I also ask that because I run a payment processing system which relies on full node that is fully anonymized. 14:50:01 Maybe see what happens if DNS_PUBLIC=tcp://9.9.9.9 is specified as an environmental variable. Documented on the --p2p-bind-ip docs: https://docs.getmonero.org/interacting/monerod-reference/#p2p-network 14:50:50 1.1.1.1 would go directly to CloudFlare's DNS resolver, assuming it works in your use case. 14:52:31 set_log checkpoints:TRACE tells you what is happening with checkpoints. You would probably was to start with --enforce-dns-checkpointing, but even the default (no enforcement) does pull the DNS checkpoints. In the current code, it checks once per hour. 15:03:41 @alfieedwards: IIRC they were never, and are still not, ICANN accredited due to it being owned by Peter Sunde. 15:03:45 They're a Tucows reseller. 15:11:57 @fartbubbler:matrix.org: Do I really have to clarify, this applies to Tucows? 15:12:55 Being a Tucows partner does not mean you have no obligations. 15:21:48 @rucknium: I have tested right now for just DNS blocklist and got: 15:21:48 2025-09-22 15:XX:XX.XXX [P2P2] WARNING net.dns src/common/dns_utils.cpp:557 WARNING: no two valid DNS TXT records were received 15:21:48 2025-09-22 15:XX:XX.XXX 7f9e78df56c0 WARNING net.dns src/common/dns_utils.cpp:343 Invalid DNSSEC TXT record signature for blocklist.moneropulse.no: validation failure : key for validation moneropulse.no. is marked as invalid because of a previous no DNSSEC records 15:22:35 And a few earlier: 15:22:35 no DNSSEC records from 9.9.9.9 for DS updates.moneropulse.XX. while building chain of trust 15:22:35 W Invalid DNSSEC TXT record signature for updates.moneropulse.XX: validation failure 15:24:13 @rucknium: Will this only work for testnet, right? I have no testnet node at the moment 15:24:59 I think one of the updates.moneropulse domains has not been behaving correctly recently. The warning may be unrelated to the node's behavior behind tor, and instead a problem withe the DNS records. 15:26:26 @rucknium: As for just updates, below is complete list of messages: 15:26:26 2025-09-22 XX:XX:XX.XXX W Invalid DNSSEC TXT record signature for updates.moneropulse.no: validation failure : no DNSSEC records from 9.9.9.9 for DS moneropulse.no. while building chain of trust 15:26:26 2025-09-22 XX:XX:XX.XXX W Invalid DNSSEC TXT record signature for updates.moneropulse.net: validation failure : no DNSSEC records from 9.9.9.9 for DS updates.moneropulse.net. while building chain of trust 15:26:26 2025-09-22 XX:XX:XX.XXX W Invalid DNSSEC TXT record signature for updates.moneropulse.org: validation failure : no DNSSEC records from 9.9.9.9 for DS updates.moneropulse.org. while building chain of trust[... more lines follow, see https://mrelay.p2pool.observer/e/xLSf3LcKR0x5alZf ] 15:27:05 It will work for mainnet. Mainnet ( checkpoints.moneropulse.XX) has some old checkpoints, up to height 1680000. 15:28:12 That looks like DNS queries aren't working for any of the domains. 15:28:37 for nodes behind Tor 15:28:58 That sounds like something that should be fixed. 15:29:38 @rucknium: I have run again without "DNS_PUBLIC=tcp://9.9.9.9" like before and monerod works without DNS warnings. 15:30:20 Interesting. Well, maybe it works OK by default. 15:34:09 I think nodes check DNS checkpoints on startup. You can set the log level from startup with the --log-level checkpoints:TRACE startup flag IIRC. That could be quicker to verify since the latest release version of monerod only checks every hour. The check frequency will be reduced to every 2 minutes in the upcoming release. 15:39:54 @rucknium: It should work (iirc) if you are behind tor 15:41:35 It = dns. the env variable might not. @alfieedwards:monero.social how are you running behind tor 15:47:34 With "--enforce-dns-checkpointing --log-level checkpoints:TRACE", seems to work: 15:47:34 2025-09-22 XX:XX:XX.XXX 7fee8a135c00 INFO logging contrib/epee/src/mlog.cpp:274 New log categories: *:WARNING,net:FATAL,net.http:FATAL,net.ssl:FATAL,net.p2p:FATAL,net.cn:FATAL,daemon.rpc:FATAL,global:INFO,verify:FATAL,serialization:FATAL,daemon.rpc.payment:ERROR,stacktrace:INFO,logging:INFO,msgwriter:INFO 15:47:34 2025-09-22 XX:XX:XX.XXX 7fee8a135c00 INFO checkpoints src/checkpoints/checkpoints.cpp:265 Blockchain checkpoints file not found 15:47:34 2025-09-22 XX:XX:XX.XXX 7fee8a135c00 INFO checkpoints src/checkpoints/checkpoints.cpp:123 CHECKPOINT PASSED FOR HEIGHT 1 <771fbcd656ec1464d3a02ead5e18644030007a0fc664c0a964d30922821a8148>[... more lines follow, see https://mrelay.p2pool.observer/e/-sbs3LcKV1FGU2FZ ] 15:51:41 @alfieedwards:monero.social: Thanks for checking. Did you have a log message for checkpoint 1680000:898c0e0b338edc5edd850d241578027f489167cf7b3edb33ed9d08274e15e20e? 15:53:21 The node has hardcoded checkpoints (list here: https://github.com/monero-project/monero/blob/389e3ba1df4a6df4c8f9d116aa239d4c00f5bc78/src/checkpoints/checkpoints.cpp#L213-L269 ). Some of the DNS checkpoints are at different heights. 15:55:58 You can check the current mainnet DNS checkpoints with dig -t TXT checkpoints.moneropulse.de +dnssec +https, but it might not work behind Tor. 16:01:10 @rucknium: Yes: 16:01:10 2025-09-22 XX:XX:XX.XXX 7fe95cc22c00 INFO checkpoints src/checkpoints/checkpoints.cpp:123 CHECKPOINT PASSED FOR HEIGHT 1680000 <898c0e0b338edc5edd850d241578027f489167cf7b3edb33ed9d08274e15e20e> 16:02:07 I think that means default behavior behind Tor works as intended :) 16:02:18 Thank you for testing it! 16:03:38 Any ETA when --enforce-dns-checkpointing can be safely enabled on production environment? 16:08:10 For best results, you would want to use --enforce-dns-checkpointing after upgrading to the next release version of monerod, which hasn't been released yet. That version will have better handling of frequent updates of the DNS checkpoints, .e.g. checking every 2 minutes instead of every 1 hour. I don't know the ETA on the next release. 17:32:35 How is the dns checkpoint going? 17:33:48 the current blocker effectively is a monero issue found while testing on testnet 17:35:57 Would the work on dns checkpoints still happen, even if qubic hashrate is falling 17:38:52 Yes 17:43:18 it's not just qubic that could do this, but any covert attacker that may or may not be trying in secret at the moment. 17:53:55 Agree, but on the other hand it's not exactly easy to reach around one third of total network hashrate, where the real fun starts, as far as I understand 18:46:54 cc datahoarder @0xfffc 18:46:56 https://www.zerobin.net/?152d20a6b4004435#PBuAlYzg28S8bKbV3a8RFv87h6VaxqEOIQx2dAliSdI= 18:47:13 i think this works 18:47:23 is_a_checkpoint is not initialized on creation? 18:47:36 so it'll effectively randomly be true or false 18:47:45 🤷‍♂️🤷‍♂️🤷‍♂️🤷‍♂️🤷‍♂️ 18:47:53 probably why it works for you :D 18:48:16 otherwise if initialized to false it'd never trigger there 18:48:24 i have no idea 18:49:12 I only moved from inside the statement to outside of it 18:49:19 So i assume its initialized elsewhere 18:49:35 no, that declaration is the "initialization" 18:49:39 there is none 18:49:45 I think in C++ it will be mostly "true" if really not initialized? Because only 0 will be false? 18:49:54 actually lemme see 18:50:06 Probably depends on the actual CPU instructions emitted for that 18:50:17 checkpoints::check_block(uint64_t height, const crypto::hash& h, bool& is_a_checkpoint) const 18:50:31 it gets initialized on if(!m_checkpoints.check_block(bei.height, id, is_a_checkpoint)) 18:50:44 that's why the declaration is just before, is_a_checkpoint is passed by reference 18:51:08 right rbrunner7 anything not 0 is true :D 18:53:52 Ok, well line 2084 is (i think) what needs to be triggered to solve the issue, but we never hit that because we dont enter the if on 1900 18:54:37 So we need checkpointed blocks to go into 1900 18:55:31 Also, i think i broke the checkpointing node :D lol. New checkpoints arent being produced 18:55:59 Also noticed that @rucknium:monero.socials node seems to be stuck in the past 18:57:50 Aren't we using testpoints.moneropulse now? 18:58:09 on my node i receive checkpoint last height '455 and my node is at '466 18:58:47 Yeah 18:58:59 445? Or 455? 18:59:10 445 is where i got it stuck 18:59:11 checkppoint '445* 18:59:34 @rucknium: ya 18:59:41 But your daemon is on an old height 18:59:58 And testpoints.mp node is probably stuck 19:00:26 I will check. I have 4 at least. Some of them are running with old domains, some new. 19:00:30 (i just did a reorg to try to test my patch above - which worked, for the wrong reasons) 19:00:36 @rucknium: The 185 one 19:00:58 I tried to mine to it and saw an okd height 19:01:24 185 is running old code. I will pull your branch and re-compile. 19:04:22 Like I've said, the checkpoint_ing_ node(s) needs to bind the checkpoint ASAP after the checkpointer script finalizes the block (i.e. submits records to the DNS server). Or it could re-org before it sees the new checkpoint. I think that can be done simply by making the DNS check frequency from 2 minutes to 2 seconds or somethi [... too long, see https://mrelay.p2pool.observer/e/3b694rcKSjcyZnd5 ] 19:04:43 I don't know if that's what happened to the checkpointing node that powers testpoints.moneropulse 19:06:10 @rucknium: thats not why it died 19:06:18 or nvm, yes it is 19:06:55 @rucknium: Probably the same thing. The checkpoint-ing node checks every 60s instead of every 120, but clearly that wasnt enough 19:07:09 Theres also an issue with the .co domain i think 19:08:30 2025-09-22 19:07:40.993 D DNSSEC not available for hostname: testpoints.moneropulse.co, skipping. 19:08:30 2025-09-22 19:07:40.993 D DNSSEC validation failed for hostname: testpoints.moneropulse.co, skipping. 19:08:30 2025-09-22 19:07:40.993 D Found 6/7 matching records from 6 valid records