Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.


Messages - Derrick

Pages: [1]
1
KeyID / Re: DRAFT: Domain Specification
« on: August 22, 2014, 01:01:54 am »
Quote from: dbrock on August 21, 2014, 10:40:39 pm
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.

2
General Discussion / Re: If you need BTSX to finish the registration, Just post your account key here
« on: August 19, 2014, 07:09:59 pm »
BTSX8A12yqQS8MhsX6iWjF4TP4yQYDdtvUSnAHFHARz4ajB6pHrdyF
Thanks!

3
KeyID / Re: DRAFT: Domain Specification
« on: August 15, 2014, 04:34:00 pm »
Quote from: xeroc on August 15, 2014, 06:49:42 am
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.

Quote from: mdw on August 15, 2014, 12:50:42 pm
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.

Quote from: mdw on August 15, 2014, 12:50:42 pm
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.

Quote from: xeroc on August 15, 2014, 01:15:45 pm
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.

Quote from: mdw on August 15, 2014, 12:50:42 pm
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.

4
KeyID / DRAFT: Domain Specification
« on: August 15, 2014, 01:51:04 am »
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

5
General Discussion / Re: Official IRC set-up
« on: May 07, 2014, 12:57:23 am »
The advantage that I see of using freenode is that most major development communities already have a presence on freenode. Additionally, freenode seems to be managed pretty well; and it seems very stable.

However having said that, I'm really not at all familiar with the other IRC servers being mentioned.

What are the advantages of using another IRC network?

6
General Discussion / Re: Official IRC set-up
« on: May 06, 2014, 03:16:11 pm »
#bitshares on freenode has been abandoned by the owner as of mid December according to freenode chanserv.

I'm willing to take and delegate responsibility for the channel as I run a couple other (completely unrelated) channels on freenode as well. According to freenode policy I need consent of the Bitshares team to take responsibility for this channel.

An OK from from bytemaster should be sufficient. Any objections?

I have also registered #bitshares-dev on freenode.

If anyone else would prefer to take this on instead please reply.

Pages: [1]

Page created in 0.023 seconds with 23 queries.