Comments (22)
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.
from register.
why just yourself only?
from register.
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.
from register.
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.
from register.
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.
from register.
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.
from register.
@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:
[email protected]
. - 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 clonetobez.dev
- Create new MX record(s) from
tobez.dev
clone totobez.is-a.dev
- I can now use
[email protected]
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.
from register.
I'm not really sure what you mean, we already support MX records if that's what you're saying?
from register.
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?
from register.
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.
from register.
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.
from register.
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.
from register.
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.
from register.
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.
from register.
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 [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.
from register.
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.
from register.
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.
from register.
This issue has been marked as stale due to inactivity and will be closed. Comment anything on this issue to prevent it
from register.
from register.
@wdhdev, as discussed, we can close this issue and open new ones with the relevant topics.
from register.
@wdhdev Can you allow me to use NS Record with Cloudflare DNS?
I registered the domain flux.is-a.dev to use Google Workspace for Essentials. I only use them for work purposes.
Thank you!
from register.
Our DNS provider does not support NS records unfortunately.
from register.
Related Issues (20)
- hi one question HOT 2
- Your connection is not private HOT 4
- Support HOT 5
- Support HOT 2
- https://manage.is-a.dev/ is redirecting to https://github.com/is-a-dev/register HOT 3
- What bug did you encounter? HOT 4
- Dashboard HOT 2
- Support HOT 2
- Looking to add new records [Support] HOT 2
- Support HOT 4
- Support HOT 1
- Moving to another DNS provider HOT 37
- Support HOT 6
- Redirecting Cloudflare Pages to my sub-domain HOT 1
- Send and Receive emails HOT 1
- I'm having problems configuring custom domains. HOT 1
- Font issue with `logo.svg` HOT 3
- What bug did you encounter? HOT 1
- Support HOT 4
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from register.