1 / 31

DNS Considerations for the MARID WG (esp., why TXT is bad)

This presentation discusses the limitations and problems associated with using TXT records in DNS, and explores alternative options for expanding the DNS protocol. It also examines the challenges and considerations in adding new types of data to DNS and the implications for mail forgery prevention.

moiram
Download Presentation

DNS Considerations for the MARID WG (esp., why TXT is bad)

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. DNS Considerations for the MARID WG(esp., why TXT is bad) Edward Lewis edlewis@arin.net MARID WG Interim Meeting

  2. Context • This presentation represents past experience in un/successfully extending the DNS • This is an engineering "exchange of ideas" • Not a statement of rules nor laying of benchmarks for a proposed solution • This is not an end product MARID WG Interim Meeting

  3. Credits • A lot of these slides are based on a new draft • http://www.ietf.org/internet-drafts/ • draft-ymbk-dns-choices-00.txt • These slides also borrow from threads on the MARID list • I admit to not having read all of it MARID WG Interim Meeting

  4. Agenda • Why MARID really wants a new type, even if you don't realize it yet • Ways to expand DNS • The TXT RR • What MARID should consider in developing the new type MARID WG Interim Meeting

  5. DNS Basic Design (1 slide) • Query/response protocol • Query: three things • domain name, class and type • Response: one thing • a set of resource records (RRs) • Ancillary data • Message flags (internal to DNS) MARID WG Interim Meeting

  6. Adding new types of data to DNS • Only four degrees of freedom • Play with Returned values • Play with Names • Play with Classes • Play with Types MARID WG Interim Meeting

  7. Play with Returned values • This is called "subtyping" • Idea • An app asks for name, class, type, gets response • Selects the RDATA's desired from answer • (E.g., reuse of the TXT record) • Problem • Encourages large data sets (use of TCP, ...) • No means to guarantee specification uniqueness MARID WG Interim Meeting

  8. Examples of how this fails • DNSSEC, the KEY Resource Record (RR) • Supposed to hold keys for all purposes • Trust model unworkable, performance hit • SIKED BoF • DNSSEC signatures • Has caused tremendous problems in code • "Corner cases" repeatedly found, some unsolvable, simply ignoring them MARID WG Interim Meeting

  9. Problem case of TXT RR • One thing to keep in mind • From the perspective of MARID • It might appear workable • From the perspective of DNS • MARID is not the only WG thinking that MARID WG Interim Meeting

  10. Play with (Prefixing) Names • Separate data based on the domain name • Idea • Separate app specific data for a host by using "_app.hostname.example.org" • Problem • Wild cards, these can't be prefixed • "Specifying the shape of the tree" (*) MARID WG Interim Meeting

  11. Play with (Suffixing) Names • Places DNS labels at the end of the name • Idea • Separate app data as in prefix and keep wildcards, e.g., "smtp1.example.org._marid" • Problem • This breaks the concept of a single-rooted tree, servers get lost looking for answers MARID WG Interim Meeting

  12. Play with Classes • Put data into alternate "dimension" of DNS • Idea • Instead of domain name tricks of RR hacks • Use new class • Problem • The class concept has atrophied - not implemented right, not spec'd right either • No guarantee names translate across classes MARID WG Interim Meeting

  13. Play with Types • Create a new RR specifically for a purpose • Idea • No name, class tricks, it's "standard DNS" • define RR type and the RDATA • Resistence (note I didn't use "Problem") • Deployment of new code • This is the recommended approach MARID WG Interim Meeting

  14. So, four degrees of freedom • Subtyping - known to have failed in past • Name altering - breaks basic DNS assumptions • Class - an atrophied path, not clear it would be right anyway • Type - the way nature intends, even though it's not a no-brainer MARID WG Interim Meeting

  15. Considerations in adding a type • Not only does DNS need to be updated • Zone-generation software needs updates • API's to DNS need to be able to input, request, and read the new type • No doubt this is "extra" work in stemming mail forgery, vs. just reusing TXT MARID WG Interim Meeting

  16. Why TXT is questioned • Today we have mail forgery and a working DNS • If we risk breaking an assumption of the DNS to stem mail forgery, are we winning? • Specifically - reuse/misuse of the TXT RR • This is why the MARID WG gets resistence from the DNS community over the use of the TXT RR MARID WG Interim Meeting

  17. Reverse Psychology • Why is the TXT RR the right way to go? • It is undestood inside the DNS • It is understood at the API of the DNS • It is understood in the supporting software • It appears to be an easy way to go MARID WG Interim Meeting

  18. TXT understood inside DNS • Is this really an advantage? • RFC 3597 specs how servers deal with newly added types • Old software is easily upgraded if not compliant with this • "Unreachable" software is rare, e.g., a NAT DNS machine at a hotel • IMO, this advantage is overstated MARID WG Interim Meeting

  19. TXT understood at the API • Is this really an advantage? • Honestly, I can't say. • This is what I mean as a "beginning", how much work is it to make the new record be known at API's of interest? • Remember - I'm not issuing challenges, but if you want to cause tinkering with DNS, there has to be a real good reason MARID WG Interim Meeting

  20. TXT understood in the support • Will registries (zone generators) allow the new type? • Again, I don't have an answer • It seems like now they might not be • Is this a strong sticking point? • Why can't registries change to allow this? • IMO, the "right way to fix a problem is to fix it in the right places" (What does that mean?) MARID WG Interim Meeting

  21. If not TXT, what then? • Hopefully this presentation presents a strong case for abandoning the TXT RR as a vehicle and spurring an effort to define a new RR • If so, the next question is "how do you design a good RR?" MARID WG Interim Meeting

  22. Designing a Good Record • Starting with "what needs to be stored" • Make it easy to retrieve • Ordinary query and response method • No additional data, RR's needed in response • Make it easy to manage • Does not overwhelm zone, administrator • Easy to debug/diagnose MARID WG Interim Meeting

  23. Some things to consider • "It's always problem, problem, problem with you" • Problems with the reverse map • Problems with performance • Problems with volume • Problems with DNSSEC • Problems with "wild cards" • Mistaking DNS with a reasoning system MARID WG Interim Meeting

  24. Reverse Map • Controversial • Many don't feel it's useful • IPv6'ers consider not having it • Optional • E.g., In ARIN's region, name servers for IP space is optional • Customers can't "overrule" ISP not having it MARID WG Interim Meeting

  25. Performance • This can easily be a red-herring • DNS is best for small records, lightweight lookups • If the data returned needs heavy computing to generate it, consider having DNS point to the generator • Much in the way MX records point to mail servers for a host MARID WG Interim Meeting

  26. Volume • A lot of DNS is still managed by hand • If a record needs to be at all entries, with positive or negative meaning, something might get lost • The DNS admin may not be an SMTP admin MARID WG Interim Meeting

  27. DNSSEC • Listing data in DNS is assumed to make it public • With DNSSEC, all entries in a zone are easily discoverable • Barring a miracle in development of the negative answers • To me, this is *not* a weakness of DNS, DNSSEC • Applications shouldn't depend on putting sensitive data in DNS MARID WG Interim Meeting

  28. Wild Cards • Problem - they are misunderstood • by users and by implementors • DNS is a tree of labels, with data "attached" • Wild cards are instructions for synthesis to cover some missing *leaf* nodes of the tree • Subject takes many more slides...no pithy moral here MARID WG Interim Meeting

  29. Reasoning • If the statement needs much thinking, DNS isn't the place to do it • Even putting a lot of weighting factors in the record can be a draw back • Don't want to have a lot of records • Don't make DNS think, it's not its job • Chaining is a sign of this • Not bad for DNS, bad for the application MARID WG Interim Meeting

  30. Summary of a good RR • Will following the rules here mean you get a good RR? • NO!!! • But following them will help • Designing a good RR will take a partnership of MARID WG expertise and DNS expertise • Hopefully not a *lot* of DNS expertise MARID WG Interim Meeting

  31. Questions? • Questions now, and on the list... MARID WG Interim Meeting

More Related