I got this warning upon starting monerod v18.0 ; did not get any DNS warnings on v17.3.2:

"WARNING net.dns src/common/dns_utils.cpp:346 Invalid DNSSEC TXT record signature for updates.moneropulse.org: validation failure <updates.moneropulse.org. TXT IN>: SERVFAIL no DS for DS org. while building chain of trust"

From StackExchange, I think i grok what moneropulse is. I have DNS checkpointing disabled in monerod because I use it for p2pool mining

OMG, this is a telltale indication of NSA active attack on you!

TY moo

Oh wait. I'm wrong. Hopefully.

lol

Just wondering if moneropuls needs to update their record or I need to point to a better resolver

Several people have reported an issue with .org DNSSEC recently. We do not know the reason yet.

AFAIK, the records are OK. They verify fine from some places, not from others.

It seems some places just somehow fuck things up.

DNS replication. Please let's not get started.

Which DNS are you using, if you don't mind sharing ?

lemme check

Also, does this also complain ? dig -t TXT updates.moneropulse.org

I don't have dig installed

yet... ;)

yes that worked, no errors, got a bunch of TXT records

; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 20843

Oh, that is interesting... Maybe we do validate wrong then.

Full output: pastebin.com/irbhe3id

All we need is someone who's getting the problem to debug.

I'm happy to compile debug monerod and share logs

(or just change the log level if that helps ;) )

Not sure. I know close to nothing about DNSSEC.

Could be a bug in libunbound too. Who knows,

I guess you can run once with --log-level 0,*dns*:DEBUG in case anything interesting pops up.

sure, one min

Long shot though.

OK, from level 4 trace output, just before the DNS SEC fail warning, I see this:

"2022-07-26 19:20:11.051 [P2P0] DEBUG net contrib/epee/include/net/levin_protocol_handler_async.h:208 [71.203.124.67:18080 OUT] anvoke_handler, timeout: 5000

"

wait sorry that's probably irrelevamnt

Okay. monerod adds a pair of trust anchors, prints "Performing DNSSEC TXT record query". Connects to 71.203.124.67 , gets block hash, then "SERVFAIL no DS for DS org. while building chain of trust"

Then it tries a fallback: "Failed to verify DNSSEC record from updates.moneropulse.org, falling back to TCP with well known DNSSEC resolvers"

... which also fails

The 71.203.124.67 seems indeed unrelated.

Yeah I assume that's just bootstrapping the blockchain sync

Anyway I've pared down the log to what looks like the DNSSEC-relevant chunks. Where's the most useful place to put it?

The thread id is likely different.

paste.debian.net is nice.

Doens't boot tor out, no js...

Hmmm... hold on... after that initial warning, I see DNSSEC queries in the log but no indication of failure

maybe a transient on-startup thing?

The DNS queries query N (equal about 5 or so) records, and chceks the majority.

If one dies a horrible death, it is of no matter.

.co is a longstanding fuckup, based on the .co registrar being an idiot. org is a new fuckup, for reasons still unknown.

That still leaves a majority being ok.

Would you mind opening a github issue with those logs, so they don't get lost ?

ofc

Looks like a dupe of this, shall I just add my logs? monero-project/monero #8452

Indeed. Sure, add your logs. Thanks.

with v0.18 i get a warning on my VPS and not with my home ISP

quite sure the reason it did not show up with v0.17 is that we were using an ancient unbound version

yes, my warning is on a VPS as well

Are you saying if you run 0.17 on the same host, you get no error/warning ?

i did make sure to update both expat (dnssec lib) and unbound (dns lib) to the latest release and it did not make a difference with the warning

moneromooo: the v0.17 release binaries used our 4 year old unbound fork, it did not show up with it yet

correct, same host, v.17 had no warning

That is a bit disquieting isn't it...

I know everyone is annoyed at me removing the unbound submodule but they had an audit and continuing to use the old version seemed like a security risk ostif.org/our-audit-of-unbound-dns-by-x41-d-sec-full-results

hopefully once everyone updated to v0.18 and once we figure out the DNSSEC warnings it stops being an issue / annoyance

Well, maybe the .org chain was borked all along and nobody realized :)

Invalid DNSSEC TXT record signature for updates.moneropulse.org: validation failure <updates.moneropulse.org. TXT IN>: no DNSKEY rrset for trust anchor . while building chain of trust

xmrfn: do you see the exact same message with log 0 on your VPS?

yes

no wait!

ok. in your log 4 it looked a bit different, unless i overlooked the line i was looking for

different reason: "SERVFAIL no DS for DS org."

at least both are related to the .org

WARNING net.dns src/common/dns_utils.cpp:346 Invalid DNSSEC TXT record signature for updates.moneropulse.org: validation failure <updates.moneropulse.org. TXT IN>: SERVFAIL no DS for DS org. while building chain of trust

hello monero science team, I also seem to have this DNS error

dsc_: on VPS?

selsta: do you require me to load up my IDE+debugger? :P

on desktop

i have no idea about DNSSEC :D

me neither

but can try

don't think it's a bug in ubound

unbound

it would be possible to bisect the unbound commit that causes the warning to show up

might help us figure what the issue is

and trying out different dns providers would also help figure out the issue

nais I fixed it

let me confirm

dsc_: how?

selsta: monero-project/monero #8452#issuecomment-1196066179

tyyy looking currently

dsc_: ok we have to fix the first DS entry

but otherwise I'm still confused, would the issue still show up if you set 8.8.8.8 as your home DNS without doing PUBLIC_DNS env var?

selsta: the issue is also fixed by doing something like `nameserver 8.8.8.8` in /etc/resolv.conf, yeah

ill edit my thinger

ok so it is likely DNS provider misconfig?

selsta: i found what causes it, I think now we need a DNS doctor/guru to tell us if what we are seeing is reasonable behaviour or not

one thing to consider is that while updating libunbound, it simply got more verbose

nvm scratch that

I assume you did try editing this first wrong DS value?

but yeah, lets wait for a DNS person to chime in :)

Yes, wrong DS value is fine as long as the right one eventually gets added

actually I don't know if having a faulty DS value is an issue or not, but for our current bug it is irrelevant at least :)

it adds both via `ub_ctx_add_ta`