Misc changes to the domain name spec

Post Reply
indolering
Posts: 801
Joined: Sun Aug 18, 2013 8:26 pm
os: mac

Misc changes to the domain name spec

Post by indolering »

TL;DR:
  • We should allow for a DNS record pass-through so we don't have to arbitrarily require stupid things in our spec.
  • Let's try to be more explicit, maybe having "sub" for sub-domains.
  • Let's cut translate and similar crappy abstractions from BIND.
  • What about a prefix for custom attributes, like 'data-' in HTML5? $ seems like the safest and least verbose choice.
Jeremy/biolizard has noted the need to start thinking about a 3.0 revision to clarify when TLS is required. I would like to throw out some ideas as well because, well, I've read the spec and determined I'm an idiot. However, a good spec should be understandable by idiots so as to not screw them up and I think we could simplify things a bit.

I would like to float the idea that we rename "alias" to "sub" for subdomain (since that is what 99% of people think of it as) and axe translate all-together. I've got another post about what we should replace translate with (because in that post I am not just guessing wildly as to how feasible my proposal is ツ)

This would lead us with map, which I find this confusing and visually unintuitive. I'm going to just give you a blow-by-blow of what was going through my head as I read the MAP definition:
"map" Object is an associative array mapping sub-domains to their configurations. Configuration format is the the same as the value field itself, making moving, copying and importing domains easier.
Ahh, that sounds good! I get an associative array and yeah, moving, copying and importing domains sounds simply enough.
There are two special sub-domain specifiers, "" and "*", which are respectively the #Domain references and the wildcard record. Wildcard matches all non-existent sub-domain names in the current context.
Okay, I get wildcard but what's a Domain reference?
Domain references

service, alias and translate entries accept references to other domains.

To reference domains in the current context, enter the referenced name as-is, or in the case of inner sub-domains, insert dots (.) between names.
Examples

<tt>"www"</tt>
<tt>"ftp.eu"</tt>

An empty String ("") signifies the currently configured domain. In the below example, http://www.us. is an alias for us. (and not itself).

{
"map": {
"us": {
"map": { "www": { "alias": "" } }
}
}
}

To reference absolute domain names, add a dot (.) to the end of the String to signify the root domain.
The "us" in this example could be referring to a sub-domian? But aren't those handle by alias? Oh, but look, it's using alias as well... Just looking at it, it seems like www is being sent to null. And why do I need to signify a root domain with a . ?

I really think the "" should be replaced with something a little more explicit or somehow made obvious that it's referring to the name itself and not another domain. Futhermore, the distinction between alias and map appears to be just so we can explicitly support CNAME.

I really don't have a firm grasp on DNS's overall architecture but this is cruft makes the spec hard to read. If we want to support full BIND compatibility, why don't we just add a BIND field which just passes whatever is in that field as the BIND record?

We should leave any translation details (such as periods at the end of FQDN) to NamecoinToBIND and leave that stuff out of the spec as much as possible.

Finally, it seems like *every* spec eventually adopts a special quantifier for custom fields. Without it, people just make their own custom fields but without any special signifiers and this leads to fragmentation. However, an official signifier allows for experimentation and eventual adoption without breakage.

HTML 5 (finally) enabled this formally using the 'data-' for attributes on HTML tags. Dashes are allowed in JSON but they are not allowed as variables in Javascript and many other languages. _ and $ can be use for variable names in Javascript but _ is dangerous as it is used by many programming languages for meta functions (and it isn't allowed in CouchDB so it would make my life a PITA ;-) ) HOWEVER $ signifies special variables everywhere...

Anyway, sorry for the stream of consciousness post. I'm interested in what everyone else thinks.
DNS is much more than a key->value datastore.

indolering
Posts: 801
Joined: Sun Aug 18, 2013 8:26 pm
os: mac

Re: Misc changes to the domain name spec

Post by indolering »

Oh, and what about writing the spec using YAML? We should still use JSON internally, but it would make things prettier (I think)
DNS is much more than a key->value datastore.

Post Reply