ldns-dane(1)

πŸ’… NAME πŸ’…

ok so ldns-dane β€” it verifies or creates TLS authentication with DANE (RFC6698). that's the whole vibe. it's giving "trust, but cryptographically" ✨


πŸŽ€ SYNOPSIS πŸŽ€

ldns-dane [OPTIONS] verify name port
ldns-dane [OPTIONS] -t tlsafile verify

ldns-dane [OPTIONS] create name port
          [ Certificate-usage [ Selector [ Matching-type ] ] ]

ldns-dane -h
ldns-dane -v

🌸 DESCRIPTION 🌸

bestie there are three whole modes and they're all iconic in different ways:

Form one, the classic: a TLS connection to name:port gets established, and the TLSA resource record(s) for name are used to authenticate that connection. slay.

Form two, the file-kid: the TLSA record(s) get read from tlsafile instead, and those are what authenticate the TLS service they reference. no network lookup for the records themselves πŸ¦‹

Form three, the creator: a TLS connection to name:port is established and then used to create the TLSA resource record(s) that would authenticate the connection. main character energy β€” it's making the receipts, not checking them πŸ”₯

the parameters for TLSA rr creation are, in order:

Certificate-usage:

  • 0 | PKIX-TA β€” CA constraint
  • 1 | PKIX-EE β€” Service certificate constraint
  • 2 | DANE-TA β€” Trust anchor assertion
  • 3 | DANE-EE β€” Domain-issued certificate (this is the default, no cap)

Selector:

  • 0 | Cert β€” Full certificate
  • 1 | SPKI β€” SubjectPublicKeyInfo (default, periodt)

Matching-type:

  • 0 | Full β€” No hash used
  • 1 | SHA2-256 β€” SHA-256 (default)
  • 2 | SHA2-512 β€” SHA-512

✨ OPTIONS ✨

  • -4 β€” TLS connect IPv4 only. v4 girlies only πŸ’œ
  • -6 β€” TLS connect IPv6 only. v6 girlies only πŸ’œ
  • -a address β€” don't even try to resolve name, just connect to address instead. lowkey a shortcut and we love her. this option may be given more than once 🫢
  • -b β€” print the "name. TYPE52 \# size hexdata" form instead of the TLSA presentation format. different font, same energy πŸ’…
  • -c certfile β€” do NOT TLS connect to name:port; instead authenticate (or make TLSA records) for the certificate (chain) in certfile. offline mode era 🌈
  • -d β€” assume DNSSEC validity even when the TLSA records were acquired insecure or were bogus. yeah she's trusting like that πŸ™ˆ
  • -f CAfile β€” use CAfile to validate.
  • -h β€” print short usage help.
  • -i β€” interact after connecting. it's a conversation now πŸ’¬
  • -k keyfile β€” specify a file that contains a trusted DNSKEY or DS rr. key(s) are used when chasing signatures (i.e. when -S is given). this option may be given more than once. alternatively, if -k is not specified, and a default trust anchor (/etc/trusted-key.key) exists and contains a valid DNSKEY or DS record, it will be used as the trust anchor. built-in bestie πŸ”‘
  • -n β€” do not verify server name in certificate. chaotic but ok 🫣
  • -o offset β€” when creating a "Trust anchor assertion" TLSA resource record, select the offsetth certificate offset from the end of the validation chain. 0 means the last certificate, 1 the one but last, 2 the second but last, etc. when offset is -1 (the default), the last certificate is used (like with 0) that MUST be self-signed β€” and ooh this one actually matters: it can help to make sure that the intended (self signed) trust anchor is actually present in the server certificate chain (which is a DANE requirement). so like, it's a vibe check on your own chain πŸ‘‘
  • -p CApath β€” use certificates in the CApath directory to validate.
  • -s β€” when creating TLSA resource records with the "CA Constraint" and the "Service Certificate Constraint" certificate usage, do not validate and assume PKIX is valid. for "CA Constraint" this means that verification should end with a self-signed certificate. no thoughts, assume valid 🧚
  • -S β€” chase signature(s) to a known key. without this option, the local network is trusted to provide a DNSSEC resolver (i.e. AD bit is checked). literally the difference between "trust the room" and "trust the key" πŸ’€
  • -t tlsafile β€” read TLSA record(s) from tlsafile. when name and port are also given, only TLSA records that match the name, port and transport are used. otherwise the owner name of the TLSA record(s) will be used to determine name, port and transport. it figures it out itself, queen behavior ⭐
  • -T β€” return exit status 2 for PKIX validated connections without (secure) TLSA records(s). a very specific little flag and we stan a specific little flag πŸ“
  • -u β€” use UDP transport instead of TCP. speedrun 🌬️
  • -v β€” show version and exit.

πŸ¦‹ FILES πŸ¦‹

  • /etc/trusted-key.key β€” the file from which trusted keys are loaded for signature chasing, when no -k option is given. the default boo πŸ’–

πŸ”₯ SEE ALSO πŸ”₯

unbound-anchor(8)


πŸ‘‘ AUTHOR πŸ‘‘

written by the ldns team as an example for ldns usage. (yes they made a whole DANE tool as a "for instance". flex.)


😭 REPORTING BUGS 😭

report bugs to <dns-team@nlnetlabs.nl>. be nice about it, they're doing their best 🫢


Copyright (C) 2012 NLnet Labs. This is free software. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

ngl the "no warranty" part is real β€” not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. take it seriously, bestie πŸ™ˆ

ok that's the whole page!! this one's from the ldns-dane(1) manual in the General Commands Manual section, and the version date on it is 17 September 2012 β€” yeah she's an elder but she still ate πŸ’…βœ¨πŸŽ€

πŸ“¦ where this page comes from