-
-
Notifications
You must be signed in to change notification settings - Fork 7.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Support for NS Records #13995
Comments
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. |
why just yourself only? |
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. |
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. |
No, those were email security records such as DKIM, not NS records.
If you can provide a valid use case and cause for needing NS records, most likely yes, assuming this is approved by @phenax.
Feel free to drop your ideas here, I'd love to hear feedback from the community on this. |
@wdhdev 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):
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. |
I'm not really sure what you mean, we already support MX records if that's what you're saying? |
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.
As I mentioned, why don't we manage these maintainer sub-domains here transparently? Is there a specific integration being problematic? |
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.
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. |
as Akshay mentioned, the API is-a.dev is using does not support checking NS records.
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. |
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.
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.
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 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. |
That is true.
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.
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 [email protected] 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. |
Isn't DKIM just a TXT record?
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.
That's exactly what we're doing right now. There's no such thing as a 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. |
Yes, but the actual subdomain name isn't allowed because it contains invalid characters.
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. |
This issue has been marked as stale due to inactivity and will be closed. Comment anything on this issue to prevent it |
@wdhdev, as discussed, we can close this issue and open new ones with the relevant topics. |
@wdhdev Can you allow me to use NS Record with Cloudflare DNS? |
Our DNS provider does not support NS records unfortunately. |
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.
The text was updated successfully, but these errors were encountered: