Intermittent issues resolving "labor.upload.akamai.com"

[tale]

On Fri, Feb 3, 2023 at 4:32 AM Greg Choules via bind-users
<bind-users at lists.isc.org> wrote:
>> From a quick look in Wireshark at what my own server (9.18.8) is doing, this looks like Akamai not responding correctly to a BIND QNAME minimisation query. Here's one response, from 95.101.36.192 for example, of many similar ones showing an issue. The response code shouldn't be REFUSED:

Definitely protocol issues going on with akamai.net.  A query for the
target in the OP, at an akamai.net auth, indicates  that there's a
zone cut at e.stor:

dig +noall +auth r33674-33729.neards.1.cftp.e.stor.lb.akamai.net
@zc.akamaitech.net
e.stor.lb.akamai.net.   4000    IN      NS      n4e.stor.lb.akamai.net.
e.stor.lb.akamai.net.   4000    IN      NS      n0e.stor.lb.akamai.net.
e.stor.lb.akamai.net.   4000    IN      NS      n3e.stor.lb.akamai.net.
e.stor.lb.akamai.net.   4000    IN      NS      n2e.stor.lb.akamai.net.
e.stor.lb.akamai.net.   4000    IN      NS      n1e.stor.lb.akamai.net.

but it returns that the stor label is a lame delegation:

dig stor.lb.akamai.net @zc.akamaitech.net | awk '/status/ {print $6}'
REFUSED,

Even if lb were itself delegated, REFUSED is still the wrong answer
for stor; in that case it should get the delegation for lb.  But lb
isn't delegated either, so refused is even more wrongerer.

I'll forward this over to Akamai.
-- 
tale