01:02:20 <jmnbtsls1E> is it possible to manually decrypt a geli partition from the loader prompt, after calling geli_load to load the key? it has a password
01:04:55 <AmyMalik> gah
01:21:40 <debdrup> It's been a while since I rebooted my system, but doesn't the prompt come after the GELI passphrase+decryption stage?
01:34:16 <jmnbtsls1E> i made a mistake in my loader.conf (specified the wrong device) and don't have an  image available at the moment to boot from to fix it
01:34:56 <jmnbtsls1E> so it doesn't attempt to automatically decrypt during boot and i reach the mountroot prompt, with the partition still encrypoted
01:35:50 <jmnbtsls1E> i've also tried : load_geli $PARTITION_TO_ENCRYPT $KEYFILE_LOCATION_IN_LOADER_PARTITION , same result
01:36:00 <jmnbtsls1E> i meant decrypt not encrypt
01:36:16 <jmnbtsls1E> loads the key but no decryption once i attempt boot
01:37:03 <jmnbtsls1E> it might be that the geli module is configured specifically in the loader.conf by the _type variable that specifies the parititon to encrypt
01:37:24 <jmnbtsls1E> that's where i made my mistake in the conf
02:10:03 <tuaris> Does ser2net only work with USB devices that are for low speed serial (RS-232)?  For example, can I use it to for USB soundcard?
02:10:47 <tuaris> Soundcard is just an example, I know there are better ways for that specific function
02:13:00 <cpet> serial 2 net ?
02:17:14 <tuaris> yeah
02:17:46 <cpet> yeah I wouldnt do that for a soundcard
02:18:21 <cpet> RS232 maxes out as 115200kbits so slow as hell in our std but fast back in the early 90 80's
02:18:48 <cpet> some industrial devices still use it though but not for playing sound
02:26:43 <AmyMalik> -.-
02:33:12 <nacelle> some things claim ~230kbps for rs232
02:33:33 <AmyMalik> not enough for hq PCM audio
02:34:58 <tuaris> Is there an alternative to ser2net that isn't speed limited like that?
02:35:21 <tuaris> again... audio was only an example.  looking for something in general
02:37:09 <AmyMalik> _what are you doing_
02:38:33 <tuaris> Example Usecase: I want to plug a USB device in a Raspberry Pi and access that device from a virtualized FreeBSD instance on a diffrent machine
02:39:24 <AmyMalik> / 134
02:45:48 <cpet> RS232 is one of thing we invented but we dont want to use any more
02:50:30 <AmyMalik> ... ha
03:14:36 <debdrup> the GEOM gate devices can be be used to share any device across the network, see: apropos ggate
03:17:13 <AmyMalik> owo
03:41:45 <jmnbtsls1E> i'm out of ideas..ifound a CD and corrected my loader.conf, but geli is not trying to decrypt the device at boot. i have this working on several systems, same exact kernel, loader, geom_eli.ko, same exact loader.conf except the partition number etc, everything but the key and the contents of the partition are the same. not sure if there's a good way to proceed
03:42:40 <jmnbtsls1E> might ask the forum or mailing list
03:43:21 <jmnbtsls1E> it does load the key, but no output in the console regarding decrypting
04:45:43 <RhodiumToad> hm, is something horked with geo.freebsd.org dns?
04:47:30 <tuaris> I can't acces and freebsd.org site, so something must be going on
04:47:47 <tuaris> Also haven't recived anything in the mailing lists
05:09:17 <RhodiumToad> I smell a bad load balancer at HE
05:11:41 <RhodiumToad> hm, maybe not
05:13:44 <RhodiumToad> ah.
05:17:40 <RhodiumToad> it's related to having the DO (dnssec OK) flag set in the query
05:22:54 <RhodiumToad> querying ns[12345].he.net for _.geo.freebsd.org with dnssec enabled returns a truncated response regardless of how big an EDNS size was specified
05:23:10 <RhodiumToad> and they don't answer to TCP fallback
06:00:00 <Erhard> Freebsd.org has been having dns issues since at least late last night. Seems worse today than last night, though (maybe some things were just cached last night, and have since expired).
06:01:43 <RhodiumToad> are you having issues with freebsd.org itself, or just stuff under .geo.freebsd.org ?
06:02:42 <Erhard> Mainly the latter
06:02:51 <RhodiumToad> hm, I'm also seeing quite slow responses and/or timeouts from ns*.he.net even without dnssec on
06:02:54 <Erhard> But git. fails too
06:03:09 <RhodiumToad> git.freebsd.org -> gitmir.geo.freebsd.org
06:03:18 <Erhard> There you go
06:03:21 <Erhard> ;-)
06:04:34 <RhodiumToad> what I'm seeing is this: queries for freebsd.org zone are sometimes getting timeouts or slow responses, but otherwise get correct answers whether dnssec is on or not
06:05:37 <RhodiumToad> but queries for geo.freebsd.org are getting proper referrals from he.net only when dnssec is off, and if it's on they get only truncated responses
06:05:39 <Erhard> I am getting a lot of timeouts. no matter what I use to resolve it (local DNS in a handfull of data centers across the world, or google, cloudflare, etc.)
06:07:11 <Erhard> Hopefully resolved soon... afk
06:24:09 <parv> File a PR?
06:26:18 <rtprio> Erhard: you can use github as a mirror if you need to
06:27:04 <Erhard> COol idea. KNow how to do that offhand before I search for it?
06:27:43 <Erhard> Like how would I get a git pull to work in /usr/src ?
06:28:40 <parv> Erhard, Are you thinking of fetching changes on top of existing clone|checkout?
06:28:55 <Erhard> Yes, would that be possible?
06:29:15 <Erhard> I could just make my own hosts entry or other dns entry of course.
06:30:26 <tuaris> that's actually a good idea seeing that I'm stuck on not being able to install packages (and my local poudriere build hasn't been updated since September)
06:30:42 <RhodiumToad> if the github mirror is properly in sync, then just some stuff with git remote should work, no?
06:31:00 <Erhard> If I knew git that well...
06:31:10 <Erhard> That last RCS I actually knew was cvs
06:31:21 <parv> You could try changing "remote.freebsd.url" attribute
06:31:21 <tuaris> I do host my own DNS resolvers.... I wonder if I could get a copy of the zone records from somewhere  and use that temporaroly
06:31:23 <RhodiumToad> if you run a local resolver, you might be able to convince it not to use dnssec, temporarily
06:31:42 <Erhard> Not sure that helps here.
06:31:57 <Erhard> As djbdns didn't resolve it either. and it does not support dnssec
06:32:25 <tuaris> I have "dnssec-validation no;" in my resolver, it doesn't help
06:33:09 <RhodiumToad> it's not validation that's the problem, just asking for dnssec breaks it
06:33:29 <parv> Current git configuration for "remote" in /usr/src for "stable/13": https://termbin.com/cffnr
06:34:17 <RhodiumToad> Erhard: I guess your problem might differ from mine. what does  drill -4 -b 8192 @ns3.he.net gitmir.geo.freebsd.org cname   return for you?
06:34:35 <RhodiumToad> er, s/cname/a
06:34:51 <tuaris> hmm, this seems to be returnign responses " drill @ns0.freebsd.org gitmir.geo.freebsd.org"
06:34:54 <Erhard> Hangs
06:34:56 <RhodiumToad> and what about   drill -4 -b 8192 @ns3.he.net git.freebsd.org cname
06:35:06 <Erhard> Oh, wait
06:35:18 <Erhard> Finally came back with results
06:35:46 <tuaris> "drill -4 -b 8192 @ns3.he.net git.freebsd.org cname" resturns a response
06:35:49 <RhodiumToad> tuaris: so what? ns0.freebsd.org isn't a nameserver for freebsd.org
06:36:26 <tuaris> hmm? that's what it returns when I do "drill SOA freebsd.org"
06:36:59 <RhodiumToad> tuaris: what's in the SOA means almost nothing. what matters are what the .org zone thinks the freebsd.org nameservers are
06:37:20 <Erhard> Though I think they are supposed to match by RFC, no?
06:37:24 <RhodiumToad> tuaris: (which are ns[2345].he.net )
06:37:52 <RhodiumToad> no, the "primary" name in the SOA is basically documentary
06:37:58 <Erhard> The guys over at #dns can tell you all the SHOULD vs. MUST stuff ;-)
06:38:33 <RhodiumToad> <--- ran DNS servers for years for a commercial service
06:38:48 <tuaris> interesting... when I do a lookup directly at each of ns[1-5].he.net all return a response.
06:39:03 <RhodiumToad> tuaris: add the -D option to drill
06:39:20 <RhodiumToad> tuaris: (which sets the "dnssec OK" flag)
06:39:42 <RhodiumToad> when I do that, the result is always an empty truncated one.
06:39:43 <tuaris> " drill -D @ns5.he.net pkg.freebsd.org" ... ->  "Error: could not find any address for the name: `ns5.he.net'"
06:40:43 <RhodiumToad> I get  ns5.he.net.     55617   IN      A       216.66.80.18    for ns5.he.net
06:44:00 <Erhard> Drill doesn't return anything here. Though host pkg.freebsd.org ns5.he.net works fine
06:45:24 <RhodiumToad> what drill command exactly?
06:45:29 <Erhard> Drill without the -D returns that pkg is a CNAME for PKGMIR
06:45:43 <Erhard>  drill -D @ns5.he.net pkg.freebsd.org
06:45:47 <Erhard> Returns ansers 0
06:45:50 <Erhard> answers
06:46:11 <Erhard> Without the -D returns the CNAME record
06:46:29 <RhodiumToad> with -D you should see it warns about a truncated response
06:46:38 <Erhard> It does do that
06:47:09 <RhodiumToad> that's the problem
06:47:41 <RhodiumToad> what's more, specifying a larger response size with EDNS doesn't help
06:48:23 <RhodiumToad> (truncation is supposed to trigger the resolver doing the query to try a larger buffer size or use TCP instead, and neither of those work in this case)
06:48:31 <tuaris> Created a forward zone for freebsd.org on my DNS resolver, that seems to be allowing stuff to resolve for now.
06:48:41 <Erhard> That was my result as well
06:49:07 <RhodiumToad> forwarding to where?
06:49:35 <tuaris> to ns[1-5].he.net
06:49:51 <tuaris> example: https://bin.morante.net/?dcac6420459f8cd3#8AH8dpKsUBg6fSQs32RCrxkswBMEZJkxcmGmaJnAFjtf
06:52:03 <tuaris> looks like I got to setup a similiar forward for geo.freebsd.org
07:05:05 <RhodiumToad> yeah. it's a hack but it seems to work well enough
07:05:52 <RhodiumToad> ahhhhh
07:05:57 <RhodiumToad> interesting
07:11:16 <RhodiumToad> you actually should only need the geo.freebsd.org one
07:11:49 <tuaris> geo.freebsd.org is forwarding to 213.138.116.75 and 96.47.72.24 and at least I can install/updates pacakges now.
07:11:53 <tuaris> oh
08:40:17 <antranigv> cpet daemon agreed. I think I'll just give root access. it's not a cloud hosted thing anyway.
11:03:44 <_xor> Yes.
11:04:01 <_xor> DNS blackout in 2/3rd of the zone (or what I was told anyway).
11:04:25 <_xor> I thought it was an issue on my side so I was trying to figure out with the pdns guys.
11:05:03 <_xor> They looked at the zone and said 2/3rd of it is "blacked out", so 2/3 requests are likely to not resolve.
11:06:32 <_xor> er, my bad...1/3, not 2/3.
11:08:26 <_xor> I was originally seeing the issue with freshports.org, but I guess freebsd.org also has a similar issue?
11:08:28 <_xor> https://dnsviz.net/d/freshports.org/dnssec/
11:08:31 <VimDiesel> Title: freshports.org | DNSViz
11:08:35 <_xor> https://dnsviz.net/d/freebsd.org/dnssec/
11:08:36 <VimDiesel> Title: freebsd.org | DNSViz
11:10:48 <adilix> hi all
11:17:35 <debdrup> _xor: I have my doubts that it's the same issue, but both may be experiencing issues at the same time.
11:22:07 <debdrup> antranigv: it's kind of interesting, to me anyway, that Unix-like literature often treats uid 0 as being the highest privilege, as there's at least one higher.
11:23:43 <debdrup> And it's not a coincidence that it crops up a lot in infosec circles, because whoever has physical access is, by its very nature, at a higher privilege than someone logged in as root.
11:25:03 <debdrup> Forcing a console to drop to single-user mode with no networking pretty succinctly deals even with attackers who've gained root access.
11:26:23 <debdrup> That's also why it's almost impossible to overstate how important it is to keep physical access, OOB BMCs, and the like absolutely locked down as tight as possible.
11:27:27 <debdrup> I'm tempted to say that OOB BMCs should only be accessible through 802.1x accessible VLAN.
13:30:45 <puretone> g'morning all
13:31:01 <puretone> quick question, are git.freebsd & pkg.freebsd down?
13:32:00 <puretone> *carefully backs away from keyboard & reaches for tea*
14:06:48 <satanist> puretone: no, but there was (or still is) a issue with the dns
14:07:29 <puretone> I can't get any response from pkg.freebsd git.freebsd & download.freebsd
14:09:25 <satanist> can you resolve git.freebsd.org (host git.freebsd.org)?
14:09:33 <puretone> negative
14:09:48 <puretone> haven't beem able to since yesterday at some point
14:16:15 <puretone> I've switched to pull from github.com for now... I can get to cgit.freebsd.org fine, but git.freebsd.org is totally unreachable. Ditto for pkg.freebsd.org & dowload.freebsd.org
16:07:42 <puretone> More servers down/missing - from nslookup - ** server can't find distcache.FreeBSD.org: SERVFAIL
16:12:53 <puretone> and pkg: http://pkg.freebsd.org/FreeBSD:13:amd64/latest/meta.txz: No address record
16:16:46 <ek> puretone: Both distcache.freebsd.org and pkg.freebsd.org resolve fine for me.
16:17:13 <puretone> I can't for the life of me get to them
16:17:35 <ek> puretone: Maybe try switching to a different DNS server in /etc/resolv.conf?
16:18:01 <puretone> tried from 7 different mahcines on different links
16:19:19 <ek> puretone: What does "drill @1.1.1.1 pkg.freebsd.org" say?
16:20:45 <puretone> opcode: QUERY, rcode: SERVFAIL, id: 57057
16:23:53 <moviuro> I'm trying to enable IPv6 rtsol on bge0. bge0 is connected to a switch that has an OpenBSD router that delivers IPv6 addresses to Linux, Windows and Android clients. FreeBSD doesn't get its IPv6 address. `ifconfig bge0 inet6 accept_rtadv`; `service rtsold onestart` ; `rtsol bge0` ; *crickets*
16:25:05 <moviuro> (OpenBSD runs a rad(8) daemon, no fancy/weird DHCPv6)
16:25:14 <CrtxReavr> moviuro, ping6 ff02::2%bge0
16:26:41 <moviuro> CrtxReavr: crickets, 100% packet loss
16:28:22 <CrtxReavr> So it can't reach anything on your network listening on the all-routers multicast address.
16:28:39 <CrtxReavr> L1 problem?  Right VLAN?
16:28:49 <moviuro> right, but that doesn't sound like a requirement because every other machine on the network did get an address
16:29:04 <moviuro> yes, same VLAN/network as my own machine
16:29:16 <CrtxReavr> So an L1 problem?
16:29:19 <CrtxReavr> What does work?
16:29:30 <CrtxReavr> Also. . .I'm not sure why you would run rtsol manually.
16:30:04 <CrtxReavr> ifconfig_bg0_ipv6="inet6 accept_rtadv"
16:30:58 <CrtxReavr> I'd add that to your rc.conf, then: sudo service netif restart && sudo service routing && restart
16:32:29 <puretone> ek: interresting bit - drill @1.1.1.1 fails but @8.8.8.8 works
16:32:54 <CrtxReavr> I wouldn't use either, but you do you.
16:33:34 <moviuro> CrtxReavr: hmmm the machine is now gone?.. no ping, no ssh :/
16:34:36 <CrtxReavr> YOu didn't useThat second && shouldn't have been in what I typed.
16:35:30 <CrtxReavr> 'course. . .if you ran ``sudo service netif restart`` without `` && sudo service routing restart`` then that's on you.
16:36:03 <moviuro> I'll need to get the full explanation as to why there are so many footguns one day
16:36:25 <CrtxReavr> "With great power, comes great responsibility."
16:36:49 <moviuro> yeah, well restarting the network daemon without also routing sounds really stupid :(
16:36:57 <CrtxReavr> Don't blindly type shit that people supply on IRC. . . ask questions. . . read manpages.
16:37:09 <CrtxReavr> I'm trying to help. . . but there are people that will try to sabotage you.
16:37:31 <CrtxReavr> Do you understand what && does?
16:37:45 <moviuro> yes, that's not the issue
16:38:00 <moviuro> the issue is the netif && routing. That's a footgun
16:38:13 <CrtxReavr> I do it all the time.
16:38:34 <CrtxReavr> Are you *SURE* you undestand what && does?
16:39:00 <CrtxReavr> 'Course. . . I'm also assuming you have a valid network config in your /etc/rc.conf
16:39:34 <rtprio> 🎶 when the route does not work cause an irc jerk, that's a footgun. 🎵
16:40:14 * CrtxReavr puts two rounds in each of rtprio's feet.
16:40:44 <puretone> lol
16:41:07 <rtprio> well, hopefully you've got a way to reboot into the console on this host
16:42:03 <CrtxReavr> Or have competant onsite hands.
16:42:15 <CrtxReavr> Or can take a walk into the datacenter.
16:44:06 <CrtxReavr> I have booked out my office, down a hall, around a corner, down another hall, up a flight of stairs, down another hallway, accross a lab to a table, with a KVM setup, all while saying "shit shit shit shit," plenty of times.
16:45:43 <CrtxReavr> Sketchy PS/2 KVMs with questionable switching ability. . .
16:45:46 <CrtxReavr> Don't miss those days.
16:46:34 <rtprio> although after having all my freetime in a weekened used to drive 6 hours one way to get a host to boot; i tend to do riskier things locally first, or autorevertable
16:48:28 <CrtxReavr> Yeah - always careful, depending on the situation.
17:36:30 <skered> pkg.freebsd.org not resolving for anyone else?
17:38:09 <mvanbaak> pkg.freebsd.org.        300     IN      CNAME   pkgmir.geo.freebsd.org.
17:38:11 <mvanbaak> pkgmir.geo.freebsd.org. 300     IN      A       147.28.184.43
17:38:19 <rtprio> pkgmir.geo.freebsd.org has address 204.15.11.66
17:39:09 <Erhard> Freebsd has been having dns issues for about 36 hours or so
17:39:38 <Kalten> pkgmir.geo.freebsd.org has address 147.28.184.43
17:39:38 <Kalten> pkgmir.geo.freebsd.org has address 213.138.116.73
17:39:39 <Kalten> pkgmir.geo.freebsd.org has IPv6 address 2604:1380:4091:a001::50:2
17:39:39 <Kalten> pkgmir.geo.freebsd.org mail is handled by 0 .
17:39:46 <rtprio> haven't seen any signs of that, Erhard
17:40:01 <Erhard> Scroll back here... Big discussion yesterday
17:40:14 <Erhard> I still can'
17:40:17 <Erhard> t resolve a lot
17:40:33 <Erhard>  host pkg.freebsd.org 1.1.1.1
17:40:35 <Erhard> Host pkg.freebsd.org not found: 3(NXDOMAIN)
17:40:41 <Erhard> Even cloudflare still can't
17:40:56 <rtprio> is only freebsd domain the problem?
17:41:08 <Erhard> I think it was anything under geo.freebsd.org
17:41:14 <Erhard> Which pkg cnames to
17:42:51 <rtprio> Erhard: using 1.1.1.1 for that resolves to my own ip
17:43:19 <rtprio> does it for you? `host pkg.freebsd.org. 1.1.1.1`
17:43:29 <rtprio> let's see your resolv.conf
17:43:32 <Erhard> No. I get nxdomain from cloudflare's server
17:43:40 <rtprio> with the trailing period?
17:43:49 <Erhard> if you specify the server it doen't use resolv.conf
17:44:27 <rtprio> right. i know; but since cloudflare has multiple dns servers in different zones, it's probably not helping to figure out where the problem lies
17:44:54 <Erhard> I see. Well, no clue. It says using 1.1.1.1. So wherever that routes to for me I suppose
17:45:20 <Erhard> But I see it on Oracle cloud too
17:45:42 <Erhard> And Kamatera in Texas.
17:46:14 <Erhard> Could still be caching issues. Or somehow related to dnssec, was what somebody (I think RhodiumToad ) thought
17:46:19 <skered> So what was the exact issue from yesterday?
17:46:30 <skered> Some TTL?
17:46:33 <Erhard> Never got a straight answer
17:46:44 <Erhard> Most people could not resolve anything under geo.freebsd.org
17:47:05 <Kalten> Would TTL not only be a problem for servers with changing IP adresses?
17:47:14 <Erhard> I could not from 7 different physcial locations using as many unique nameservers.
17:47:25 <Erhard> TTL is ignored by some nameservers.
17:47:38 <Erhard> LIterally the he servers weren't responding correctly.
17:48:00 <Erhard> Lasting problems could certaily by caching. (ttl)
17:48:16 <Erhard> Not sure if it has been resolved. Mine still don't resolve, but I haven't cleared the cache.
17:48:38 <Erhard> Cloudflare is still not resolving, but I have heard they cache everything for 24 hours regardless (no clue if that is true)
17:49:01 <rtprio> have you queried agianst gns[1-2].freebsd.org ?
17:49:38 <skered> Seems like someone is on it... https://twitter.com/bkidney/status/1596952088176640000
17:49:41 <VimDiesel> Title: Brian Kidney (@bkidney⊙bn) on Twitter: "@ed_maste is there an issue with the FreeBSD DNS? I cannot resolve https://t.co/IJor4TRH4a, even if I use the Google server 8.8.8.8." / Twitter
17:50:07 <Erhard> Host pkg.freebsd.org not found: 5(REFUSED)
17:50:10 <Erhard> for gns
17:50:18 <Erhard> It's on their end. I will wait
17:51:21 <rtprio> put some hostfile lines in and call it a day
17:51:30 <Erhard> Yes, one option.
17:51:46 <Erhard> I'm in no hurry and don't want to do that on 11 servers.
17:51:53 <Erhard> And then have to remove it, etc.
17:52:28 <rtprio> no centeral management on those 11 servers?
17:52:46 <Erhard> Nope. too spread out and unique in other ways
17:53:09 <Erhard> Just not worth the fuss. Other things to do today
19:45:46 <CrtxReavr> The trailing dot on NS queries is just a little added namespace syntax - should be quite moot for IPs.
19:53:23 <RhodiumToad> pkg.freebsd.org is out-of-zone for the gns* servers, hence the REFUSED
19:53:49 <_xor> So what's the status of the DNS issue(s) now?
19:53:58 <RhodiumToad> those serve only .geo.freebsd.org queries, and pkg.freebsd.org is a cname to pkgmir.geo.freebsd.org
19:54:13 <RhodiumToad> still broken by my tests, same way as last night
19:55:17 <RhodiumToad> ns*.he.net are returning truncated results any time they are queried _with dnssec enabled_ for names that should result in a referral to gns*.freebsd.org
19:56:06 <_xor> Hmm, I'd been having issues with freshports.org (yes, unrelated) for a while. Now I'm seeing the same with various subs on freebsd.org.
19:56:40 <RhodiumToad> oh, and also ns*.he.net have been variably slow and/or timing out, which may be a separate problem
19:57:15 <RhodiumToad> right now they're responding ok tho
19:57:37 <_xor> Is there a discussion thread for this issue somewhere or is it mostly ad-hoc?
19:58:06 <RhodiumToad> to see the problem, compare  drill @ns2.he.net git.freebsd.org a   with  drill -D @ns2.he.net git.freebsd.org a
19:58:22 <RhodiumToad> (the -D option sets the "dnssec OK" flag in the query)
19:59:32 <_xor> ah
20:00:57 <_xor> So is turning off dnssec on my side a stop-gap fix for this for the time being?
20:01:12 <_xor> Well, dnssec for that domain I mean.
20:01:29 <RhodiumToad> if it stops your resolver from setting the DO bit in the relevant queries, then it will help
20:05:47 <RhodiumToad> (otherwise, not)
20:25:11 <RhodiumToad> ahhhh
20:27:22 <RhodiumToad> ok, so here's another wrinkle: the correct answer can be obtained when querying by TCP
20:27:43 <RhodiumToad> but last night, that wasn't working (none of ns*.he.net would answer to TCP queries)
20:29:48 <RhodiumToad> the ns*.he.net answer is 2071 bytes, so one might speculate that their nameserver is refusing to send responses of that size even when EDNS allows it
20:35:22 <RhodiumToad> (add -t to those drill commands to see it)
20:46:15 <RhodiumToad> so to correct my previous statement, the problem does seem to be fixed now
20:53:59 <Erhard> Yes, where not cached it seems to be working. Cool
20:55:00 <RhodiumToad> the fact that it fails to resolve at all when tcp fallback isn't working is pretty sub-optimal, though
21:15:07 <Erhard> Sounds like the he servers are misconfigured. Or the firewall or some agressive anti-spoof or something
21:17:12 <RhodiumToad> or they were under attack and were not mitigating it properly
21:20:44 <Erhard> YEah, amplification attack mitigation that blocked large replies, which was having side effects.
21:22:06 <RhodiumToad> checking around, the reply size limit may be a normal setting; the failure is due to failing to allow TCP fallback
21:23:02 <Erhard> Better to structure things so the reply is smaller ;-)
21:25:00 <Erhard> I'm not a huge fan of the dnssec implementation. While signing is good for validation something still needs to be done about privacy
21:25:24 <RhodiumToad> most of the reply is of course dnssec signatures
21:25:35 <Erhard> I figured, hence my statement there.
21:25:37 <RhodiumToad> afk.
21:25:42 * Erhard waves
21:38:41 <ceno0_> kk
21:40:38 <ceno0_>  hi nay