In a secure zone, a resolver can query for the initial NXT associated with the zone name. Using the next domain name RDATA field from that RR, it can query for the next NXT RR. By repeating this, it can walk through all the NXTs in the zone. If there are no wildcards, it can use this technique to find all names in a zone. If it does type ANY queries, it can incrementally get all information in the zone and thus defeat attempts to administratively block zone transfers.
If there are any wildcards, this NXT walking technique will not find any more specific RR names in the part of the name space the wildcard covers. By doing explicit retrievals for wildcard names, a resolver could determine what intervals are covered by wildcards but still could not, with these techniques, find any names inside such intervals except by trying every name.
If it is desired to block NXT walking, the recommended method is to add a zone wide wildcard of the KEY type with the no-key type value and with no type (zone, entity, or user) bit on. This will cause there to be one zone covering NXT RR and leak no information about what real names exist in the zone. This protection from pseudo-zone transfers is bought at the expense of eliminating the data origin authentication of the non-existence of names that NXT RRs can provide. If an entire zone is covered by a wildcard, a malicious server can return an RR produced by matching the resulting wildcard NXT and can thus hide all the real data and delegations in the zone that have more specific names.