Re: Implementing DANE for qmail

* Erwin Hoffmann <[email protected]> [2017-04-09 20:15]:
> > Am 09.04.2017 um 17:52 schrieb Manvendra Bhangui <[email protected]>:
> > It
> > is MUST that the zone which has a TLSA RR must be signed by DNSSEC and
> > the applications which query the domain for TLSA RR validation should
> > use a DNSSEC aware resolver. This is where I am confused. Do all
> > resolver setup support DNSSEC?
> No. qmail-remote uses a stub-resolver and DNSSEC/TLS validation
> could/should be done by means of a proxy.=20

huh? no proxy.

it should use the regular resolver. dnssec-validated answers are
indicated by the ad flag.

; <<>> DiG 9.4.2-P2 <<>> +dnssec quigon.bsws.de
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 17183
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 3, AUTHORITY: 5, ADDITIONAL: 1
                   ^^
                   here

> You can briefly check, that this is on my agenda for s/qmail. The
> hard part is the validating DNS resolver.=20

you don't rewrite that.

> It is easy with DJBDNS.

err, no. it is easy with unbound. and probably even bind.

> DNSSEC is be definition not secure

unfounded (and wrong) claim.

> but depends a X.509 system (not PKI) -- the one to avoid according to TLS=
A.

there are no certs indeed, just keys. current dnssec is relatively
straightforward, it isn't the mess the early proposals were any more.

> Apart from that, PKI still needs to be supported.

sigh. if your agenda is "reinventing the wheel, again", then yes, probably.

But really, that is everything but smart. You just make qmail-remote
understand the AD flag, and call into LibreSSL's libtls for certificate
verification. Or another TLS lib if you like pain.
Add a little glue and done.

-- 
Henning Brauer, [email protected], [email protected]
BS Web Services GmbH, AG Hamburg HRB 128289, http://bsws.de
Full-Service ISP - Secure Hosting, Mail and DNS Services
Dedicated Servers, Rootservers, VMs/VPS, Application Hosting