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@link38.eu wrote:
Hello Michael,
Hi,
I get this:
[ms@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