[Opendnssec-user] TTL for the record set to 86400

[Mathieu Arnold]

Hi,


Using OpenDNSSEC 1.4.14 (migrating to 2.1 on the todo list).


Today, in preparation for a migration, I downed TTLs in a few zones, and
by chance, while looking for something else, I found in the logs that
all the TTL I downed to 10 minutes (from 1 day) were being ignored with:


Oct 10 14:23:57 ns1 ods-signerd: In zone file prepacolles.fr: TTL for
the record 'mail.prepacolles.fr. 600 IN A 79.143.244.130' set to 86400


I looked in the signer's source, I can't seem to find where and why it
is doing that, or where to disable it.

[Berry A.W. van Halderen]

Post by Mathieu Arnold
Using OpenDNSSEC 1.4.14 (migrating to 2.1 on the todo list).
Today, in preparation for a migration, I downed TTLs in a few zones, and
by chance, while looking for something else, I found in the logs that
Oct 10 14:23:57 ns1 ods-signerd: In zone file prepacolles.fr: TTL for
the record 'mail.prepacolles.fr. 600 IN A 79.143.244.130' set to 86400
I looked in the signer's source, I can't seem to find where and why it
is doing that, or where to disable it.

That would be the code (in signer/src/signer/zone.c:zone_add_rr()) that
makes sure all records in a record set (i.e. all "A" records for
mail.prepacolles.fr) have the same TTL value.

Often overlooked is when you have a default TTL value in place, where
one of the records does not have a TTL value (and thus uses the default)
and the other has a TTL value specified. In case you change one, you
should change both, or not use a default value.

For DNSSEC it is required to have all records use a single TTL value.

\Berry

[Mathieu Arnold]

Post by Berry A.W. van Halderen

Post by Mathieu Arnold
Using OpenDNSSEC 1.4.14 (migrating to 2.1 on the todo list).
Today, in preparation for a migration, I downed TTLs in a few zones, and
by chance, while looking for something else, I found in the logs that
Oct 10 14:23:57 ns1 ods-signerd: In zone file prepacolles.fr: TTL for
the record 'mail.prepacolles.fr. 600 IN A 79.143.244.130' set to 86400
I looked in the signer's source, I can't seem to find where and why it
is doing that, or where to disable it.

That would be the code (in signer/src/signer/zone.c:zone_add_rr()) that
makes sure all records in a record set (i.e. all "A" records for
mail.prepacolles.fr) have the same TTL value.

Ok, but, then, as all records in the unsigned zone have 600 for their
specific TTLs, and mail.prepacolles.fr only has one record, the A, why
would the TTL 600 be dropped? (The zones go through named-compilezone to
expand any BIND9 artefacts like $GENERATE and such.)

The zone fed to the signer is https://pastebin.com/1gzibnUi

Post by Berry A.W. van Halderen
Often overlooked is when you have a default TTL value in place, where
one of the records does not have a TTL value (and thus uses the default)
and the other has a TTL value specified. In case you change one, you
should change both, or not use a default value.
For DNSSEC it is required to have all records use a single TTL value.

[Yuri Schaeffer]

Post by Mathieu Arnold
Ok, but, then, as all records in the unsigned zone have 600 for their
specific TTLs, and mail.prepacolles.fr only has one record, the A, why
would the TTL 600 be dropped? (The zones go through named-compilezone to
expand any BIND9 artefacts like $GENERATE and such.)

I believe this is a manifestation of bug OPENDNSSSEC-890. As Barry
explained the Signer should enforce the same TTL on all RRs within an
RRSET. Therefore it looks through all TTLs of the RRSET and decides what
the best value should be. This as all good and well but it erroneously
considered the TTLs of the just deleted records as well. This can make a
TTL sticky and explains your case.

The fix for this will be in the next OpenDNSSEC 2 release (for which a
date is not scheduled yet). As a workaround a full AXFR should resolve
the issue for now.

//Yuri

[Yuri Schaeffer]

Hi Mathieu,

Post by Yuri Schaeffer
The fix for this will be in the next OpenDNSSEC 2 release (for which a
date is not scheduled yet). As a workaround a full AXFR should resolve
the issue for now.

I erroneously stated the fix was to be released. But in fact the fix was
released last August with OpenDNSSEC version 2.1.3. The patch is not
applicable to 1.4 so the best course of action will be to upgrade to
OpenDNSSEC 2.1.4.

Regards,
Yuri