dns considerations for the marid wg esp why txt is bad n.
Skip this Video
Loading SlideShow in 5 Seconds..
DNS Considerations for the MARID WG (esp., why TXT is bad) PowerPoint Presentation
Download Presentation
DNS Considerations for the MARID WG (esp., why TXT is bad)

Loading in 2 Seconds...

play fullscreen
1 / 31

DNS Considerations for the MARID WG (esp., why TXT is bad) - PowerPoint PPT Presentation

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. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.

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