g0v-network/domains

To manage domains and subdomain DNS records for g0v-related domains (and friends)

domains's Issues

Add comprehensive docs for managing records

• record types
• diff between CNAME and ALIAS
• adding a redirect
• adding a subdomain
• adding a new domain
• explain email forwarding

Document URLFWD record type

re-ticketed from: #52

This isn't well-documented in OctoDNS, but there's an redirect pseudo-type (not a real DNS record type) specifically for cloudflare. We should mention that there are only 3 rules available for free. And that redirecting "www" as well will consume a rule.

Code:
https://github.com/octodns/octodns-cloudflare/blob/dcb228e38fbc20e680a6eefa51068eebac201de5/octodns_cloudflare/__init__.py#L343-L354

Add a check for whether our Cloudflare API token has edit permissions on a domain

Re-ticketed from #11

Just a sanity check before merge, to ensure that someone has already updated the cloudflare token to be able to work with the new domain.

Improve useability of HOWTO examples

Right now, in the HOWTO.md doc, we have some expandable config examples:
https://github.com/g0v-network/domains/blob/main/docs/HOWTO.md#examples

Right now, these look like this (using the diff formatter):

It's nice, because one diff can show changes in multiple files in the repo.

But as you can see in the above screenshot, highlighting also includes the + and - context lines.

It would be nice if there was a quicker, easier way to create a new PR. This could involve one or both of:

1. Creating a hyperlink that initiates a stub PR and scaffolds out a new file, like Hypha does in the right-hand column of their meeting note directory.

2. Use GitHub flavoured markdown to make the diffs more selectable using GitHub's permalink embed style. This is commonly used in pull requests and issues, but also works in any markdown docs within the repo. Example: https://github.com/patcon/test-github-markdown/

   domains/c4nada.ca.domain/c4nada.ca.yaml

   Lines 1 to 10 in 1601c05

   	---
   	'':
   	- type: TXT
   	values:
   	# Who has admin for this domain
   	- admin=patcon
   	# Used for 301 redirect service below
   	- 301 https://g0v.tw/
   	- type: ALIAS
   	value: 301.ronny.tw.

cc: Sam @therealitycorp

Link the g0v domain guidelines

https://docs.google.com/document/d/1g4unx-__fvCc6tPLeniPd_jb5EoIDALXOYkROWyVaTo/edit#

• add our g0v domains to doc
• link guidelines from readme #10
• link translated guidelines via google translate #10
  • requested publishing gdoc as HTML
• open convo about hosting in git?

Do a real dry-run and output errors in PR checks if fails

Re-ticketed from #14

Example: surpassing thresholds as above.

Add metadata linting in PR checks

Not for checking the whole config file, but just checking format of our metadata key, which is being used to keep track of:

1. the repository the code comes from that's using the subdomain, and
2. the maintainer(s) responsible for whatever lives at the subdomain

Could also use the linter to check for has admin control of the domain. I'm currently storing this in a TXT entry at the root level of each domain, as admin=foo.

https://github.com/23andMe/Yamale
https://github.com/nrkno/yaml-schema-validator-github-action

Show dry-run deploy plan as comment in PRs

Just realized this was a feature of the github action. Neat!

https://github.com/solvaholic/octodns-sync#outputs

Add a workflow to leave comment in PR on successful update

Right now, the "test" comment shows what the change will be. But in order to confirm that the merged PR successfull updates the DNS, someone needs to know to hop into the "Actions" tab of the repo:

• merged PR (without confirmation): #34
• Action listing to see results of merge: https://github.com/g0v-network/domains/actions/workflows/domain-sync.yml

This would be better if there was a hint after merge. A simplest possible MVP is to just leave a comment with a link to the Actions listing page after merge: https://github.com/g0v-network/domains/actions/workflows/domain-sync.yml

Add README link to a PR showing how repo works

Specifically, this is the clearest one: #11

Create issue template for adding a new domain

Re-ticketed from #11

GitHub issue template docs: https://docs.github.com/en/communities/using-templates-to-encourage-useful-issues-and-pull-requests/configuring-issue-templates-for-your-repository

This would make it a bit more clear. Essentially copying from docs/HOWTO.md

Fix continuous integration to work with unreleased octodns version

Related: solvaholic/octodns-sync#50

plan and sync no longer works. going to wait a few days to decide the best path forward, but for now will put a warning in README.

Create dynamic landing page to support invitations to "fork" any gov page (wildcard DNS)

Pretend that I want to quickly suggest to someone that they could "fork" https://competitionbureau.gc.ca/ or https://space.canada.ca to a g0v domain managed via this repo.

I could tweet them:

• a link to a g0v.tw explainer website (to explain the movement), and
• maybe the docs to this repo (to explain how it works), and then maybe also
• the real website (e.g., competitionbureau.gc.ca) and
• the non-existent proposed one (e.g., competitionbureau.g0v.ca).

But all of that is confusing and hard to fit in a tweet.

It would maybe be neat if I could instead just link the person to any not-yet-created g0v subdomain http://competitionbureau.g0v.ca, and have a simple splash page explain all of this :)

Proposal

To do this, could set up a small app to sit behind a wildcard DNS record, and "catch" any subdomains that haven't had a record specifically created. In theory, this could walk people through all of:

• what is the g0v movement and where did it start?
• what does "fork the government" mean here?
• how do they request use of this subdomain via this repo?
  • since we can pull the domain name (competitionbureau.g0v.ca) out of the browser url, we could even point them directly to creating the file on GitHub, e.g., click here for example. helper app.

Thoughts? Could this be helpful for other g0v nobodies?

Ensure this repo works well on windows machines

Re-ticketed from @ThenWho hitting windows speedbump

This can be fixed like so: octodns/octodns#665 (comment)

Document use of 301.ronny.tw redirect app

Re-ticketed from ronnywang/301-service#2 (comment)

Start managing domain: newspeak.link

Hey @systemantix @clementbriens @edsaperia, going to stub out what it would take to manage newspeak.link via this repo, in case you're open to it. Worst case scenario, this was a good chance to better-document the process 🙂

Steps of Process

Full documentartion of steps [in theory] are detailed here: https://github.com/g0v-network/domains/blob/main/docs/HOWTO.md#domains

(Pull requests with doc improvements very welcome.)

Role Legend
👒 g0v-network/domains repo maintainer must do this, aka @patcon
💪 PR submitter (or anyone) can do this, but likely either you or me
👑 domain owner must do this, aka clement

• 👒 add newspeak.link domain to Cloudflare account (status will be "pending transfer") [screenshot]
• 👒 import existing DNS records into pending Cloudflare domain
• 👒 enable management of pending domain under the Cloudflare API key
• 💪 create a minimal config file at newspeak.link.domain/newspeak.link.yaml, [see branch]
• 💪 transfer any existing DNS records into config file(s), in this case just newspeak.link.domain/newspeak.link.yaml, [see branch]
• 💪 add entry for newspeak.link to config.yaml [see branch]
• 💪 create a PR with the above config changes (#42)
  • 🚧 If Cloudflare preparation has already been done, an automated comment from CI will do a dry-run and show any differences between YAML config files and the "live" DNS records
• 👒 if looks good, merge the PR
• 👑 change DNS nameservers (on Tucows?) to point to Cloudflare nameservers:

  clyde.ns.cloudflare.com
  tina.ns.cloudflare.com
  

• 💪 confirm nameservers are switched by check NS records: host -t ns newspeak.link
• 👒 give push access on g0v-network/domains to newspeak.link domain owner (though future expectation is to work via PRs like this)
• 💪 document in clementbriens/newspeak-shortlink how the domain is managed.

Try merging multiple DNS node levels into one file

I am curious whether the config files for both of these could be merged into something like ALL.talent.c4nada.ca.yaml:

• talent.c4nada.ca.yaml
• go.talent.c4nada.ca.yaml

https://github.com/g0v-network/domains/tree/main/c4nada.ca.domain

This would allow all the config to exist at one url, accessible at some shortlink like https://go.talent.c4nada.ca/dns

Also, ownership/maintainership metadata could be assumed as encompassing all child DNS records. (instead of repeating for each sub-node)

Just need to test it out.

Ensure test workflow runs against merge commit, not HEAD of feature branch

Re-ticketed from: #33 (comment)

It seems that the test workflow is being run against the feature branch rather than against the merge commit of feature+mainline.