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

May 20, 2004 MARID WG Interim Meeting 31

Questions?

• Questions now, and on the list...