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

View by Category
About This Presentation



This presentation represents past experience in un/successfully extending the DNS ... Instead of domain name tricks of RR hacks. Use new class. Problem ... – PowerPoint PPT presentation

Number of Views:61
Avg rating:3.0/5.0
Slides: 32
Provided by: ietf5
Learn more at: http://www.ietf.org


Write a Comment
User Comments (0)
Transcript and Presenter's Notes

Title: DNS%20Considerations%20for%20the%20MARID%20WG%20(esp.,%20why%20TXT%20is%20bad)

DNS Considerations for the MARID WG(esp., why
TXT is bad)
  • Edward Lewis
  • edlewis_at_arin.net

  • 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

  • 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

  • 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

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)

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

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

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

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

Play with (Prefixing) Names
  • Separate data based on the domain name
  • Idea
  • Separate app specific data for a host by using
  • Problem
  • Wild cards, these can't be prefixed
  • "Specifying the shape of the tree" ()

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

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

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

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

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

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

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

TXT understood inside DNS
  • Is this really an advantage?
  • RFC 3597 specs how servers deal with newly added
  • 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

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

TXT understood in the support
  • Will registries (zone generators) allow the new
  • 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?)

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

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

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

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

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

  • 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
  • The DNS admin may not be an SMTP admin

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

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

  • 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

Summary of a good RR
  • Will following the rules here mean you get a good
  • 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

  • Questions now, and on the list...
About PowerShow.com