On Wed, 21 Nov 2018, Stephen Farrell wrote:
We currently permit >1 RR, but
actually
I suspect that it would be better to try to restrict this.
Not sure we can and I suspect that'd raise DNS-folks' hackles,
but maybe I'm wrong.
I think the SOA record is the only exception allowed (and there
is an exception to that when doing AXFR I believe)
Usually these things are defined as "pick the first DNS RRTYPE
that satisfies you".
- get rid of not_before/not_after - I don't believe those
are useful given TTLs and they'll just lead to failures
I'm mostly ambivalent on this, but on balance, I think these are useful,
as they are not tied to potentially fragile DNS TTLs.
If there were a justification offered for 'em I'd be
ok with it, but TBH, I'm not seeing it. And my main
experience of the similar dates on RRSIGs are that they
just break things and don't help.
This has a totally different expiry behavior from RRSIGs, so I'm
not sure that's that useful an analogy.
Disagree. They're both specifying a time window for DNS data.
Same problems will arise is my bet.
You mean the problem of not being able to replay old data? :)
My main ask though for these time values is that their presence
be explicitly justified. That's missing now, and I suspect won't
be convincing, but maybe I'll turn out to be wrong.
Note that TTLs are about the caching of data and nothing else. If
the content of your record requires some specific time of death,
you cannot rely on TTL. Note that a TTL on a received RRTYPE can
have any value under the published TTL on the authoritative server
if it was flowing through caching recursive servers. So you cannot
use a TTL for some other kind of expiry value for another protocol.
Also, DNS software sometimes enforces maximum and minimum TTL values,
so again, do not use DNS TTL for other protocol timing parameters.
Although, if I am correct, the epectation is that all of this data
will be used without mandating DNSSEC validation, so all these
security parameters could be modified by any DNS party in transit
to try and break the protocol or privacy of the user. The "not DNSSEC
camel" is growing fast.
Paul
Paul
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
