Title: DNS%20Considerations%20for%20the%20MARID%20WG%20(esp.,%20why%20TXT%20is%20bad)
1DNS Considerations for the MARID WG(esp., why
TXT is bad)
- Edward Lewis
- edlewis_at_arin.net
2Context
- 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
3Credits
- 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
4Agenda
- 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
5DNS 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)
6Adding new types of data to DNS
- Only four degrees of freedom
- Play with Returned values
- Play with Names
- Play with Classes
- Play with Types
7Play 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
8Examples 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
9Problem 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
10Play 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" ()
11Play 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
12Play 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
13Play 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
14So, 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
15Considerations 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
16Why 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
17Reverse 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
18TXT 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
19TXT 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
20TXT 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?)
21If 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?"
22Designing 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
23Some 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
24Reverse 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
25Performance
- 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
26Volume
- 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
27DNSSEC
- 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
28Wild 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
29Reasoning
- 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
30Summary 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
31Questions?
- Questions now, and on the list...