Mark Andrews wrote:
Stop asking for type XXXX support and ask for UNKNOWN record support
from your provider. UNKNOWN record support will handle type XXXX
and anything new that will come along.
+1
By supporting UNKNOWN record format, providers get to know which
types are actually being used by their customers and can then hire
developers to add support for the types that are actually being
used.
+1
Tools to convert between UNKNOWN and type specific representations
will appear. They are trivial to write.
and most likely its specifics to tied to backend I/O storage methods.
Not everything is a droppable text file and not everyone is going to
be using EDLIN, QEDIT, NotePad or some *nix flavor text editor.
Bind hass command line (CLI) tool to automatic the process of addng
unnamed types, I am trying to find out if Windows DNS 5.0 DNSCMDS
does, and so far it doesn't. But Microsoft .NET Provisioning API
does support the creation of unnamed resource records. But from what
I am reading so far, it seems to have been abandon starting with
VS2010. I posted a question in the MSDN Directory Services and
Network Infrastructure Servers support forums and so far, NADA.
Personally, I thought this was resolved with DNS 5.0 which finally did
add direct support for the previous wish list "unknown type" SRV and
other records required for AD (Active Directory) and DNSSEC.
But if the reality is such that the Default Window Server brand (not
desktop brands) with its already optional installation DNS server
option, does not come with an out of the box RFC3597 support by now,
even if undocumented or via a registry option, well, its beating a
dead horse now. I am all ready to support going with TXT only for SPF.
Take SPF as a example. If providers had supported UNKNOWN format
then the SPF generation tools would have done UNKNOWN + SPF type
specific rather than TXT + SPF.
+1.
_______________________________________________
Ietf mailing list
Ietf@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf