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

View by Category
About This Presentation
Title:

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

Description:

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

less

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

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


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

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

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

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

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)

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

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

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

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

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" ()

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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