Confirmed users
308
edits
Security/DNSSEC-TLS: Difference between revisions
Jump to navigation
Jump to search
no edit summary
mNo edit summary |
No edit summary |
||
| Line 49: | Line 49: | ||
[http://www.nlnetlabs.nl/projects/ldns/ ldns], [https://www.dnssec-tools.org/ DNSSEC-Tools], and [http://unbound.net/download.html Unbound] all use BSD licenses. Thus far, I've had the most success using ldns. Unbound uses ldns. | [http://www.nlnetlabs.nl/projects/ldns/ ldns], [https://www.dnssec-tools.org/ DNSSEC-Tools], and [http://unbound.net/download.html Unbound] all use BSD licenses. Thus far, I've had the most success using ldns. Unbound uses ldns. | ||
== Creating a TLSA Record == | |||
Material embedded in a TLSA record must follow the [http://tools.ietf.org/html/draft-ietf-dane-protocol-07 specification]. This involves making the decision of what to embed. As mentioned above, the embedded material may be a certificate identifying an end entity (i.e. the server clients will connect to), a certification authority's certificate (where that certificate is an ancestor of a certificate on the server), or a public key (which may correspond to either of the two situations). Then, the actual data embedded may be the full representation, a sha256 hash, or a sha512 hash. Different decisions may be appropriate for different situations. | |||
Once the certificate type and reference type are determined, an entry must go into the zone file that is authoritative for the domain name of the server. | |||
== Contact == | == Contact == | ||
David Keeler (irc: keeler, email: d[irc name]@mozilla.com) | David Keeler (irc: keeler, email: d[irc name]@mozilla.com) | ||