Original text:
Index  I  Insecure delegation 

Reviewer comments:
Should terms in some sections be alphabetized? Or should some sections be split up more? I realize the current sorting is to start with the most relevant terms and then define ones that are connected to those terms, and on from there. However, as I was reading through some of the longer sections (5 and 6), I found the current order a bit confusing. For instance, at the beginning of section 5, it starts off with: Resolver Stub resolver Iterative mode Recursive mode ... and I was saying "hey, what about a recursive resolver?" and then I found that farther down the page. But then after that it goes: Recursive resolver Priming Root hints Negative caching Authoritative servers ... And then later: Zone transfer Secondary server Slave server Primary server Primary master Which I just found confusing. (For instance, why does Primary appear after Secondary?) I realize that alphabetizing is probably not the right solutions (unless we are making a "dictionary"), but I wonder about at least splitting up section 5 into separate sections for "DNS Servers" and "DNS Clients". As it is right now I found it a bit confusing to move through all the terminology. Just a suggestion - feel free to ignore, of course.
Alphabetizing is indeed the wrong solution. We want a kind of a flow, but that could mean different things to different people. If you can suggest specific reorderings, that would be useful.
Would the right answer be an alphabetic index?
Alphabetic indexes in current RFCs have been a massive failure. They might be better when we have HTML RFCs, but we hope to be done with this before they exist.
Well, arguably they alerady exist on the tools site. So there's that. Also, while alphabetic indexes have often failed, the class of RFCs that contain only definitions, such as this one is, is pretty small. I note that RFC 6365 has an index. It's a little unfortunate that it refers to page numbers instead of sections, but it's still helpful to find a term. A
Added an index in URL

Revised text:
Index <ins> A Alias Anycast Apex Asterisk label Authoritative data Authoritative server Authoritative-only server arpa: Address and Routing Parameter Area Domain C CNAME Canonical name Child Class independent Closest encloser Closest provable encloser Combined signing key (CSK) D DNS operator DNSSEC Policy (DP) DNSSEC Practice Statement (DPS) DNSSEC-aware and DNSSEC-unaware Delegation Delegation-centric zone Domain name E EDNS EPP Empty non-terminals (ENT) F Fast flux DNS Forward lookup Forwarder Forwarding Full resolver Full-service resolver Fully qualified domain name (FQDN) G Global DNS Glue records H Hardware security module (HSM) Hidden master Host name </ins> I <ins> IDN In-bailiwick Infrastructure domain </ins> Insecure delegation <ins> Instance Iterative mode K Key signing key (KSK) L Label Locally served DNS zone M Master file Master server N NODATA NSEC NSEC3 Naming system Negative caching Negative response Next closer name O OPT Occluded name Open resolver Opt-out Origin Out-of-bailiwick Owner P Parent Passive DNS Policy-implementing resolver Presentation format Primary master Primary server Priming Private DNS Public suffix R RDAP RR RRset Recursive mode Recursive resolver Referrals Registrant Registrar Registry Resolver Reverse DNS, reverse lookup Root hints Root zone S SOA field names Secondary server Secure Entry Point (SEP) Service name Signed zone Signing software Slave server Source of Synthesis Split DNS Stealth server Stub resolver Subdomain T TLD TTL Trust anchor U Unsigned zone V Validating resolver Validation View W WHOIS Wildcard Wildcard domain name Z Zone Zone cut Zone enumeration Zone signing key (ZSK) Zone transfer </ins>