<alfieedwards> > <@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"

<alfieedwards> 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?

<alfieedwards> 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 mrelay.p2pool.observer/e/l-Pd2rcKWFg3eUx2 ]

<alfieedwards> If not Njalla, then Enom is also a good one.

<radanne:matrix.org> 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.

<fartbubbler:matrix.org> Njalla will absolutely fuck customers that they don't like. If they like you, you're usually good.

<alfieedwards> 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 mrelay.p2pool.observer/e/6un92rcKbGtBdVZt ]

<alfieedwards> @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.

<alfieedwards> Allowing such domains would risk of losing ICANN accreditation.

<alfieedwards> @alfieedwards: I also ask that because I run a payment processing system which relies on full node that is fully anonymized.

<rucknium> 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: docs.getmonero.org/interacting/monerod-reference/#p2p-network

<rucknium> 1.1.1.1 would go directly to CloudFlare's DNS resolver, assuming it works in your use case.

<rucknium> 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.

<fartbubbler:matrix.org> @alfieedwards: IIRC they were never, and are still not, ICANN accredited due to it being owned by Peter Sunde.

<fartbubbler:matrix.org> They're a Tucows reseller.

<alfieedwards> @fartbubbler:matrix.org: Do I really have to clarify, this applies to Tucows?

<alfieedwards> Being a Tucows partner does not mean you have no obligations.

<alfieedwards> @rucknium: I have tested right now for just DNS blocklist and got:

<alfieedwards> 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

<alfieedwards> 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 <blocklist.moneropulse.no. TXT IN>: key for validation moneropulse.no. is marked as invalid because of a previous no DNSSEC records

<alfieedwards> And a few earlier:

<alfieedwards> no DNSSEC records from 9.9.9.9 for DS updates.moneropulse.XX. while building chain of trust

<alfieedwards> W Invalid DNSSEC TXT record signature for updates.moneropulse.XX: validation failure

<alfieedwards> @rucknium: Will this only work for testnet, right? I have no testnet node at the moment

<rucknium> 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.

<alfieedwards> @rucknium: As for just updates, below is complete list of messages:

<alfieedwards> 2025-09-22 XX:XX:XX.XXX W Invalid DNSSEC TXT record signature for updates.moneropulse.no: validation failure <updates.moneropulse.no. TXT IN>: no DNSSEC records from 9.9.9.9 for DS moneropulse.no. while building chain of trust

<alfieedwards> 2025-09-22 XX:XX:XX.XXX W Invalid DNSSEC TXT record signature for updates.moneropulse.net: validation failure <updates.moneropulse.net. TXT IN>: no DNSSEC records from 9.9.9.9 for DS updates.moneropulse.net. while building chain of trust

<alfieedwards> 2025-09-22 XX:XX:XX.XXX W Invalid DNSSEC TXT record signature for updates.moneropulse.org: validation failure <updates.moneropulse.org. TXT IN>: no DNSSEC records from 9.9.9.9 for DS updates.moneropulse.org. while building chain of trust[... more lines follow, see mrelay.p2pool.observer/e/xLSf3LcKR0x5alZf ]

<rucknium> It will work for mainnet. Mainnet ( checkpoints.moneropulse.XX) has some old checkpoints, up to height 1680000.

<rucknium> That looks like DNS queries aren't working for any of the domains.

<rucknium> for nodes behind Tor

<rucknium> That sounds like something that should be fixed.

<alfieedwards> @rucknium: I have run again without "DNS_PUBLIC=tcp://9.9.9.9" like before and monerod works without DNS warnings.

<rucknium> Interesting. Well, maybe it works OK by default.

<rucknium> 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.

<ofrnxmr:xmr.mx> @rucknium: It should work (iirc) if you are behind tor

<ofrnxmr:xmr.mx> It = dns. the env variable might not. @alfieedwards:monero.social how are you running behind tor

<alfieedwards> With "--enforce-dns-checkpointing --log-level checkpoints:TRACE", seems to work:

<alfieedwards> 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

<alfieedwards> 2025-09-22 XX:XX:XX.XXX 7fee8a135c00 INFO checkpoints src/checkpoints/checkpoints.cpp:265 Blockchain checkpoints file not found

<alfieedwards> 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 mrelay.p2pool.observer/e/-sbs3LcKV1FGU2FZ ]

<rucknium> @alfieedwards:monero.social: Thanks for checking. Did you have a log message for checkpoint 1680000:898c0e0b338edc5edd850d241578027f489167cf7b3edb33ed9d08274e15e20e?

<rucknium> The node has hardcoded checkpoints (list here: github.com/monero-project/monero/bl…eckpoints/checkpoints.cpp#L213-L269 ). Some of the DNS checkpoints are at different heights.

<rucknium> You can check the current mainnet DNS checkpoints with dig -t TXT checkpoints.moneropulse.de +dnssec +https, but it might not work behind Tor.

<alfieedwards> @rucknium: Yes:

<alfieedwards> 2025-09-22 XX:XX:XX.XXX 7fe95cc22c00 INFO checkpoints src/checkpoints/checkpoints.cpp:123 CHECKPOINT PASSED FOR HEIGHT 1680000 <898c0e0b338edc5edd850d241578027f489167cf7b3edb33ed9d08274e15e20e>

<rucknium> I think that means default behavior behind Tor works as intended :)

<rucknium> Thank you for testing it!

<alfieedwards> Any ETA when --enforce-dns-checkpointing can be safely enabled on production environment?

<rucknium> 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.

<barthman132:matrix.org> How is the dns checkpoint going?

the current blocker effectively is a monero issue found while testing on testnet

<barthman132:matrix.org> Would the work on dns checkpoints still happen, even if qubic hashrate is falling

<ofrnxmr:xmr.mx> Yes

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.

<rbrunner7> 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

<ofrnxmr:xmr.mx> cc datahoarder @0xfffc

<ofrnxmr:xmr.mx> zerobin.net/?152d20a6b4004435#PBuAl…8S8bKbV3a8RFv87h6VaxqEOIQx2dAliSdI=

<ofrnxmr:xmr.mx> i think this works

is_a_checkpoint is not initialized on creation?

so it'll effectively randomly be true or false

<ofrnxmr:xmr.mx> 🤷‍♂️🤷‍♂️🤷‍♂️🤷‍♂️🤷‍♂️

probably why it works for you :D

otherwise if initialized to false it'd never trigger there

<ofrnxmr:xmr.mx> i have no idea

<ofrnxmr:xmr.mx> I only moved from inside the statement to outside of it

<ofrnxmr:xmr.mx> So i assume its initialized elsewhere

no, that declaration is the "initialization"

there is none

<rbrunner7> I think in C++ it will be mostly "true" if really not initialized? Because only 0 will be false?

actually lemme see

<rbrunner7> Probably depends on the actual CPU instructions emitted for that

checkpoints::check_block(uint64_t height, const crypto::hash& h, bool& is_a_checkpoint) const

it gets initialized on if(!m_checkpoints.check_block(bei.height, id, is_a_checkpoint))

that's why the declaration is just before, is_a_checkpoint is passed by reference

right rbrunner7 anything not 0 is true :D

<ofrnxmr:xmr.mx> 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

<ofrnxmr:xmr.mx> So we need checkpointed blocks to go into 1900

<ofrnxmr:xmr.mx> Also, i think i broke the checkpointing node :D lol. New checkpoints arent being produced

<ofrnxmr:xmr.mx> Also noticed that @rucknium:monero.socials node seems to be stuck in the past

<rucknium> Aren't we using testpoints.moneropulse now?

<sneedlewoods_xmr:matrix.org> on my node i receive checkpoint last height '455 and my node is at '466

<ofrnxmr:xmr.mx> Yeah

<ofrnxmr:xmr.mx> 445? Or 455?

<ofrnxmr:xmr.mx> 445 is where i got it stuck

<sneedlewoods_xmr:matrix.org> checkppoint '445*

<ofrnxmr:xmr.mx> @rucknium: ya

<ofrnxmr:xmr.mx> But your daemon is on an old height

<ofrnxmr:xmr.mx> And testpoints.mp node is probably stuck

<rucknium> I will check. I have 4 at least. Some of them are running with old domains, some new.

<ofrnxmr:xmr.mx> (i just did a reorg to try to test my patch above - which worked, for the wrong reasons)

<ofrnxmr:xmr.mx> @rucknium: The 185 one

<ofrnxmr:xmr.mx> I tried to mine to it and saw an okd height

<rucknium> 185 is running old code. I will pull your branch and re-compile.

<rucknium> 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 mrelay.p2pool.observer/e/3b694rcKSjcyZnd5 ]

<rucknium> I don't know if that's what happened to the checkpointing node that powers testpoints.moneropulse

<ofrnxmr:xmr.mx> @rucknium: thats not why it died

<ofrnxmr:xmr.mx> or nvm, yes it is

<ofrnxmr:xmr.mx> @rucknium: Probably the same thing. The checkpoint-ing node checks every 60s instead of every 120, but clearly that wasnt enough

<ofrnxmr:xmr.mx> Theres also an issue with the .co domain i think

<ofrnxmr:xmr.mx> 2025-09-22 19:07:40.993 D DNSSEC not available for hostname: testpoints.moneropulse.co, skipping.

<ofrnxmr:xmr.mx> 2025-09-22 19:07:40.993 D DNSSEC validation failed for hostname: testpoints.moneropulse.co, skipping.

<ofrnxmr:xmr.mx> 2025-09-22 19:07:40.993 D Found 6/7 matching records from 6 valid records