<shortwavesurfer2009> 8 reorg

<rucknium> @ofrnxmr:xmr.mx: Is that you that caused re-orgs on testnet? Checkpointing node got stuck because no hashpower was pointed at it testnetnode4.moneroconsensus.info

<rucknium> I was slow spamming testnet and some of my txs were invalidated by the 10+ re-org: testnet.xmrchain.net/txpool

tested the dns-checkpoints server and added NOTIFY, now secondary public DNS servers get new records within 5s or so git.gammaspectra.live/P2Pool/monero-highway

<rucknium> DataHoarder: Thanks! How can this be deployed on testnet?

The usage guidelines should allow you to deploy one

though you can forgo the external DNS secondaries

you need a VPS or some server with an external IP that can bind port 53 for dns

(or port forward to port dns)

replace checkpoints.example.com with for example testpoints-highway.moneroconsensus.info and that should be good to go

I run a test instance of this on checkpoints.gammaspectra.live (which should have the current mainnet checkpoints)

$ dig +dnssec +multi checkpoints.gammaspectra.live TXT @ns1.he.net

$ dig +dnssec +multi checkpoints.gammaspectra.live TXT @1.1.1.1

etc.

I can make a specific guide to get something running on DigitalOcean (Ubuntu 24.04) as it's let's say, "fun" when you need to run things on port 53 :)

<rucknium> Is it: 1) Point monero-highway to the authoritative name server (e.g. njalla), 2) Point checkpointed nodes to monero-highway?

1) set up delegation of testpoints-highway.example.com on your DNS provider (this lets it be authoritative for that subdomain only)

2) yes

<rucknium> Thanks. I will test it.

just setting up another one to test with the commands I used, I think you can bind to the external IP to have port 53 work well :)

@rucknium:monero.social: here's a quick guide paste.debian.net/hidden/8bca7c39

took me from the time I said to make the guide to now to have it live

10m job :)

ofc, you want to run the dns-checkpoints.bin on a service or some what that restarts

but it's ready now to take new checkpoints via port 19080 on localhost

and serve these on testpoints.gammaspectra.live directly

so yeah, all you need to add in your DNS provider is an A record for the nameserver, the NS nameserver record, the DS signer delegation record for DNSSEC

you can check if all is ok via for example dnsviz.net/d/testpoints.gammaspectra.live/dnssec

or dnssec-analyzer.verisignlabs.com/testpoints.gammaspectra.live

the graph will look something like this with no error/warnings markers irc.gammaspectra.live/e170cb0436678…ra.live-2025-09-05-12_18_22-UTC.png

read DNSSEC Notes on git.gammaspectra.live/P2Pool/monero-highway#dnssec-notes to see if selecting ed25519 vs secp256r1 is worth it for you

secp256r1 is the highest deployment % at 69.8%, but ed25519 has improved massively at 63%

69% is max you can get effectively

I have a secp256r1 key on checkpoints.gammaspectra.live, ed25519 on testpoints :)

<ofrnxmr:xmr.mx> No > <@rucknium> @ofrnxmr:xmr.mx: Is that you that caused re-orgs on testnet? Checkpointing node got stuck because no hashpower was pointed at it testnetnode4.moneroconsensus.info

if you want to test if your local setup DNS resolver supports DNSSEC + Ed25519, you can use $ dig +dnssec +multi testpoints.gammaspectra.live TXT

or use rootcanary.org/test.html on a browser that fetches system DNS server directly (instead of DNS over TLS/HTTPS)

<rucknium> When do I add this, on what, pointing to where? > <DataHoarder> so yeah, all you need to add in your DNS provider is an A record for the nameserver, the NS nameserver record, the DS signer delegation record for DNSSEC

on your DNS provider, say njalla or cloudflare

on here paste.debian.net/hidden/8bca7c39 it'd be the entries on lines 29, 30, 32

for my specific example

<rucknium> Do I add A, NS, and DS records to the domain that is supposed to be the checkpointing domain, or to a domain that points to my "new" DNS server?

irc.gammaspectra.live/84fda98dde73cc8f/image.png

we are talking subdomains here, say, you want testpoints.gammaspectra.live to be the "checkpointing" subdomain

you go to where you manage records for gammaspectra.live itself

then add DS/NS records on testpoints.gammaspectra.live (this causes the delegation)

the A record is so it can be found by name to IP, but if you have one already you can reuse

<datahoarder> ^ does that make more sense?

<rucknium> I am trying. Getting You can not mix NS with other records.

<rucknium> when I try to add a NS

<rucknium> record to townforger.net

you want to setup a subdomain, not change the whole domain, as you are delegating

say, testpoints2.townforger.net

so set a NS record on testpoints2.townforger.net (in the interface)

use a subdomain that's not in use by anything else, ofc

<rucknium> a different subdomain that the one that the nodes are querying for the checkpoint TXT recrds...?

<rucknium> ok

if you want to replace the current setup you can use the same

but then you need to remove all other records on that subdomain :)

TXT for example

so checkpoints.townforger.net right?

that still has a TXT entry, which needs to be removed if you want to delegate

delegate = you are telling the world that "records on checkpoints.townforger.net are handled by <this other server>, here's some records that prove that, find the rest there"

for that you need NS records, and for adding dnssec, the DS one as well

<datahoarder> For your setup something like this I guess?

<datahoarder> mrelay.p2pool.observer/p/wP_lnLIKbmIwUnhZ/1.txt (code snippet, 18 lines)

If you are replacing the setup, of course

<rucknium> I think I have the records added. On my VPS, the running go process says

<rucknium> time=2025-09-05T13:35:58.273Z level=ERROR msg="Failed to start DNS server on UDP" bind=185.193.127.188:53 error="listen udp 185.193.127.188:53: bind: permission denied"

<rucknium> time=2025-09-05T13:35:58.275Z level=ERROR msg="Failed to start DNS server on TCP" bind=185.193.127.188:53 error="listen tcp 185.193.127.188:53: bind: permission denied"

<rucknium> I guess I need to allow permission to bind on port 53

correct

or bind to a different port and set firewall rules to bring TCP/UDP to that port

<rucknium> I think I just needed to use sudo dns-checkpoints.bin, which may have security implications, but we'll ignore that now.

<rucknium> DataHoarder: I input dig +tcp +dnssec +multi checkpoints.townforger.net SOA @1.1.1.1 and get some info. Is it working?

I think you can set bind permissions to the binary. I have a TODO to drop permissions if it's given more after binding

lemme try

that's still using njalla

$ dig +dnssec +multi checkpoints.townforger.net NS @1-you.njalla.no

that still shows it's using njalla and there is no delegation

<rucknium> Njalla gives me an option to "use custom domain servers" in its GUI. Should I do something there?

no, that overwrites the entire domain

you only want to delegate a single subdomain (so the rest is unaffected)

you should get under SOA your new NS details if that works

or at least under the NS command, you should see the new nameserver

so, what records did you set on njalla?

<rucknium> I'm starting the doubt the value of me testing this and understanding how it works. Or, at least, whether the value exceeds the cost

I think it's the DNS part we are failing at, the value for having a quick DNS server (for low TTL records) and not exposing main API keys is good, maybe not for this testing stage

<rucknium> DS checkpoints2.townforger.net 36693 15 2 B1218AB95D21849AA2FDBC89FE74708F326149FFCB45724D92F60C8772887BAB

<rucknium> NS checkpoints2.townforger.net ns1-checkpoints2.townforger.net

<rucknium> A ns1-checkpoints2.townforger.net 185.193.127.188

aha

lemme see on that

looks good on checkpoints2, lemme see if server replies

185.193.127.188 is not replying to DNS queries on port 53 TCP/UDP

records otherwise look ok!

<rucknium> Need to open port maybe on the VPS?

this should be able to verify it directly $ dig +dnssec +multi checkpoints2.townforger.net SOA @ns1-checkpoints2.townforger.net

yeah, port 53 TCP/UDP or on firewall

I'll look into the specific bind permissions so no root is desired :)

<rucknium> DataHoarder: Try checking again

works!

<rucknium> 🎉

yep and all valid

<rucknium> sudo ufw allow out 53

<rucknium> sudo ufw allow in 53

looks ok!

<rucknium> did it. Not sure I need out

you need out due to UDP

looks ok on dnssec-analyzer.verisignlabs.com/checkpoints2.townforger.net as well

<rucknium> Thanks for all the hand-holding.

no TXT records yet, you can feed those via the HTTP API

<rucknium> DataHoarder: How do I do that and what do you mean?

effectively POST to the http port you set, with &txt arguments for each txt entry

I mean to publish checkpoints

<rucknium> By the way, the TXT record is frozen because the checkpointng node is stuck. I will un-stick it

<rucknium> I have another script pushing the TXT records. I should use something else?

you can probably modify it slightly to also push them here

this does it but any other library you have would work as well $ curl -XPOST "127.0.0.1:19080/?txt=abc123&txt=def567&txt=ghi890"

I checked server again, and it's publishing updated signed records fine btw :)

<rucknium> So, I can push TXT records directly to my VPS instead of using the Njalla API. That's what you're saying?

yep

(and that's the point, it stays local/owned by the checkpointer owner, and limited on impact)

no need to have full njalla API keys on server

or cloudflare or whatever is in use

<rucknium> Thanks. I will try that

addressed the privilege part git.gammaspectra.live/P2Pool/monero…ghway#binding-to-low-numbered-ports

also added the regular binary hardening flags on the compilation step

That produces a static binary with no external dependencies, with PIE / Full RELRO / NX setup and full FORTIFY :)

<rucknium> DataHoarder: Thanks. How would you overwrite a records with the interface curl -XPOST "127.0.0.1:19080/?txt=abc123&txt=def567&txt=ghi890";?

any new change overwrites the current set

you are passing a list of TXT records to update

<rucknium> Ok. How is TTL set?

TTL is set on cmdline, defaults to 300

-ttl 5m

for example, when starting the program

you can use -ttl 1h or any other duration string

<rucknium> So I just pass the raw checkpoint height:hash?

yep

I think it's height=hash so you can escape that = sign

or use a request library, it will do it for you

I can make any interface / API there that is ergonomic, just had that simple one for testing

you can run the binary + -help to see a list or arguments it can take

<rucknium> It's colon. I hope colon doesn't need to be escaped (about to find out)

I'd recommend not changing -authority-ttl below the default value, if anything, you could raise it to 7 days

colon is fine!

I see you posted some checkpoints on there already!

<rucknium> I think it's working. I will make a diagram

<rucknium> I think there was deep re-org on testnet. 184 blocks?

<ofrnxmr:xmr.mx> Wasnt me

<boog900> has anyone noticed someone is injecting unreachable nodes into testnet

<boog900> it seems to be the same addresses as the ones that were injected onto mainnet a while ago

<ofrnxmr> I dont know which are which, but i dod notice there are a fuck ton of the same ip w a different port

<boog900> 38.6.15*.*

<boog900> pretty sure that is the same address that was injected into mainnet that @jhendrix:imagisphe.re found

<ofrnxmr> Yeah

<ofrnxmr> Also 154.199.21*.*

<rucknium> DataHoarder: Here is my first draft of diagram slides. Click arrows on the bottom to go through the slides: cryptpad.disroot.org/diagram/#/2/di…KdZZKC66exXJAm9WiJsQvN8kJutOM/embed

I'll check in a few hours!

<boog900> this seed: 176.9.0.187 is injecting the peers

<boog900> wait multiple seeds are

<boog900> every seed I connected to is sending me those peers

<boog900> I think that means these addresses were reachable to the seed nodes 🤔

<ofrnxmr:xmr.mx> Means those nodes just connected to seeds at some point

<ofrnxmr:xmr.mx> Probably possible to just spin up bunch of nodes using different --p2p-bind-port

<boog900> @ofrnxmr:xmr.mx: It would have to be somewhat recent otherwise they would be ejected but yeah

<boog900> @ofrnxmr:xmr.mx: they cover multiple IP addresses

<ofrnxmr> @boog900: i noticed these maybe 2weeks ago

<ofrnxmr> Idk how recent "recent" has to be though, or when they first appeared

<boog900> I mean they have been on mainnet for quite a while

<boog900> Males me wonder if they are really reachable to certain nodes but not mine for whatever reason

<ofrnxmr> I think they are only online for long enough to get out on seed node peerlists

<ofrnxmr> Put*

<ofrnxmr> Afaict, they have all "never" been connected to from my nodes on my liat

<ofrnxmr> @plowsof:matrix.org

<ofrnxmr> Can check his seeds to see if/when last connected

Will have a look

<ofrnxmr:xmr.mx> 38.6.15*.* nodes

@rucknium:monero.social, initial feedback, split Secure Server into a "Group" of "Distributed DNSSEC Checkpointer Servers"