ldns-dane(1)

1ldns-dane(1)                General Commands Manual               ldns-dane(1)
2
3
4

NAME

6       ldns-dane - verify or create TLS authentication with DANE (RFC6698)
7

SYNOPSIS

9       ldns-dane [OPTIONS] verify name port
10       ldns-dane [OPTIONS] -t tlsafile verify
11
12       ldns-dane [OPTIONS] name port create
13                 [ Certificate-usage [ Selector [ Matching-type ] ] ]
14
15       ldns-dane -h
16       ldns-dane -v
17
18

DESCRIPTION

20       In  the  first form: A TLS connection to name:port is established.  The
21       TLSA resource record(s) for name are used to authenticate  the  connec‐
22       tion.
23
24       In  the second form: The TLSA record(s) are read from tlsafile and used
25       to authenticate the TLS service they reference.
26
27       In the third form: A TLS connection to  name:port  is  established  and
28       used  to create the TLSA resource record(s) that would authenticate the
29       connection.  The parameters for TLSA rr creation are:
30
31       Certificate-usage:
32              0      CA constraint
33              1      Service certificate constraint
34              2      Trust anchor assertion
35              3      Domain-issued certificate (default)
36
37       Selector:
38              0      Full certificate (default)
39              1      SubjectPublicKeyInfo
40
41       Matching-type:
42              0      No hash used
43              1      SHA-256 (default)
44              2      SHA-512
45
46       In stead of numbers the first few letters of the  value  may  be  used.
47       Except  for the hash algorithm name, where the full name must be speci‐
48       fied.
49
50

OPTIONS

52       -4     TLS connect IPv4 only
53
54       -6     TLS connect IPv6 only
55
56       -a address
57              Don't try to resolve name, but connect to address instead.
58
59              This option may be given more than once.
60
61       -b     print "name. TYPE52 \# size hexdata" form instead of  TLSA  pre‐
62              sentation format.
63
64       -c certfile
65              Do  not TLS connect to name:port, but authenticate (or make TLSA
66              records) for the certificate (chain) in certfile instead.
67
68       -d     Assume DNSSEC validity even when the TLSA records were  acquired
69              insecure or were bogus.
70
71       -f CAfile
72              Use  CAfile  to  validate. Default is /etc/pki/tls/certs/ca-bun‐
73              dle.trust.crt
74
75       -h     Print short usage help
76
77       -i     Interact after connecting.
78
79       -k keyfile
80              Specify a file that contains a trusted DNSKEY or DS rr.   Key(s)
81              are used when chasing signatures (i.e. -S is given).
82
83              This option may be given more than once.
84
85              Alternatively,  if  -k  is  not  specified,  and a default trust
86              anchor (/var/lib/unbound/root.key) exists and contains  a  valid
87              DNSKEY or DS record, it will be used as the trust anchor.
88
89       -n     Do not verify server name in certificate.
90
91       -o offset
92              When  creating  a "Trust anchor assertion" TLSA resource record,
93              select the offsetth certificate offset from the end of the vali‐
94              dation  chain. 0 means the last certificate, 1 the one but last,
95              2 the second but last, etc.
96
97              When offset is -1 (the default), the last  certificate  is  used
98              (like  with  0)  that MUST be self-signed. This can help to make
99              sure that the intended (self signed) trust  anchor  is  actually
100              present  in  the  server  certificate  chain  (which  is  a DANE
101              requirement).
102
103       -p CApath
104              Use certificates in the CApath directory to validate. Default is
105              /etc/pki/tls/certs/
106
107       -s     When creating TLSA resource records with the "CA Constraint" and
108              the "Service Certificate Constraint" certificate usage,  do  not
109              validate and assume PKIX is valid.
110
111              For "CA Constraint" this means that verification should end with
112              a self-signed certificate.
113
114       -S     Chase signature(s) to a known key.
115
116              Without this option, the local network is trusted to  provide  a
117              DNSSEC resolver (i.e. AD bit is checked).
118
119       -t tlsafile
120              Read  TLSA  record(s) from tlsafile. When name and port are also
121              given, only TLSA records that match the name, port and transport
122              are used. Otherwise the owner name of the TLSA record(s) will be
123              used to determine name, port and transport.
124
125       -u     Use UDP transport instead of TCP.
126
127       -v     Show version and exit.
128
129

FILES

131       /var/lib/unbound/root.key
132              The file from which trusted keys are loaded for signature  chas‐
133              ing, when no -k option is given.
134
135

AUTHOR

141       Written by the ldns team as an example for ldns usage.
142
143

REPORTING BUGS

145       Report bugs to ldns-team@nlnetlabs.nl.
146
147

COPYRIGHT

149       Copyright  (C) 2012 NLnet Labs. This is free software. There is NO war‐
150       ranty; not even for MERCHANTABILITY or FITNESS FOR  A  PARTICULAR  PUR‐
151       POSE.
152
153
154
155
156                               17 September 2012                  ldns-dane(1)