Mark Andrews wrote:
Many web interfaces are little more than line text editors with a pulldown
list for the type. Very few are more than that. The data just gets passed,
as text, to a backend which adds it to a database / zone. Lots of those
backends already support the new type. The only change that needs to be
made is to add a type to the pull down list.
In one support case, gigantic isp to remain nameless, the addition of
new TXT-based protocol support now caused "wildcard conflicts" between
SPF and DKIM.
Customer to us: What records to I add?
Us: Use our tool-generated records and contact ISP - they should have
a "Total DNS management" web based system, to add the generated
records there.
They did, there was a conflict with getting DKIM records and SPF
records, two different name spaces.
Us: Constant ISP, they should allow you to separate SPF and DKIM records.
ISP to Customer: Nothing wrong, its all fine. Just add it under TXT.
Customer to US: Is this your BUG?
Us: It has to be the ISP, lets check it out - Remote support.
There was no specific way to separate TXT records, it was all lump
under one input.
US: Contact ISP, tell them what we told you.
Customer to US: VOILA, fixed, ISP fixed it with a special prefix you
add to the record.
Basically, what they did was independent of the pull down, the
editable field allowed you to add the subdomain prefix.
Whatever! :)
Agree, it isn't so far to update the frontend, but we can't always
blame the ISP when the specification isn't all clear. If the
impression is that TXT is good enough, then the expense to do code
change is less justified.
_______________________________________________
Ietf mailing list
Ietf@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf