> 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 _______________________________________________ Opendnssec-user mailing list [email protected] https://lists.opendnssec.org/mailman/listinfo/opendnssec-user
