Author Topic: DRAFT: Domain Specification  (Read 4349 times)

0 Members and 1 Guest are viewing this topic.

Offline mdw

  • Jr. Member
  • **
  • Posts: 28
    • View Profile
Hi all,

I'm working on getting the DNS GUI in place. Here's a working draft of the record editor—

https://danielbrockman.se/2014/bts-dns-editor/1/

Right now I'm focusing on getting the basic structure right, and there's quite a bit of surface polishing to be done still, but feel free to comment, especially if you see anything that doesn't seem to make sense logically.

(Subdomain mappings will be handled outside of this UI in a way that basically puts the root domain plus all subdomains next to each other in a flat list.)

 +5%
"A good friend will always stab you in the front." - Oscar Wilde

Offline Derrick

  • Newbie
  • *
  • Posts: 6
    • View Profile
https://danielbrockman.se/2014/bts-dns-editor/1/
Awesome. looks great. Thanks Daniel!

I do plan to remove TTL from "service" based on xeroc's suggestion.  I'll update the OP now.

Are there any more comments on the proposal? I'm ready to update the wiki.
« Last Edit: August 22, 2014, 01:03:46 am by Derrick »

Offline xeroc

  • Board Moderator
  • Hero Member
  • *****
  • Posts: 12922
  • ChainSquad GmbH
    • View Profile
    • ChainSquad GmbH
  • BitShares: xeroc
  • GitHub: xeroc
+5% . I likeit ... a litle more css and bootstrap and it will shine ...

I see you are from sweden ... I currently am too .. southern part .. close to malmö .. want to meet in person? Just for the fun and some coffee?

Offline dbrock

  • Newbie
  • *
  • Posts: 8
    • View Profile
Hi all,

I'm working on getting the DNS GUI in place. Here's a working draft of the record editor—

https://danielbrockman.se/2014/bts-dns-editor/1/

Right now I'm focusing on getting the basic structure right, and there's quite a bit of surface polishing to be done still, but feel free to comment, especially if you see anything that doesn't seem to make sense logically.

(Subdomain mappings will be handled outside of this UI in a way that basically puts the root domain plus all subdomains next to each other in a flat list.)

Thanks,
Daniel

Offline xeroc

  • Board Moderator
  • Hero Member
  • *****
  • Posts: 12922
  • ChainSquad GmbH
    • View Profile
    • ChainSquad GmbH
  • BitShares: xeroc
  • GitHub: xeroc
+5%

you guys are sticking lots of brain power into this .. outcome will be fabulous

Offline Derrick

  • Newbie
  • *
  • Posts: 6
    • View Profile
looks familiar ... I think namecoin has some similar rules in their id namespace .. afair
Indeed. The intent is to keep it mostly compatible with the dot-bit specification.

Is there a place where it differs?
The major difference at this point is the omission of some fields which were either redundant, or not commonly used (if at all), or have lacked any implementation.

A couple fields which are too specific to a current technology have been generalized, such as "email" becoming "contact", which can contain an email address, but could also be a twitter handle, or a keyhotee id. The "tor" value is omitted because it is redundant to the alias field. The client can determine for itself how to handle Tor sites when a .onion alias is present.

Also why no TLS, or some way to publish a "fingerprint" or pubkey?

Some form of registration of encryption fingerprints is certainly desirable, however given a lack of client implementations I left it out.
The "tls" value for specifying certificates fingerprints per protocol port is functional, but it may not always compatible with multiple servers as are allowed by the ip fields for example.
There might be a way to make this field more generic, maybe a certificate fingerprint list for each port would work.
 I'd love to see more discussion on this.

do we really need the Time-To-Life?
Good point. I expect that there will need to be some form of default TTL for dns-bridges. Clients such as an email server may find a TTL value useful but it doesn't seem necessary to specify a separate TTL value for services.

You never know when it might be advantageous to use common software tools that can interoperate.
Yes! The easier it is for current developers to adopt any current software to support BDNS the better.
« Last Edit: August 15, 2014, 04:41:29 pm by Derrick »

Offline xeroc

  • Board Moderator
  • Hero Member
  • *****
  • Posts: 12922
  • ChainSquad GmbH
    • View Profile
    • ChainSquad GmbH
  • BitShares: xeroc
  • GitHub: xeroc
Is there a place where it differs? Also why no TLS, or some way to publish a "fingerprint" or pubkey?
Thats a very good idea ..

also: do we really need the Time-To-Life? I asume the resolver is a client in the P2P network and updates his database on time the transaction arives ..

Offline mdw

  • Jr. Member
  • **
  • Posts: 28
    • View Profile
Just scrolling through looking, it DOES look like a proper subset of Namecoin specification for d/ namespace

Not intended as criticism! Don't get me wrong, I think unless there's a compelling reason to vary from conventions it's better not to. You never know when it might be advantageous to use common software tools that can interoperate.

Is there a place where it differs? Also why no TLS, or some way to publish a "fingerprint" or pubkey?

« Last Edit: August 15, 2014, 01:02:08 pm by mdw »
"A good friend will always stab you in the front." - Oscar Wilde

Offline xeroc

  • Board Moderator
  • Hero Member
  • *****
  • Posts: 12922
  • ChainSquad GmbH
    • View Profile
    • ChainSquad GmbH
  • BitShares: xeroc
  • GitHub: xeroc
looks familiar ... I think namecoin has some similar rules in their id namespace .. afair

Offline Derrick

  • Newbie
  • *
  • Posts: 6
    • View Profile
Domain Configuration Values

BDNS domains are configured using json syntax.

A simple and functional domain configuration value to point your .p2p domain to a server looks like this:
Code: [Select]
{ "ip": "123.45.6.7" }
or with wildcard subdomains all pointing to the same IP address
Code: [Select]
{ "ip": "123.45.6.7", "map": { "*": "@"} }
There are other fields in this specification for more advanced needs, and more complex examples are shown at the end of this document.


ip

DNS Equivalent: A
Type: IPv4 Single or IPv4 Array
ipv4 address(es) for the domain

examples
Code: [Select]
"ip"  : "192.168.1.1"
Code: [Select]
"ip": ["192.168.1.1", "192.168.7.1"]

ip6

DNS Equivalent: AAAA
Type: IPv6 Single or IPv6 Array
ipv6 address(es) for the domain

examples

Code: [Select]
"ip6": "2001:4860:0:1001::68"
Code: [Select]
"ip6": ["2001:4860:0:1001::68"]

ns

DNS Equivalent: NS
Type: Host Single or Host Array
Assigns (a) nameserver(s) to handle address and record resolution for the domain.
The "ns" setting overrides all other settings unless the domain is modified modified by an import value.usage

examples

Code: [Select]
"ns": "ns.myserver.net"
Code: [Select]
"ns": ["ns.myserver.net", "192.168.3.4"]

map

Defines subdomains as name/value pairs, where the name is the subdomain and the value is a valid Domain Configuration Value.
The Domain Configuration spec is extended in a map to allow for the special name "*", and the reference values "@" and "".
The special name "*" refers to any otherwise undeclared name, i.e., a wildcard subdomain.
The special value "@" refers to the root domain, and "" refers to the parent of the subdomain.

examples
Code: [Select]
"map": {
"www": { "alias" : "@" },
"com": { "alias" : "www.example.com." },
"ftp": { "import": "example-ftp" },
"mx":  { "ip": "123.45.6.7" }
}

Using "*" and "@". Any subdomain of <domain> will be resolved as the root <domain>. That is, <anything>.<domain> -> <domain>.
Code: [Select]
"map": {
"*": { "alias" : "@" }
}


alias

DNS Equivalent: CNAME
Type: Host Single
Points the domain to another configured domain, using either an absolute reference, or a relative reference in a map.

examples
Alias references a classic domain name:
Code: [Select]
"alias": "www.example.net." Alias references another .p2p domain name:
Code: [Select]
"alias": "www.example.p2p." Alias references a TOR hidden site:
Code: [Select]
"alias": "idnxcnkne4qt76tg.onion." Alias in a map, "www.<domain>" aliases the root domain:
Code: [Select]
"map": {
"www": { "alias" : "@" }
}


Alias in a nested map, "www.sub.<domain>" aliases its parent domain "sub.", "ftp.sub.<domain>" references the absolute domain "ftp.example.com" in the classic DNS system:
Code: [Select]
"map": {
"sub": {
"map": {
"www": { "alias" : "" },
"ftp": { "alias" : "ftp.example.com." }
},
"*": { "alias" : "@" }
}


translate

DNS Equivalent: DNAME
Type: Host Single
A Delegation Name as defined in RFC 6672. Aliases the subtree of one domain to another.

example
Code: [Select]
"translate": "otherhost.bit."

service

DNS Equivalent: SRV, MX
Type: Array of service records
Service records based on RFC 2782. These can specify smtp, pop, imap, or other services for the domain.
The format for each service record is:
Code: [Select]
["service", "protocol", priority, port, "host"]
  • service: the symbolic name of the desired service.
  • proto: the transport protocol of the desired service; this is usually either TCP or UDP.
  • priority: the priority of the target host, lower value means more preferred.
  • port: the TCP or UDP port on which the service is to be found.
  • host: the canonical hostname of the machine providing the service, ending in a dot.

example
Code: [Select]
    "service": [
["smtp", "tcp", 10, 25, "mail.host.p2p."],
["smtp", "tcp", 20, 25, "mail.host.net."],
["pop", "tcp", 0, 110, "mail.host.p2p."]
["imap", "tcp", 0, 143, "imap.host.p2p."]
]


contact

DNS Equivalent: SOA, RP
Type: Single or Array of free-text
Declares a contact for the domain, could be email, KeyID, etc...

examples
Code: [Select]
"contact": "hostmaster@example.net"
Code: [Select]
"contact": ["hostmaster@example.p2p","keyhotee/5oNF5EJXDiMpHASnxxvnzn4GSmxVuEgZ1r25QaXS3MfXEJZgDk"]

loc

DNS Equivalent: LOC
Type: Single RFC-1876 location
Geolocation. Format is described in RFC 1876

example

This example represents 52°22'23?N 4°53'32?E
Code: [Select]
"loc": "52 22 23.000 N 4 53 32.000 E -2.00m 0.00m 10000m 10m"

import

Type: Single or Array of BDNS names
Merges the domain with the data from another BDNS domain. Imports overwrite local values.
This is useful because of the 1024 character limitation on domain configuration values. Service records for example can get long, and storing some data elsewhere and importing it allows a complex domain to fit within the data limit, as well as allowing sharing of configuration data between domains.
Recursion is possible, and should be checked for.

example
Code: [Select]
"import": "sample-services"

info

Type: free-text
A place for providing additional notes about the domain

examples


Code: [Select]
"info": "RESERVED"
Code: [Select]
"info": "buyme@example.bit"

Full examples

Code: [Select]
{
    "ip"      : "192.168.1.1",
    "ip6"     : "2001:4860:0:1001::68",
    "contact"   : "hostmaster@example.bit",
    "info"    : "Example & Sons Co.",
    "service" : [ ["smtp", "tcp", 10, 0, 25, "mail"] ],
    "map":
    {
        "www" : { "alias": "" },
        "ftp" : { "ip": ["10.2.3.4", "10.4.3.2"] },
        "mail": { "ns": ["ns1.host.net", "ns12.host.net"] }
    }
}
Code: [Select]
{
    "ip" : "8.8.8.8",
    "map":
    {
        "us":
        {
            "ip" : "1.2.3.4",
            "map": { "www": { "alias": "" } }
        },
        "eu":
        {
            "map": { "www": { "alias": "us.@" } }
        },
        "*": { "alias": "" }
    }
}


Attribution

Concepts and examples in this specification are based in whole or in part on the Namecoin Domain Name Specification
« Last Edit: August 22, 2014, 01:06:31 am by Derrick »