Every nameserver is authoritative

The AA bit in a DNS response means "this answer comes from a server that holds this zone". This check asks every address of every delegated nameserver for the zone apex, directly and with recursion off, and reads that bit. A server named in the delegation that does not hold the zone is a lame delegation: listed as an authority, with nothing to be authoritative about.

It is graded as a failure rather than a nuisance because of how resolvers use a nameserver set. They do not work through it in order — they choose, usually by measured latency, and they will happily choose the broken one. So the domain does not fail; it fails for some queries, from some resolvers, at some times. That is the hardest shape of fault to get reported and the hardest to reproduce once somebody does.

The usual cause is a migration finished on one side only: nameservers changed at the registrar while the old provider still lists the zone, or a new provider that requires the zone to be created on their side before it will answer for it. A typo in an NS record produces the same thing — the name resolves, a server answers, and it has never heard of your zone.

Decide whether the lame server should be serving this zone. If it should, add the zone to it. If it should not, remove it from the delegation at the registrar and from the NS record set in the zone — both places, or the two disagree and you have traded one fault for another.

Check the answer directly rather than through a resolver: dig +norecurse @ns1.example.net example.com SOA, and look for aa in the flags. Through a recursive resolver you cannot tell which server answered, which is what lets lame delegations survive for years.

After a migration, leave the old nameservers serving the correct zone until the parent-side TTL has expired everywhere — a day or two for most gTLDs. Removing them from the delegation and switching them off the same afternoon is what creates this state in the first place.