Parents simply store one master public key for each child; this is much more practical. This means that a little data is pushed to the parent, instead of massive amounts of data being exchanged between the parent and children. This does mean that clients have to do a little more work when verifying keys. More specifically, verifying a DNS zone's KEY RRset requires two signature verification operations instead of the one required by RFC 2535 (there is no impact on the number of signatures verified for other types of RRsets). Most view this as a small price to pay, since it makes DNSSEC deployment more practical. Authenticating NXDOMAIN responses and NSEC Cryptographically proving the absence of a domain requires signing the response to every query for a non-existent domain. This is not a problem for online signing servers, which keep their keys available online. However, DNSSEC was designed around using offline computers to sign records so that zone-signing-keys could be kept in cold storage. This represents a problem when trying to authenticate responses to queries for non-existent domains since it is impossible to pre-generate a response to every possible hostname query. The initial solution was to create NSEC records for every pair of domains in a zone. Thus if a client queried for a record at the non-existent k.example.com, the server would respond with an NSEC record stating that nothing exists between a.example.com and z.example.com. However, this leaks more information about the zone than traditional unauthenticated NXDOMAIN errors because it exposes the existence of real domains. Preventing domain walking The NSEC3 records (RFC 5155) were created as an alternative which hashes the name instead of listing them directly. Over time, advancements in hashing using GPUs and dedicated hardware meant that NSEC3 responses could be cheaply brute forced using offline dictionary attacks. NSEC5 has been proposed to allow authoritative servers to sign NSEC responses without having to keep a private key that can be used to modify the zone. Thus stealing an NSEC5KEY would only result in the ability to more easily enumerate a zone. Due to the messy evolution of the protocol and a desire to preserve backwards compatibility, online DNSSEC signing servers return a "white lie" instead of authenticating a denial of existence directly. The technique outlined in RFC 4470 returns a NSEC record in which the pairs of domains lexically surrounding the requested domain. For example, request for