My main point was however that it's really not okay that CloudFlare allows setting up other record types (e.g. TXT, but basically any) next to a CNAME.

  $ echo "A AAAA CAA CNAME DS HTTPS LOC MX NS TXT" | sed -r 's/ /\n/g' | sed -r 's/^/rfc1034.wlbd.nl /g' | xargs dig +norec +noall +question +answer +authority @coco.ns.cloudflare.com
  ;rfc1034.wlbd.nl.  IN A
  rfc1034.wlbd.nl. 300 IN CNAME www.example.org.
  ;rfc1034.wlbd.nl.  IN AAAA
  rfc1034.wlbd.nl. 300 IN CNAME www.example.org.
  ;rfc1034.wlbd.nl.  IN CAA
  rfc1034.wlbd.nl. 300 IN CAA 0 issue "really"
  ;rfc1034.wlbd.nl.  IN CNAME
  rfc1034.wlbd.nl. 300 IN CNAME www.example.org.
  ;rfc1034.wlbd.nl.  IN DS
  rfc1034.wlbd.nl. 300 IN DS 0 13 2 21A21D53B97D44AD49676B9476F312BA3CEDB11DDC3EC8D9C7AC6BAC A84271AE
  ;rfc1034.wlbd.nl.  IN HTTPS
  rfc1034.wlbd.nl. 300 IN HTTPS 1 . alpn="h3"
  ;rfc1034.wlbd.nl.  IN LOC
  rfc1034.wlbd.nl. 300 IN LOC 0 0 0.000 N 0 0 0.000 E 0.00m 0.00m 0.00m 0.00m
  ;rfc1034.wlbd.nl.  IN MX
  rfc1034.wlbd.nl. 300 IN MX 0 .
  ;rfc1034.wlbd.nl.  IN NS
  rfc1034.wlbd.nl. 300 IN NS rfc1034.wlbd.nl.
  ;rfc1034.wlbd.nl.  IN TXT
  rfc1034.wlbd.nl. 300 IN TXT "Check my cool label serving TXT and a CNAME, in violation with RFC1034"

So let me know if someone is interested in this ticket, see my GitHub for mail address. I know other speakers where even unaware of this (so I might know another ticket for sale).

But maybe DNSSEC is the 'unnecessary complexity' for you (I think it's kind of fundamental to secure DNS). Also without DNSSEC they needed RFC's like https://datatracker.ietf.org/doc/html/rfc8020 to clarify fundamentals (same goes for https://datatracker.ietf.org/doc/html/rfc8482 to fix stuff).

My point was that you don't need to compete with paid features, just please give the developers money to develop the software further (and fix bugs/issues), so e.g. buy some 'enterprise license', even if you don't need it in terms of features.

IMHO a MIT license is better than AGPL with a Contributor License Agreement (CLA) like with Elastic.

Gitea is MIT, so free and open-source, permissive.

Also see https://news.ycombinator.com/item?id=45929247#45930949

When deciding which software fork to pick, it is about the development power. Also note my point about security: https://news.ycombinator.com/item?id=45929247#45930310

I'm a 5+ year government employee, I touched quite some governmental repositories but all are non-paid.

I'm also a fan of the government hosting the code in an EU jurisdiction, preferably our own Dutch jurisdiction, and even better, self host.

The issue with deviating from the upstream license is that only the code author can upstream a patch, since GPLv3 cannot be changed by a non-author of the code to MIT. Resulting in less being patched upstream, and so more merge conflicts, the maintenance burden I was talking about.

Forgejo used to be a set of patches applied on Gitea, but they moved to a fork with cherry picking Gitea commits, this is more work. In my view they don't have the development to keep up with Gitea.

Security wise, Gitea was safer in this case.

Also note the SECURITY.md was deleted: https://codeberg.org/forgejo/forgejo/commit/277dd02e706b6e51..., there is a security https://forgejo.org/docs/next/contributor/discussions/#secur... but it's a bit harder to find.

The problem is, Forgejo changed the license (https://codeberg.org/forgejo/governance/pulls/24#issuecommen...) and ended up doing a hard fork (https://forgejo.org/2024-02-forking-forward/#consequences-of...) which creates quite some maintenance burden. There used to be a (weekly) gitea chery-pick (e.g. https://codeberg.org/forgejo/forgejo/pulls?state=closed&labe...) but the TODO section was getting ever larger, and it seems it stopped in July (week 26).

So they start missing stuff, e.g. features like https://codeberg.org/forgejo/forgejo/issues/9552

I'm a self hosting GoGogs / Gitea user for almost 10 years, I did follow the Gitea fork. However regarding the Forgejo fork: the main contributors stayed with Gitea. The ideologically forked Forgejo made some license changes and hard fork decisions that increased the maintenance burden even more, resulting in missing upstream features and decreased security. Forgejo is more busy managing ideals, than creating software.

Also listed in https://incidentdatabase.ai/cite/1009/

See all issues on: https://internet.nl/site/mastercard.com/3122570

Nameserver is not reachable on advertised IPv6:

    $ dig +short +tcp @dns1.mastercard.com dns1.mastercard.com AAAA
    2607:3c00:6404:4::53

    $ dig +tcp @2607:3c00:6404:4::53 mastercard.com SOA
    ;; Connection to 2607:3c00:6404:4::53#53(2607:3c00:6404:4::53) for mastercard.com failed: timed out.

I also would expect an IPv6 on the apex/www, since there are quite some ISP's with IPv6 where IPv4 is a GCNAT, if there is a noisy user on the IPv4, it's tricky to block those, except if the ISP supports IPv6 and the web server too.

Weirdly enough the SOA serial which is in YYYYMMDDnn (see https://datatracker.ietf.org/doc/html/rfc1912#section-2.2) was not updated (still indicates 2011):

    $ dig +short +tcp @dns1.mastercard.com mastercard.com SOA
    dns1.mastercard.com. hostmaster.mastercard.com. 2011127982 14400 3600 2419200 300

    $ dig +short @a22-65.akam.net. az.mastercard.com SOA
    a1-29.akam.net. hostmaster.az.mastercard.com. 2020068768 3600 600 604800 300

Sadly nobody recorded this in either DNSViz history (https://dnsviz.net/d/az.mastercard.com/Z5ErUw/dnssec/ is the first) or ZoneMaster history (see https://www.zonemaster.net/en/result/3fa42e8e683db1bf).