On 5/8/2014 5:13 PM, John Levine wrote:
DNSMadeEasy calls this an "ANAME" record, internally they just lookup
the destination's IP and cache it, updating it as needed.
It works, but it would be nice if this could be done in DNS. Sadly, it
can't, and probably won't in our lifetimes.
I do a similar thing in my DNS crudware, a pseudo-entry in the zone,
every time the background update script runs, it does A and AAAA
lookups and puts the results in the real zone, bumping the SOA serial
if the result changed since last time. It's a crock, but one that we
all seem to want.
I suppose we could invent something like an AAAAANAME (that's A and
AAAA name), that worked like a restricted CNAME and does an indirect
lookup only for A or AAAA requests. Or overimplement it with a bitmap
of the RR types to indirect for.
Or, a bitmap of the RR types to *not* indirect for, which
a) often if not usually will be a shorter list (even in the zone apex
case, you have 2 exclusions -- NS and SOA -- and typically 2 or more of
A/AAAA/MX/SPF/TXT as inclusions, potentially even more if the zone is
DNSSEC-signed), and
b) would automatically cover new RR types as they are defined
As an implementation detail, zone-loading logic could, if desired,
*automatically* set these bits based on what other record types with the
same owner name are explicitly defined in the zone file (on the
reasonable assumption that a data owner wouldn't explicitly define an
RRset in a zone file, only to have it be "hidden" forever by an
indirection record with the same owner name).
Of course, it's one thing to dream up a new RR type, quite another thing
to get it standardized via the IETF and then change the installed base
to actually recognize and use it. Also, during the (presumably long)
transition period, you'd have to use EDNS0 signalling or something
similar so that a server knows whether a client understands the new
record type or not. If the client doesn't understand the new type, you
need a fallback mechanism to cough up usable terminal-node records "the
old-fashioned way".
- Kevin
_______________________________________________
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
from this list
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
