18:56:10 <xmrfn> I got this warning upon starting monerod v18.0 ; did not get any DNS warnings on v17.3.2:
18:56:13 <xmrfn> "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"
18:57:17 <xmrfn> From StackExchange, I think i grok what moneropulse is. I have DNS checkpointing disabled in monerod because I use it for p2pool mining
18:57:32 <moneromooo> OMG, this is a telltale indication of NSA active attack on you!
18:57:38 <xmrfn> TY moo
18:57:43 <moneromooo> Oh wait. I'm wrong. Hopefully.
18:57:46 <xmrfn> lol
18:58:07 <xmrfn> Just wondering if moneropuls needs to update their record or I need to point to a better resolver
18:58:13 <moneromooo> Several people have reported an issue with .org DNSSEC recently. We do not know the reason yet.
18:58:36 <moneromooo> AFAIK, the records are OK. They verify fine from some places, not from others.
18:58:47 <moneromooo> It seems some places just somehow fuck things up.
18:59:03 <xmrfn> DNS replication. Please let's not get started.
18:59:32 <moneromooo> Which DNS are you using, if you don't mind sharing ?
18:59:59 <xmrfn> lemme check
19:00:10 <moneromooo> Also, does this also complain ? dig -t TXT updates.moneropulse.org
19:01:33 <xmrfn> I don't have dig installed 
19:02:06 <xmrfn> yet...  ;)
19:02:54 <xmrfn> yes that worked, no errors, got a bunch of TXT records
19:03:15 <xmrfn>   ; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 20843
19:03:18 <moneromooo> Oh, that is interesting... Maybe we do validate wrong then.
19:04:20 <xmrfn> Full output: https://pastebin.com/irbhe3id
19:04:30 <moneromooo> All we need is someone who's getting the problem to debug.
19:05:30 <xmrfn> I'm happy to compile debug monerod and share logs
19:06:20 <xmrfn> (or just change the log level if that helps ;) )
19:08:20 <moneromooo> Not sure. I know close to nothing about DNSSEC.
19:08:44 <moneromooo> Could be a bug in libunbound too. Who knows,
19:09:18 <moneromooo> I guess you can run once with  --log-level 0,*dns*:DEBUG in case anything interesting pops up.
19:09:28 <xmrfn> sure, one min
19:09:29 <moneromooo> Long shot though.
19:25:28 <xmrfn> OK, from level 4 trace output, just before the DNS SEC fail warning, I see this:
19:25:31 <xmrfn> "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
19:25:31 <xmrfn> "
19:26:08 <xmrfn> wait sorry that's probably irrelevamnt
19:32:55 <xmrfn> 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"
19:34:00 <xmrfn> Then it tries a fallback: "Failed to verify DNSSEC record from updates.moneropulse.org, falling back to TCP with well known DNSSEC resolvers"
19:36:08 <xmrfn> ... which also fails
19:37:09 <moneromooo> The 71.203.124.67 seems indeed unrelated. 
19:37:23 <xmrfn> Yeah I assume that's just bootstrapping the blockchain sync
19:37:38 <xmrfn> Anyway I've pared down the log to what looks like the DNSSEC-relevant chunks. Where's the most useful place to put it?
19:37:48 <moneromooo> The thread id is likely different.
19:38:04 <moneromooo> paste.debian.net is nice.
19:38:20 <moneromooo> Doens't boot tor out, no js...
19:41:04 <xmrfn> Hmmm... hold on... after that initial warning, I see DNSSEC queries in the log but no indication of failure
19:41:11 <xmrfn> maybe a transient on-startup thing?
19:42:39 <xmrfn> https://paste.debian.net/hidden/8702a64c/
19:49:50 <moneromooo> The DNS queries query N (equal about 5 or so) records, and chceks the majority.
19:50:11 <moneromooo> If one dies a horrible death, it is of no matter.
19:51:11 <moneromooo> .co is a longstanding fuckup, based on the .co registrar being an idiot. org is a new fuckup, for reasons still unknown.
19:51:35 <moneromooo> That still leaves a majority being ok.
19:53:28 <xmrfn> https://paste.debian.net/1248443/
19:57:36 <moneromooo> Would you mind opening a github issue with those logs, so they don't get lost ?
19:59:05 <xmrfn> ofc
19:59:43 <xmrfn> Looks like a dupe of this, shall I just add my logs? https://github.com/monero-project/monero/issues/8452
20:08:04 <moneromooo> Indeed. Sure, add your logs. Thanks.
20:10:41 <selsta> with v0.18 i get a warning on my VPS and not with my home ISP
20:11:57 <selsta> quite sure the reason it did not show up with v0.17 is that we were using an ancient unbound version
20:14:46 <xmrfn> yes, my warning is on a VPS as well
20:16:10 <moneromooo> Are you saying if you run 0.17 on the same host, you get no error/warning ?
20:18:33 <selsta> 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
20:19:19 <selsta> moneromooo: the v0.17 release binaries used our 4 year old unbound fork, it did not show up with it yet
20:20:19 <xmrfn> correct, same host, v.17 had no warning
20:22:57 <moneromooo> That is a bit disquieting isn't it...
20:28:01 <selsta> 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 https://ostif.org/our-audit-of-unbound-dns-by-x41-d-sec-full-results/
20:28:34 <selsta> hopefully once everyone updated to v0.18 and once we figure out the DNSSEC warnings it stops being an issue / annoyance
20:32:23 <moneromooo> Well, maybe the .org chain was borked all along and nobody realized :)
20:36:49 <selsta> 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
20:38:13 <selsta> xmrfn: do you see the exact same message with log 0 on your VPS?
20:38:22 <xmrfn> yes
20:39:28 <xmrfn> no wait!
20:39:30 <selsta> ok. in your log 4 it looked a bit different, unless i overlooked the line i was looking for
20:39:42 <xmrfn> different reason: "SERVFAIL no DS for DS org."
20:41:19 <selsta> at least both are related to the .org
20:42:09 <xmrfn> 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
20:48:21 <dsc_> hello monero science team, I also seem to have this DNS error
20:48:34 <selsta> dsc_: on VPS?
20:48:42 <dsc_> selsta: do you require me to load up my IDE+debugger? :P
20:48:45 <dsc_> on desktop
20:49:06 <selsta> i have no idea about DNSSEC :D
20:49:34 <dsc_> me neither
20:49:37 <dsc_> but can try
20:59:04 <selsta> don't think it's a bug in ubound
20:59:10 <selsta> unbound
20:59:54 <selsta> it would be possible to bisect the unbound commit that causes the warning to show up
21:00:13 <selsta> might help us figure what the issue is
21:02:43 <selsta> and trying out different dns providers would also help figure out the issue
21:43:31 <dsc_> nais I fixed it
21:43:45 <dsc_> let me confirm
22:59:49 <selsta> dsc_: how?
23:02:44 <dsc_> selsta: https://github.com/monero-project/monero/issues/8452#issuecomment-1196066179
23:06:23 <selsta> tyyy looking currently
23:10:19 <selsta> dsc_: ok we have to fix the first DS entry
23:12:34 <selsta> 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?
23:16:53 <dsc_> selsta: the issue is also fixed by doing something like `nameserver 8.8.8.8` in /etc/resolv.conf, yeah
23:17:06 <dsc_> ill edit my thinger
23:17:26 <selsta> ok so it is likely DNS provider misconfig?
23:20:25 <dsc_> 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
23:21:19 <dsc_> one thing to consider is that while updating libunbound, it simply got more verbose
23:21:38 <dsc_> nvm scratch that
23:22:00 <selsta> I assume you did try editing this first wrong DS value?
23:22:03 <dsc_> but yeah, lets wait for a DNS person to chime in :)
23:22:27 <dsc_> Yes, wrong DS value is fine as long as the right one eventually gets added
23:23:33 <dsc_> 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 :)
23:24:39 <dsc_> it adds both via `ub_ctx_add_ta`