REQUEST FOR COMMENTS (literally): The d/ specification

https://www.namecoin.org/dot-bit/
hla
Posts: 46
Joined: Mon Nov 10, 2014 12:01 am
os: linux
Contact:

REQUEST FOR COMMENTS (literally): The d/ specification

Post by hla »

The draft Domain Names specification is now available: https://github.com/hlandau/ncdocs/blob/ ... n-names.md

This is a literal request for comments (not an RFC). If you have any questions, comments or issues with the specification, please post them now or forever hold your peace. ;)

Overview
The new specification sanitizes a lot of the cruft that has built up in the specification listed on the wiki. It also makes breaking changes for the cause of greater sanity and syntactic consistency. While implementations are free to support older syntaxes, this document specifies the directives which should be considered preferred for use going forward.

Note in particular that the format for SRV and TLSA records has changed substantially. import has been clarified and delegate deprecated, as import is a superset of its functionality. An experimental mechanism for the opaque insertion of otherwise unsupported DNS records has been added. DNSSEC-enabled delegation via NS and DS is, of course, supported.

Further changes may still be made, but I think this is pretty close to the finished result.

phelix
Posts: 1634
Joined: Thu Aug 18, 2011 6:59 am

Re: REQUEST FOR COMMENTS (literally): The d/ specification

Post by phelix »

whooha
The JSON object SHOULD be encoded as compactly as possible, without unnecessary whitespace
+1

Could you give an example of how a TLS record looks like?

IMHO at least for the end user international characters should not be allowed. It makes tricking users way easier. Consequently I vote for disallowing "xn--" altogether.
nx.bit - some namecoin stats
nf.bit - shortcut to this forum

biolizard89
Posts: 2001
Joined: Tue Jun 05, 2012 6:25 am
os: linux

Re: REQUEST FOR COMMENTS (literally): The d/ specification

Post by biolizard89 »

phelix wrote:whooha
The JSON object SHOULD be encoded as compactly as possible, without unnecessary whitespace
+1

Could you give an example of how a TLS record looks like?

IMHO at least for the end user international characters should not be allowed. It makes tricking users way easier. Consequently I vote for disallowing "xn--" altogether.
There was a discussion about IDN homograph issues a while back on this forum; I think it was mentioned that most browsers will refuse to load domains that are mixed-script. I'm not sure if that's sufficient protection, and I haven't actually tested that behavior.
Jeremy Rand, Lead Namecoin Application Engineer
NameID: id/jeremy
DyName: Dynamic DNS update client for .bit domains.

Donations: BTC 1EcUWRa9H6ZuWPkF3BDj6k4k1vCgv41ab8 ; NMC NFqbaS7ReiQ9MBmsowwcDSmp4iDznjmEh5

hla
Posts: 46
Joined: Mon Nov 10, 2014 12:01 am
os: linux
Contact:

Re: REQUEST FOR COMMENTS (literally): The d/ specification

Post by hla »

phelix wrote:whooha
The JSON object SHOULD be encoded as compactly as possible, without unnecessary whitespace
+1

Could you give an example of how a TLS record looks like?

IMHO at least for the end user international characters should not be allowed. It makes tricking users way easier. Consequently I vote for disallowing "xn--" altogether.
The following example record from RFC 6698:

Code: Select all

  _443._tcp.www.example.com. IN TLSA (
      0 0 1 d2abde240d7cd3ee6b4b28c54df034b9
            7983a1d16e8a410e4561cb106618e971 )
translates to:

Code: Select all

{
  "map": {
    "www": {
      "map": {
        "_tcp": {
          "map": {
            "_443": {
              "tls": [[0,0,1,"0qveJA180+5rSyjFTfA0uXmDodFuikEORWHLEGYY6XE="]]
            }
          }
        }
      }
    }
  }
}
I'm against disallowing IDN. There's no need to second-guess this decision, as it's already been made. If you're paranoid about it, just display xn-- domains literally, don't refuse to process them. If the user types an IDN domain, that can be translated to punycode; what the user types should be an adequately trustworthy indication of the desired endpoint.

biolizard89
Posts: 2001
Joined: Tue Jun 05, 2012 6:25 am
os: linux

Re: REQUEST FOR COMMENTS (literally): The d/ specification

Post by biolizard89 »

As was stated on IRC, Hugo's format for TLSA is definitely simpler to process for DNS bridges than Pagel's draft, and also easier for people who know DNS to use. Maybe this is a stupid question, but how is the "allow subdomains" bool handled in Hugo's spec?

I don't see any problem with allowing IDN's myself.
Jeremy Rand, Lead Namecoin Application Engineer
NameID: id/jeremy
DyName: Dynamic DNS update client for .bit domains.

Donations: BTC 1EcUWRa9H6ZuWPkF3BDj6k4k1vCgv41ab8 ; NMC NFqbaS7ReiQ9MBmsowwcDSmp4iDznjmEh5

domob
Posts: 1129
Joined: Mon Jun 24, 2013 11:27 am
Contact:

Re: REQUEST FOR COMMENTS (literally): The d/ specification

Post by domob »

I'm also for IDN. If there are security concerns, the browser should handle them adequately (disallowing mixed script or even displaying the xn-- literally in case of paranoid users). I have no opinion on the draft apart from that, since I'm not a DNS or d/ expert.
BTC: 1domobKsPZ5cWk2kXssD8p8ES1qffGUCm | NMC: NCdomobcmcmVdxC5yxMitojQ4tvAtv99pY
BM-GtQnWM3vcdorfqpKXsmfHQ4rVYPG5pKS
Use your Namecoin identity as OpenID: https://nameid.org/

biolizard89
Posts: 2001
Joined: Tue Jun 05, 2012 6:25 am
os: linux

Re: REQUEST FOR COMMENTS (literally): The d/ specification

Post by biolizard89 »

Is this thread a good place to discuss the format of "import" in Hugo's spec? I know that was in a different thread prior to the spec being posted here... @Hugo do you prefer that to be here or in the other thread?
Jeremy Rand, Lead Namecoin Application Engineer
NameID: id/jeremy
DyName: Dynamic DNS update client for .bit domains.

Donations: BTC 1EcUWRa9H6ZuWPkF3BDj6k4k1vCgv41ab8 ; NMC NFqbaS7ReiQ9MBmsowwcDSmp4iDznjmEh5

phelix
Posts: 1634
Joined: Thu Aug 18, 2011 6:59 am

Re: REQUEST FOR COMMENTS (literally): The d/ specification

Post by phelix »

@hla: thanks for the example. I like the encoding. Besides that the nesting looks horribly complicated but I guess we can't get around it.

This may not be the right place to discuss but I have a very strong opinion against allowing IDN: http://en.wikipedia.org/wiki/IDN_homograph_attack Also I see only a tiny benefit from IDN.
nx.bit - some namecoin stats
nf.bit - shortcut to this forum

biolizard89
Posts: 2001
Joined: Tue Jun 05, 2012 6:25 am
os: linux

Re: REQUEST FOR COMMENTS (literally): The d/ specification

Post by biolizard89 »

phelix wrote:This may not be the right place to discuss but I have a very strong opinion against allowing IDN: http://en.wikipedia.org/wiki/IDN_homograph_attack Also I see only a tiny benefit from IDN.
According to https://en.wikipedia.org/wiki/IDN_homog ... the_attack , Firefox uses a TLD whitelist, while Chromium blacklists IDN's whose charset is not entirely from exactly 1 of the user's chosen languages. Generally I think Chromium's approach makes more sense; does anyone know why Firefox doesn't do this?
Jeremy Rand, Lead Namecoin Application Engineer
NameID: id/jeremy
DyName: Dynamic DNS update client for .bit domains.

Donations: BTC 1EcUWRa9H6ZuWPkF3BDj6k4k1vCgv41ab8 ; NMC NFqbaS7ReiQ9MBmsowwcDSmp4iDznjmEh5

johnc
Posts: 89
Joined: Sun Dec 28, 2014 10:03 am

Re: REQUEST FOR COMMENTS (literally): The d/ specification

Post by johnc »

Not sure if related, but how does NMC handles TLS revocations?
This guy is working on that and i think it could very well either use namecoin or give his opinion.

https://github.com/ChristopherA/revocab ... cates-hack

Post Reply