We have a mailing list – two of them, in fact.
For general discussion, the “discuss” list:
https://lists.bclug.ca/mailman/listinfo/discuss
Alternately, send an email to discuss-subscribe@bclug.ca, then simply reply to the confirmation email message.
For announcements, the “announce” list:
https://lists.bclug.ca/mailman/listinfo/announce
Alternately, send an email to announce-subscribe@lists.bclug.ca, then simply reply to the confirmation email message.
Please note:
Having issues sending email to Yahoo accounts.
We have TLS, SPF, DKIM, and, DMARC all (mostly) configured correctly, and yet…
Trying to diagnose issues with a DNS PTR record, which may solve it.
Meanwhile, if you have a non-Yahoo account, we advise you try that one.
Thanks for your patience.
Our email is now being accepted by Yahoo and Shaw thanks to the PTR record being created by Mark at https://indieservenetworks.com!
So, PTR record(s)… Seems correctly configured, but I’m a bit rusty on whether
AUTHORITY: 0is a Bad Thing™ on PTR RRs.dig -t ptr lists.bclug.ca;; Got answer:;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 25405 ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
;; ANSWER SECTION:lists.bclug.ca. 154 IN PTR 222.143.212.199.in-addr.arpa.
For the record, now that a valid PTR RR has been set in DNS, Authority: 0 is still showing:
dig -x $(dig +short lists.bclug.ca)...
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
...
;; ANSWER SECTION:
222.143.212.199.in-addr.arpa. 7132 IN PTR kwvoip.ca.
$ dig +short lists.bclug.ca. A lists.bclug.ca. AAAA lists.bclug.ca. CNAME199.212.143.222
$ dig +trace -x 199.212.143.222
...
143.212.199.in-addr.arpa. 86400 IN NS isdns1.indieserve.net.
143.212.199.in-addr.arpa. 86400 IN NS isdns2.indieserve.net.
...
222.143.212.199.in-addr.arpa. 14400 IN PTR kwvoip.ca.
;; Received 80 bytes from 199.212.143.9#53(isdns2.indieserve.net) in 79 ms
$ dig @isdns1.indieserve.net. +norecurse -x 199.212.143.222
; <> DiG 9.11.5-P4-5.1+deb10u5-Debian <> @isdns1.indieserve.net. +norecurse -x 199.212.143.222
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 48458
;; flags: qr aa; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 3
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
; COOKIE: 67139890bf1a7c2453274e3560a1b5b0a2ccb42e94d33624 (good)
;; QUESTION SECTION:
;222.143.212.199.in-addr.arpa. IN PTR
;; ANSWER SECTION:
222.143.212.199.in-addr.arpa. 14400 IN PTR kwvoip.ca.
;; AUTHORITY SECTION:
143.212.199.in-addr.arpa. 86400 IN NS isdns2.indieserve.net.
143.212.199.in-addr.arpa. 86400 IN NS isdns1.indieserve.net.
;; ADDITIONAL SECTION:
isdns1.indieserve.net. 14400 IN A 199.212.143.2
isdns2.indieserve.net. 14400 IN A 199.212.143.9
;; Query time: 77 msec
;; SERVER: 199.212.143.2#53(199.212.143.2)
;; WHEN: Sun May 16 17:15:44 PDT 2021
;; MSG SIZE rcvd: 196
$
Looks reasonable to me.
I think the "AUTHORITY: 0" bit in the comments is just dig telling
you that it got zero AUTHORITY records – you're mostly looking for ANSWER records, so most of the time AUTHORITY records in such a query are the DNS server being "helpful" in providing additional information that may be useful or relevant, as AUTHORITY and/or ADDITIONAL record(s) … generally as relevant – and as may be needed or it has space to add such within a single UDP packet and may be useful or significant (notably to try and avoid a follow-up query/response that may ask for exactly that information).
When I did query against authoritative server, it gave authoritative answer (note the "aa" flag – authoritative answer) – server is basically saying I'm authoritative in this answer, you need not look further. The +norecurse option also says in our query, don't do recursion – basically tell me what you presently can, without asking any additional nameservers.
And this is unlike doing:
$ dig -x 199.212.143.222; <> DiG 9.11.5-P4-5.1+deb10u5-Debian <> -x 199.212.143.222
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 27065
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 3
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
; COOKIE: 1c89fb02189eb081778edd9860a1b85c739f71b9dca83d1b (good)
;; QUESTION SECTION:
;222.143.212.199.in-addr.arpa. IN PTR
;; ANSWER SECTION:
222.143.212.199.in-addr.arpa. 14357 IN PTR kwvoip.ca.
;; AUTHORITY SECTION:
143.212.199.in-addr.arpa. 86356 IN NS isdns1.indieserve.net.
143.212.199.in-addr.arpa. 86356 IN NS isdns2.indieserve.net.
;; ADDITIONAL SECTION:
isdns1.indieserve.net. 13219 IN A 199.212.143.2
isdns2.indieserve.net. 13219 IN A 199.212.143.9
;; Query time: 0 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Sun May 16 17:27:08 PDT 2021
;; MSG SIZE rcvd: 196
$
Where we're just hitting a more local nameserver, and it's doing(/trying) any needed recursion to answer our query, and since I happened to do similar query shortly before, we're mostly seeing cached data. Note the lack of aa flag in the response. Note also the TTLs showing lower values … that's because it's been cached, and is counting down the seconds from what it first got – it will expire from the cache not later than when that's counted down to zero – then it would need to again issue more queries to relevant nameserver(s) to get fresh version of that DNS data to answer such a query … which it would again cache the relevant response data.
Anyway, hello from
https://berkeleylug.com/Pi.BerkeleyLUG/
etc. See also:
https://www.wiki.balug.org/wiki/doku.php?id=balug:covid-19