REQUEST FOR COMMENTS (literally): The d/ specification
REQUEST FOR COMMENTS (literally): The d/ specification
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.
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.
Re: REQUEST FOR COMMENTS (literally): The d/ specification
whooha
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.
+1The JSON object SHOULD be encoded as compactly as possible, without unnecessary whitespace
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.
-
- Posts: 2001
- Joined: Tue Jun 05, 2012 6:25 am
- os: linux
Re: REQUEST FOR COMMENTS (literally): The d/ specification
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.phelix wrote:whooha
+1The JSON object SHOULD be encoded as compactly as possible, without unnecessary whitespace
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.
Re: REQUEST FOR COMMENTS (literally): The d/ specification
The following example record from RFC 6698:phelix wrote:whooha
+1The JSON object SHOULD be encoded as compactly as possible, without unnecessary whitespace
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.
Code: Select all
_443._tcp.www.example.com. IN TLSA (
0 0 1 d2abde240d7cd3ee6b4b28c54df034b9
7983a1d16e8a410e4561cb106618e971 )
Code: Select all
{
"map": {
"www": {
"map": {
"_tcp": {
"map": {
"_443": {
"tls": [[0,0,1,"0qveJA180+5rSyjFTfA0uXmDodFuikEORWHLEGYY6XE="]]
}
}
}
}
}
}
}
-
- Posts: 2001
- Joined: Tue Jun 05, 2012 6:25 am
- os: linux
Re: REQUEST FOR COMMENTS (literally): The d/ specification
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.
I don't see any problem with allowing IDN's myself.
Re: REQUEST FOR COMMENTS (literally): The d/ specification
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/
BM-GtQnWM3vcdorfqpKXsmfHQ4rVYPG5pKS
Use your Namecoin identity as OpenID: https://nameid.org/
-
- Posts: 2001
- Joined: Tue Jun 05, 2012 6:25 am
- os: linux
Re: REQUEST FOR COMMENTS (literally): The d/ specification
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?
Re: REQUEST FOR COMMENTS (literally): The d/ specification
@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.
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.
-
- Posts: 2001
- Joined: Tue Jun 05, 2012 6:25 am
- os: linux
Re: REQUEST FOR COMMENTS (literally): The d/ specification
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?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.
Re: REQUEST FOR COMMENTS (literally): The d/ specification
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
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