@Ejegg to confirm why current link shortener doesn't allow parameters; @greg to initiate process of securing new domain with Production SRE.

I believe the code to handle passing along query string params would need to be in

https://gerrit.wikimedia.org/r/plugins/gitiles/mediawiki/extensions/UrlShortener/+/refs/heads/master/includes/SpecialUrlRedirector.php

and it's not there, so that explains why it doesn't work. I'm guessing they wouldn't actually want to allow that, since it would let someone blow up the cache by hitting short URLs with tons of different parameters. I can ask the developers, though!

Checking on this request for a short link domain to use for Acoustic SMS messages. This will help with the long term branding and SMS deliverability for the program.

One note is that the DNS for the selected domain will need to pointed at an Azure Front Door CDN which will require a CNAME value in DNS. Thus it will need to be a subdomain, unless Wikimedia DNS supports "CNAME flattening" at the root domain level.

Hey, sorry, this fell off the priority list during December; thanks for the reminder.

I just chatted with a member of the SRE Traffic team (who owns the domain/DNS for us) and basically:

1. generic new domains are relatively straight-forward (get Legal to register it, SRE then adds the DNS info)
2. dotwiki domains are harder for a few reasons (see T88873)

The SRE team is at an offsite next week, but if we/Fundraising/@EWilfong_WMF can maybe think of a good generic domain (something.org) that is available, that might be the easiest path forward.

The Traffic team will correct me if I'm wrong about the above.

Thanks for the background here on the .wiki domains. Perhaps a subdomain of an already owned and in use Wikimedia domain would be ideal here. Would a subdomain of the current URL shortener domain (w.wiki) work in this instance? For example: t.w.wiki?

The two main goals here are:

1. Short domain name since SMS messages are priced by content length
2. A wiki-related domain that builds builds user trust and reinforces the Wiki brand.

Thanks for the summary @greg! To confirm what has been said: given the nature of the .wiki gTLD and the fact that we don't own it and thus have no control over it, we are a bit hesitant for it being used for anything outside of the already existing use cases, such as w.wiki. (learn.wiki also exists but since it already does now, there is nothing really to be done here and we can't take that back.)

w.wiki given its nature is considered a canonical domain; see a full list here. Our policy on canonical domains is that unless we operate the services running under them, we are hesitant to point them to third-party services or do redirects, as we have no control over those third-party or redirected domains and thus can't control their security or anything else about them. Subdomains of w.wiki or any other canonical domain fall under the same considerations. Similar to w.wiki, wikimediafoundation.org is an exception to this. But what we are trying to do here is to prevent this list of exceptions from growing...

@EWilfong_WMF is correct that we don't CNAMEs at the apex of a zone, so it can't be a CNAME for m.wiki or or anything else anyway but has to be a subdomain of it.

In the long term, we are working on an official policy that states this. For now, I am happy to answer any more questions or to brainstorm this further from Traffic's side. For any other domain registrations, Legal will register it and Traffic will deploy the DNS side; we are here to help with that.

@greg, @XenoRyet and I are reviewing this against the next quarter's SMS projects - what are the next steps on this?

I'm working with Sean K on selecting and then acquiring and then delegating the domain. Went through conversations with Legal and Comms (Brand).

@ssingh update on our end. We identified the domain we'd like to use and Chuck R from Legal has already acquired it for this purpose (wiki.gives). We'd like to point the ns to ones used by our SMS/Email marketing platform contractor named Triology. Is that within reason for this task? The nameservers are:
ns1-06.azure-dns.com
ns2-06.azure-dns.net
ns3-06.azure-dns.org
ns4-06.azure-dns.info

Let me know if I should do anything else (eg: email Legal with the request first). Thanks!

Hi @greg: (Using this task is perfectly fine, thanks). The delegation for wiki.gives will be done at Markmonitor's (registrar) side, so we will need to update the NS records there and point them to the above, moving them away from ns[0-2].wikimedia.org where they currently point to. There is no other DNS deployment required on our end in that case; we only need to do that if we were doing subdomain delegation, which we are not.

Makes sense, thank you @ssingh ! Just to be clear in my mind: Are the markmonitor changes done by Traffic or Legal/Trademarks team?

Mentioned in SAL (#wikimedia-operations) [2025-05-14T16:56:34Z] <sukhe> updating nameservers for wiki.gives in Markmonitor to set up delegation: T379318

@greg: The change has been made and Markmonitor has been updated. NS records have a fairly large TTL of 86400 seconds or one day, so it will be a while (1-2 days) before the various recursors pick up the change (not counting the time it takes for the update to propagate from the registrar to the gives TLD).

I am leaving this open and will follow up once the change is live. Let us know if there are any questions in the meantime.

(In the past this was handled by Legal but Traffic can make such changes now. I was mostly waiting for a confirmation on which parts to delegate.)

Awesome, thank you very much @ssingh ! I'll let the Acoustic side know now.

@greg: Traffic was notified about this an it seems like wiki.gives is a 404. Is that expected?

In T379318#11693429, @ssingh wrote:

@greg: Traffic was notified about this an it seems like wiki.gives is a 404. Is that expected?

I wonder if it gives that error on the root but works with the shorturl. I'll ask our fundraising team that uses this.

I can confirm that is how it works. The root URL does not have a page, but the short URLs generated by Acoustic work as expected.

Thanks for confirming folks. No action required on this then.