<helene:unredacted.org> that sounds problematic :D > <DataHoarder> it just looks at the AD flag

You are trusting the DNS Server you set

That is why you should run local recursive dns servers

They check the chain of trust of delegation

<ofrnxmr> I think monerod checks

<ofrnxmr> It prints logs about getting the chain of trust etc

Does it have an embedded recursive dns client?

<ofrnxmr> 🤷‍♂️

<syntheticbird> no

<syntheticbird> but cuprate can

<syntheticbird> did I talked to you about our lord and savior hickory-dns

<syntheticbird> secure, correct, rust-written dns resolver library, now in discount for the whole family

<syntheticbird> github.com/hickory-dns/hickory-dns

<syntheticbird> github.com/hickory-dns/hickory-dns/tree/main/crates/client

<321bob321> Hates self sign certs

<alfieedwards> Hello, I've read so far:

<alfieedwards> eddieoz.com/monero-under-attack-how…-responds-to-selfish-mining-attacks

<alfieedwards> monero-project/monero #10064

<alfieedwards> [... more lines follow, see mrelay.p2pool.observer/e/-MfSs7cKTWRieWN1 ]

<alfieedwards> I just hope Monero project future won't depend on a few domains registered at Gandi and "protected" behind a single Cloudflare account...

<syntheticbird> that's a lot of text

<basses:matrix.org> @syntheticbird: stop watching tiktok

<alfieedwards> @syntheticbird: And it's not LLM! 😀

<syntheticbird> @basses:matrix.org: no, i love reducing my brain size

<syntheticbird> @alfieedwards: odd thing to say

<syntheticbird> @alfieedwards: CHAT DONT LOOK AT ME LOOK AT THIS MESSAGE.

2) dnssec is and was always required. the code for this is already in Monero

1) the code is already in monero and it's an opt-in temporary bandaid before proper means are developed

also for 2) if using dns-checkpoint or a custom server that is possible. However, exposing the hardcoded IPs of each one opens you to DDoS

note the system is fail-safe and stopping checkpoints = no harm. node operators can also disable the opted-in flag and restart, and nothing else happens

DNS deployment for last comment also allows you to have a hidden server signing the records, then deploying to DNS secondaries. There is no need to have the active IP(s) in NS records be the alive ones.

I have shown this in checkpoints.gammaspectra.live example dnsviz.net/d/checkpoints.gammaspectra.live/dnssec

(one issuing server and several secondaries across different ISPs, but these ISPs cannot sign new records, only publish pre-signed zones)

keep in mind this is not intended to be permanent, nor the bandaid over the entire temporary deployment

as better options/decentralization is possible that can be deployed then, but waiting while bleeding and specifically having end user transactions invalidated and reverted, that's harmful

<alfieedwards> > <DataHoarder> also for 2) if using dns-checkpoint or a custom server that is possible. However, exposing the hardcoded IPs of each one opens you to DDoS

<alfieedwards> How can I host my own checkpoint server? There are different approaches to DDoS protection, reverse-proxies are just one of them. You may host on infrastructure where there are hardware firewalls (Palo Alto, etc) and exposed IP won't be the issue.

you cannot use reverse proxies for DNS servers in the way you see them

a checkpoint server is a normal DNS server with DNSSEC enabled

that serves a TXT record

you can use bind gitlab.isc.org/isc-projects/bind9

or any other DNS server that can support that

DNS servers can stay offline and only send pre-signed zones to the actual serving nameservers

As a proof of concept (that has been tested) also made git.gammaspectra.live/P2Pool/monero-highway#cmd-dns-checkpoints

<alfieedwards> How this fail-safe mechanism works? Won't unavailability of checkpoint nodes allow for reorg attacks to continue? > <DataHoarder> note the system is fail-safe and stopping checkpoints = no harm. node operators can also disable the opted-in flag and restart, and nothing else happens

this is a bare-bones DNS server with DNSSEC that serves a single zone, for serving the TXT record

yes alfieedwards. fail-safe means if anything would go wrong, it stops to a "safe" point

meaning no more checkpoints are issued

same as if domains are seized, they cannot pass 2/3rd entries

again. this is not a PERMANENT setup, but temporary, and once improved, it would spread further. The code already exists in Monero and is in use

here are the details about MoneroPulse (the set of domains that would have the TXT records. they are already in use today, by default only as a warning, node operators have to opt-in to enforce these, and it would still be opt-in)

<rucknium> Checkpoints can be manually added, without DNS, by placing a checkpoints.json file in the .bitmonero directory of each node.

more than the 4 listed are added monero-project/monero #10075

<alfieedwards> Thank you for explanation. I just hope there will be more moneropulse domains with different registrars than Gandi, even if it is a temporary solution.

Transferring the domains takes time, too

<alfieedwards> NS from DNSpod, etc, besides Cloudflare could also be used

Current test ongoing on testnet at this moment deploys checkpoints to Cloudflare DNS via batch API request

this is the script running these for the test git.gammaspectra.live/P2Pool/monero…eckpointer/cmd/checkpointer/main.go

rucknium also has an alternative script

sorry, wrong branch. it's master git.gammaspectra.live/P2Pool/monero…/src/branch/master/cmd/checkpointer

logic is -> each -checkpoint-interval (recommended 5 minutes), issue checkpoints at depth -checkpoint-depth (default 2)

depth of 2 means tip = 100, checkpoint would be placed at height = 98

if -checkpoint-interval is 0, checkpoints are issued as soon as a block is received, but same -depth rule is followed. blocks are received via ZMQ or RPC as fallback, and inclusion in previous checkpointed chain is enforced

you will see a lot of //sanity check / panic() calls to bail out

<rucknium> My alternative prototype checkpointing script is here: gist.github.com/Rucknium/daf4d52976fc4d32e378771f2e45f8f1 > <DataHoarder> Rucknium also has an alternative script

<jfuffjcjkdrngisozkfng:matrix.org> But how temporary are we talking ? > <DataHoarder> 1) the code is already in monero and it's an opt-in temporary bandaid before proper means are developed

<jfuffjcjkdrngisozkfng:matrix.org> A year ? More ?

this was discussed in MRL. I think a year and a half was thrown around as a number to have bandaids, but this doesn't mean "THIS" DNS checkpoints bandaids

there are more distributed ways of handling this. bandaid means anything before a hard-fork effectively

(or soft-fork)

if a better distribution than DNS checkpoints is available and deployed in N weeks, it'd be N weeks for this

if they need to stay longer, decentralizing these more would become priority

note for these to make sense people need to be making progress on the long-term solution.

<jfuffjcjkdrngisozkfng:matrix.org> DataHoarder: Yes because of how easily some registrars can get socially engineered to hand over accounts

<ofrnxmr:xmr.mx> These domains have been in use for many yrs

<ofrnxmr:xmr.mx> They are uses for dns checkpoints, dns blocklist, and dns monerod version updates

<alfieedwards> DataHoarder: Are masternodes considered?

<ofrnxmr:xmr.mx> Not really

what do you mean, for bandaid? or long term

(afaik for neither)

<alfieedwards> Well, for Tor network similar concept (of consensus in terms of various parameters among selected "authority" nodes hosted by Tor Project members) works since a long time without issues: consensus-health.torproject.org

<alfieedwards> I hope it will be effective also for Monero

<jack_ma_blabla:matrix.org> @alfieedwards: masternodes = pos ?

<alfieedwards> If one were to think about it, it would indeed have to rely on PoS. Which is an absolutely bad idea And I hope Monero never goes for it, as it would got literally bought by big funds.

<ofrnxmr:xmr.mx> #monero

<one-horse-wagon> For the

<ofrnxmr:xmr.mx> #monero:monero.social

The 7th domain (.co) is now updating as well

🥳

all good from the checkpointer side?

yep, no unexpected behavior and very stable

<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> Hello, I've read so far:

<longtermwhale:matrix.org> i am not sure if that attack vector was taken serious or has relevance, but a ddos attack, especially timed in a short burst (knowing for example i will cause a chain reorganisation by publishing blocks) is very very very easy to accomplish and if outsourced cheaply executed. cloudflare wont help enough especially when talking [... too long, see mrelay.p2pool.observer/e/z9fxt7cKeFBhMm91 ]

<longtermwhale:matrix.org> attack scenario could be qubic having 18 blocks, alt chain whatever blocks, then ddos on the checkpoints for 1 hour. thats easily done. mind, that you dont have to worry about cfb necessarily, but about kids talking and backing crypto on discord :-)

note the checkpoints are DNS servers themselves

that'd mean taking down all DNS servers across the world offline or specifically for current testing that's Cloudflare DNS itself

> attack scenario could be qubic having 18 blocks, alt chain whatever blocks, then ddos on the checkpoints for 1 hour.

once a checkpoint is issued and received it sticks on nodes

<ofrnxmr:xmr.mx> Even if reorg successful, nodes will have the original chain. They will later receive checkpoint that conflict with attacking chain, and drop the attacking chain

<ofrnxmr:xmr.mx> If the checkpoint_ing_ node(s) blocks conflict with current checkpoints, no new checkpoints will be issued