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

2. May 20, 2004MARID WG Interim Meeting2 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

3. May 20, 2004MARID WG Interim Meeting3 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

4. May 20, 2004MARID WG Interim Meeting4 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

5. May 20, 2004MARID WG Interim Meeting5 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)

6. May 20, 2004MARID WG Interim Meeting6 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

7. May 20, 2004MARID WG Interim Meeting7 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

8. May 20, 2004MARID WG Interim Meeting8 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

9. May 20, 2004MARID WG Interim Meeting9 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

10. May 20, 2004MARID WG Interim Meeting10 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" (*)

11. May 20, 2004MARID WG Interim Meeting11 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

12. May 20, 2004MARID WG Interim Meeting12 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

13. May 20, 2004MARID WG Interim Meeting13 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

14. May 20, 2004MARID WG Interim Meeting14 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

15. May 20, 2004MARID WG Interim Meeting15 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

16. May 20, 2004MARID WG Interim Meeting16 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

17. May 20, 2004MARID WG Interim Meeting17 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

18. May 20, 2004MARID WG Interim Meeting18 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

19. May 20, 2004MARID WG Interim Meeting19 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

20. May 20, 2004MARID WG Interim Meeting20 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?)

21. May 20, 2004MARID WG Interim Meeting21 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?"

22. May 20, 2004MARID WG Interim Meeting22 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

23. May 20, 2004MARID WG Interim Meeting23 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

24. May 20, 2004MARID WG Interim Meeting24 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

25. May 20, 2004MARID WG Interim Meeting25 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

26. May 20, 2004MARID WG Interim Meeting26 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

27. May 20, 2004MARID WG Interim Meeting27 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

28. May 20, 2004MARID WG Interim Meeting28 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

29. May 20, 2004MARID WG Interim Meeting29 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

30. May 20, 2004MARID WG Interim Meeting30 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

31. May 20, 2004MARID WG Interim Meeting31 Questions? Questions now, and on the list...