~bitfehler/names.sr.ht-discuss

6 5

Summary of design goals and priorities

Details
Message ID
<CHVUXZKXJJ4C.NB3VSS2CBXE1@megumin>
DKIM signature
pass
Download raw message
Hi! I am pleased to see the community picking this thread up.

The vision I have in mind for names.sr.ht is essentially to offer name
registration as an eNom reseller, as well as DNS hosting (with or
without a corresponding registration). The DNS hosting bit is intended
to be built such that you push zone files to a git.sr.ht repository to
update them - no crappy JavaScript-laden web interface.

I have prototyped some bits for this here:

https://git.sr.ht/~sircmpwn/names.sr.ht

It's 2 years old so take this with a very large grain of salt. I
consider this a mock-up moreso than something we can expect to develop
any further.

IMO the steps (in order) to realize this are:

1. Develop an API wrapper for the eNom API in Go
2. Design a proposed GraphQL schema
3. Regroup for review and consultation

I imagine that from here the GraphQL schema will be fleshed out with an
implementation, then a frontend can be written on top of it, and then
we'll figure out all of the fussy questions like which DNS server to
use, hosting concerns, and so on, but for now I think these first three
steps are plenty to occupy the community for a while. Good luck!
Details
Message ID
<Ygp0fwVyYyMpOQtn@axminster>
In-Reply-To
<CHVUXZKXJJ4C.NB3VSS2CBXE1@megumin> (view parent)
DKIM signature
pass
Download raw message
> Hi! I am pleased to see the community picking this thread up.
> 
> The vision I have in mind for names.sr.ht is essentially to offer name
> registration as an eNom reseller, as well as DNS hosting (with or
> without a corresponding registration). The DNS hosting bit is intended
> to be built such that you push zone files to a git.sr.ht repository to
> update them - no crappy JavaScript-laden web interface.
Sounds good. This is a nice interface.

Basically, you have two options:

  1. Accept zone files, and hand them directly to a nameserver (e.g.
     with BIND9);
  2. Accept zone files, and reconcile them to the current state of the
     zone stored in a database (e.g. with PowerDNS).

(2) is more complex and sophisticated but it has a few advantages:

  - It avoids exposing a nameserver's zonefile parser to the public (which
    may lead to Hyrum's law issues, and maybe security issues).

  - It's probably more scalable, though this isn't necessarily a
    pressing concern yet.

  - DNSSEC, if/when it is supported, tends to be more robust; with BIND9
    and DNSSEC, the zone files have to be regenerated regularly as
    signatures expire. This is a moving part liable to break. It's
    especially annoying when this happens since you get a split view
    where DNSSEC-validating resolvers stop working for the domain and
    other resolvers don't, so the breakage is not necessarily
    immediately apparent. With e.g. PowerDNS, signatures are generated
    on the fly, and it's basically infallible.

The Go package github.com/miekg/dns has a zonefile parser so
implementing this in Go probably wouldn't be too complex. Though (1)
would probably still get something functional faster.

Anyway, just something to think about and this can come later. I'll give
the API side some thought.
Details
Message ID
<082dd499-17b3-3ba8-a812-dc477ec6a5eb@lmcm.io>
In-Reply-To
<Ygp0fwVyYyMpOQtn@axminster> (view parent)
DKIM signature
missing
Download raw message
> The vision I have in mind for names.sr.ht is essentially to offer
> name registration as an eNom reseller, as well as DNS hosting (with
> or without a corresponding registration).

1. Git-based DNS hosting sounds like the interesting, useful service. But what's the value in becoming a domain name reseller? It's not a market that particularly needs another intermediary.

2. If becoming a domain name reseller is desirable then is there any particular reason to choose eNom? There aren't really any angels in the market, but a registrar like Gandi that materially supports FOSS projects[1] (and also supports resellers and a domains API) might be more fitting.

[1]: https://www.gandi.net/en-GB/gandi-supports
Details
Message ID
<CHX1FXFJYZB3.1SKDRSB2MTNY4@cipher.host>
In-Reply-To
<CHVUXZKXJJ4C.NB3VSS2CBXE1@megumin> (view parent)
DKIM signature
fail
Download raw message
DKIM signature: fail
> The vision I have in mind for names.sr.ht is essentially to offer name
> registration as an eNom reseller, as well as DNS hosting (with or
> without a corresponding registration).

I have the same question as above, why eNom in particular? Considering
SourceHut may be moving incorporation to the EU at some point, I would
vote for a company like Gandi or, even better, ClouDNS[1].

ClouDNS in particular offers DDoS-protected anycast DNS with good uptime
and raw performance around the world, DNSSEC and white label support, an
okay API, and are incorporated in Bulgaria.

I chose them as the back-end provider to offer DNS hosting and domain
registration on my WordPress hosting business, and so far, have nothing
but good things to say about them.

> The DNS hosting bit is intended to be built such that you push zone
> files to a git.sr.ht repository to update them - no crappy
> JavaScript-laden web interface.

Whoever is working on this may want to look into LuaDNS[1], probably the
oldest DNS hosting company offering Git integration.

Their documentation for the feature can be found over here[2], and an
example repository can be found here[3].

[1] https://www.cloudns.net/ 
[2] http://www.luadns.com/help.html#git-integration
[3] https://github.com/luadns/dns
Details
Message ID
<CHXBQC9YEW1A.33M946HMDERGX@taiga>
In-Reply-To
<CHX1FXFJYZB3.1SKDRSB2MTNY4@cipher.host> (view parent)
DKIM signature
fail
Download raw message
DKIM signature: fail
On Wed Feb 16, 2022 at 1:18 AM CET, James Pond wrote:
> I have the same question as above, why eNom in particular? Considering
> SourceHut may be moving incorporation to the EU at some point, I would
> vote for a company like Gandi or, even better, ClouDNS[1].

eNom is reseller-first and I prefer that approach.
Details
Message ID
<7f2f8c6f-94c6-24a7-e5a3-3c3486ae2501@bitfehler.net>
In-Reply-To
<CHVUXZKXJJ4C.NB3VSS2CBXE1@megumin> (view parent)
DKIM signature
pass
Download raw message
On 2/14/22 15:59, Drew DeVault wrote:
> The DNS hosting bit is intended
> to be built such that you push zone files to a git.sr.ht repository to
> update them - no crappy JavaScript-laden web interface.

Should this be the _only_ interface? Or also something GraphQL-based to 
modify individual records?
Details
Message ID
<CKQKU7MFK9L7.2ENARU9BCOPHW@taiga>
In-Reply-To
<7f2f8c6f-94c6-24a7-e5a3-3c3486ae2501@bitfehler.net> (view parent)
DKIM signature
pass
Download raw message
On Wed Jun 15, 2022 at 10:45 AM CEST, Conrad Hoffmann wrote:
> On 2/14/22 15:59, Drew DeVault wrote:
> > The DNS hosting bit is intended
> > to be built such that you push zone files to a git.sr.ht repository to
> > update them - no crappy JavaScript-laden web interface.
>
> Should this be the _only_ interface? Or also something GraphQL-based to 
> modify individual records?

This is the _only_ interface for DNS updates, yes, but GraphQL used for
other concerns.
Reply to thread Export thread (mbox)