[Opendnssec-user] TTL clamped to minimum 3600?

[Havard Eidnes]

> 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?

Both uninett.no.axfr and uninett.no.backup2 have correct entries
for the CNAME I'm reproducing the problem with now.

From uninett.no.axfr:

test.uninett.no.        121     IN      CNAME   login.uninett.no.
test.uninett.no.        121     IN      RRSIG   CNAME 8 3 121 20160212211701 20160122141336 46194 uninett.no. X06REkLHrdF7YWZf2v95gJVh+uNgeLRm+ytFQvlybLbxlv1bj/Ms4IdCqW5dBfwGo2U8VHvOKNxP1ixCOUQIBvBZIfL23ApM3KfY96fh0Vu0Ikb1v470TUoqaIPbQ3quQ+CpLY/y8P4krb14y4hCwYFblB3lmBwS3gIr/Nmj9VE=

from uninett.no.backup2:

test.uninett.no.        121     IN      CNAME   login.uninett.no.

The uninett.no.ixfr file also has

test.uninett.no.        121     IN      CNAME   login.uninett.no.

However, when I query the name server which is downstream from
OpenDNSSEC, I get:

% dig @ns.uninett.no. test.uninett.no. cname +norec +dnssec
...
;; ANSWER SECTION:
test.uninett.no.        3600    IN      CNAME   login.uninett.no.
test.uninett.no.        121     IN      RRSIG   CNAME 8 3 121 20160212211701 20160122141336 46194 uninett.no. X06REkLHrdF7YWZf2v95gJVh+uNgeLRm+ytFQvlybLbxlv1bj/Ms4IdC qW5dBfwGo2U8VHvOKNxP1ixCOUQIBvBZIfL23ApM3KfY96fh0Vu0Ikb1 v470TUoqaIPbQ3quQ+CpLY/y8P4krb14y4hCwYFblB3lmBwS3gIr/Nmj 9VE=
...

Also, manually doing a zone transfer looks correct:

ns# dig -k keys/Khugin-ns.+163+64739.private @158.38.0.175 uninett.no. axfr | egrep '^test.uninett.*(login|RRSIG)'
test.uninett.no.        121     IN      CNAME   login.uninett.no.
test.uninett.no.        121     IN      RRSIG   CNAME 8 3 121 20160212211701 20160122141336 46194 uninett.no. X06REkLHrdF7YWZf2v95gJVh+uNgeLRm+ytFQvlybLbxlv1bj/Ms4IdC qW5dBfwGo2U8VHvOKNxP1ixCOUQIBvBZIfL23ApM3KfY96fh0Vu0Ikb1 v470TUoqaIPbQ3quQ+CpLY/y8P4krb14y4hCwYFblB3lmBwS3gIr/Nmj 9VE=
ns#

However, doing an IXFR with dig reveals that the CNAME record is
actually *not* part of the incremental zone transfer when I query
for the latest update where I bumped the TTL on the CNAME record
from 120 to 121:

ns# dig -k keys/Khugin-ns.+163+64739.private -t ixfr=2016012218 @158.38.0.175 uninett.no. 

; <<>> DiG 9.9.2-P1 <<>> -k keys/Khugin-ns.+163+64739.private -t ixfr=2016012218 @158.38.0.175 uninett.no.
; (1 server found)
;; global options: +cmd
uninett.no.             3600    IN      SOA     ns.uninett.no. hostmaster.uninett.no. 2016012219 14400 3600 1814400 900
uninett.no.             3600    IN      SOA     ns.uninett.no. hostmaster.uninett.no. 2016012218 14400 3600 1814400 900
uninett.no.             3600    IN      RRSIG   SOA 8 2 3600 20160212205210 20160122141234 46194 uninett.no. XZdOJpFhaLej3v6pemWyvuXLqhHTs3+lXk5Jdz5rR/VuUECy8FMl0EdZ uKSHUlXh8uoggyj0yN9tVzY0ErWaBvzL//GiXXupXvQTo+yKUIxyKZg6 MFSYW8EWf6b0IQ8qZLTbyncG2kbGIWxpAiMAzRxzcgYmWrx/vPeAiJvD RcA=
_original-serial.uninett.no. 3600 IN    TXT     "2016012215"
_original-serial.uninett.no. 3600 IN    RRSIG   TXT 8 3 3600 20160212105938 20160122141234 46194 uninett.no. qOy3MghWxStDVtHlVJoibirjtvljNGir3t6AM2pMzZlZ1PKlDCX9MrLV YCEgabZK2LRpaGu+K8+65fCj4oYa/SZoapEQJZasdDK5tz6rv3poIs+N DQ+HI20edYFMRE7/umB7zKrjeFBLJfuAg95BH6y7UCQCUGfvPoQbBiWG iOk=
test.uninett.no.        120     IN      RRSIG   CNAME 8 3 120 20160212031816 20160122141234 46194 uninett.no. EDyv94QTIDng4y8ZokdFJk+cjOc7B0MpS1erL1KMa8VFGIxHm+O1bp7/ +E6N4ymhJYk4ygDOlbA0PX4/62xDlm7Tmj6ZYlNichpfhIVhx7kg71Hy +pm27vOtCdxXIg2iq23GzPGIIZkQN6hhcpuUCh6wyVuyEzp5J6afgjfz /LI=
uninett.no.             3600    IN      SOA     ns.uninett.no. hostmaster.uninett.no. 2016012219 14400 3600 1814400 900
_original-serial.uninett.no. 3600 IN    TXT     "2016012216"
uninett.no.             3600    IN      RRSIG   SOA 8 2 3600 20160212181041 20160122141336 46194 uninett.no. bUMqbjEhvmxsLAfii0JfvLYS4UClqoqcPeJSLReRoMwqrxhFCURT9PDl 92gTOqGrK7e41O2km1ECk+Q7nSnxZojqvZPaxoLDZhb9tuezugEiyiH+ enWtzOLQyYs/9OtXC3r3pujW4DI05kry8i9omjmS/skHRwyhLJ3iXfte z/s=
_original-serial.uninett.no. 3600 IN    RRSIG   TXT 8 3 3600 20160212121358 20160122141336 46194 uninett.no. qF1ZiL+ZYEXQlrIIuIDMIV7wiD6tApwRYNReIsvOW7O3RfY4pKrvp1jb LzET/z3n0EqanoGHcU/SfkjVl2yuJ6wO/02cmpjetj5V74TeAAWOW0Bv 6cq9KeljLRqL0yQl4/TObE6Xk0r4bUOwsZaZ/txsIcnVqSgU8bVnZIL5 hpE=
test.uninett.no.        121     IN      RRSIG   CNAME 8 3 121 20160212211701 20160122141336 46194 uninett.no. X06REkLHrdF7YWZf2v95gJVh+uNgeLRm+ytFQvlybLbxlv1bj/Ms4IdC qW5dBfwGo2U8VHvOKNxP1ixCOUQIBvBZIfL23ApM3KfY96fh0Vu0Ikb1 v470TUoqaIPbQ3quQ+CpLY/y8P4krb14y4hCwYFblB3lmBwS3gIr/Nmj 9VE=
uninett.no.             3600    IN      SOA     ns.uninett.no. hostmaster.uninett.no. 2016012219 14400 3600 1814400 900
hugin-ns.               0       ANY     TSIG    hmac-sha256. 1453476061 300 32 EREfGnA9BSSeSfonV95ZLiTzC7bdI1nS1+bGjMHVWIA= 29381 NOERROR 0 
;; Query time: 5 msec
;; SERVER: 158.38.0.175#53(158.38.0.175)
;; WHEN: Fri Jan 22 16:21:01 2016
;; XFR size: 12 records (messages 1, bytes 1664)

ns# 

Here the only change was the change of the TTL on the CNAME
record itself (plus our _original-serial TXT record).  However,
changing the target of the CNAME made the CNAME appear in the
IXFR output.  So it looks like only a TTL change doesn't make the
record show up in IXFR (while it should), so the previous TTL
will stick around.

Regards,

- Håvard