XMPP Service Operators - 2023-12-09


  1. theavidhorizon

    nuegia.net, +1

  2. nuegia.net

    Hello, this is a PSA for anyone running dualstack servers

  3. nuegia.net

    recently, my IPv6 provider had an outage. This left IPv4 still reachable while IPv6 was not. Some other server operators whom federate with nuegia.net though took it upon themselves to try to restore connectivity early by adding an entry to their server's hostsfile with the v4 fallback address of my server's s2s endpoint

  4. nuegia.net

    this did not work. In fact when IPv6 connectivity was restored this resulted in broken federation for those servers that had did this hack

  5. nuegia.net

    the problem was with dialback security.

  6. nuegia.net

    if you want to ensure dualstack federation resiliency, I reccomend that you have two SRV records instead of one.

  7. nuegia.net

    the primary SRV entry can point to your A/AAAA records or AAAA record. The secondary should be A record only.

  8. nuegia.net

    The reason for this is because of the way dns64 works. IPv6-only networks use DNS64 to connect with legacy-only ip networks. IPv6-only networks query only AAAA records. The dns64 server then responds with the native AAAA record if it exists, but if it does not the dns64 server will generate a AAAA record on the fly within the network's NAT64 pool address range (which is usually a special /96 set aside for containing the entire IPv4 address range).

  9. nuegia.net

    If you only have one SRV record for your xmpp-s2s endpoint and that SRV record points to a dualstack A+AAAA record the A record will NEVER BE TRIED!

  10. yakov

    what if you have no srv records at all?

  11. nuegia.net

    you really should have SRV records. That's part of properly setting up an XMPP server.

  12. nuegia.net

    I guess all bets are off then since your relying on undefined fallback behavior.

  13. nuegia.net

    yakov, here's instructions on how to fix this https://prosody.im/doc/dns

  14. yakov

    yes, but if you're not using mismatched domains/redirects, or load balancing, or non-standard ports are SRV records necessary?

  15. yakov

    also do any clients/servers check use TLSA records yet?

  16. Martin

    My server (running prosody-trunk) does.

  17. yakov

    is it really advisable for Let's Encrypt users to renew the existing certificate instead of generating anew?

  18. yakov

    seems counterintuitive

  19. yakov

    **** suggests this)

  20. yakov

    cert watch*

  21. Martin

    nuegia.net: So you suggest two srv records, one for v4 and one for v6? But you just point at a domain in the srv record and the domain will have records for v6 and legacy.

  22. nuegia.net

    yakov, I'm not sure what the RFC says but the prosody documentation makes it appear that if you don't have any SRV records at all that is only suitable for a simple legacy-only configuration that does not account for AAAA records at all.

  23. yakov

    `netstat -tupwn | grep beam | grep "::" | wc -l` gives 67 connections for me

  24. yakov

    with no srv records

  25. nuegia.net

    Martin, the primary domain can be dualstack. Wether it's AAAA only or A+AAAA doesn't matter or change the behavior of what will happen in dns64. The secondary fallback SRV record should point to a A-only record.

  26. unix.dog

    its not undefined fallback behavior but it is fallback behavior to have no SRV record and just A or AAAA records

  27. nuegia.net

    it may be more confusing if the primary SRV record points to A+AAAA though, as depending on the other people's network configuration they could be connecting to entirely diffent addresses. This could make troubleshooting harder.

  28. nuegia.net

    the way i have my records set is the primary SRV xmpp-s2s record points to a AAAA record and the secondary fallback SRV record points to a A record. This is because the XMPP origin server does not have any IPv4 records bound to it and is IPv6-only. All incoming IPv4 connections are handled by a TCP reverse proxy server which then translates the incoming IPv4 to the server's real IPv6 address via the ProxyV2 Protocol to preverse the origin connection's IP address for spam filtering and logging purposes.

  29. nuegia.net

    all outgoing IPv4 addresses are handled by NAT64 and DNS64

  30. nuegia.net

    unix.dog, prosody.im's public documentation says if you have no SRV records only an A record is queried.

  31. nuegia.net

    wether the documentation is consistent with prosody's behavior I have not checked.

  32. unix.dog

    https://xmpp.org/rfcs/rfc6120.html#tcp-resolution-fallback

  33. unix.dog

    it should be an A or AAAA lookup

  34. nuegia.net

    'or' is funny wording to use for a standard.

  35. unix.dog

    yeah

  36. nuegia.net

    tis might be a case of the source code of various daemons being the true behavior, but SRV record behavior seems much better defined.

  37. MSavoritias (fae,ve)

    Ganneff@fulda.social - If you are out there happily applying the new #Debian pointrelease - DO NOT REBOOT into the updated #linux #kernel. It contains a serious (and silent) #data #corruption #bug that MAY (not must) affect you. Fixes are in preparation, but builds will take a bit to complete.

  38. MSavoritias (fae,ve)

    https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1057843 https://lore.kernel.org/stable/20231205122122.dfhhoaswsfscuhc3@quack3/

  39. techmetx11

    hi

  40. MSavoritias (fae,ve)

    From the link above > The commit got merged in 6.5-rc1 so all stable kernels that have > 91562895f803 ("ext4: properly sync file size update after O_SYNC direct > IO") before 6.5 are corrupting data So watch what kernel you are upgrading to if you are using ext4

  41. techmetx11

    MSavoritias (fae,ve): thanks for the warning :)

  42. MSavoritias (fae,ve)

    Yw 😃

  43. techmetx11

    you are really a nice person

  44. Licaon_Kter

    MSavoritias (fae,ve): fixed in 6.1.66, right?

  45. MSavoritias (fae,ve)

    Yeah according to the bug report from debian.

  46. roughnecks

    official debian announcement: https://livellosegreto.it/@debian@framapiaf.org/111551950920597483

  47. nuegia.net

    *sigh* that's really bad.

  48. nuegia.net

    This was the rust kernel wasn't it? linux major version 6's change.

  49. Menel

    Too late, already rebooted some hours ago

  50. roughnecks

    ouch

  51. jacob.eva

    Yikes

  52. nuron (anoxinon.me)

    I just installed the affected kernel a few hours ago but did not yet rebooted the mashine. What is the best way to get rid of this peace of code? 🙂 Just remove it via apt and rebuild initramfs?

  53. nuron (anoxinon.me)

    I just installed the affected kernel a few hours ago but did not yet rebooted the mashine. What is the best way to get rid of this piece of code? 🙂 Just remove it via apt and rebuild initramfs?

  54. nuegia.net

    nuron (anoxinon.me), yes

  55. nuegia.net

    consider blocking that version from installation too

  56. nuegia.net

    man apt-mark(8)

  57. nuron (anoxinon.me)

    If I try to purge the kernel, apt would like to remove linux-image-amd64 and wireguard as well. I guess thats not what it should do?

  58. nuegia.net

    remove the specific kernel version, not the metapackage

  59. nuegia.net

    linux-image-amd64 is a metapackage

  60. nuegia.net

    it points to other package that can satisfy it's dependency

  61. nuron (anoxinon.me)

    I typed: `apt purge linux-image-6.1.0-14-amd64`

  62. nuegia.net

    I don't know

  63. nuron (anoxinon.me)

    🙂

  64. nuron (anoxinon.me)

    > linux-image-amd64 is a metapackage thats why i'm confused a bit

  65. nuegia.net

    let me know if you figure it out. I've had trouble with apt in the past too trying to remove or install specific kernel versions.

  66. nuegia.net

    metapackages work a little bit like CNAMEs in dns

  67. nuegia.net

    their a fake package the points to several real packages as dependencies

  68. moparisthebest

    > is it really advisable for Let's Encrypt users to renew the existing certificate instead of generating anew? yakov: renewing a certificate isn't a thing that exists, but there is no reason not to keep the same key unless you have reason to think it's been compromised, and then you can pin it everywhere with DANE and HPKP and the upcoming XEP 😉

  69. nuron (anoxinon.me)

    nuegia.net: I just removed the -14 kernel as well the meta package and wireguard. Rebooted, everything looks fine. Its using the -13 kernel as before

  70. nuegia.net

    moparisthebest, key pinning with SANE and HPKP? What's that? Is it a replacement for certificate authorities?

  71. moparisthebest

    nuegia.net: DANE yes

  72. nuegia.net

    is it production ready?

  73. nuegia.net

    can I get rid of lets encrypt now?

  74. moparisthebest

    Yes it's been in use for gotta be near a decade

  75. moparisthebest

    No because not all servers and clients support it yet

  76. nuegia.net

    where can I find documentation for doing this?

  77. nuegia.net

    damn

  78. moparisthebest

    Not even all TLDs... Looking at you .im

  79. savagepeanut

    nuegia.net, best place to set it up and test it is probably https://certwatch.xmpp.net/

  80. yakov

    uwu why is dnssec not mandatory yet?

  81. savagepeanut

    It is for new TLDs. Old ones like .im managed to get grandfathered in

  82. moparisthebest

    But all major TLDs and all new gTLDs support DNSSEC, just gotta convince all the .im domains to drop it