Hi, @rpw. I love DNS questions and I’ll do my best to answer these. I’m going to address each domain separately.
Before I go into details, I want to clarify one key aspect of working with DNS at Netlify - we we can and cannot help with.
What we can do! 
- troubleshoot issues with Netlify DNS
- check the correctness of DNS records for services hosted at Netlify
- help get records entered into our Netlify DNS service
- track down the point of failure for external DNS services (Netlify or not Netlify)
What we cannot do.
- check the correctness of DNS records for any service not hosted at Netlify
- troubleshoot the internals of third-party systems
The point I am making is, if you have a DNS record for a service we are not providing and don’t have any information about - we have no way of knowing if this is the “correct” record.
So, for any third-party services, you will need to contact those services or consult their documentation to determine the correct values.
Once correct values are known, we are absolutely happy to troubleshoot the entry of the records themselves as well as the checking that the DNS service is answering correctly for any records configured with our service.
Enough caveats! On to answers!
beauhaus.net
For this domain, I do show the Netlify DNS enabled. One of the best ways to check this is by querying the whois record and seeing the name servers returned there:
$ whois beauhaus.net | grep -i "name server"
Name Server: DNS1.P02.NSONE.NET
Name Server: DNS2.P02.NSONE.NET
Name Server: DNS3.P02.NSONE.NET
Name Server: DNS4.P02.NSONE.NET
Name Server: DNS1.P02.NSONE.NET
Name Server: DNS2.P02.NSONE.NET
Name Server: DNS3.P02.NSONE.NET
Name Server: DNS4.P02.NSONE.NET
Another good check in using dig with the +trace option. This does a recursive lookup from the top-level domain (TLD) name servers down to the authoritative server for the domain. Also, +trace lookup answers will often differ from a standard query (which will not use the authoritative DNS server directly). These differences often are the key to revealing a root cause for DNS issues.
The <CUT - TEXT REMOVED> indicates removed lines from the output which showed the TLD answers. The remaining lookup is a response from a TLD name server (l.gtld-servers.net) and then the authoritative server for
$ dig beauhaus.net NS +trace
<CUT - TEXT REMOVED>
;; Received 1169 bytes from 199.7.83.42#53(l.root-servers.net) in 32 ms
beauhaus.net. 172800 IN NS dns1.p02.nsone.net.
beauhaus.net. 172800 IN NS dns2.p02.nsone.net.
beauhaus.net. 172800 IN NS dns3.p02.nsone.net.
beauhaus.net. 172800 IN NS dns4.p02.nsone.net.
A1RT98BS5QGC9NFI51S9HCI47ULJG6JH.net. 86400 IN NSEC3 1 1 0 - A1RUUFFJKCT2Q54P78F8EJGJ8JBK7I8B NS SOA RRSIG DNSKEY NSEC3PARAM
A1RT98BS5QGC9NFI51S9HCI47ULJG6JH.net. 86400 IN RRSIG NSEC3 8 2 86400 20191030061324 20191023050324 36407 net. FL85OYk++rt2usgp3123/tt4nn05+L4hy73ZuYqatEhBiuNKWaGN9zIX 4yRKHIvMT0cDivs+G+ourg/y96hn1A7g+gPCv06KDCOm0o7RxGUkxNH7 MTmlUr4o0eG1MSiNoG0IykABL7sZ04JyyglIR1OWjYXZMa8HLn56mFb1 bss0+pYew4We1T1Sz3GSphFyRjnT9GNzhBdHNuSDhwwxSQ==
BUAI40VRFU38FICVNE835GMPV965GMAT.net. 86400 IN NSEC3 1 1 0 - BUB1E70EU453Q0PD3SA3MB8Q86Q28DG5 NS DS RRSIG
BUAI40VRFU38FICVNE835GMPV965GMAT.net. 86400 IN RRSIG NSEC3 8 2 86400 20191030060727 20191023045727 36407 net. P4GiW/xiHFNj31P1zSEQBTkOHtazOiIgWLnFSnj8c/pa/lwoICmx+w9J E9WkEenTbfmgVKYx/f+aNrwcOOOK6FWWFkib3zeT/X7TPiUZl/DLCXdz bWnhUoROynkKPOpZIoFh5IYydTUOv79RjJPnd+dxxR3ksNBssFLvq0LK 4Oc0sSpQozH7kbkJnRX1zUZdhmU4P+qXHmyllUb0+mDDbw==
;; Received 740 bytes from 192.41.162.30#53(l.gtld-servers.net) in 17 ms
beauhaus.net. 3600 IN NS ns06.domaincontrol.com.
beauhaus.net. 3600 IN NS ns05.domaincontrol.com.
beauhaus.net. 3600 IN NS dns1.p02.nsone.net.
beauhaus.net. 3600 IN NS dns2.p02.nsone.net.
beauhaus.net. 3600 IN NS dns3.p02.nsone.net.
beauhaus.net. 3600 IN NS dns4.p02.nsone.net.
;; Received 182 bytes from 198.51.45.2#53(dns2.p02.nsone.net) in 16 ms
This shows something interesting. The top level DNS server (l.gtld-servers.net) shows four name server (NS) record for this domain:
beauhaus.net. 172800 IN NS dns1.p02.nsone.net.
beauhaus.net. 172800 IN NS dns2.p02.nsone.net.
beauhaus.net. 172800 IN NS dns3.p02.nsone.net.
beauhaus.net. 172800 IN NS dns4.p02.nsone.net.
But the Netlify controlled name server shows six name servers:
beauhaus.net. 3600 IN NS ns06.domaincontrol.com.
beauhaus.net. 3600 IN NS ns05.domaincontrol.com.
beauhaus.net. 3600 IN NS dns1.p02.nsone.net.
beauhaus.net. 3600 IN NS dns2.p02.nsone.net.
beauhaus.net. 3600 IN NS dns3.p02.nsone.net.
beauhaus.net. 3600 IN NS dns4.p02.nsone.net.
However, those top two (ns05 and ns06) will never be used. Those two records can be deleted in Netlify DNS.
There are two other records I want to mention. First this one:
beauhaus.net. 600 IN A 50.63.202.32
This is an A record pointing the bare domain to an IP address (something outside of Netlify). It is definitely okay to do this at Netlify (or any other DNS service provider as far as I know) but whether or not this is correct - that is something only you can answer.
The second record is this one:
_domainconnect.beauhaus.net. 3600 IN CNAME _domainconnect.gd.domaincontrol.com.
This looks like a verification record needed for web hosting done by the domain registrar. It isn’t related to Netlify’s services and isn’t required by us. So, just like the A record above, only you can say if this is needed or not. My best guess is that it is not currently needed. On the other hand, if you do still have a website for this domain (or one of its subdomains like blog.beauhaus.net) also hosted at GD it could still be.
recessct.com
This looks to be working correctly at this time. When moving any domain name to Netlify DNS, the biggest factor affecting changed is the time to live (TTL) value in the name server (NS) records before those records are changed.
It is not uncommon for NS records to have values of 86400, which is the time that other name servers should cache this record in seconds. If one “does the math”, 86400 is 24 hours. NS records with this TTL will take 24 hours to expire and so the new record won’t take effect for that long. Often, this is when a dig example.com NS and a dig example.com NS +trace (both) are helpful and the differences between the two will show that caching is the root cause.
Many people rely on Google for DNS. In these cases, it can be helpful to try clearing their public DNS cache for your NS records here:
Other thoughts
I’m not sure if you still need this rule or not:
https://rpw-ref4.netlify.com/ myClientsSite.com
The correct syntax for such a rule would be:
https://rpw-ref4.netlify.com/* https://myclientssite.com/:splat 301!
(I removed the capital letters because domain names ignore case.)
This rule would would cause any request for that Netlify site to be restarted at the same path but at the new domain name.
However, in most cases, if you just wanted to direct traffic for that domain to some other site, you would make DNS record (wherever DNS is configured) point the domain where you wanted it to go and just delete the Netlify site. Why have a site at Netlify at all if all traffic is just directed elsewhere?
Again, though, I think you probably are past needing this. I just wanted to cover the details, though, in case such a rule is needed in the future.
Redirect and rewrites are very useful and there is more information about them here:
Also, if you are moving DNS service to Netlify, there is information about how to avoid downtime here:
And for changes to the hosting of existing site, there are more details about minimizing downtime here:
If there are other question, we’re happy to follow-up again.