Unable to Connect Archer AX6000 Router to Hitron Fiber Optics Modem

[wordweaver777 (Bill Kochman)]

David and Sebby, thank you for the additional information. It is going to take me some time to understand and absorb the different options, and then to decide what to do.

Actually, I am still holding on to the hope that my ISP will resolve this issue on their end, which would obviously be the easiest solution. I have been with them for about two decades now, so you would think that they would at least extend this courtesy to me.

I am not sure why they are not offering static IP addresses for their fiber option connections. But whatever the case may be, they should at least be willing to make an exception for me, considering how long I have been with them. I am going to continue to press the issue with them the next time I have them on the phone. After all, they created this mess in the first place by providing me with wrong information. I have had a static IP address with them for many years, and everything was working fine. So it is just not fair that they suddenly pull the rug out from under me.

Sorry David for my slow response to your previous message, but as you can imagine, I am up to my forehead in trying to work all of this out. Please don’t think that I’ve been ignoring your comment.

To make matters worse, in addition to the static IP address issue, yesterday morning, of all days, after almost seven years of constant use as my web server, my iMac’s hard drive decided to fail with an unrepairable disk error.

I have tried everything I can think of, from using the terminal, to trying to restore across the Internet, to trying to get it to recognize my external backup drives, to even using an old macOS 10.6.2 – Snow Leopard – disk to at least try to get it running again, so that I can completely restore to my current Ventura configuration. But everything has been to no avail.

With the static IP address issue, I was dead in the water as far as Internet access to my web server was concerned. Now I am deader than dead.

So for now, I am temporarily forced to running my web server on my personal work machine. Obviously, this is not a good or ideal choice, because I do a lot on my personal machine, and the web server should have its own dedicated machine, as it has had for many years now … until now.

Until I make a more permanent choice regarding the static IP issue, I am going to go to my registrar and put my current dynamic IP in the A records, and see what happens. It hasn’t changed in two days now.

I just hate the idea of having to spend more money for something that is not my fault.

[wordweaver777 (Bill Kochman)]

Sebby, yes, I forgot to mention that the asynchronous connection with the fibre optic cable is a HUGE piece of bait for me. As I said before, here on Guam – and I imagine everywhere – the ISPs are REALLY chintzy when it comes to upstream. I mean, just a few visitors, and the pipes get clogged. Not any more with this new fiber optic connection.

[wordweaver777 (Bill Kochman)]

David, I understand that CNAME entries are basically aliases. But the one thing I am not fully understanding is how register.com would know what to do with billkochman.com if there is no IP address in the A record. How would register.com know where to send the https request next? How would that request get from register.com to my ISP’s DNS server, and then to my server?

Or are you saying that I would use the CNAME record in my register.com configuration, in conjunction with a dynamic IP service such as noip.com?

In other words, I would create a CNAME record in my register.com configuration which points to my noip.com domain name. The http request would then be sent to noip.com, and noip.com would know where to send the https request next, because I have my router configured with noip.com, which keeps them updated to my latest dynamic IP address.

Is that it, or am I still way off base and sounding like a total newbie?

[seth (Seth Anderson)]

I don’t know which of Guam’s 2 ISPs you are using, but I do know that my grandmother who lives in Yona didn’t get back her basic internet service for nearly 2 months after Typhoon Mawar. In other words, they are very chintzy

[wordweaver777 (Bill Kochman)]

Ha! Seth, she should be thankful! I got mine back a few days under FOUR MONTHS … and then they kill me with a trojan horse by giving me free fiber optic for three months, but without telling me that I would lose my static IP address, so that my entire operation is now offline. :(

[Shamino (David C.)]

@wordweaver777

Or are you saying that I would use the CNAME record in my register.com configuration, in conjunction with a dynamic IP service such as noip.com?

In other words, I would create a CNAME record in my register.com configuration which points to my noip.com domain name. The http request would then be sent to noip.com, and noip.com would know where to send the https request next, because I have my router configured with noip.com, which keeps them updated to my latest dynamic IP address.

That’s pretty much it, but this resolution takes place at the DNS level, before HTTP gets involved.

A web browser will give billkochman.com to its DNS client (probably built-in to the OS it’s running on). That client will try to get an address. It won’t find one, but it will find the CNAME aliasing it to your No-IP domain. It will then request an address for that name, and it will get your dynamic IP address. The DNS client will return that address to the browser, and the browser will send the HTTP request to that address (but still with billkochman.com in the request headers).

This isn’t unusual. Consider again, Apple’s web site. They use a whole system of CNAME records so their web site gets served by a pool of servers belonging to the Akamai content distribution network.

There is no A record for www.apple.com. It is a CNAME pointing it to www.apple.com.edgekey.net:

$ dig www.apple.com any

; <<>> DiG 9.8.3-P1 <<>> www.apple.com any
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 49064
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 4, ADDITIONAL: 8

;; QUESTION SECTION:
;www.apple.com.			IN	ANY

;; ANSWER SECTION:
www.apple.com.		1618	IN	CNAME	www.apple.com.edgekey.net.
...

www.apple.com.edgekey.net it itself a CNAME pointing it at www.apple.com.edgekey.net.globalredir.akadns.net:

$ dig www.apple.com.edgekey.net any

; <<>> DiG 9.8.3-P1 <<>> www.apple.com.edgekey.net any
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 42018
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 13, ADDITIONAL: 8

;; QUESTION SECTION:
;www.apple.com.edgekey.net.	IN	ANY

;; ANSWER SECTION:
www.apple.com.edgekey.net. 21290 IN	CNAME	www.apple.com.edgekey.net.globalredir.akadns.net.
...

And then www.apple.com.edgekey.net.globalredir.akadns.net is yet another CNAME pointing it to e6858.dscx.akamaiedge.net:

$ dig www.apple.com.edgekey.net.globalredir.akadns.net any

; <<>> DiG 9.8.3-P1 <<>> www.apple.com.edgekey.net.globalredir.akadns.net any
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 19795
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 10, ADDITIONAL: 6

;; QUESTION SECTION:
;www.apple.com.edgekey.net.globalredir.akadns.net. IN ANY

;; ANSWER SECTION:
www.apple.com.edgekey.net.globalredir.akadns.net. 3171 IN CNAME	e6858.dscx.akamaiedge.net.
...

Finally, e6858.dscx.akamaiedge.net has an A record with an IPv4 address and two AAAA records, with two IPv6 addresses, which is where your browser actually goes when you try to get a page from www.apple.com:

$ dig e6858.dscx.akamaiedge.net any

; <<>> DiG 9.8.3-P1 <<>> e6858.dscx.akamaiedge.net any
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 37053
;; flags: qr rd ra; QUERY: 1, ANSWER: 3, AUTHORITY: 8, ADDITIONAL: 9

;; QUESTION SECTION:
;e6858.dscx.akamaiedge.net.	IN	ANY

;; ANSWER SECTION:
e6858.dscx.akamaiedge.net. 20	IN	A	23.220.132.219
e6858.dscx.akamaiedge.net. 20	IN	AAAA	2600:1408:c400:188d::1aca
e6858.dscx.akamaiedge.net. 20	IN	AAAA	2600:1408:c400:1883::1aca
...

It’s also interesting to note that if you compare this with the results I saw yesterday, that the e6858 hostname mapped to different IP addresses from what I’m seeing tonight. This is clearly part of how Akamai operates, bringing various mirror-servers on- and off-line as needed to balance global load. And Apple doesn’t have to care, because all those changes take place entirely within Akamai’s DNS servers - Apple’s own DNS server only has the CNAME that hands everything off to the Akamai DNS servers.

Your configuration would be much simpler than this, but it’s the same general principle.

[wordweaver777 (Bill Kochman)]

Thanks for the explanation, David. So it seems that I pretty much did understand it after all. I guess the question now — assuming that my ISP is unable to provide me with a satisfactory solution — is to question why I should pay both register.com and noip.com, when I don’t have to. Well, actually, I am already paid up on register.com until 2030. But why split up what I need to do when it can all be done by noip.com?

Here is something related which you might find interesting. Earlier this afternoon, after putting my web server and websites on my personal work machine — being as the other machine is dead in the water — I went to both register.com and Go Daddy, to change my A record to my current dynamic IP address.

Well, to my surprise, within a few hours, my new IP address for my one website on Go Daddy has already propagated all the way out here on Guam. In contrast, the new IP address for Bill’s Bible Basics still hasn’t propagated out here from register.com. So Go Daddy is clearly faster when it comes to new URL propagation.

[Sebby (Sabahattin Gucukoglu)]

Assuming you can’t get your static IP back but nonetheless you do have a valid public IP address of your own then, yes, it would seem to me that you should choose a registrar that offers DNS services capable of receiving DDNS updates from clients. Obviously, if your router supports NOIP with your own custom hostnames in your own domains, then that would seem to be a clear win for NOIP. I just checked and my registrar of choice, Joker, offers this feature, and they’re very reasonably priced—but no router I use supports them, so the update would be done with a script or program on a computer. I use Cloudflare for DNS, chiefly for DNSSEC and TLSA support; they too support dynamic DNS but only from a dedicated client program or script. Just make sure you’re happy with what you get and that you’re paying a good price for it.

DNS propagation isn’t in the way of spreading waves, but rather in predictable memory loss. Briefly: DNS servers have caches storing records of information, and each record has a “time-to-live”. So a record “propogates” once a cache has forgotten, either because the time-to-live expired or for some other reason (server runs out of memory, is restarted or dies, or is actually a cluster of different servers you hit at different times with different requests). There is therefore no simple way to say why you saw a different propagation time from one service to another, but TTL is probably the simplest explanation. That or your records are being queried infrequently enough that caches have simply aged out the records under resource pressure.

[Shamino (David C.)]

@wordweaver777

Well, to my surprise, within a few hours, my new IP address for my one website on Go Daddy has already propagated all the way out here on Guam. In contrast, the new IP address for Bill’s Bible Basics still hasn’t propagated out here from register.com. So Go Daddy is clearly faster when it comes to new URL propagation.

As @Sebby wrote, the concept of DNS propagation is not nearly so straightforward.

It’s not like when you mirror data, where the master server pushes updates to lots of backup servers.

DNS servers by default don’t provide data for more than the specific domains they’re configured to use. Everything else they have is cache. And cache entries have timeout parameters (provided by the server that is responsible for the records).

For instance, on my home DNS server, my domain has the following data at the top of its zone config file (domain and emal addresses redacted):

$TTL  604800
@  IN SOA  myhost.example.com. myname.myemailhost.example.com. (
           2021082401   ; Serial
               604800   ; Refresh
                86400   ; Retry
              2419200   ; Expire
               604800 ) ; Negative Cache TTL

In the above:

• The $TTL directive specifies that if not configured otherwise, all entries in the file will expire after 604,800 seconds (7 days).
• The SOA (start of authority) record contains metadata about the zone (domain). In this example, it specifies:
  • The name of the zone (leftmost column). The @ means it is the “current” origin. When used at the top of the file, before any other records have been specified, it is the zone’s default domain name (as specified by the config file that’s loading the zone file).
  • The master name server for the domain is myhost.example.com. The trailing . means this is the full name and not a prefix to the zone’s domain name. In my real system, it’s the hostname of the server running Bind.
  • The administrator responsible for the domain is myname.myemailhost.example.com. Again, the trailing . means this is a full name and not a prefix. In my real system, it’s my e-mail address.
    • By convention, this should be an e-mail address with the @ replaced by a ..
    • If the user name has a dot in it, the dot should be quoted with a \ character. So joey.bagadonuts@example.com would be entered as joey\.bagadonuts.example.com.
  • The serial number (2021082401) is an arbitrary number, It should be changed to a larger value every time the file changes.
    • Although you could just apply sequential numbers, starting from 1, by convention, the number used is the date and a serial number (YYYYMMDDss). So the above would be the first edit of August 24, 2021 (the last time I changed the file).
  • The Refresh value (604,800) is the interval (in seconds) at which secondary name servers should re-query the zone. This is most commonly set to 86,400 (24 hours) for small and stable zones. In my case, since I rarely change anything, I set it to 7 days.
  • The Retry value (86,400) is the interval (in seconds) at which secondary servers should retry requests (vs returning cached data) if the primary server doesn’t respond. This is most commonly set to 7200 (2 hours) for small and stable zones. I set mine to 24 hours, but it’s really irrelevant, because I don’t have any secondary server on my domain.
  • The Expire value (2,419,200) is the time interval (in seconds) describing how long secondary servers should keep responding when the master server isn’t responding. Common practice is 3,600,000 (1000 hours). My server is using 28 days, since my values rarely change.
  • The negative response caching TTL (604,800) is used to calculate the time-to-live. DNS servers will return the smaller of this value and the $TTY value (above) with responses. DNS clients are allowed to cache the value for up to the time, after which, they must discard it and request a fresh copy. Common practice is 172,800 (2 days). I’m using 7 days.

Anyway, all that having been said, when you changed your master zone files (at register.com and at GoDaddy), both should have immediately changed their corresponding SOA records to have a new serial number and the updated A records. So anybody who asks after that will get the new data.

But servers between yourself and the master server may have cached values. Those values may linger until they expire. So if your ISP has a cached address, you may not see the change for a day or two. But if it doesn’t have a cached value, then you should see the change immediately. The same applies to any other DNS servers between yourself and the master server for your domain.

[Shamino (David C.)]

And just for completeness, here’s a summary of what actually happens when your request a DNS resolution (assuming nobody has anything cached). Feel free to skip this if you like.

For example, let’s try to resolve www.apple.com to an IPv4 address. Our host will send our DNS server (probably your ISP’s server) a request for www.apple.com, requesting an A record, containing its address.

Since nothing is cached, your ISP’s server has to send a request to one of the root servers. These are a pool of (currently) 13 DNS hostnames, named A through M in the root-servers.net domain, which in turn are associated with thousands of servers distributed worldwide. The IP addresses needed to access these servers is pre-configured in all DNS servers (and can be dynamically updated if they change), which is how DNS servers can bootstrap themselves into operation.

The root servers only know about where the name-servers are for all of the top-level domains (.com, .net, .mx, etc.). They know nothing else. So if I send one a query for www.apple.com, I will only get NS records. In this case, the pool of Generic Top-Level Domain (GTLD) servers which are (among other things) responsible for the .com domain:

$ dig @a.root-servers.net www.apple.com
...
com.			172800	IN	NS	e.gtld-servers.net.
com.			172800	IN	NS	b.gtld-servers.net.
com.			172800	IN	NS	j.gtld-servers.net.
com.			172800	IN	NS	m.gtld-servers.net.
com.			172800	IN	NS	i.gtld-servers.net.
com.			172800	IN	NS	f.gtld-servers.net.
com.			172800	IN	NS	a.gtld-servers.net.
com.			172800	IN	NS	g.gtld-servers.net.
com.			172800	IN	NS	h.gtld-servers.net.
com.			172800	IN	NS	l.gtld-servers.net.
com.			172800	IN	NS	k.gtld-servers.net.
com.			172800	IN	NS	c.gtld-servers.net.
com.			172800	IN	NS	d.gtld-servers.net.
...

(Although I’m not showing it here, the A and AAAA records for the name servers are also returned, to avoid a simple request from exploding into a data-storm of DNS requests. The “dig” utility also reports metadata about the request, which I’m also not presenting here.).

So, the next thing I need to do is send my request to one of those GTLD servers. They will not resolve the address, but they will give me NS records for the name servers responsible for the apple.com domain:

$ dig @a.gtld-servers.net www.apple.com
...
apple.com.		172800	IN	NS	a.ns.apple.com.
apple.com.		172800	IN	NS	b.ns.apple.com.
apple.com.		172800	IN	NS	c.ns.apple.com.
apple.com.		172800	IN	NS	d.ns.apple.com.
...

Now, I need to send my request to one of those name servers. And since they are authoritative, for the apple.com domain, they will resolve www.apple.com, returning (as we previously saw) a CNAME record declaring that it is an alias to www.apple.com.edgekey.net:

$ dig @a.ns.apple.com www.apple.com
...
www.apple.com.		1800	IN	CNAME	www.apple.com.edgekey.net.
...

Now we need to resolve www.apple.com.edgekey.net. And since nothing is cached, that means going all the way back to the root servers. Which will give us the GTLD pool again, because the GTLD servers are responsible for .net as well as .com:

$ dig @a.root-servers.net www.apple.com.edgekey.net
...
net.			172800	IN	NS	e.gtld-servers.net.
net.			172800	IN	NS	f.gtld-servers.net.
net.			172800	IN	NS	m.gtld-servers.net.
net.			172800	IN	NS	i.gtld-servers.net.
net.			172800	IN	NS	j.gtld-servers.net.
net.			172800	IN	NS	b.gtld-servers.net.
net.			172800	IN	NS	a.gtld-servers.net.
net.			172800	IN	NS	c.gtld-servers.net.
net.			172800	IN	NS	k.gtld-servers.net.
net.			172800	IN	NS	h.gtld-servers.net.
net.			172800	IN	NS	l.gtld-servers.net.
net.			172800	IN	NS	g.gtld-servers.net.
net.			172800	IN	NS	d.gtld-servers.net.
...

So we now send that request to a GTLD server and get the name server for edgekey.net:

$ dig @a.gtld-servers.net www.apple.com.edgekey.net
...
edgekey.net.		172800	IN	NS	ns1-66.akam.net.
edgekey.net.		172800	IN	NS	usw6.akam.net.
edgekey.net.		172800	IN	NS	adns1.akam.net.
edgekey.net.		172800	IN	NS	ns4-66.akam.net.
edgekey.net.		172800	IN	NS	ns7-65.akam.net.
edgekey.net.		172800	IN	NS	ns5-66.akam.net.
edgekey.net.		172800	IN	NS	a6-65.akam.net.
edgekey.net.		172800	IN	NS	a12-65.akam.net.
edgekey.net.		172800	IN	NS	a5-65.akam.net.
edgekey.net.		172800	IN	NS	a16-65.akam.net.
edgekey.net.		172800	IN	NS	a18-65.akam.net.
edgekey.net.		172800	IN	NS	a28-65.akam.net.
edgekey.net.		172800	IN	NS	a13-65.akam.net.
...

Note that all of these are various Akamai DNS servers, which is as we’d expect since Edgekey is an Akamai service. So we now send our request to one of these, which tells us that (as we previously saw) it is a CNAME alias to www.apple.com.edgekey.net.globalredir.akadns.net:

$ dig @ns1-66.akam.net www.apple.com.edgekey.net
...
www.apple.com.edgekey.net. 21600 IN	CNAME	www.apple.com.edgekey.net.globalredir.akadns.net.
...

So now we go around again to resolve this hostname. Let’s assume that we’ve already cached the fact that .net is handled by the GTLD servers and send our request there first. We get a different pool of Akamai DNS server (apparently, edgekey.net is managed by a different set of servers from akadns.net):

dig @a.gtld-servers.net www.apple.com.edgekey.net.globalredir.akadns.net
...
akadns.net.		172800	IN	NS	a3-129.akadns.net.
akadns.net.		172800	IN	NS	a7-131.akadns.net.
akadns.net.		172800	IN	NS	a11-129.akadns.net.
akadns.net.		172800	IN	NS	a1-128.akadns.net.
akadns.net.		172800	IN	NS	a9-128.akadns.net.
akadns.net.		172800	IN	NS	a5-130.akagtm.org.
akadns.net.		172800	IN	NS	a28-129.akagtm.org.
akadns.net.		172800	IN	NS	a13-130.akagtm.org.
akadns.net.		172800	IN	NS	a18-128.akagtm.org.
akadns.net.		172800	IN	NS	a12-131.akagtm.org.
...

And now we send the request to one of those DNS servers to find that is is (as we already know) yet another CNAME, aliasing it to e6858.dscx.akamaiedge.net:

$ dig @a3-129.akadns.net www.apple.com.edgekey.net.globalredir.akadns.net
...
www.apple.com.edgekey.net.globalredir.akadns.net. 3600 IN CNAME	e6858.dscx.akamaiedge.net.
...

So here we go again. As before, we have already cached the fact that .net is handled by the GTLD pool, but since we haven’t yet seen or cached akamaiedge.net, we need to send our request there next, and we’ll get yet another pool of Akamai DNS servers for that domain:

$ dig @a.gtld-servers.net e6858.dscx.akamaiedge.net
...
akamaiedge.net.		172800	IN	NS	la1.akamaiedge.net.
akamaiedge.net.		172800	IN	NS	la3.akamaiedge.net.
akamaiedge.net.		172800	IN	NS	lar2.akamaiedge.net.
akamaiedge.net.		172800	IN	NS	ns3-194.akamaiedge.net.
akamaiedge.net.		172800	IN	NS	ns6-194.akamaiedge.net.
akamaiedge.net.		172800	IN	NS	ns7-194.akamaiedge.net.
akamaiedge.net.		172800	IN	NS	ns5-194.akamaiedge.net.
akamaiedge.net.		172800	IN	NS	a12-192.akamaiedge.net.
akamaiedge.net.		172800	IN	NS	a28-192.akamaiedge.net.
akamaiedge.net.		172800	IN	NS	a6-192.akamaiedge.net.
akamaiedge.net.		172800	IN	NS	a1-192.akamaiedge.net.
akamaiedge.net.		172800	IN	NS	a13-192.akamaiedge.net.
akamaiedge.net.		172800	IN	NS	a11-192.akamaiedge.net.
...

And now we send our request to one of those DNS servers. But note that we’re not getting an address yet. The akamaiedge.net DNS server doesn’t know the address for the full hostname, so it sends us more NS records for servers that are authoritative for the dscx.akamaiedge.net domain:

$ dig @la1.akamaiedge.net e6858.dscx.akamaiedge.net
...
dscx.akamaiedge.net.	4000	IN	NS	n3dscx.akamaiedge.net.
dscx.akamaiedge.net.	4000	IN	NS	n4dscx.akamaiedge.net.
dscx.akamaiedge.net.	4000	IN	NS	n2dscx.akamaiedge.net.
dscx.akamaiedge.net.	4000	IN	NS	n1dscx.akamaiedge.net.
dscx.akamaiedge.net.	4000	IN	NS	n7dscx.akamaiedge.net.
dscx.akamaiedge.net.	4000	IN	NS	n6dscx.akamaiedge.net.
dscx.akamaiedge.net.	4000	IN	NS	n5dscx.akamaiedge.net.
dscx.akamaiedge.net.	4000	IN	NS	n0dscx.akamaiedge.net.
...

So we now send our request to one of those DNS servers, which finally returns an A record, which gives us the IP address we need:

$ dig @n3dscx.akamaiedge.net e6858.dscx.akamaiedge.net
...
e6858.dscx.akamaiedge.net. 20	IN	A	23.55.200.211
...

When you realize all that must go on behind the scenes, it’s pretty incredible that most of the time when you type in or click on a URL, that address resolution happens so fast it seems immediate.

A lot of this is due to the fact that DNS servers cache quite a lot of data, so requests for commonly-accessed hostnames (like Apple’s web server) are almost always resolved using values cached by nearby DNS servers.

But when something changes, clients may need to wait for those cached values to expire, which might take a few days. Ideally, the old IP address should remain valid for a few days during the transition period so users don’t see an interruption, but when that’s not possible (or if the transition isn’t done properly), users may see a site go off-line for a couple of days until the cached data expires, and then it will “magically” come back with its new address.

[wordweaver777 (Bill Kochman)]

David, thank you for the extensive explanation. Wow! When you let it rip, you let it rip! Yes, I understand TTL. I have used it a few times in some of the cron jobs I have had to set up for my server over the years.

Actually, what I discovered not even an hour ago, is that while my Go Daddy domain name – bovineexcrement.com – populated very quickly, my register.com domains may have done so as well. However, I just didn’t know it. The reason for that is because some time ago, apparently while conducting some tests on my personal work machine with regards to my actual server machine, I added some entries in my personal work machine’s hosts file which contain my static IP address for my primary domain. That is, billkochman.com

As a result, each time that I tried to go to that domain, as well as to csnet.live, Firefox was unable to connect for obvious reasons: nobody lives at that static IP address as of three days ago.

The minute I removed those entries from my hosts, both of the aforementioned domains are accessible again, in addition to my Go Daddy domain. So, all is well for the time being … until my dynamic IP address changes again.

Right now I am in the middle of crafting an email letter to one of the higher ups in the hierarchy at my ISP. She has assisted me in the past, so hopefully, she will be able to pull some weight and assist me again with regards to getting my static IP address restored. I am not giving up this fight so easily. Given my loyalty to their company for some twenty years now, I deserve it, right?

[wordweaver777 (Bill Kochman)]

Sebby, thanks again for your input. As I just told David, I am going to continue to fight for getting my static IP address restored with my ISP. I am hoping that the lady I am writing to will advocate for me, and get me what I want, need and deserve. After all, it would be the easiest, least-complicated solution. All I would have to do is go back into my A records and enter the new static IP address.

But, yes, I agree, if for some odd reason it remains a no-go, then going with noip.com definitely seems to be the reasonable and logical way to go, even if it means dishing out more money.

[wordweaver777 (Bill Kochman)]

Ha! I am a little surprised that none of you sharp-eyed and more technical folks who have participated in this thread, haven’t commented on a mistake I have made several times now while participating in this thread. That error is that I kept saying “asynchronous” – meaning that upstream and downstream are not the same – when in fact, the fiber optic connection I now have is indeed symmetrical at 150 mb maximum. To date, during my testing, I have seen download speeds of up to 15-16 MB/second. So, as I expected, and already knew, you never get exactly what they promised, due to Internet congestion, and a host of other factors. But it is still much better than what I was getting with my previous coaxial cable setup.

BTW, earlier this morning I sent a lengthy, diplomatic but very straightforward email to my ISP, in which I clearly explained my position, as well as my expectations. Now I am waiting to see how they respond. I only have one goal: restore my static IP address.