[Opendnssec-user] TTL values through to signed zone?

[Berry A.W. van Halderen]

On 12/3/19 11:19 PM, Havard Eidnes wrote:
> Dec  3 22:16:20 signer-host ods-signerd: In zone file eduvpn.uninett.no: TTL for the record 'vpn.eduvpn.uninett.no. 600 IN A 158.38.2.19' set to 86400
> 

> 
> I suspect this is code which is supposed to ensure that all the RRs in
> an RRset has the same TTL (a correct goal to ensure).
> 
> Hm, I wonder...  This is a two-record RRset, but I suspect one record
> is attempted to be replaced at a time, so ...  will I then ever be
> able to reduce the TTL of the RRset, even if I do it simultaneously
> for both of them in the original master zone?  (That's a rhetorical,
> the answer appears to be "no".)  Or do I have to go the path via
> having just one RR?  Or ... it actually looks like I had to go the
> path via briefly having 0 RRs in the RRset; I now have the appropriate
> TTL emitted after signature.
> 
> It appears to me that some operations internally in OpenDNSSEC really
> should be on a "per RRset" basis, not just "per RR"(?)

There is a long history history here with attempts to make sure things
work correctly in every case.  The current solution isn't 100% perfect
but workable.  A big rework needs to be done for a fundamental solution.

But it indeed boils down to what to do when there is garbage input.
Multiple different TTLs on one RRSET isn't valid.  But what to do when
it happens.  The original idea was never, ever to output a bogus zone
and thus correct one of the TTLs.  With whatever value doesn't really
matter.
But architecturally OpenDNSSEC doesn't know which incoming records are
new or old at this time and thus this can lead you to never being able
to correct the situation.  I'm not going to recite every situation but
also other problems can occur.
Not having different TTLs for a single RRSET did originally not lead
to problems.  At the moment the code is such to prevent ever going
bogus accepting changes to other RRSETS, but sometimes requiring a full
re-sign or remove the offending RRSET to resolve problems.

I'd agree operations to be on a RRSET basis or even on a full delegation
or DNS label would be better.  With zone files (or [IA]XFRs) you don't
input RRSETs however, they can be in different parts of the input.
In the end you need a history of changes to zone to really prevent any
kind of problems.

\Berry

References:
https://issues.opendnssec.org/browse/SUPPORT-192
https://issues.opendnssec.org/browse/OPENDNSSEC-890
https://issues.opendnssec.org/browse/SUPPORT-219