Under TRRP, Ingress Tunnel Routers (ITRs) cache protocol and egress information for each destination IP address which transits the router. This fails to take advantage of subnetting knowledge where a set of egress information is valid for a range of IP addresses. The Zone Transfer Identifier for TRRP offers a way for an ITR reduce the number of routes it has to cache by seeking and retaining the complete set of egress information for a particular netmask.
DNS Route Specifier:
TRRP specifies routes via DNS TXT records in the format "pp,ii,route pp,ii,route ..." where pp is a hexidecimal priority, ii is a protocol Identifier and route is the egress information needed by the Identifier.
Identifier: zt = Zone Transfer.
Priority: the priority for the "zt" identifier should always be "ff". An ITR should ignore the priority of the zt identifier regardless of its setting.
Route: The "route" parameter offers the netmask from which the zone should be constructed. It is a decimal number between 0 and 24 for IPv4 addresses and between 0 and 124 for IPv6 addresses. The number indicates the count of "1" digits in the netmask's base-2 representation. It must be evenly divisible by 8 for IPv4 addresses and evenly divisible by 4 for IPv6 addresses. If the netmask is not evenly divisible, the ITR must ignore the zone transfer identifier.
Example:
The ITR makes a DNS TXT request for 4.3.2.1.v4.trrp.arpa. It receives one TXT record in response:
80,g4,192.168.100.1 ff,zt,24
This means that the DNS Route server has advised the ITR that a DNS zone containing the route information for this zone is available at the /24 boundary, i.e. 3.2.1.v4.trrp.arpa. The ITR expects to find a DNS SOA record for 3.2.1.v4.trrp.arpa and it expects to be able to transfer the zone via TCP to port 53 of any DNS server designated as authoritative for the zone.
How to do a zone transfer:
Once advised that a zone transfer exists for a particular zone, it may verify the information by requesting the SOA record for the zone. If the SOA record exists, it may transfer the zone from any NS server specified to be authoritative for the zone.
Note that in order to transfer the zone, the authoritative DNS server must accept DNS connections on TCP port 53 and must allow any requestor to transfer the zone.
Unlike the normal DNS secondarying process, the transferred zone is from an untrusted source. Accordingly, the ITR must carefully seek and remove any "glue" entries which provide information for which the zone is not authoritative.
Where the authoritative DNS server is smart enough to dynamically reorder the Route records based on the requesting IP address, it should do so for the transferred zone as well. The "refresh after" time offered by the authoratitive DNS server should be the same as the shortest TTL of any entry inside it the zone.
When to do a zone transfer:
When an ITR receives a DNS Route which contains a netmask in a "zt" Identifier, it should cache the fact that a zone is claimed to be available for the specified range of addresses. When the ITR next receives packet for a destination which is not yet cached but which falls within the same netmask, it should make the normal TRRP lookup and the SOA lookup in parallel. If the SOA lookup request returns a valid DNS zone then the ITR should transfer the zone and implement the records in its cache, discarding any more specific cached routes. Regardless of whether the zone transfer is successful, the cached zone "claim" from the first request should be discarded.
The ITR must recheck the SOA when the TTL expires. If the SOA version number increased by at least 1 or if the SOA version number has decreased by more than 10000, the ITR must retransfer or discard the entire zone.
If the ITR receives a host-unreachable message for any of the specified ETRs, it must immediately recheck the zone's SOA at the authoritative servers regardless of the TTL. Such rechecks should be rate limited to once every 5 seconds to avoid DOSing the authoritative server.
Why do a Zone Transfer instead of a Netmask Lookup?
The Netmask Identifier allows networks to efficiently specify simple routing relationships: everything within this /24 routes the same way. A Zone Transfer allows networks to efficiently specify complex routing relationships: These particular IP addresses route according to policy X while those follow policy Y.