Re: The state of DNS support, was Deprecating SPF

In message <[email protected]>, Hadriel Kaplan wr
ites:
> 
> Well if we're going to risk being ridiculed, I'll go all-in. :)
> 
> At one time I had thought along the same lines - not to deprecate TXT, but ra
> ther to just say: "let's go pre-allocate a dozen new RR Types, and tell DNS s
> ervers to implement them, with undefined-text-content, and we give them rando
> m acronym names, and future IETF mechanisms can go use them on a first-come-f
> irst-served basis; and those future IETF specs can figure out a backronym exp
> ansion for the acronyms, and define what the text-content formatting is, etc.
> "
> 
> But from reading the problems SPF listed in RFC 6686 and the emails from SPFB
> IS folks, I don't think that would solve the problem, even if by some miracle
> all DNS servers on the planet supported the new RRs.  There're just too many
> other DNS-related-things involved. (DNS servers and registries, and their pr
> ovisioning interfaces, and DNS resolvers/caches, firewalls, CGN middleboxes, 
> client libraries and their APIs...)

There are DNS servers that completely support arbitary types.  And
have for over a decade.  Before that they could resolve and cache
arbitary types and have done so for over 20 years.  About the only
one that doesn't is that shipped by Microsoft.

There are DNS resolvers that support arbitary types and have been
able to for over 20 years.  This is basic RFC 1034 functionality.
Unfortunately Microsoft failed to read that part of RFC 1034 or
failed to understand it when they were developing their resolver
code.

Most firewalls don't care diddly squat about DNS record types.  For
those that do blocking unknown types in firewalls does diddly squat
for security and just cause problems for everyone.  Just turn the
DNS checking off.

NAT (carrier grade or otherwise) don't care about DNS message
content. 

Then there are provisioning systems which haven't been upgraded
since Noah was a boy and you don't have to use anyway.

> So here's the to-be-ridiculed part...
> I suggest a new strategy: let the wookie win.  Instead of denying their exist
> ence, accept that there will be more folks who want to deploy new DNS-using a
> pplications quickly and without waiting for the entire Internet of DNS-relate
> d-things to change.  It's going to happen whether we want it to or not.  So w
> e might as well try to fix whatever problems we envision it will cause, and p
> rovide guidance of how to use TXT the best way.  Right now RFC 5507 only warn
> s folks against it, but I don't see a "if you are going to use TXT anyway, th
> en do it this way" type thing.  Nor do I see an IANA registry of prefix names
> , nor an RFC describing a general solution to the wildcarding problem when pr
> efixing.  I think those things are possible, maybe.
> 
> We can require abstinence or we can give out condoms.  Which one do you think
>  is more likely to prevent spread of disease?
> 
> -hadriel
> 
> 
> On Aug 25, 2013, at 11:36 PM, "Dickson, Brian" <[email protected]> wrote:
> 
> > At the risk of ridicule, and in the interest of potentially useful results:
> > 
> > Why not deprecate TXT, or at least abandon the current TXT and introduce
> > a new TXT code point? And, as each iteration gets trashed, move on to the
> > next one?
> > 
> > It's not like there is a shortage of type code values, and it is not like
> > the RDATA of TXT is complicated, or in any way is required to be unique.
> > SPF is, after all, exactly the same as TXT except for being different.
> > 
> > If SPF want to take over TXT, let them. We can all move to TXT2, until
> > someone ruins it, and then we can introduce TXT3, etc.
> > 
> > I realize it is rather silly, but if it works, and it disambiguates things,
> > the fact that it _is_ silly is perhaps not the greatest reason for not
> > doing it.
> > 
> > This might provide a small clue to the next group of other-protocol folk,
> > that using TXT instead of asking for their own RRTYPE, is foolish, unwise,
> > and likely to result in having a new RRTYPE lobbed at them in retaliation.
> > :-)
> > 
> > (My two cents, late to the discussion.)
> > 
> > Brian
> > 
> 
> _______________________________________________
> dnsext mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/dnsext
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email protected]
_______________________________________________
dnsext mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dnsext