Post on 02-Jan-2016
description
transcript
May 20, 2004 MARID WG Interim Meeting 1
DNS Considerations for the MARID WG
(esp., why TXT is bad)Edward Lewis
edlewis@arin.net
May 20, 2004 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
May 20, 2004 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
May 20, 2004 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
May 20, 2004 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)
May 20, 2004 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
May 20, 2004 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
May 20, 2004 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
May 20, 2004 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
May 20, 2004 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" (*)
May 20, 2004 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
May 20, 2004 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
May 20, 2004 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
May 20, 2004 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
May 20, 2004 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
May 20, 2004 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
May 20, 2004 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
May 20, 2004 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
May 20, 2004 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
May 20, 2004 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?)
May 20, 2004 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?"
May 20, 2004 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
May 20, 2004 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
May 20, 2004 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
May 20, 2004 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
May 20, 2004 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
May 20, 2004 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
May 20, 2004 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
May 20, 2004 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
May 20, 2004 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