[Opendnssec-user] TTL clamped to minimum 3600?

[Matthijs Mekking]

Hi Havard,

On 20-01-16 18:03, Havard Eidnes wrote:
> Sigh,
> 
> I jumped the gun on this one, in both cases; now that I've had
> time to look at it a bit more calmly, I think I can formulate a
> better question, and I'm now back to thinking there's a bug
> in OpenDNSSEC.
> 
> In a zone we sign, we try to set the TTL on a CNAME record to
> 300s.  On the hidden master, when queried for the name, we get:
> 
> login.uninett.no.       300     IN      CNAME   login2.uninett.no.
> 
> which is the intended TTL.
> 
> The zone data (or rather, an incremental change) passes through
> OpenDNSSEC, and if I ask for the data for this record including
> DNSSEC data from the name server at the other end, I get
> 
> login.uninett.no.       3600    IN      CNAME   login2.uninett.no.
> login.uninett.no.       300     IN      RRSIG   CNAME 8 3 300 20160210142813 20160120135441 46194 uninett.no. fatEO2XW4afwWolA1hfRRhI678GYEhe1WGKNKKfs1yUHsO+UYZXfmKV+ RN6a5CLwRDjfm3Nel7bhRDXZydYGjuyMZyotvQXHBbdon101Dmt23Ofl V4xaieMS+aWFq6gr6tM1WCueZHgUwDmllqAT81i3JxLRSNQnxumiv2nj EO8=
> 
> Notice that the TTL on the CNAME record has been, umm...,
> "adjusted" to 3600, while the RRSIG TTL and the original-ttl
> field in the RRSIG record has the original TTL from the hidden
> master from the original CNAME record.

Does the CNAME record on disk (in the working directory) also have this
"fixed" TTL, or do you only see it when querying for the data?

Best regards,
  Matthijs


> 
> If you ask a validating resolver for this record, it will of
> course set the TTL to 300 and start decrementing the TTL from
> there, as the specs dictate.
> 
> However, if you ask a non-validating resolver, it will start to
> count from 3600, and that's not what we intended.
> 
> The really strange thing is that we have other records in this
> zone which have a lower TTL than 3600, and which show up in the
> signed version of the zone with this identical lower-than-3600
> TTL, e.g. the address records at the zone apex.
> 
> Are we hitting some bug which only hits data transferred using
> incremental zone transfers, so that if the zone is transferred
> using AXFR, the original TTL is preserved, while it isn't with
> IXFR transfers?  That's what it looks like from here, but I've
> not dug into the code to answer that question...
> 
> Config as discussed earlier: zone transfer in, zone transfer out,
> patched OpenDNSSEC 1.4.7 (ref. the earlier fixes discussed here).
> 
> Regards,
> 
> - Håvard
> _______________________________________________
> Opendnssec-user mailing list
> Opendnssec-user at lists.opendnssec.org
> https://lists.opendnssec.org/mailman/listinfo/opendnssec-user
>