This is an outline of how a typical series of requests might occur in a BIND environment. You're at blah.customer.isp.com. You want to log in to somewhere.student.cwru.edu. You run this command:
ssh somewhere.cwru.eduWhat happens? First, blah sends a query to one of its local name servers, say, ns1.isp.com. The query asks for A (address) records for the name somewhere.cwru.edu, and it asks the name server to consult other name servers, if necessary, to find the requested records.
The name server notices that it isn't in charge of the name somewhere.cwru.edu, and moreover, it doesn't have the requested information in its cache. But the request came from a customer's machine, and it requested that other servers be consulted, so that's what will happen. This process is called recursion.
ns1.isp.com might start with the root servers, but more likely, it will already have records in its cache that tell where the name servers for the .edu domain are. So next, one of the .edu servers will be consulted with a new query coming from ns1.isp.com, asking for the same information as the original query, but without requesting recursion. The .edu server will respond with a referral: "I don't know, but here are the name servers for the .cwru.edu domain. Try asking them." ns1.isp.com adds these name server records to its cache, for a limited time, to speed up future queries.
ns1.isp.com will select one of the .cwru.edu servers - say, ns2.cwru.edu - and send it another query. ns2.cwru.edu will notice that it is in charge of the name somewhere.cwru.edu, so it can return an authoritative answer - either the requsted information, or an indication that that information does not exist.
ns2.cwru.edu consults the data it's been provided with, and it sees that somewhere.cwru.edu has no address record, but it it has a CNAME (canonical name) record - i.e., it's an alias for another name: somewhere.student.cwru.edu. This name has an address record. Both the CNAME record and the address record are returned to ns1.isp.com, which adds them to its cache and returns them back to you at blah.customer.isp.com.
Now you have the address of the host you want to connect to, so you make the connection. But sshd on somewhere.cwru.edu is configured to accept connections only from certain hosts. It can extract your address - say, 1.2.3.4 - from the connection itself, but it needs to map this back to a hostname to decide whether to accept or drop the connection. It does this by looking up PTR (pointer) records for the name 4.3.2.1.in-addr.arpa.
This query proceeds much like the last one. somewhere.cwru.edu asks, say, ns3.cwru.edu to recursively find the PTR record. ns3.cwru.edu contacts one of the root servers, say, f.root-servers.net. (The addresses of the root servers might be known, or some other nearby name server might be consulted to find them.) f.root-servers.net returns a referral to a name server for 1.in-addr.arpa, which returns a referral to a name server for 2.1.in-addr.arpa, which, say, is your ISP's server, since it owns all 1.2.*.* addresses. That server returns a PTR record containing blah.customer.isp.com, and sshd uses this to decide whether to let you in.
(If sshd is being paranoid, it may also double-check this name by looking up the address for blah.customer.isp.com. If none of the addresses belonging to that name match the address you're connecting from, you won't be let in. This is done to thwart an attack where the attacker controls the in-addr.arpa domain for the address ey is connecting from (4.3.2.1.in-addr.arpa in the example above, if you were the attacker) - ey could serve a trusted name for her own address. But presumably, ey won't be in control of the domain for the trusted name, so the addresses won't match.)