In message <4f4c1106.4020...@gmail.com>, Hector writes:
> 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.

Which is one of the reasons DNS people argued and argued and argued
that TXT was not the right solution for DKIM.  The IETF can still
correct this by adding a DKIM type and deprecating the prefix. :-)

> 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.

No.  You just need a interface that lets you specify the domain name of
the record you are adding. 
 
> 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.
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: ma...@isc.org
_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Reply via email to