Support for NS Records

[wdhdev]

I would like to request for NS records to be added to the service. Our plan for NS record use is only to delegate NS records for trusted people (e.g. maintainers). They will not be supported for the general public due to abuse risks. This would be greatly helpful, especially for maintainer domains.

Since the PSL PR was merged, Cloudflare DNS is also supported, which is incredibly useful in this case.

Any NS records being added will be reviewed by myself and will only be approved if the user has a genuine reason for the addition. Once again, only specific trusted users will be allowed to do this, most likely only maintainers.

[tobezdev]

Wasn't this also attempted in #11475?

Would also be lovely if us with professional organisations (i.e: me with @shielderbot-org and tobez.dev) could use this too. Understandably, I see there being some sort of verification for this to prevent abuse like you mentioned but this is a really good shout nonetheless.

Happy to brainstorm some potential verification ideas and/or create some prototypes if you guys wish - just give me a shout.

[MaskDuck]

why just yourself only?

[tobezdev]

Not what I said. I was using myself as an example for what I meant. I was aiming it generally at everyone with origanisations/businesses that could also see this being useful.

[MaskDuck]

Not what I said. I was using myself as an example for what I meant. I was aiming it generally at everyone with origanisations/businesses that could also see this being useful.

Sorry I haven't made it clear enough. I was trying to reply to William's comment to ask why only he can review PRs.

[wdhdev]

Sorry I haven't made it clear enough. I was trying to reply to William's comment to ask why only he can review PRs.

Only specific maintainers will be allowed to review NS records to ensure a high standard and valid reasoning. I probably should've clarified better, that most likely NS records will require 2 reviews, one by a maintainer and another by me or Phenax.

[wdhdev]

Wasn't this also attempted in #11475?

No, those were email security records such as DKIM, not NS records.

Would also be lovely if us with professional organisations (i.e: me with @shielderbot-org and tobez.dev) could use this too. Understandably, I see there being some sort of verification for this to prevent abuse like you mentioned but this is a really good shout nonetheless.

If you can provide a valid use case and cause for needing NS records, most likely yes, assuming this is approved by @phenax.

Happy to brainstorm some potential verification ideas and/or create some prototypes if you guys wish - just give me a shout.

Feel free to drop your ideas here, I'd love to hear feedback from the community on this.

[tobezdev]

@wdhdev A better scope of my ideas:

Could see this being useful for organisations, businesses and professional projects to 'clone' initial domains. Could be useful if, say, companies wanted to use a specified is-a.dev domain email address or similar. Just as an example (though this likely won't happen):

• I would like to create an email address: contact@tobez.is-a.dev.
• Create the email address on my root domain (tobez.dev) using an email forwarder (i.e: Cloudflare)
• Add an NS record at tobez.is-a.dev to clone tobez.dev
• Create new MX record(s) from tobez.dev clone to tobez.is-a.dev
• I can now use contact@tobez.is-a.dev as an email address that forwards to another inbox, handled by Cloudflare.

Obviously, this is probably a very rare use-case and would probably require some other kind of setup, but would be really nice to add to the is-a.dev service, providing it is all about providing professional-looking domains to people. I do feel as if professional looking Emails would also fit into a similar scope.

[wdhdev]

I'm not really sure what you mean, we already support MX records if that's what you're saying?

[phenax]

As discussed before in #2380, our current DNS infra doesn't support NS records. So if we need this, we'll need to have a separate discussion on scalable alternatives that we could evaluate, that support NS on subdomains.

But I am having a hard time understanding why we need NS? @wdhdev is there a very specific use-case you have in mind?

In terms of opening this up to users, the reason for the PR review process is to ensure that to the best of our abilities, we can see what is being hosted here. Which is important because we will always be tied to the terms and conditions of any DNS service we use under the hood. Of course, it won't be perfect but it's better than nothing. Allowing users to use NS, no matter how vetted they are, makes that process much more opaque and impossible to find bad actors. Right now, every DNS record hosted by our service is documented in this repo as its own json file. Which means, all information about everything hosted and any changes made is right here. When it was created/updated, who created it, how to get in touch with the user, and what it points to. From the very beginning, this was intended to be as transparent as possible which is why everything "core" to the management of dns records is in this single repo.

This would be greatly helpful, especially for maintainer domains.

As I mentioned, why don't we manage these maintainer sub-domains here transparently? Is there a specific integration being problematic?

[wdhdev]

As for the DNS infrastructure not supporting NS records, I believe we could theoretically move to Cloudflare assuming we can get increased records limits which shouldn't be too hard through their support, I would assume. We could also look into Bunny.net or something else as well. Also, the current DNS service isn't the most stable, for example, URL records not redirecting, slow DNS deployment, etc.

Use for NS records would be highly restricted, and the reason why it would be useful is for creating some records that we don't support by default, for example SRV records.

Also, since we have been added to the PSL, I do not believe in the event of abuse of NS records, only that specific subdomain would be at fault instead of the entire root domain, however abuse would be extremely unlikely as we will restrict NS record creation heavily.

To put it simply, if a domain does not explicitly require NS records with good reason, it will not be allowed to create them.

As I mentioned, why don't we manage these maintainer sub-domains here transparently? Is there a specific integration being problematic?

All maintainer subdomains will and are managed transparently unless it is explicitly not possible. For example with the former is-a.dev mail service, there were a couple records that were not able to be added for email security due to us not supporting them (TLSA, SRV records). There are no current integrations being problematic at this point in time however.

[MaskDuck]

as Akshay mentioned, the API is-a.dev is using does not support checking NS records.

I believe we could theoretically move to Cloudflare assuming we can get increased records limits which shouldn't be too hard through their support, I would assume.

this basically means we would have to transfer around 4k of DNS records and rewrite the scripts of the project as a whole, which may introduce unneeded bugs to the service. therefore I don't support the idea of moving to another platform to hold DNS records.

[wdhdev]

as Akshay mentioned, the API is-a.dev is using does not support checking NS records.

I believe we could theoretically move to Cloudflare assuming we can get increased records limits which shouldn't be too hard through their support, I would assume.

this basically means we would have to transfer around 4k of DNS records and rewrite the scripts of the project as a whole, which may introduce unneeded bugs to the service. therefore I don't support the idea of moving to another platform to hold DNS records.

For a CI rewrite, we can use DNSControl, I've found this is pretty easy to use and link with Cloudflare at least, I have personally not found any issues with it. FYI, we will not need to manually transfer and check 4k records, once we rewrite the CI, we can just run the publish records workflow and it will automatically deploy all records. However, I do understand the issues this could cause so that is something to keep in mind, however in the long run I personally believe it would be best.

[MaskDuck]

I know that we can use a script. but still, deploying 4k DNS records at a time is very risky in my opinion and we can't bear those risks - you cannot just wait for 24-48 hrs for all changes to be deployed - e.g. some people have emails here and it will be a catastrophe for them if they miss out any important emails e.g. password resets, work, etc. the 24-48 hr delay time is very long. also:

to sum up: despite all the benefits, the cons DOES outweigh the pros.

[phenax]

Regarding migration to another service, I'd say we should move that discussion to a new issue and propose potential solutions there to not polute this issue.

creating some records that we don't support by default

I feel like the use-case of is-a-dev needs to be more clear. Even though we provide a somewhat low-level interface to get sub-domains compared to something like js.org, we don't need to become a DNS provider that allows every DNS record type possible. I think it's fine to support more record types but we should add them in only if we think that's what is-a-dev should be used for. Use-case comes first.

for example SRV records

Currently we could add SRV support if we need to since upstream supports it. But referring back to the previous point, let's figure out the use-cases first if we want it open to users. But if it is just for maintainers and we're creating this boundary of users vs maintainers, it would be nice if it was validated in our checks.

this basically means we would have to transfer around 4k of DNS records and rewrite the scripts of the project as a whole

This is concerning but if we believe if there is a strong alternative that we can be sure will work long term, then I think it could be justifiable. We can do a blue-green-ish deployment to the new service with just a small downtime. Either way, let's continue this in a separate issue if we need to.

[wdhdev]

I feel like the use-case of is-a-dev needs to be more clear. Even though we provide a somewhat low-level interface to get sub-domains compared to something like js.org, we don't need to become a DNS provider that allows every DNS record type possible. I think it's fine to support more record types but we should add them in only if we think that's what is-a-dev should be used for. Use-case comes first.

That is true.

for example SRV records

Currently we could add SRV support if we need to since upstream supports it.

SRV records are commonly used for Minecraft servers, and there are a few users that would like this support. We also need DKIM support too for emails.

this basically means we would have to transfer around 4k of DNS records and rewrite the scripts of the project as a whole

This is concerning but if we believe if there is a strong alternative that we can be sure will work long term, then I think it could be justifiable. We can do a blue-green-ish deployment to the new service with just a small downtime. Either way, let's continue this in a separate issue if we need to.

Yeah, this is a separate issue. I might look into some good alternatives and open a separate issue for this.

---

I do also have a question, regarding email addresses on the root domain, where does that stand? Did you find out why it caused the DNS to break? It would be helpful to have emails such as security@is-a.dev and stuff.

---

As for URL records not being a proper DNS record, @VaibhavSys had a good idea.

We could still "support" URL records except it will just point those domains to an A or CNAME record pointing to a webserver which will redirect those domains.

[phenax]

We also need DKIM support too for emails

Isn't DKIM just a TXT record?

Did you find out why it caused the DNS to break?

Haven't looked into it yet. Let's resolve the DNS service discussion first since theres no point in debugging if we're changing the stack.

We could still "support" URL records except it will just point those domains to an A or CNAME record pointing to a webserver which will redirect those domains.

That's exactly what we're doing right now. There's no such thing as a URL dns record. Its just an A record pointing to our server that then redirects to the pointed url. So, that's not an issue.

Regarding the NS record, unless we have a use-case for it, I think we should go ahead and close this issue. We can open a separate issue for SRV if we need.

[wdhdev]

Isn't DKIM just a TXT record?

Yes, but the actual subdomain name isn't allowed because it contains invalid characters.

Regarding the NS record, unless we have a use-case for it, I think we should go ahead and close this issue.

Fair, it would probably be a bit of a hassle for now. However I do still think we should consider moving to a different DNS service for better service that does support NS, that way when we do have a proper need for NS records we can easily add support for them.

[github-actions[bot]]

This issue has been marked as stale due to inactivity and will be closed. Comment anything on this issue to prevent it

[wdhdev]

@phenax

[phenax]

@wdhdev, as discussed, we can close this issue and open new ones with the relevant topics.