[dns-operations] AXFR support for custom DNS features (Was: Recommended zone serial number format for over 100 changes / day)
Edward Lewis
edward.lewis at icann.org
Sat Apr 2 14:33:27 UTC 2016
Having worked at another vendor that did similar work and having worked on
"DNS Zone Transfer Protocol (AXFR)" (RFC 5936):
On 4/1/16, 14:26, "dns-operations on behalf of Andrew Sullivan"
<dns-operations-bounces at dns-oarc.net on behalf of ajs at anvilwalrusden.com>
wrote:
>It's not necessarily strictly that the features aren't supported by
>AXFR. It's that there's no well-known way to configure these
>behaviours across provider -- basically, they're not part of the
>standard, so they don't interoperate.
I'll strongly second Andrew's statement. We (previous employer) didn't
insert our rules into resource records hence we didn't distribute them via
AXFR. Had we done so, only our servers would be able to reconstruct the
instructions encoded in the RDATA's - plus anyone else we would have
chosen to interoperate with. (Which turned out to be nobody.)
What I found back then, the bottleneck for getting interoperability in
what was essentially "synthesized DNS responses" was the inability to
transfer the rules in AXFR.
With one exception. Wildcards (RFC 4592) are an example of standardized
synthesized DNS responses which are interoperable, in part, because the
rules are simple enough to be encoded in a resource record and thus can be
stuffed into an AXFR. All that is needed is a special owner name ("*").
I have to give credit to Dan Bernstein for that enlightenment.
(Seriously, folks. Yes, really.)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4604 bytes
Desc: not available
URL: <https://lists.dns-oarc.net/pipermail/dns-operations/attachments/20160402/424583f2/attachment.bin>
More information about the dns-operations
mailing list