DNS hierarchy: Does more labels lead to increased DNS resolution time?

I have been taught that DNS resolvers work backwards from the top-level domain, checking for child nameservers at each level. For example, a resolver trying to resolve a.b.example.com would, assuming no caching, consult the root servers, then the .COM nameservers, then check b.example.com for its own NS records -- and if there are none -- resolve this fourth-level domain using example.com's authoritative nameservers. I understand that this child NS checking must happen for the DNS to function properly, but does this add to the DNS resolution time of "deeper" subdomains such as fourth, fifth, and sixth-level subdomains compared to "shallower" labels such as second and third-level domains?

I would think that glue records would negate this when the resolution involves authoritative nameservers (for example, Nominet appears to allow glue records for both .UK and .CO.UK domains), but what about situations where glue records are not involved or are only partially involved (e.g. a.b.c.d.example.com. vs. www.example.com.)? Thank you for your time.

I have been taught that DNS resolvers work backwards from the top-level domain, checking for child nameservers at each level.

The resolver doesn't so much check for nameservers at each level, rather it gets redirected at (potentially) each delegation. Consider the case where our recursive resolver hasn't got any records cached but knows of the root zone.

A client asks the question c.b.a.example.com. IN A, the resolver does not know who is authoritative for c.b.a.example.com., b.a.example.com., ..., example.com. or com.. It does know who is authoritative for . (the root zone) though.

The resolver asks a root nameserver c.b.a.example.com. IN A, but since the root nameservers aren't authoritative for com., they would reply something along the lines of com. IN NS ... to state the nameservers which are authoritative for com.. The resolver goes on to ask one of those nameservers the same question of c.b.a.example.com. IN A, which might return another delegation of example.com. IN NS ....

It's not the case that each label in a name corresponds to a delegation, after all, it could be the case that c.b.a.example.com. is in the example.com. zone, such that when the resolver asks a nameserver authoritative for example.com. the question c.b.a.example.com. IN A, it can answer c.b.a.example.com. IN A ... (unless of course it delegates, at say a.example.com.).

It's expected that each delegation increases resolution time (possibly not in the case where a server might be authoritative for multiple of those delegations), but this doesn't necessarily mean that more labels lead to increased resolution times.

As for glue records, they are not authoritative. Hypothetically, if example.com. had a nameserver ns1.example.com. with an A record also in the com. zone as a glue record, we may still ask ns1.example.com. for its own A record(s), since for client queries we should ask an authoritative nameserver for the answer.

Does more labels lead to increased DNS resolution time?

No, not in general, because you have to remember (which is often misunderstood) that . in a name is NOT necessarily a delegation.

To take your own example, as your description is slightly wrong because of the above, for a.b.example.com, once the querying nameserver has found the authoritative nameservers for example.com it query those, and they MAY have directly the answer for a.b.example.com because b.example.com is not necessarily a separate zone with different nameservers delegated out of zone example.com.

You can't know where delegation points are just by looking at a string, you need to do active DNS queries. For example gouv.fr is NOT delegated out of fr, where co.uk is delegated out of uk... but with exact same nameservers (observing the SOA record allows to see where the delegation happens).

As for

I have been taught that DNS resolvers work backwards from the top-level domain

First they start from root, to be perfectly exact. Then, the concept is true, but there are ton of caches. So, in practice, it rarely has to start again from the far right. Nameservers of .com for example, as well as those of names being "always" requested (like the top X websites...) will be in all caches, and as such won't trigger new queries (except when TTL goes to zero of course, but then it is one query, result put in cache and then result used for tons of further queries).

I would think that glue records

Glue records have nothing to do with the above, or almost. There are coming into play for only a very specific case, where nameservers are in-bailiwick of the domain name they serve. Then they are needed, but do also create all sort of problems so that their merit is dubious regarding making queries faster.