Your nameservers have AAAA records, but you didn't include the IPv6 addresses as glue records (hence the glue records are not consistent with the addresses returned by your nameserver). Running the check with both IPv4 and IPv6 addresses listed returns the following:
Will a DNS lookup for a subdomain, such as assets.example.com, be faster if the parent domain, example.com, has already been resolved?
Assuming that there is a caching server in the scene, yes. This is because in order to find an A record for anything in example.com., the nameservers for example.com. must be known. When the request for assets.example.com. is made the nameservers for example.com. should already be cached, and so the only query is for assets.example.com. itself.
I know there are other intermediate DNS servers, such as those provided by ISPs. At what point are they queried?
These are typically caching or recursive nameservers. These do the hard work on your behalf (the multiple requests to traverse the tree) and then cache the result to speed up later queries for the same name.
Are all authoritative com nameservers, for example, exact mirrors, or would a resolver have to try each in turn?
Yes, they contain the same information. The resolver just has to find one which is actually working.
If the com TLD nameserver we're referred to does not know how to resolve example, is it right to say that's the end of the line: example.com cannot be resolved?
If the .com. nameserver responds and says example.com. does not exist, then the result is that the name does not exist. If the .com. nameserver doesn't respond to the query the resolver should try a different .com. nameserver.
When I register a domain and configure nameservers, am I in effect editing a group of NS records for my subdomain in the database used by the nameservers for that TLD? Does the registrar itself maintain "proxy" nameservers?
Correct. When you register the domain you provide NS records (and some A records if you need glue) to be inserted in the parent domain. The registrar doesn't necessarily run those nameservers itself, but have a mechanism to modify the database of those nameservers.
Best Answer
Read the source Luke :)
From tcpdump/print-domain.c:
So % indicates "checking disabled" which to my understanding of RFC4035 indicates that the resolver is not enforcing authentication of the RRs on the server.
From bind/lib/bind/resolv/res_mkquery.c:
According to RFC2671 it's perfectly legal for a resolver to include additional data, and with this raise the UDP packet size above the 512 byte limit. So Ladadadada's assumption is correct in this aspect.
Thanks for your time and sorry that I didn't read the source before...