On Tue, Aug 19, 2014 at 11:24:47AM -0600, Peter Saint-Andre wrote:
> >Since we're ultimately looking at an SRV RRset
>
> Correct.
>
> >(possibly after CNAME expansion of the original domain),
>
> Disallowed by RFC 2782, right? Or do you mean expansion of the SRV "Name"
> rather than the SRV "Target"?
Yes, the "Name".
> >More appropriately,
> >"entire" applies not to RRset, but rather "entire chain" of aliases
> >(CNAME or DNAME if any) leading to the ultimate SRV RRset.
>
> I find the term "ultimate SRV RRset" to be a bit vague. Do you suggest that
> we spend time and energy in defining it for use in this specification?
Just be clear that the text in question is talking about the security
if the sequence of CNAMEs leading to the result, (all the links in
the chain need to be "secure"). The RRset at the end of the chain
is "secure" or not, binary, thus "entire" does not apply to that.
> >Not continuing with connections to the target service applies when
> >the DNS lookup fails ("bogus", "indeterminate", "timeout", ...).
>
> Are you referring to this text?
>
> o If the response is "bogus" or "indeterminate", the client MUST NOT
> connect to this target server; instead it uses the next most
> appropriate SRV target.
Yes, "bogus" is not the only case in which you skip the target,
and "indeterminate" (as defined in 4035) is best viewed as an error
condition. All error conditions in resolving the TLSA RRset lead
to skipping the target.
> And are you suggesting that we expand that text to mention additional DNS
> lookup errors (e.g., "timeout")?
All DNS lookup errors, with or without examples of specific ones.
Definitely not limited to just "bogus" and "indeterminate".
> >DNS lookup error handling is more comprehensively specified in the
> >SMTP draft, and perhaps should be borrowed from that document in
> >its entirety.
>
> Yes, Section 2.1 of draft-ietf-dane-smtp-with-dane is indeed quite
> comprehensive. I am hesitant to copy it to draft-ietf-dane-srv primarily
> because copying introduces the possibility of divergence in text and
> secondarily because that text talks about SMTP. It seems safer to me if we
> point to that text from the dane-srv specification.
Whatever works for you. There is also a possibility of migrating
that text to the OPS draft, if the WG consensus is that such text
would be better placed there, and used by reference in both SMTP
and SRV. This of course means that OPS must be published at least
concurrently with SMTP (and SRV) or even before.
--
Viktor.
_______________________________________________
dane mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dane
