[dns-operations] Recommended zone serial number format for over 100 changes / day

[David C Lawrence]

Matthias Leisi writes:
>>> For example, Alias, LBR, Geo, and WRR (to name just a few) don't
...
>> These are not actual DNS RR types and would not be covered by AXFR.
>> They are a special feature of the particular authoritative server
>> software and can't be expected to work interoperably when with other
> 
> "can't be expected to work interoperably" why not, actually?
> "FXFR" for "Feature XFR" does not seem to be technically difficult,
> but I'm not aware of any recent attempts to standardise something like
> that. 

Well that's why they can't be expected to work interoperably.  They're
not standardized.  Sure, developers can co-operate to make two
different implementations interoperate, but without standardization
that doesn't get very far.  Even just having a public draft and RFC
6895 expert review helps.

For example, several DNS providers have a feature which mimics a CNAME
at the apex of a zone.  DNSMadeEasy happens to do it through a
pseudo-RR that they call ANAME.  Yet ANAME has no IANA-assigned RR
type; I imagine that if DNSMadeEasy actually stores ANAME with other
DNS records in a zone file, they use some RR code from the Private Use
space, 65280-65534.  However, if this is documented publicly anywhere,
it hasn't been easy for me to find.

So even though Akamai has a similar feature (as do CloudFlare and
others), we configure it through a different mechanism that does not
use DNS RRs.  If DNSMadeEasy allowed us to AXFR a zone and included
their ANAME RR in the transfer data, it is opaque to us.  We could only
handle it via the RFC 3597 generic TYPEnnnnn mechanism, which would
not give it anything near the functionality that it has on DNSMadeEasy
servers.

If you want interoperability, you need to standardize.