We usually don’t have that long TTLs and I actually found it quite likely that I could have forgotten one...

> On 11 Nov 2017, at 3:36 pm, Peter Müller <peter.mueller(a)link38.eu> wrote:
> 
> Hello Michael,
> 
>> Hi,
>> 
>> I get this:
>> 
>> [ms(a)hughes ~]$ dig TLSA _443._tcp.ipfire.org
>> 
>> ; <<>> DiG 9.11.1-P3-RedHat-9.11.1-2.P3.fc26 <<>> TLSA _443._tcp.ipfire.org
>> ;; global options: +cmd
>> ;; Got answer:
>> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 4259
>> ;; flags: qr rd ra ad; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1
>> 
>> ;; OPT PSEUDOSECTION:
>> ; EDNS: version: 0, flags:; udp: 4096
>> ;; QUESTION SECTION:
>> ;_443._tcp.ipfire.org.        IN    TLSA
>> 
>> ;; ANSWER SECTION:
>> _443._tcp.ipfire.org.    21600    IN    CNAME    _letsencrypt.certs.ipfire.org.
>> _letsencrypt.certs.ipfire.org. 21600 IN    TLSA    2 1 1 60B87575447DCBA2A36B7D11AC09FB24A9DB406FEE12D2CC90180517 616E8A18
>> 
>> ;; Query time: 66 msec
>> ;; SERVER: 192.168.191.1#53(192.168.191.1)
>> ;; WHEN: Fri Nov 10 22:18:02 GMT 2017
>> ;; MSG SIZE  rcvd: 129
>> 
>> What is it you are getting?
> The same now. Not sure what caused the delay here. Anyway, it works. :-)
> 
> Best regards,
> Peter Müller
>> 
>> If you want to avoid the caches, just query
>> ns[123].lightningwirelabs.com.
>> 
>> -Michael
>> 
>>> On Fri, 2017-11-10 at 20:59 +0100, Peter Müller wrote:
>>> Hello Michael,
>>> 
>>> during some tests, I noticed that the DANE record for
>>> www.ipfire.org is still missing. In the first place, I
>>> thought this was because of some DNS reply caching, but
>>> it isn't.
>>> 
>>> Just for the record, should be an easy change.
>>> 
>>> Apart from that all DANE records seem to be present.
>>> 
>>> I will deal with the Postfix configuration on IPFire's MX
>>> next week (need to work at the weekend).
>>> 
>>> Best regards,
>>> Peter Müller  
>