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