Apologies, Al, but I wasn't able to see that image (because of
inherent limitations on mailing lists). Would you mind just hosting the
image and posting its URL?
Or, I suppose, you could e-mail it to me.
---------- Forwarded message ----------
From: Al <awbalug(a)sunnyside.com>
To: balug-admin(a)lists.balug.org
Cc:
Bcc:
Date: Tue, 4 Jun 2024 07:34:43 -0700
Subject: Re: [BALUG-Admin] Comcast Business apparently blocking 5353 UDP
Re: linuxmafia.com "retry limit exceeded" CR145359298
Look for the arrow in this image, lower left:
---------- END Forwarded message ---------
Just noting more weirdness for the record.
Michael, I haven't yet opened a ticket with Comcast Business. I want to
have a coherent account of what I'm talking about, and simple criteria
to show success conditions. I _strongly fear_ that the root cause will
turn out to be SECURITYEDGEtm, that Comcast will refuse to disable it,
and that they'll say it's now an integral part of the "BUSINESS INTERNET
ESSENTIAL" customer agreement [sic], and that they no longer offer an
alternative plan that omits it and still provides static IPs.
And if _that_ is the case, I'm really not sure what Chez Moen's backup
plan is. (Also, I'm getting a bit exhausted by diagnosing and coping
with technology companies suddenly turning evil and customer-hostile.
First, my domain registrar, and now this! Again!)
So, the weirdness below: Is it really credible that Michael's
nameserver 96.86.170.229 is suddenly sending NOTIFYs for
savingthedolph.in and sf-lug.org? Why? There haven't been zonefile
changes, have there?
I'm starting to think that Comcast's middleman infrastructure is
artificially generating those, forging 96.86.170.229 as alleged source.
I'm not sure why. It could be either a gaffe in implementation _or_
a kludge to ensure that their infrastructure has current cached data
at the expense of the real auth. nameservers.
On another note, 198.144.194.12 is Aaron T. Porter's ns.primate.net,
which is not primary but rather a secondary for sf-lug.org. I have
a faint recollection _either_ that "secondary sends out NOTIFY even
though it shouldn't" is common _or_ that I've seen this with Aaron's
nameservers before and never gotten resolution. Probably I should
just make logcheck ignore those from 198.144.194.12 in its roles as
secondary.
----- Forwarded message from logcheck system account <logcheck(a)linuxmafia.com> -----
Date: Tue, 04 Jun 2024 12:02:01 -0700
From: logcheck system account <logcheck(a)linuxmafia.com>
To: root(a)linuxmafia.com
Subject: linuxmafia.com 2024-06-04 12:02 System Events
System Events
=-=-=-=-=-=-=
Jun 4 11:35:18 linuxmafia named[15622]: client 96.86.170.229#49840: received notify for zone 'savingthedolph.in'
Jun 4 11:35:18 linuxmafia named[15622]: zone savingthedolph.in/IN: Transfer started.
Jun 4 11:35:19 linuxmafia named[15622]: transfer of 'savingthedolph.in/IN' from 96.86.170.229#53: connected using 96.95.217.99#35905
Jun 4 11:35:19 linuxmafia named[15622]: zone savingthedolph.in/IN: transferred serial 1717526118
Jun 4 11:35:19 linuxmafia named[15622]: transfer of 'savingthedolph.in/IN' from 96.86.170.229#53: Transfer completed: 1 messages, 8 records, 1082 bytes, 0.097 secs (11154 bytes/sec)
Jun 4 11:40:48 linuxmafia named[15622]: client 96.86.170.229#7259: received notify for zone 'sf-lug.org'
Jun 4 11:40:48 linuxmafia named[15622]: zone sf-lug.org/IN: Transfer started.
Jun 4 11:40:48 linuxmafia named[15622]: transfer of 'sf-lug.org/IN' from 96.86.170.229#53: connected using 96.95.217.99#59792
Jun 4 11:40:48 linuxmafia named[15622]: zone sf-lug.org/IN: transferred serial 1717526448
Jun 4 11:40:48 linuxmafia named[15622]: transfer of 'sf-lug.org/IN' from 96.86.170.229#53: Transfer completed: 1 messages, 10 records, 1208 bytes, 0.089 secs (13573 bytes/sec)
Jun 4 11:42:49 linuxmafia named[15622]: client 198.144.194.12#50384: received notify for zone 'sf-lug.org'
Jun 4 11:42:49 linuxmafia named[15622]: zone sf-lug.org/IN: refused notify from non-master: 198.144.194.12#50384
----- End forwarded message -----
OK, those fsckers are _definitely_ screwing with my DNS, again.
See that "73.189.65.18" IP? Well...
$ dig -x 73.189.65.18 +short
c-73-189-65-18.hsd1.ca.comcast.net.
$
I'm betting this also somehow accounts for my mameserver mysteriously
getting NOTIFYs for domain mpaoli.net every 90 seconds.
----- Forwarded message from logcheck system account <logcheck(a)linuxmafia.com> -----
Date: Mon, 03 Jun 2024 15:02:02 -0700
From: logcheck system account <logcheck(a)linuxmafia.com>
To: root(a)linuxmafia.com
Subject: linuxmafia.com 2024-06-03 15:02 System Events
System Events
=-=-=-=-=-=-=
Jun 3 14:48:39 linuxmafia named[15622]: client 73.189.65.18#16833: received notify for zone 'mpaoli.net'
Jun 3 14:48:39 linuxmafia named[15622]: zone mpaoli.net/IN: refused notify from non-master: 73.189.65.18#16833
Jun 3 14:48:44 linuxmafia named[15622]: client 73.189.65.18#16833: received notify for zone 'mpaoli.net'
Jun 3 14:48:44 linuxmafia named[15622]: zone mpaoli.net/IN: refused notify from non-master: 73.189.65.18#16833
----- End forwarded message -----
So,
I did finally hear back from Comcast Business - they were supposed to call,
they didn't, but rather emailed me,
and I responded (tail end trimmed a bit,
Rick, the one I CCed you has the tech's direct phone # and hours, etc.):
---------- Forwarded message ---------
From: Michael Paoli <michael.paoli(a)berkeley.edu>
Date: Mon, Jun 3, 2024 at 6:38 PM
Subject: Re: Comcast ticket#CR145359298
To: Oquin, Summer <Summer_Oquin(a)comcast.com>
Cc: Rick Moen <rick(a)linuxmafia.com>
Hi, thanks for getting back to me on:
Comcast ticket#CR145359298
So, bad news, good news:
Bad news: All appearances and evidence are it is a Comcast Business issue,
Good news: issue not on this account, but on another - on the client end.
So, please add the following note on the ticket:
CR145359298 - issue appears to be on/towards other end,
different Comcast Business account, address:
1105 ALTSCHUL AVE UNIT HMOFC MENLO PARK CA 94025
issue, client IP:
96.95.217.98/29
communication fails with UDP to server: 96.86.170.229 UDP port 5353
Also observed:
Server receives and responds.
Response packets never make it to client (96.95.217.98).
If target port is changed to 53 or protocol changed to TCP,
then client successfully receives reply packets.
Also able to communicate from other Internet clients to
server: 96.86.170.229 UDP port 5353
Once that note has been added, please feel free to close out
CR145359298 at your convenience.
I expect the other Comcast Business customer (whom I've CCed)
will be contacting Comcast Business support and/or you to work to
resolve the matter.
Thanks!
On Mon, Jun 3, 2024 at 3:02 PM Oquin, Summer <Summer_Oquin(a)comcast.com> wrote:
>
> Hello Michael,
>
> I received your ticket regarding the connectivity issues you were experiencing at the business location of 1816 CARLETON ST APT D-HMOFC
>
> BERKELEY CA 94703 and currently I am not seeing anything that would be interfering with your internet connection. I have confirmed there is no dual route with your gateway static 96.86.170.230 and that you do have two devices currently connected on your usable statics 96.86.170.226 and 96.86.170.229. Please let me know if you are still experiencing any issues and what they are by replying to this email directly or by calling me using the number below, and I would be happy to further investigate.
>
>
>
>
>
> Thank you,
>
> Summer
>
> Advanced Tech 4 (ABS)
>
> Comcast Business
>
> Office hours: Mon-Fri 8:00am-4:30pm MST
---------- END Forwarded message ---------
On Mon, Jun 3, 2024 at 7:21 AM Michael Paoli <michael.paoli(a)berkeley.edu> wrote:
>
> SecurityEdge still seems to be optional,
> and not present (yay!) on my Comcast Business account.
> I checked there, looking for it, per their documentation, on where
> it would/should be - and found it not at all present here (yay!).
>
> Also, still waiting to hear back from Comcast Business support, but when I do,
> at this point, this is essentially what I've got for 'em:
> CR145359298 - issue appears to be on/towards other end,
> different Comcast Business account, address:
> 1105 ALTSCHUL AVE UNIT HMOFC MENLO PARK CA 94025
> issue, client IP:
> 96.95.217.98/29
> communication fails with UDP to server: 96.86.170.229 UDP port 5353
> Also observed:
> Server receives and responds.
> Response packets never make it to client (96.95.217.98).
> If target port is changed to 53 or protocol changed to TCP,
> then client successfully receives reply packets.
> Also able to communicate from other Internet clients to
> server: 96.86.170.229 UDP port 5353
>
> On Mon, Jun 3, 2024 at 7:07 AM Al <aw009(a)sunnyside.com> wrote:
> >
> > That security edge feature is no longer optional on Comcast business accounts. However you can log into your Comcast business website portal as yourself and look at your options and very quickly turn security edge off.
> >
> > On June 3, 2024 01:24:23 Michael Paoli via BALUG-Admin <balug-admin(a)lists.balug.org> wrote:
> >
> >> Rick,
> >>
> >> I found non-Comcast Business client I could test from and ...:
> >> $ curl -s https://ipv4.balug.org/myip && dig -p 5353 +nomultiline
> >> @96.86.170.229 +noall +answer sflug.com. SOA
> >> 54.149.53.111
> >> sflug.com. 172800 IN SOA ns1.sf-lug.org. jim.well.com. 1716775812
> >> 10800 3600 3600000 86400
> >> $ sudo traceroute -f 13 -nUp 5353 96.86.170.229
> >> traceroute to 96.86.170.229 (96.86.170.229), 30 hops max, 60 byte packets
> >> 13 96.110.41.78 22.205 ms 68.85.191.206 23.194 ms 96.110.41.74 21.052 ms
> >> 14 162.151.86.58 23.357 ms 162.151.78.186 22.058 ms 162.151.86.58 22.490 ms
> >> 15 162.151.78.186 22.559 ms 96.86.170.229 35.853 ms 40.269 ms
> >> $
> >>
> >> Works fine from there. So, alas, looks like issue on/towards your
> >> Comcast Business side/end of things.
> >> So ... feel free to follow-up with Comcast Business at your convenience.
> >> Might also want to have them cross-reference:
> >> Ticket #: CR145359298
> >> If that's useful. They don't seem to (thus far) give me a way to
> >> update that on-line,
> >> but when they call, I'll let 'em know to call off the dogs on this side
> >> of it - and looks like issue on/towards your Comcast Business side of things.
> >>
> >> On Mon, Jun 3, 2024 at 12:20 AM Michael Paoli
> >> <michael.paoli(a)berkeley.edu> wrote:
> >>>
> >>>
> >>> Rick,
> >>>
> >>> I've opened case with Comcast Business,
> >>> Ticket #: CR145359298
> >>> I tried their on-line chat, that basically walked me through some basic
> >>> checks, then to a not available at this time, call, or ... so, called ...
> >>> got someone nice enough ... not incompetent but no expert, and yeah,
> >>> "of course" quite limited in what they could do ...
> >>> did eventually get it escalated to create the ticket ... as about the
> >>> only option
> >>> 1st tier had left would be to dispatch hardware tech ... which would probably be
> >>> total waste of everyone's time, as was working perfectly fine before, no changes
> >>> in hardware, and works fine on UDP port 53, but not 5353 (and works on TCP).
> >>> Also, did dig a little further ... traceroute ...
> >>> packets actually are in fact making it to the server ... but not back to client,
> >>> so, ... not really sure where the issue would be - could be anywhere between
> >>> "my" Comcast "router", and "yours".
> >>> At first I was thinking most likely at/around my end based upon the
> >>> tracroute data,
> >>> but checking server and seeing it gets packets and responds ...
> >>> could be getting lost/blocked anywhere between - and without ability to
> >>> capture along hops along the way on network, dear knows where. I'd guess
> >>> most likely at/near one of the two ends, but who knows, some security/firewall
> >>> (dis)services push that filtering further away from the endpoints,
> >>> even if they're
> >>> (generally) driven by customers (whether that's penultimate ISP
> >>> end-user customer)
> >>> or smaller to fair sized businesses or ISPs pushing the filtering
> >>> further away from the
> >>> endpoints to aid in more efficient filtering (less undesired traffic -
> >>> when it's not desired,
> >>> better handling of DDoS, etc.).
> >>>
> >>> So, e.g., on server I see:
> >>> 07:14:36.728454 IP 96.95.217.98.55659 > 96.86.170.229.5353: 16449 op8
> >>> [b2&3=0x4243] [17991a] [17477q] [18505n] [19019au][|domain]
> >>> 07:14:36.728465 IP 96.95.217.98.57523 > 96.86.170.229.5353: 16449 op8
> >>> [b2&3=0x4243] [17991a] [17477q] [18505n] [19019au][|domain]
> >>> 07:14:36.729032 IP 96.86.170.229.5353 > 96.95.217.98.48836: 16449 op8
> >>> FormErr- [0q] 0/0/0 (12)
> >>> 07:14:36.729165 IP 96.86.170.229.5353 > 96.95.217.98.55659: 16449 op8
> >>> FormErr- [0q] 0/0/0 (12)
> >>> 07:14:36.729272 IP 96.86.170.229.5353 > 96.95.217.98.57523: 16449 op8
> >>> FormErr- [0q] 0/0/0 (12)
> >>>
> >>> Curious if Al and/or others have same issue with 96.86.170.229.5353
> >>> UDP (which would make
> >>> it more probable issue is on/towards my end), or if it might be more
> >>> specific to the
> >>> linuxmafia.com / guido side of things - in which it might be closer to
> >>> that (Comcast Business) end of things.
> >>>
> >>> On Sun, Jun 2, 2024 at 10:34 PM Michael Paoli via BALUG-Admin
> >>> <balug-admin(a)lists.balug.org> wrote:
> >>>>
> >>>>
> >>>> +Al
> >>>> Uh oh ...
> >>>> the TLDR:
> >>>> looks like most likely it's a Comcast Business issue on my end.
> >>>> Anyway, I'll see if this apparently relatively new disservice that
> >>>> they've enabled that I never requested nor wanted, is anything I've got
> >>>> relatively simple access to disable that crud. And if that's not the case,
> >>>> looks like it'll be time for me to open a support ticket with 'em.
> >>>
> >>>
> >>>> And from guido:
> >>>>
> >>>> # traceroute -nUp 53 -m 15 96.86.170.229
> >>>> traceroute to 96.86.170.229 (96.86.170.229), 15 hops max, 60 byte packets
> >>>> 1 96.95.217.102 1.567 ms 1.714 ms 2.000 ms
> >>>> 2 10.61.209.67 10.034 ms 17.091 ms 17.308 ms
> >>>> 3 96.216.9.141 15.642 ms 16.185 ms 16.438 ms
> >>>> 4 68.85.154.113 15.559 ms 15.263 ms 68.85.154.117 17.271 ms
> >>>> 5 96.108.99.245 21.485 ms 96.108.99.249 23.446 ms 23.462 ms
> >>>> 6 68.86.143.89 21.394 ms 20.951 ms 68.86.143.93 20.611 ms
> >>>> 7 162.151.87.226 21.823 ms 162.151.86.58 18.559 ms 162.151.87.226 13.063 ms
> >>>> 8 162.151.78.186 17.808 ms 17.503 ms 162.151.79.134 19.191 ms
> >>>> 9 68.85.191.206 19.451 ms 68.85.103.154 19.450 ms 68.85.191.206 18.210 ms
> >>>> 10 73.189.65.18 25.648 ms 30.850 ms 30.607 ms
> >>>> 11 96.86.170.229 38.275 ms 38.315 ms 36.705 ms
> >>>> # traceroute -nUp 5353 -m 15 96.86.170.229
> >>>> traceroute to 96.86.170.229 (96.86.170.229), 15 hops max, 60 byte packets
> >>>> 1 96.95.217.102 1.510 ms 1.671 ms 1.922 ms
> >>>> 2 10.61.209.67 10.667 ms 10.61.209.66 16.563 ms 10.61.209.67 17.305 ms
> >>>> 3 96.216.9.141 16.927 ms 96.216.9.137 16.745 ms 16.855 ms
> >>>> 4 * 68.85.154.113 17.025 ms 17.141 ms
> >>>> 5 96.108.99.245 20.670 ms 96.108.99.249 51.907 ms 96.108.99.245 31.021 ms
> >>>> 6 68.86.143.89 19.265 ms 18.382 ms 68.86.143.93 16.142 ms
> >>>> 7 162.151.87.226 18.098 ms 162.151.86.58 12.378 ms 12.306 ms
> >>>> 8 162.151.78.186 11.393 ms 11.518 ms 16.363 ms
> >>>> 9 68.85.191.206 16.545 ms 16.623 ms 17.228 ms
> >>>> 10 73.189.65.18 32.347 ms 24.524 ms 30.043 ms
> >>>> 11 * * *
> >>>> 12 * * *
> >>>> 13 * * *
> >>>> 14 * * *
> >>>> 15 * * *
> >>>> #
> >>>> Bloody damn hell ...
> >>>> looks like most likely it's a Comcast Business issue on my end.
> >>>> I've got nothin' firewalling that, and should work fine.
Trying to figure out something in logfiles. Filtering down this
report just to sf-lug.com, balug.org, and savingthedolph.in DNS stuff,
as "retry limit exceeded" seems to be a recurring theme and I'd like to
figure out why (and fix).
----- Forwarded message from logcheck system account <logcheck(a)linuxmafia.com> -----
Date: Sun, 02 Jun 2024 15:02:01 -0700
From: logcheck system account <logcheck(a)linuxmafia.com>
To: root(a)linuxmafia.com
Subject: linuxmafia.com 2024-06-02 15:02 System Events
System Events
=-=-=-=-=-=-=
Jun 2 14:22:31 linuxmafia named[1093]: client 96.86.170.229#35399: received notify for zone 'balug.org'
Jun 2 14:24:01 linuxmafia named[1093]: zone balug.org/IN: refresh: retry limit for master 96.86.170.229#5353 exceeded (source 0.0.0.0#0)
Jun 2 14:24:01 linuxmafia named[1093]: zone balug.org/IN: Transfer started.
Jun 2 14:24:01 linuxmafia named[1093]: transfer of 'balug.org/IN' from 96.86.170.229#5353: connected using 96.95.217.99#36846
Jun 2 14:24:01 linuxmafia named[1093]: zone balug.org/IN: transferred serial 1717363350
Jun 2 14:24:01 linuxmafia named[1093]: transfer of 'balug.org/IN' from 96.86.170.229#5353: Transfer completed: 1 messages, 8 records, 871 bytes, 0.080 secs (10887 bytes/sec)
Jun 2 14:28:07 linuxmafia named[1093]: zone sf-lug.org/IN: refresh: retry limit for master 96.86.170.229#5353 exceeded (source 0.0.0.0#0)
Jun 2 14:28:07 linuxmafia named[1093]: zone sf-lug.org/IN: Transfer started.
Jun 2 14:28:07 linuxmafia named[1093]: transfer of 'sf-lug.org/IN' from 96.86.170.229#5353: connected using 96.95.217.99#40709
Jun 2 14:28:07 linuxmafia named[1093]: transfer of 'sf-lug.org/IN' from 96.86.170.229#5353: Transfer completed: 0 messages, 1 records, 0 bytes, 0.058 secs (0 bytes/sec)
Jun 2 14:52:03 linuxmafia named[1093]: zone savingthedolph.in/IN: refresh: retry limit for master 96.86.170.229#5353 exceeded (source 0.0.0.0#0)
Jun 2 14:52:03 linuxmafia named[1093]: zone savingthedolph.in/IN: Transfer started.
Jun 2 14:52:03 linuxmafia named[1093]: transfer of 'savingthedolph.in/IN' from 96.86.170.229#5353: connected using 96.95.217.99#35512
Jun 2 14:52:03 linuxmafia named[1093]: transfer of 'savingthedolph.in/IN' from 96.86.170.229#5353: Transfer completed: 0 messages, 1 records, 0 bytes, 0.052 secs (0 bytes/sec)
Jun 2 14:58:05 linuxmafia named[1093]: zone sflug.com/IN: refresh: retry limit for master 96.86.170.229#5353 exceeded (source 0.0.0.0#0)
Jun 2 14:58:05 linuxmafia named[1093]: zone sflug.com/IN: Transfer started.
Jun 2 14:58:05 linuxmafia named[1093]: transfer of 'sflug.com/IN' from 96.86.170.229#5353: connected using 96.95.217.99#47957
Jun 2 14:58:05 linuxmafia named[1093]: transfer of 'sflug.com/IN' from 96.86.170.229#5353: Transfer completed: 0 messages, 1 records, 0 bytes, 0.052 secs (0 bytes/sec)
----- End forwarded message -----
At tne command line (on my nameserver):
$ dig @96.86.170.229 sf-lug.com axfr | wc -l
36
$ dig @96.86.170.229 balug.org | wc -l
18
$ dig @96.86.170.229 savingthedolph.in | wc -l
19
$
I'm going to be lazy (and need to go out for an errand),
so will just say, WTF?
*chef's kiss*
Timo Reitnauer of Wellington, NZ was, indeed, the co-founder of the
original, NZ-based firm. The 2019 buyout caused layoff of the entire
existing staff, and I'm pretty sure Timo has no involvement in the
CentralNic-puppeteered firm based on London.
Still, amusing.
https://www.linkedin.com/posts/timo-reitnauer-237a5b1ab_im-keen-to-try-some…
----- Forwarded message from iwantmyname <help.support.iwantmyname.com(a)getveromail.com> -----
Date: Mon, 03 Jun 2024 05:07:13 +0000
From: iwantmyname <help.support.iwantmyname.com(a)getveromail.com>
To: rick(a)linuxmafia.com
Subject: Need any help with your iwantmyname account?
Reply-To: help(a)support.iwantmyname.com
Hey there,
I noticed that you don't have any domains in your iwantmyname account yet so I wanted to quickly check in to see how you're getting along.
Do you need a hand in buying a new domain name or transferring one from your previous registrar? Just hit the reply button and let me know how I can help you get started.
Cheers,
Timo Reitnauer
Co-Founder
https://iwantmyname.com
----- End forwarded message -----
On Mastodon, I'm @unixmercenary@infosec.exchange.
As such, I just tooted this
(https://infosec.exchange/@unixmercenary/112534258603738688 ):
may be seeking a new #DNSregistrar. Once upon a time, there was a
highly clueful one named ideegeo Group, Ltd. d/b/a IWantMyName.com in
Wellington, NZ, technically a retail reseller for large German registrar
1API.
Early on, their staff efficiently and quickly fixed an odd problem,
where my two domains were suddenly private WHOIS against my wishes: The
tech found that 1API had unilaterally toggled everyone private to
quickly comply with GDPR rollout -- and intervened to revert that on my
domains.
Roll forward to 2019. British multinational CentralNic Group PLC
acquired ideegeo Group Ltd., and shut down the NZ operation.
Uh-oh.
About a year later, I saw that my domains were suddenly private WHOIS
again, saw still nothing in the customer WebUI to adjust that, and
opened another ticket, referencing the first one, speculating 1API might
have done it again, and asking the same fix.
A tech from the new lot immediately closed the ticket with the
explanation that the operator of the .com and .net TLDs had imposed
private WHOIS on all domains, and therefore IWantMyName was powerless to
help me.
I almost accepted this pile of bullhockey, but then thought to
cross-check, among others, domains 1API.net and IWantMyName.com -- whose
public WHOIS data immediately disproved the nonsense claim. I reopened
the ticket, pointing out their claim is provably wrong, and reiterating
my request.
The tech closed the ticket again with the comment that he'd repeated
what the technical staff told him -- not commenting on the fact that it
was provably false.
I escalated this matter to corporate staff in London, saying that
gaslighting customers is uncool, that I could easily take business
elsewhere, and that I'd be deciding that in a couple of days. A senior
tech in London reopened the case, told me he' fix things, did so,
explained that first-level techs had relied on bad information, and
observed (justly) that few customers wished to eschew private WHOIS. As
resolution occurred before my deadline, I stayed.
Yesterday, after verifying that IWantMyName.com's customer WebUI still
doesn't permit early renewal, I opened a new ticket saying "Please
manually extend by two years each of my domains linuxmafia.com and
unixmercenary.net, please charge my credit card of record number NNNN
for the US $95.26 entailed, and please do that now."
I got back a response saying:
"We currently only register and renew domains automatically for one year
at a time.
We've found that longer registration periods lead to a higher chance of
customers losing or forgetting their account details or missing
notifications and ultimately letting their domains expire due to
outdated contact information for expired credit card details.
The annual notifications serve as a reminder of sorts to keep everything
up to date. Or, if something unexpected happens and the domain is no
longer needed, it can be cancelled with no time/money lost.
If you have any other questions, just let us know."
I waited a day, then wrote back saying I'd seen no action on my request.
The tech referred me to the above statement.
I wrote back:
"That was not even anywhere near an answer to my request.
I didn't ask about automatic renewal policy. I requested manual
processing of two-year extension, now, for each of my two domains,
charging the appropriate fees totalling US $95.26 to my credit card of
record.
Please do that now.
I will continue to escalate this matter, if it is not addressed."
This is in "You had one job" territory, nicht wahr? Any fellow Ops
people with clueful-registrar suggestions? Needing to escalate routine
requests has gotten old.
For the record, for good and compelling reasons, I keep domains a long
way from expiration, run a weekly cron job executing d-check
(http://linuxmafia.com/pub/linux/network/) to watch whois for upcoming
renewal dates, and renew well in advance of need.
Likewise, I insist on public WHOIS so it can fulfil its design role of
permitting contact, by anyone observing a problem or other matter
needing attention, to the Administrative, Technical, and Registrant
contacts as appropriate.
"You'll be doxed", someone says says? Funny, that: Maybe they might
use the real street address, real telephone number, real e-mail address,
and "ICBM address" (latitude, longitude, and altitude of my favourite
chair) on my personal Web page, instead.
Michael, this is _not_ a complaint (as I just silenced these via
/etc/logcheck/ignore.d.server/local.rules), but why am I getting
a constant barrage of NOTIFYs about mpaoli.net from your 96.86.170.226
nameserver?
If you figure it out, and curb NOTIFY being sent at 90 second intervals,
please advise, and I'll remove those two "ignore" lines from local.rules .
----- Forwarded message from logcheck system account <logcheck(a)linuxmafia.com> -----
Date: Sun, 02 Jun 2024 18:02:01 -0700
From: logcheck system account <logcheck(a)linuxmafia.com>
To: root(a)linuxmafia.com
Subject: linuxmafia.com 2024-06-02 18:02 System Events
System Events
=-=-=-=-=-=-=
Jun 2 17:02:29 linuxmafia named[1093]: client 96.86.170.226#30759: received notify for zone 'mpaoli.net'
Jun 2 17:02:29 linuxmafia named[1093]: zone mpaoli.net/IN: notify from 96.86.170.226#30759: zone is up to date
Jun 2 17:04:00 linuxmafia named[1093]: client 96.86.170.226#8181: received notify for zone 'mpaoli.net'
Jun 2 17:04:00 linuxmafia named[1093]: zone mpaoli.net/IN: notify from 96.86.170.226#8181: zone is up to date
Jun 2 17:04:00 linuxmafia named[1093]: client 96.86.170.226#37529: received notify for zone 'mpaoli.net'
Jun 2 17:04:00 linuxmafia named[1093]: zone mpaoli.net/IN: notify from 96.86.170.226#37529: zone is up to date
Jun 2 17:05:30 linuxmafia named[1093]: client 96.86.170.226#13482: received notify for zone 'mpaoli.net'
Jun 2 17:05:30 linuxmafia named[1093]: zone mpaoli.net/IN: notify from 96.86.170.226#13482: zone is up to date
Jun 2 17:07:00 linuxmafia named[1093]: client 96.86.170.226#19217: received notify for zone 'mpaoli.net'
Jun 2 17:07:00 linuxmafia named[1093]: zone mpaoli.net/IN: notify from 96.86.170.226#19217: zone is up to date
Jun 2 17:08:31 linuxmafia named[1093]: client 96.86.170.226#30329: received notify for zone 'mpaoli.net'
Jun 2 17:08:31 linuxmafia named[1093]: zone mpaoli.net/IN: notify from 96.86.170.226#30329: zone is up to date
Jun 2 17:10:01 linuxmafia named[1093]: client 96.86.170.226#36447: received notify for zone 'mpaoli.net'
Jun 2 17:10:01 linuxmafia named[1093]: zone mpaoli.net/IN: notify from 96.86.170.226#36447: zone is up to date
Jun 2 17:11:32 linuxmafia named[1093]: client 96.86.170.226#10624: received notify for zone 'mpaoli.net'
Jun 2 17:11:32 linuxmafia named[1093]: zone mpaoli.net/IN: notify from 96.86.170.226#10624: zone is up to date
Jun 2 17:11:33 linuxmafia named[1093]: client 96.86.170.226#22179: received notify for zone 'mpaoli.net'
Jun 2 17:11:33 linuxmafia named[1093]: zone mpaoli.net/IN: notify from 96.86.170.226#22179: zone is up to date
Jun 2 17:13:02 linuxmafia named[1093]: client 96.86.170.226#12961: received notify for zone 'mpaoli.net'
Jun 2 17:13:02 linuxmafia named[1093]: zone mpaoli.net/IN: notify from 96.86.170.226#12961: zone is up to date
Jun 2 17:14:33 linuxmafia named[1093]: client 96.86.170.226#29402: received notify for zone 'mpaoli.net'
Jun 2 17:14:33 linuxmafia named[1093]: zone mpaoli.net/IN: notify from 96.86.170.226#29402: zone is up to date
Jun 2 17:16:04 linuxmafia named[1093]: client 96.86.170.226#10227: received notify for zone 'mpaoli.net'
Jun 2 17:16:04 linuxmafia named[1093]: zone mpaoli.net/IN: notify from 96.86.170.226#10227: zone is up to date
Jun 2 17:16:04 linuxmafia named[1093]: client 96.86.170.226#62072: received notify for zone 'mpaoli.net'
Jun 2 17:16:04 linuxmafia named[1093]: zone mpaoli.net/IN: notify from 96.86.170.226#62072: zone is up to date
Jun 2 17:17:34 linuxmafia named[1093]: client 96.86.170.226#38200: received notify for zone 'mpaoli.net'
Jun 2 17:17:34 linuxmafia named[1093]: zone mpaoli.net/IN: notify from 96.86.170.226#38200: zone is up to date
Jun 2 17:19:04 linuxmafia named[1093]: client 96.86.170.226#31395: received notify for zone 'mpaoli.net'
Jun 2 17:19:04 linuxmafia named[1093]: zone mpaoli.net/IN: notify from 96.86.170.226#31395: zone is up to date
Jun 2 17:19:05 linuxmafia named[1093]: client 96.86.170.226#43946: received notify for zone 'mpaoli.net'
Jun 2 17:19:05 linuxmafia named[1093]: zone mpaoli.net/IN: notify from 96.86.170.226#43946: zone is up to date
Jun 2 17:20:35 linuxmafia named[1093]: client 96.86.170.226#52576: received notify for zone 'mpaoli.net'
Jun 2 17:20:35 linuxmafia named[1093]: zone mpaoli.net/IN: notify from 96.86.170.226#52576: zone is up to date
Jun 2 17:22:06 linuxmafia named[1093]: client 96.86.170.226#30061: received notify for zone 'mpaoli.net'
Jun 2 17:22:06 linuxmafia named[1093]: zone mpaoli.net/IN: notify from 96.86.170.226#30061: zone is up to date
Jun 2 17:23:36 linuxmafia named[1093]: client 96.86.170.226#44444: received notify for zone 'mpaoli.net'
Jun 2 17:23:36 linuxmafia named[1093]: zone mpaoli.net/IN: notify from 96.86.170.226#44444: zone is up to date
Jun 2 17:25:06 linuxmafia named[1093]: client 96.86.170.226#36944: received notify for zone 'mpaoli.net'
Jun 2 17:25:06 linuxmafia named[1093]: zone mpaoli.net/IN: notify from 96.86.170.226#36944: zone is up to date
Jun 2 17:26:37 linuxmafia named[1093]: client 96.86.170.226#28976: received notify for zone 'mpaoli.net'
Jun 2 17:26:37 linuxmafia named[1093]: zone mpaoli.net/IN: notify from 96.86.170.226#28976: zone is up to date
Jun 2 17:28:07 linuxmafia named[1093]: client 96.86.170.226#11125: received notify for zone 'mpaoli.net'
Jun 2 17:28:07 linuxmafia named[1093]: zone mpaoli.net/IN: notify from 96.86.170.226#11125: zone is up to date
Jun 2 17:28:08 linuxmafia named[1093]: client 96.86.170.226#56348: received notify for zone 'mpaoli.net'
Jun 2 17:28:08 linuxmafia named[1093]: zone mpaoli.net/IN: notify from 96.86.170.226#56348: zone is up to date
Jun 2 17:29:38 linuxmafia named[1093]: client 96.86.170.226#24066: received notify for zone 'mpaoli.net'
Jun 2 17:29:38 linuxmafia named[1093]: zone mpaoli.net/IN: notify from 96.86.170.226#24066: zone is up to date
Jun 2 17:31:08 linuxmafia named[1093]: client 96.86.170.226#43222: received notify for zone 'mpaoli.net'
Jun 2 17:31:08 linuxmafia named[1093]: zone mpaoli.net/IN: notify from 96.86.170.226#43222: zone is up to date
Jun 2 17:31:09 linuxmafia named[1093]: client 96.86.170.226#47912: received notify for zone 'mpaoli.net'
Jun 2 17:31:09 linuxmafia named[1093]: zone mpaoli.net/IN: notify from 96.86.170.226#47912: zone is up to date
Jun 2 17:32:39 linuxmafia named[1093]: client 96.86.170.226#61955: received notify for zone 'mpaoli.net'
Jun 2 17:32:39 linuxmafia named[1093]: zone mpaoli.net/IN: notify from 96.86.170.226#61955: zone is up to date
Jun 2 17:34:09 linuxmafia named[1093]: client 96.86.170.226#59555: received notify for zone 'mpaoli.net'
Jun 2 17:34:09 linuxmafia named[1093]: zone mpaoli.net/IN: notify from 96.86.170.226#59555: zone is up to date
Jun 2 17:35:39 linuxmafia named[1093]: client 96.86.170.226#18134: received notify for zone 'mpaoli.net'
Jun 2 17:35:39 linuxmafia named[1093]: zone mpaoli.net/IN: notify from 96.86.170.226#18134: zone is up to date
Jun 2 17:37:10 linuxmafia named[1093]: client 96.86.170.226#3483: received notify for zone 'mpaoli.net'
Jun 2 17:37:10 linuxmafia named[1093]: zone mpaoli.net/IN: notify from 96.86.170.226#3483: zone is up to date
Jun 2 17:37:10 linuxmafia named[1093]: client 96.86.170.226#41816: received notify for zone 'mpaoli.net'
Jun 2 17:37:10 linuxmafia named[1093]: zone mpaoli.net/IN: notify from 96.86.170.226#41816: zone is up to date
Jun 2 17:38:40 linuxmafia named[1093]: client 96.86.170.226#34917: received notify for zone 'mpaoli.net'
Jun 2 17:38:40 linuxmafia named[1093]: zone mpaoli.net/IN: notify from 96.86.170.226#34917: zone is up to date
Jun 2 17:40:11 linuxmafia named[1093]: client 96.86.170.226#24244: received notify for zone 'mpaoli.net'
Jun 2 17:40:11 linuxmafia named[1093]: zone mpaoli.net/IN: notify from 96.86.170.226#24244: zone is up to date
Jun 2 17:41:41 linuxmafia named[1093]: client 96.86.170.226#52424: received notify for zone 'mpaoli.net'
Jun 2 17:41:41 linuxmafia named[1093]: zone mpaoli.net/IN: notify from 96.86.170.226#52424: zone is up to date
Jun 2 17:43:12 linuxmafia named[1093]: client 96.86.170.226#44240: received notify for zone 'mpaoli.net'
Jun 2 17:43:12 linuxmafia named[1093]: zone mpaoli.net/IN: notify from 96.86.170.226#44240: zone is up to date
Jun 2 17:44:42 linuxmafia named[1093]: client 96.86.170.226#44982: received notify for zone 'mpaoli.net'
Jun 2 17:44:42 linuxmafia named[1093]: zone mpaoli.net/IN: notify from 96.86.170.226#44982: zone is up to date
Jun 2 17:46:13 linuxmafia named[1093]: client 96.86.170.226#48398: received notify for zone 'mpaoli.net'
Jun 2 17:46:13 linuxmafia named[1093]: zone mpaoli.net/IN: notify from 96.86.170.226#48398: zone is up to date
Jun 2 17:46:13 linuxmafia named[1093]: client 96.86.170.226#12034: received notify for zone 'mpaoli.net'
Jun 2 17:46:13 linuxmafia named[1093]: zone mpaoli.net/IN: notify from 96.86.170.226#12034: zone is up to date
Jun 2 17:47:44 linuxmafia named[1093]: client 96.86.170.226#18028: received notify for zone 'mpaoli.net'
Jun 2 17:47:44 linuxmafia named[1093]: zone mpaoli.net/IN: notify from 96.86.170.226#18028: zone is up to date
Jun 2 17:49:14 linuxmafia named[1093]: client 96.86.170.226#40531: received notify for zone 'mpaoli.net'
Jun 2 17:49:14 linuxmafia named[1093]: zone mpaoli.net/IN: notify from 96.86.170.226#40531: zone is up to date
Jun 2 17:49:14 linuxmafia named[1093]: client 96.86.170.226#27099: received notify for zone 'mpaoli.net'
Jun 2 17:49:14 linuxmafia named[1093]: zone mpaoli.net/IN: notify from 96.86.170.226#27099: zone is up to date
Jun 2 17:50:44 linuxmafia named[1093]: client 96.86.170.226#6762: received notify for zone 'mpaoli.net'
Jun 2 17:50:44 linuxmafia named[1093]: zone mpaoli.net/IN: notify from 96.86.170.226#6762: zone is up to date
Jun 2 17:52:15 linuxmafia named[1093]: client 96.86.170.226#60085: received notify for zone 'mpaoli.net'
Jun 2 17:52:15 linuxmafia named[1093]: zone mpaoli.net/IN: notify from 96.86.170.226#60085: zone is up to date
Jun 2 17:53:45 linuxmafia named[1093]: client 96.86.170.226#48793: received notify for zone 'mpaoli.net'
Jun 2 17:53:45 linuxmafia named[1093]: zone mpaoli.net/IN: notify from 96.86.170.226#48793: zone is up to date
Jun 2 17:55:16 linuxmafia named[1093]: client 96.86.170.226#10334: received notify for zone 'mpaoli.net'
Jun 2 17:55:16 linuxmafia named[1093]: zone mpaoli.net/IN: notify from 96.86.170.226#10334: zone is up to date
Jun 2 17:56:47 linuxmafia named[1093]: client 96.86.170.226#41121: received notify for zone 'mpaoli.net'
Jun 2 17:56:47 linuxmafia named[1093]: zone mpaoli.net/IN: notify from 96.86.170.226#41121: zone is up to date
Jun 2 17:58:17 linuxmafia named[1093]: client 96.86.170.226#44158: received notify for zone 'mpaoli.net'
Jun 2 17:58:17 linuxmafia named[1093]: zone mpaoli.net/IN: notify from 96.86.170.226#44158: zone is up to date
Jun 2 17:58:17 linuxmafia named[1093]: client 96.86.170.226#35535: received notify for zone 'mpaoli.net'
Jun 2 17:58:17 linuxmafia named[1093]: zone mpaoli.net/IN: notify from 96.86.170.226#35535: zone is up to date
Jun 2 17:59:47 linuxmafia named[1093]: client 96.86.170.226#1727: received notify for zone 'mpaoli.net'
Jun 2 17:59:47 linuxmafia named[1093]: zone mpaoli.net/IN: notify from 96.86.170.226#1727: zone is up to date
Jun 2 18:01:18 linuxmafia named[1093]: client 96.86.170.226#64910: received notify for zone 'mpaoli.net'
Jun 2 18:01:18 linuxmafia named[1093]: zone mpaoli.net/IN: notify from 96.86.170.226#64910: zone is up to date
Jun 2 18:01:18 linuxmafia named[1093]: client 96.86.170.226#19593: received notify for zone 'mpaoli.net'
Jun 2 18:01:18 linuxmafia named[1093]: zone mpaoli.net/IN: notify from 96.86.170.226#19593: zone is up to date
----- End forwarded message -----
I note with no objection that you dropped offlist, but I'll move back
anyway.
Quoting Michael Paoli (michael.paoli(a)berkeley.edu):
> I'm thinking the option may also be generic,
> but whether or not it actually does anything may be
> TLD specific, so, e.g. may do nothing for com.,
> but may actually be usefully effective for some other
> TLDs. I.e. com. may not even use or accept "Billing Contact"
> into whois data, but some other TLDs may accept such.
FWIW, I also see that Billing Contact isn't shown in public WHOIS for
unixmercenary.net, either -- but that's consistent with your hypothesis,
since both com. and net. are operated by VeriSign, Inc. as
"authoritative registry", or, as VeriSign calls it, the firm's "naming
services division".
https://en.wikipedia.org/wiki/Verisign#Naming_services
That line of business it acquired by buying Network Solutions in 2000,
divesting the _regisrar_ portion in 2003 but keeping the registry
(wholesale & back-end) portion. They also, ugh, have the contract for
the root nameserver operation, operating two of them, "A" and "J",
directly. Plus maintaining the root zonefile.
NetSol, in turn, got the football in 1993 under contract from NSF. The
division between "registry" and "registrar" (within NetSol) followed in
1998 when ICANN got conjured into existence (at the invitation of Dept.
of Commerce, IIRC), and ICANN grandly pronounced that it required NetSol
to engineer an interface permitting competing registrars. (ICANN by
itself was a "Who the hell are you?" paper tiger, but they had the
blessing of US Dept. of Commerce Dept., which had legal and checkbook
power, and ISTR somehow the issuance of marching orders somehow went
from Commerce to ICANN to IATA (which is a nonprofit under Commerce
Dept. contract, hence checkbook power).
VeriSign Naming Services is now at 12061 Bluemont Way, Reston Town
Center development, Reston, VA.
Anyway, bottom line, I concur with your guess that "Billing Contact
doesn't go into WHOIS" is probably implemented at the VeriSign
com./net./etc. end of things, and is probably a legacy of NetSol 1990s
buildout that's still embedded into everything, there.