I've contracted an ex Azure DNS team member to write up articles about DNS [1] and published it for free. I considered my DNS knowledge okay, but I learned something every article he wrote.
If you want to be better at DNS than >99% of your colleagues for the rest of your career, then invest a single day in reading those.
I have found (and commented on previously, sorry for the repetition but it's so common as to warrant it IMHO) that one of the biggest hard-to-diagnose issues is in https://www.nslookup.io/learning/zone-delegation/ under "The duality of NS records":
>So there are actually TWO sets of NS records for every zone: the authoritative NS record set in the child zone and the delegation NS record set in the parent zone. It is recommended that these NS record sets be identical, but they do not have to be. Generally speaking, DNS resolvers can use either set of NS records. When a resolver has access to both, it will prefer the authoritative NS record set from the child zone. The way DNS data should be preferred, or ranked, by resolvers is specified in RFC 2181 section 5.4.1.
"Generally speaking" is all-too true.
NS records in the root are glue. If a resolver only has these records, it will (likely) cache them and not bother getting the NS records from the authoritative zone server (i.e., asking one of the "glue" servers for NS records), and consider itself done for that's zone's NS settings.
But the two most common mistakes in DNS zone administration is lame delegation (non-existent SOA or NS records from the nameserver), and having different NS records in the root vs the authoritative zone, possibly with different (and conflicting) DNS configurations.
Admins update the servers named in the SOA they are administering, but don't update the root (typically, at their registrar). They feel free to change the names in the NS records, or do it and forget to update the root -- because it quite often works fine. As long as the glue points to at least one working (non-lame) nameserver, all might seem okay.
The moral of the story is that it is very risky not to keep the root's glue in sync with the NS records in the zone (including TTL values!).
If you want to be better at DNS than >99% of your colleagues for the rest of your career, then invest a single day in reading those.
[1]: https://www.nslookup.io/learning/