Mailing List

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.

By admin

Linux admin, JS / React / Python / Perl developer.

5 comments

  1. 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.

  2. So, PTR record(s)… Seems correctly configured, but I’m a bit rusty on whether AUTHORITY: 0 is 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.

    1. 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.

    2. $ dig +short lists.bclug.ca. A lists.bclug.ca. AAAA lists.bclug.ca. CNAME
      199.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

Comments are closed.