On Thu, Sep 05, 2013 at 03:12:05PM -0700, Ian Fette (????????) wrote:
> You mention that you only bother if the MX RRset was secure.
Correct.
> In the Gmail case, we've got a lot of customers using "google apps for your
> domains". We tell them to point their MX records to e.g. ASPMX.L.GOOGLE.COM
Yes, I've seen such domains.
> Let's say hypothetically ianfette.com has an MX record for
> ASPMX.L.GOOGLE.COM but the administrator of ianfette.com can't be bothered
> to set up DNSSEC. That implies that even if google.com had deployed DNSSEC
> and _25._tcp.ASPMX.L.GOOGLE.COM existed that would be ignored?
Correct. A chain is only as strong as its weakest link. When the
original MX RRset is insecure, the base domain for the TLSA RR is
subject to compromise. There is then no point in making TLSA
lookups even if the MX host domain is DNSSEC validated.
A domain only benefits from DANE, when *it* adopts DNSSEC. If it
out-source MX service, the hosting domain also needs adopt DNSSEC.
; client record in signed zone
;
example.com. IN MX 0 mx.example.net.
; provider record in signed zone.
;
mx.example.net. IN A 192.0.2.1
_25._tcp.mx.example.net. IN TLSA 3 1 1 ...
If either zone is insecure, TLSA records are ignored.
I think this should not dissuade you from implementing DANE, there
are plenty of users to protect in gmail.com itself. If client
domains have more reason to implement DNSSEC, that's for the better.
--
Viktor.
_______________________________________________
dane mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dane
