I think we should adopt a pull request template that explains how they have to provide a plan and use a consistent title format like:

Create fionah.dino.icu

I'd be happy to work on this.

Thoughts?

From Cloudflare:

A DNS pointer record (PTR for short) provides the domain name associated with an IP address. A DNS PTR record is exactly the opposite of the 'A' record, which provides the IP address associated with a domain name.

DNS PTR records are used in reverse DNS lookups.

I believe the ability to enable this on a per-subdomain basis would be best, if possible.

Initially the subdomain tist.hackclub.com got deployed and was working fine. with cname : HackClub-TIST.github.io

Later we got the G suite for tist.hackclub.com , in order to configure g suite, the mx record was added and the dry run was successful and merged by @lachlanjc but deploy isn’t successful

error: “requests.exceptions.HTTPError: 400 Client Error: Bad Request for url:https://api.dnsimple.com/v2/***/zones/hackclub.com/records”

we found out that when we add a new records are getting deployed to DNS but when we delete/change a record, the deploy fails.

@hackclub/core We are stuck now and could really use your help.

I am attaching the required stuff we need below.

tist:
- ttl: 1
  type: A
  value: 104.198.14.52
- ttl: 3600
  type: TXT
  value: 
  - v=spf1 include:_spf.google.com ~all
  - google-site-verification=lwxLcm8yYFFYkHdZxXUoO00wJ48SCNPRn6ZdAhKoHjA
- ttl: 3600
  type: MX
  values:
  - exchange: aspmx.l.google.com.
    preference: 1
  - exchange: alt1.aspmx.l.google.com.
    preference: 5
  - exchange: alt2.aspmx.l.google.com.
    preference: 5
  - exchange: alt3.aspmx.l.google.com.
    preference: 10
  - exchange: alt4.aspmx.l.google.com.
    preference: 10

Ok, so we had #278. This hasn't worked for a while. You can see the commits. The OctoDNS says the dry run's good but then deploy never is. Matthew & I are very much stuck.

Currently we have added this record:

summer:
- ttl: 1
  type: A
  value: 104.198.14.52
- ttl: 3600
  type: TXT
  value: v=spf1 include:_spf.google.com ~all
- ttl: 3600
  type: MX
  values:
  - exchange: aspmx.l.google.com.
    preference: 1
  - exchange: alt1.aspmx.l.google.com.
    preference: 5
  - exchange: alt2.aspmx.l.google.com.
    preference: 5
  - exchange: alt3.aspmx.l.google.com.
    preference: 10
  - exchange: alt4.aspmx.l.google.com.
    preference: 10

Which is the same thing as this pre-existing record:

alpharetta:
- ttl: 1
  type: A
  value: 104.248.78.24
- ttl: 3600
  type: TXT
  value: v=spf1 include:_spf.google.com ~all
- ttl: 3600
  type: MX
  values:
  - exchange: aspmx.l.google.com.
    preference: 1
  - exchange: alt1.aspmx.l.google.com.
    preference: 5
  - exchange: alt2.aspmx.l.google.com.
    preference: 5
  - exchange: alt3.aspmx.l.google.com.
    preference: 10
  - exchange: alt4.aspmx.l.google.com.
    preference: 10

I'm not sure why it's failing to deploy but we've tried a lot of things. See #279 #280 #281 #282 & #283 lol

TXT records for hackclub.com are missing. Out of the 16 TXT records on hackclub.com (root), only 12 are visible:

❯ dig -t TXT hackclub.com

; <<>> DiG 9.10.6 <<>> -t TXT hackclub.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 26691
;; flags: qr rd ra; QUERY: 1, ANSWER: 12, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;hackclub.com.			IN	TXT

;; ANSWER SECTION:
hackclub.com.		5	IN	TXT	"ALIAS for hackclub.com.herokudns.com"
hackclub.com.		5	IN	TXT	"TAILSCALE=xJzhP4gW3Mb3W6fpcMh7"
hackclub.com.		5	IN	TXT	"google-site-verification=pheoxaglA5iew_VN0RUE-eWf6lL9FlqC0vROqUGlhiA"
hackclub.com.		5	IN	TXT	"2610E0D36E"
hackclub.com.		5	IN	TXT	"google-site-verification=g4D9KzvB2JVf_HCcslryBI05oOxVdee9sspmd9pBAaU"
hackclub.com.		5	IN	TXT	"google-site-verification=2979FUSGCz-WxnW6EukLx_N_Ay31YOyGBnvUSbwHcXc"
hackclub.com.		5	IN	TXT	"AA418B02F6"
hackclub.com.		5	IN	TXT	"segment-site-verification=ED0mCO5yaFBc40hEvipDG5OiON3Nemh2"
hackclub.com.		5	IN	TXT	"61220A24D7"
hackclub.com.		5	IN	TXT	"google-site-verification=U8tZZVtnG2hU2CIde1FeMzGJM7d9yYUfuCKYwWVYeGo"
hackclub.com.		5	IN	TXT	"google-site-verification=haP-NAN6fjhxiSxwB7HeLmeHnUI7MsXARShhPBKSn6A"
hackclub.com.		5	IN	TXT	"google-site-verification=w6ZIJvwwXDKPKLvV_RZbxLF6vb0xfJoRidbw5LeiUcE"

;; Query time: 291 msec
;; SERVER: 172.17.61.30#53(172.17.61.30)
;; WHEN: Fri Jan 13 11:47:59 PST 2023
;; MSG SIZE  rcvd: 759

This is causing issues with Hack Club Bank's Stripe emails since stripe-verification=5bdd0e2475b12744bfe1f778ac419f917800d476fd498ae2682ecd161d162c64 is missing.

Recently, a change landed that delegated hackclub.app to our nameserver via an NS record. It appears that the NS record either didn't propagate to DNSimple, or DNSimple isn't serving it correctly.

Evidence:

When digging hackclub.app, it should return the IP address with an authoritative of ns.hackclub.app. Rather, it's returning nil, with an authoritative of ns1.dnsimple.com. This shows that the NS record didn't take effect and delegate to our nameserver.

I tried to fix this by adding the same CNAME record in #927, but you can't have a CNAME on the root domain. I don't know enough about how DNS works to know the way to do it.

@reesericci landed a change that seemed fine, but during deployment it failed due to reasons unknown. This doesn't seem to be an isolated incident based on what I've seen (and overheard) in the recent past.

Hey!

We have been building a website that would need a backend at this point. We cannot use netlify functions due to their limitations and do not have a domain to use for the backend.
If we were to use our VPS's IP directly, it would give us an issue with SSL, and then making calls on HTTP from HTTPS would give other issues.

I'm opening this issue to ask whether our club can have 1 more subdomain, something like psn-server.
It would be really great if we could!

Ideally, when a PR lands but fails to deploy successfully, the PR should be auto-updated with a comment notifying the author that their PR didn't successfully ship to production. Example of this having happened (deploy failure: link)

Problem

For nest, we stood up our own authoritative DNS server at 188.40.159.194 (ns.hackclub.app).

We would like to migrate hackclub.app to using this server instead of using hackclub/dns.

However we'd also like to continue using the Hack Club DNSimple as a secondary DNS server:

Configure your zones with Secondary DNS having DNSimple acting as a secondary DNS. Zone transfers are done via AXFR with a primary server of your choice.

What needs to be done

Why this isn't a PR

This isn't a PR because it requires changes on the registrar side.

An alternative could be to use NS records, but that creates another point of failure and is less efficient than just delegating directly.

An NS record would mean that a client would have to ask DNSimple just to get pointed to our DNS server - an unnecessary hoop.

I noticed that this still uses master and not main. Guessing this is an oversight since other hack club repos use main - regardless of the name choice it would probably be best to keep the primary branch name consistent across Hack Club repos to make it easier for maintainers / contributors.

We need an account id and API token for the DNSimple so that we can manage a wildcard certificate for Nest

Setting a default TTL of 1 second does not allow for proper caching and can put strain on the DNS network. The "best practice" is between 12 and 24 hours, but if that's too long it might make sense to follow Cloudflare, which sets their "Auto" TTL to 300 seconds (or 5 minutes)1.

In general, it's good practice to have a slightly longer TTL to enable faster queries2 and better redundancy.

#227 (comment)

DNSSEC does not seem to be configured for our domains

As noticed in #1094, a CNAME record that has a pathname in it (in this case /pizza) still passes the OctoDNS tests but when deployed to production predictably fails.

Related to #977

graph TD
    id1{Open a pull request}-->id2[Pull request is reviewed]
    id2-->id3[Changes are made]
    id3-->id2
    id2-->merged[Pull request is merged]-->deployed[Changes are deployed!]

    style deployed fill:green

https://github.blog/2022-02-14-include-diagrams-markdown-files-mermaid

the current github action does not validate the yaml file, and octodns just silently eats errors, giving incorrect output
adding a yaml validator to the actions, required for a pr to merge, would reduce this impact

example:
#886