Subject: diff between -02 and -03 of forgery-resilience

From: bert hubert <[email-masked]>
Date: Mon, 24 Mar 2008 14:17:40 +0100

Hi everybody,

Now that it has been agreed that 0x20 and forgery-resilience should not be
conjoined, it is a good time for -03 which I hope can go for last call
quickly.

I've worked in most concerns raised, with some slight exceptions to retain a
brief document.

http://www.ietf.org/internet-drafts/draft-ietf-dnsext-forgery-resilience-03.txt

Differences:

Full view:

http://adsl-xs4all.ds9a.nl/cgi-bin/resilience.fcgi/changeset?new=trunk%2Fdraft-ietf-dnsext-forgery-resilience.xml%4020&old=trunk%2Fdraft-ietf-dnsext-forgery-resilience.xml%4013

Summary:

* Waive port churn and other rules in case cryptographic verification is in
  place that guarantees answer validity. This makes sure these measures for
  the interim period do not place a burden on future security-aware
  resolvers.

The above is new, and based on concerns by Wouter Wijngaards that DNSSEC
security-aware resolvers have no benefit of the rules contained in the
draft, yet would need to implement them. 

The rest of changes are more clerical:

* Add reference to RFC 4086 (random number generation)

* Improve wording on 'random' - only specify that implementations should
  strive towards unpredictability, we can't demand it (without a revolution
  in the state of mathematics!)
* Improve 'arbitrary' vs 'random' wording
* Improve 'identical' vs 'equivalent' wording (case folding comparisons)    
* Make case-folding explicit in a number of places
* Tone down wording on existing practices
* Make sure document does not confuse current practice with normative rules 
  ('use the first correct answer' versus 'generally the first correct answer
   is used')
* 'Matching the question' chapter renamed to 'Forcing the question' (chapter
  title was completely wrong)

* Clarify birthday paradox a bit, fix error (22 -> 23)
* Clarify that as large a port range as *practicable* should possibly be
  used (iow, do not mandate taking down the whole server)

Kind regards,

Bert Hubert

-- 
http://www.PowerDNS.com      Open source, database driven DNS Software 
http://netherlabs.nl              Open and Closed source services

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/namedroppers/>

---

From: Paul Vixie <[email-masked]>
Date: Mon, 24 Mar 2008 16:07:07 +0000

> ...

i now think this wording overspecifies (in section 9, countermeasures)

   o  Question name (compared case-insensitively)

i'd rather leave the ambiguous wording in RFC 1034 in maximal effect while
we puzzle our way through the dns-0x20 issues.  in the above wording, any
initiator who compares case-sensitively is noncompliant, whereas under the
existing RFC 1034 rules, compliance level of such behaviour is unspecified.
(and in addition, the change is substantive, nowhere close to "clerical".)

similarly, in 4.2 (matching the question section), where the text now says:

   DNS packets, both queries and answers, contain a question section.
   Incoming answers should be verified to have a question section that
   is equivalent to that of the outgoing query.

i would rather this remain ambiguous, changing "equivilent" to "the same as".
(because sameness can mean identity of equivilence, and i'd like initiators
who demand identity here to remain compliant.)

in section 10 (security considerations) we see this text:

   The above notwithstanding, it should be noted that using a low Time
   To Live for DNS records raises the chances of an attacker spoofing a
   resolver.

i think this should be amended by adding the following after "resolver":

            by using the attacks described in this document.

i'd also like to see the following new paragraph added to section 10:

   All of the spoofing attacks described in this document are due to the
   nearly universal lack of IP source address validation (see [BCP38] and
   [SAC004] for more information).  If the source address of a UDP datagram
   were trustworthy, then there would be no need for forgery resilience in
   DNS initiators.

and then in the references section, add something pointing to these two:

	http://tools.ietf.org/html/bcp38
	http://www.icann.org/committees/security/sac004.txt

thanks for your continued work on forgery-resilience.

---

From: Edward Lewis <[email-masked]>
Date: Mon, 24 Mar 2008 13:03:19 -0400

>    were trustworthy, then there would be no need for forgery resilience in

I still need to read -03, but I wanted to add to Paul's comment...

Not "All of the spoofing attacks" fit this.  If the spoof is sourced 
on the same LAN (or "LAN") as the victim or the true server then 
BCP38 won't matter.
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                                +1-571-434-5468
NeuStar

Never confuse activity with progress.  Activity pays more.

---

From: Yue Luo <[email-masked]>
Date: Mon, 24 Mar 2008 10:36:33 -0700

The draft discusses about the effect of TTL on the vulnerability.  This assumes that a record in the cache is not overwritten before its expiration.  This assumption needs more discussion.  An attacker can design ways to "piggy back" records in spoofed responses order to overwrite important cache entries.  For example, to attack c.isi.edu, the attacker can use packet similar to that in section 6.2.7 of RFC 1034.

The draft should
1) make it explicit that the discussion relies on the assumption that cached records are not overwritten
2) discuss under what condition a cached record may be overwritten
3) provide guideline to reader to prevent critical cache records from being written.

Thank you.
Yue

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of bert hubert
Sent: Monday, March 24, 2008 6:18 AM
To: [email-masked]
Subject: diff between -02 and -03 of forgery-resilience

Hi everybody,

Differences:

Full view:

Summary:

Kind regards,

Bert Hubert

---

From: Paul Vixie <[email-masked]>
Date: Mon, 24 Mar 2008 17:36:05 +0000

> Not "All of the spoofing attacks" fit this.  If the spoof is sourced on the
> same LAN (or "LAN") as the victim or the true server then BCP38 won't
> matter.

fair enough.  spoofing responses from a server on the same lan is not a case
i had considered, but i suppose that there are configurations where a recursive
and authoritative server are on the same lan.  my wording is inadequate there.

---

From: Robert Elz <[email-masked]>
Date: Tue, 25 Mar 2008 06:02:00 +0700

Date:        Mon, 24 Mar 2008 16:07:07 +0000
    From:        Paul Vixie <[email-masked]>
    Message-ID:  <[email-masked]>

  |    o  Question name (compared case-insensitively)
  | 
  | i'd rather leave the ambiguous wording in RFC 1034 in maximal effect while
  | we puzzle our way through the dns-0x20 issues.  in the above wording, any
  | initiator who compares case-sensitively is noncompliant, whereas under the
  | existing RFC 1034 rules, compliance level of such behaviour is unspecified.

I think you're attempting to create doubt about aspects of 1034 that really
are clear - there's really no doubt that whenever names are compared, ascii
case is ignored (the names are the same if all that differs is the case).
Please don't try to pretend that 1034 isn't clear about that (I wish it wasn't,
it would be nice to be completely rid of this, in the DNS, but it is,
for now anyway).

What isn't specified (of the things relevant here) is whether the server is
required to repeat the exact same question bits in the response, or just a
question that means the same thing.

kre

---

From: Paul Vixie <[email-masked]>
Date: Mon, 24 Mar 2008 23:47:10 +0000

> case is ignored (the names are the same if all that differs is the case).

perhaps you have no doubt.  perhaps others have some.  all i'm asking is, let
us not try to clarify the point here, unless doing so improves forgery
resilience, which in this case, it does not.  let it remain doubtable by some.

> Please don't try to pretend that 1034 isn't clear about that (I wish it
> wasn't, it would be nice to be completely rid of this, in the DNS, but it
> is, for now anyway).

i'm not pretending so much as recounting.  and, please don't tell me what i'm
trying to do, i may not agree, and then we'll be off on that as a side-topic.

> question that means the same thing.

i believe i covered that by asking for "sameness" vs. "equivilence".

---

From: Mark Andrews <[email-masked]>
Date: Tue, 25 Mar 2008 10:48:13 +1100

> on the same LAN (or "LAN") as the victim or the true server then 

	Today you can do BCP 38 at the LAN level for most (not all)
	LAN technologies.  Even for those LAN technologies where
	you can't you are usually performing a attack on yourself
	as well as the victim.

	Mark

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

---

From: Joe Abley <[email-masked]>
Date: Mon, 24 Mar 2008 20:15:21 -0400

> 	you can't you are usually performing a attack on yourself

I find this quite impenetrable.

Joe

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Tue, 25 Mar 2008 09:14:31 +0100

On Mon, Mar 24, 2008 at 04:07:07PM +0000,
 Paul Vixie <[email-masked]> wrote 

>    were trustworthy, then there would be no need for forgery resilience in

Strongly -1 here. See the Last Call comments and the IESG DISCUSS for
draft-ietf-dnsop-reflectors-are-evil, which had the exact same issue
(overreliance on BCP38).

---

From: bert hubert <[email-masked]>
Date: Tue, 25 Mar 2008 11:16:09 +0100

On Mon, Mar 24, 2008 at 10:36:33AM -0700, Yue Luo wrote:

> The draft discusses about the effect of TTL on the vulnerability.  This

Yue,

You are right that the TTL features in the calculations - in degenerate
cases the TTL revolves into the network rtt, as the draft notes.

To not overly broaden the document, I'm trying to stay within the bounds of
recommendations outside of the actual payload of DNS packets, and focus on
port numbers, id choices etc.

	Bert

---

From: Florian Weimer <[email-masked]>
Date: Tue, 25 Mar 2008 12:26:11 +0100

> on the same LAN (or "LAN") as the victim or the true server then

I think that there's a strong requirement to implement ingress
filtering on LANs, too.  Basically, you need to filter at the first
trust boundary, which means that you cannot run a pure L2 access
network anymore.

However, my personal experience is that BCP38 is only implemented by
cheap consumer Internet access.  Anything else I've looked at
performed egress filtering only (or the upstreams of the ISP I was
subscribed to performed ingress filtering, same difference), if there
were any filters at all.  Like the L2 access network scenario, this
doesn't protect you against DNS spoofing attacks.

-- 
Florian Weimer                <[email-masked]>
BFK edv-consulting GmbH       http://www.bfk.de/
Kriegsstraße 100              tel: +49-721-96201-1
D-76133 Karlsruhe             fax: +49-721-96201-99

---

From: Paul Vixie <[email-masked]>
Date: Tue, 25 Mar 2008 13:14:54 +0000

> >    [SAC004] for more information).  If the source address of a UDP
> >    datagram were trustworthy, then there would be no need for forgery
> >    resilience in DNS initiators.
> 

does ed lewis' observation (that on LANs, BCP38 doesn't help you) and my
agreement (that the language should be modified to that effect) help at all?

i'm concerned that a reader of this document know the real source of the
terror, which isn't in DNS's design alone, but rather, the whole IP stack.

---

From: Edward Lewis <[email-masked]>
Date: Tue, 25 Mar 2008 15:38:59 -0400

>http://www.ietf.org/internet-drafts/draft-ietf-dnsext-forgery-resilience-03.txt

Comments on -03, "#" in the left means lines from the document.

#      Measures for making DNS more resilient against forged answers
#               draft-ietf-dnsext-forgery-resilience-03.txt
...
# Abstract
#
#    The current Internet climate poses serious threats to the Domain Name
#    System.  In the interim period before the DNS protocol can be secured
#    more fully, measures can already be taken to harden the DNS to make
#    'spoofing' a recursing nameserver many orders of magnitude harder.
#
#    Even a cryptographically secured DNS benefits from having the ability
#    to discard bogus answers quickly, as this potentially saves large
#    amounts of computation.
#
#    By describing certain behaviour that has previously not been
#    standardised, this document sets out how to make the DNS more
#    resilient against accepting incorrect answers.  This document updates
#    RFC 1034.

I don't like the apologetic tone of the abstract.  The more I have seen of
DNSSEC the more I realize it is a mistake to fuse cryptography into the
naming system and protocol - but that's an aside.  The upshot is that this
document shouldn't be apologizing for its existence, what it is espousing is
just good, making it harder to stuff answers is nothing but "goodness."

(My) Abstract (suggestion)

This document presents steps that can be taken to make it harder for
a third party to forge a reply to an outstanding query.  By making it
harder to predict the values of the fields a client checks to verify that
an incoming response relates to an outstanding query, the chance a
third party can insert an illegitimate answer is lowered.

This document updates portions of RFC 1034 instructing a client to
be more careful when accepting incoming responses.

# 2.  Introduction

(First a disclaimer - when it comes to opening sections of documents I get
overly concerned with setting up the problem correctly. I'll try to keep
my nits to a minimum.)

#
...
#    Additionally, it has recently become possible to acquire SSL/TLS
#    certificates with no other confirmation of identity than the ability
#    to respond to a verification email sent via SMTP ([RFC2821]) - which
#    generally uses DNS for its routing.

The above is the kind of "claim" that really needs to be substantiated
via a reference.  I am referring to the "possible to acquire certificates"
statement.  As a matter of fact, I don't really believe that it is true,
at least I doubt the value of a certificate backed only by email.  I would
suspect there is also a credit card angle to this too.

But I stress, I am not trying to argue this point, but just asking for the
inclusion of a reference to a document that supports the claim.

# 3.  Description of DNS spoofing
#
#    When certain steps are taken it is feasible to 'spoof' the current
#    deployed majority of caching resolvers with carefully crafted and
#    timed DNS packets.  Once spoofed, a caching server will repeat the
#    data it wrongfully accepted, and make its clients contact the wrong,
#    and possibly malicious, servers.

Is 'spoof' the accurate word here?  "Forged answers" are the problem, as
well as the practice of "message insertion."  I suppose you could say it is
the case that the problem is someone spoofing a server, but the problem
being tacked here is not server authentication but forgery resistance.

#    To understand how this process works it is important to know what
#    makes a resolver (and more specifically a caching server) accept an
#    answer.
#
#    The following sentence in section 5.3.3 of [RFC1034] presaged the
#    present problem:
#
#      The resolver should be highly paranoid in its parsing of responses.
#      It should also check that the response matches the query it sent
#      using the ID field in the response.
#
#    DNS data is to be accepted by a resolver if and only if:

These rules are not from 5.3.3. of RFC 1034, are they?  From the flow here
I thought they were.  These are this document's summary, right?

#
#    1.  The question section of the reply packet is equivalent to that of
#        a question packet currently waiting for an answer
#
#    2.  The ID field of the reply packet matches that of the question
#        packet
#
#    3.  The answer comes from the same network address the question was
#        sent to
#
#    4.  The answer comes in on the same network address, including port
#        number, as the question was sent from
#
#    In general, the first answer matching these four conditions is
#    accepted.

"In practice" not "in general."  What I want to make clear (and this has
already been in email) is that the "first answer" acceptance is a convenience
and *not necessarily* the best approach.

Perhaps it would illustrative to show a time diagram of how a forged answer
might slip in.

(Packet sniffer attack)

Client     v issues query       gets        gets
DNS                             forgery ^   true ^
Intermediate     v Sees query
(Attacker)         Forges response ^
Intended                  v Sees query
DNS Server                  Prepares response ^

             0------------1------------2------------3------------4-----time->

(Predictor Attack)

Client     v issues query  gets             gets
DNS                        forgery ^        true ^
Intermediate based on prediction
(Attacker)   sends response ^
Intended                  v Sees query
DNS Server                  Prepares response ^

             0------------1------------2------------3------------4-----time->

In both cases, the false one comes first, which is why the current practice
(accept first) is suspect.  BTW - the ascii art is "more precise than
accurate," meant as a substitute for sending in the text I'd like to see.

#    If a third party succeeds in meeting the four conditions before the
#    answer from the authentic answer does so, it is in a position to feed
#    a resolver fabricated data.  When it does so, we dub it an attacker,
#    attempting to spoof in fake data.
#
#    All conditions mentioned above can theoretically be met by a third
#    party, with the difficulty being a function of the resolver
#    implementation and zone configuration.

"difficulty" of what?  I think you mean generating a forgery that is
accepted as genuine.

# 4.  Details

Details of what...?  Details of attacks or details of defenses?

#    The previous paragraph discussed a number of requirements an attacker
#    must match in order to spoof in manipulated (or fake) data.  This
#    section discusses the relative difficulties and how implementation
#    defined choices impact the amount of work an attacker has to perform
#    to meet said difficulties.
#
#    Some more details can be found in section 2.2 of [RFC3833].
#
# 4.1.  Forcing a question

I think this is what you are saying in this section:

This is one form of what I call a predictive attack.  In this, the attacker
predicts that the victim will make a move in response to a stimulus from
the attacker.  To the attacker, they first decide what forged answer they want
the victim to accept and then force the victim to ask the question.  The
challenge remaining for the attacker is to fill in the fields of the response
that it can't predict before the true response arrives.

...

Another form of predictive attack is one that takes advantage of the TTL,
the attacker doesn't make the victim ask but guesses when the question will
arise and then attempts to get an accepted forgery.

# 4.3.  Matching the ID field
...
#    Additionally, if the target nameserver can be forced into having
#    multiple identical questions outstanding, the 'Birthday Attack'
#    phenomenon means that any fake data sent by the attacker is matched
#    against multiple outstanding questions, significantly raising the
#    chance of success.  Further details in Section 5.

I ask (again) for a reference to something defining the term "Birthday
Attack."  I am not asking for an explanation of it in email, this document
has to have a refernce for the term somewhere.

# 4.4.  Matching the source address of the authentic answer
#
...
#    Generally, this condition requires at most two or three attempts
#    before it is matched.
#
#    It should be noted that meeting this condition entails being able to
#    transmit packets on behalf of the address of the authoritative
#    nameserver.  While two Best Current Practice documents ([RFC2827] and
#    [RFC3013] specifically) direct Internet access providers to prevent
#    their customers from assuming IP addresses that are not assigned to
#    them, these recommendations are not universally (nor even widely)
#    implemented.

After reading this section, I wonder why the response's source address is
checked at all.  If it is soooo easy to forge, what's the use?

# 4.6.  Have the answer arrive before the authentic answer
#
#    Once any packet has matched the previous four conditions (plus
#    possible additional conditions), no further answers are generally
#    accepted.
#
#    This means that the third party has a limited time in which to inject
#    its spoofed answer, typically in the order of at most 100ms
#    (depending on the network distance to the authentic authoritative
#    nameserver).
#
#    This time period can be far longer if the authentic authoritative
#    nameservers are (briefly) overloaded by queries, perhaps by the
#    attacker.

So the summary is - the attacker can either stimulate the victim into asking,
otherwise predict the time of an particular question, or just through dumb
luck, throw packets forging the message ID, question, source and destination
addresses plus a plausible reply (answer/authority/additional section) in less
than 100ms.  Our challenge is to make the forgery too difficult to do.

What is unclear is whether the attacks assume that the attacker is
1) next to the victim
2) between the victim and true source (in-line)
3) next to true source
4) no where's near either

and whether

5) the attack is targeting a particular domain
6) the attack is targeting the cache of the victim

# 5.  Birthday attacks
#
#    The so called birthday paradox implies that a group of 23 people
#    suffices to have a more than even chance of having two or more
#    members of the group share a birthday.

This time I'll ask the same question again - the number "23" is related to
only 366 days in a year, right?  What would the number be if it were 8K or 32K
(which are the numbers presented earlier in the section on message IDs being
just 14 or the full 16 bits)?

#    An attacker can benefit from this exact phenomenon if it can force
#    the target resolver to have multiple equivalent outstanding questions
#    at any one time to the same authoritative server.

This is a new "issue" - whether a querier would have such a situation.

# 6.  Accepting only in-zone answers

This is not the next section I expected.  The document has taken time to set
up the problem of forgery and I would expect that is time to shift gears into
the steps to be taken to make forgery harder.  But instead we branch off into
something completely unrelated.

#    Answers from authoritative nameservers often contain information that
#    is not part of the zone for which we deem it authoritative.  As an
#    example, a query for the MX record of a domain might get as its
#    answer a mail exchanger in another domain, and additionally the IP
#    address of this mail exchanger.
#
#    If accepted uncritically, the resolver stands the chance of accepting
#    data from an untrusted source.  Care must be taken to only accept
#    data if it is known that the originator is authoritative for that
#    data.

I really don't buy that.  If that were true, glue would never work.  In
DNS you need to have some level of trust in what you see at first peek
but know to find better info, and ditch bad stuff once you know.

#
#    One very simple way to achieve this is to only accept data if it is
#    part of the domain we asked the question for.

I think this is too simplistic to be true.  What you want to restrict
acceptance to is data germane to the question.  Like the NS records for the
zone purporting to be authoritative for the answer, CNAME/DNAME records
redirection.  While I don't like that RFC 1034 included CNAME chasing (in
retrospect a mistake in my book but I realize why it is there), we have it.

(Terminology - we don't ask for data that is "part of a domain.")

# 7.  Combined difficulty
#
#    Given a known or static destination port, matching ID field, source

Instead of "destination" use some play on "query/question" "source/origination"
to disambiguate between the query and response source and destination.

#    and destination address requires on average in the order of 2 * 2^15
#    = 65000 packets, assuming a domain has 2 authoritative nameservers.

64K packets...and it isn't "2 authoritative" but "2 nameserver IP addresses."
Remember, we have anycast and load balancers out there.

#    If the window of opportunity available is around 100ms, as assumed
#    above, an attacker would need to be able to briefly transmit 650000
#    packets/s to have a 50% chance to get spoofed data accepted on the
#    first attempt.
#
#    A realistic minimal DNS answer consists of around 80 bytes, including
#    IP headers, making the packet rate above correspond to a respectable
#    burst of 416Mb/s.

But this attacks just one victim server, not a widespread cache poisoning.

#    As of mid-2006, this kind of bandwidth was not common but not scarce
#    either, especially among those in a position to control many servers.
#
#    These numbers change when a window of a full second is assumed,
#    possibly because the arrival of the authentic answer can be prevented
#    by overloading the bonafide authoritative hosts with decoy questions.
#    This reduces the needed bandwidth to 42 Mb/s.

I get a little uneasy stretching this without evidence of actual activity
to back it up.  For one, I'd have to also have sufficient bandwidth to flood
all authoritative servers (and recall when you deal with anycast, all the
servers that the victim would see, not the attacker) to lengthen the window
of vulnerability.  If I was cutting down from 420 to 42 Mb/s for an attack
at a cost of needing n x a high number to shut down other server response,
I don't think it would be worth it - and it would raise alarm bells more
readily.

Upshot - the above paragraph seems like hyperbole to me.

#    If in addition the attacker is granted more than a single chance and
#    allowed up to 60 minutes of work on a domain with a time to live of
...

Most crooks screw up on the first attempt and get cold feet or caught.  This
is why law enforcement works.  Again, this paragraph seems more like a scare
statement than the telling of a motivating incident.

# 7.2.  Calculation
#
#    The probability of spoofing a resolver is equal to the amount of fake
#    packets that arrive within the window of opportunity, divided by the
#    size of the problem space.

"Spoofing a resolver"...I think that should be "getting a forged answer
accepted as real.  And I don't believe that is the correct probability
measure either.  What you have is a measure of what percentage of possible
answers could be confused with the real one.  The probability of getting
an answer accepted illegitimately is the probability of getting an acceptable
forgery through in the time allotted.

#
#    When the resolver has 'D' multiple identical outstanding questions,
#    each fake packet has a proportionally higher chance of matching any
#    of these questions.  This assumption only holds for small values of
#    'D'.

If they are "identical outstanding questions" then what does "matching
any of these" refer to?  I suppose your meaning of identical has some
degrees of freedom in it.

#
#    In symbols, if the probability of being spoofed is denoted as P_s:
#
#               D * F
#    P_s =    ---------
#             N * P * I
#
P_s = (average number of identical queries x packets sent by attacker) /
       (number of nameservers x ports x ids)

I don't know...that makes no real sense to me.  You are assuming that the
attacker is trying to get one "point of poisoning" at one server.  A point
of poisoning is either one RRset or all the sets at a domain name (via
an "any" response).

(I've been staring at this for a while and can't get it, so I'll move on.)

# 8.  Discussion
#
#    The calculations above indicate the relative ease with which DNS data
#    can be spoofed.  For example, using the formula derived earlier on a
#    domain with a 3600 second TTL, an attacker sending 7000 fake answer
#    packets/s (a rate of 4.5Mb/s), stands a 10% chance of spoofing a
#    record in the first 24 hours, which rises to 50% after a week.

The problem I have is that the "relative ease" is only presented via a
calculation that I have a hard time following.  Is this kind of attack
really happening?  Is there any evidence to demonstrate (as opposed to
calculate) the relative ease?

# 9.  Countermeasures
...
#    o  Question name (compared case-insensitively)
#
#    o  Question class and type

Keep in mind that the above does not (yet) apply to AXFR.

#    Resolver implementations MUST have the ability to:

Why are these "MUST"s and not "RECOMMEND"ations?
Is this needed for interoperability?

#    If a resolver sends out multiple equivalent questions to any
#    authoritative server, before receiving an answer, all MUST have
#    identical ID, source address and source port.

Then you are fixing D:=1?

#    Resolvers SHOULD favour authoritative nameservers with which a trust
#    relation has been established; Stub-resolvers SHOULD be able to use
#    TSIG ([RFC2845]) or IPSEC ([RFC2401]) when communicating with their
#    recursive resolver.

Or SIG(0) or some other message/datagram verification scheme...

#    In case a cryptographic verification of answer validity is available,
#    resolver implementations MAY waive above rules, and rely on this
#    guarantee instead.

Why?  What if I sign something, distribute it and then discover I want to
"revoke" it.  It is possible someone could replay the shoulda-been-revoked
data to drown out the good replacement data.  Or what if I yank off DNSSEC
because of an error and want to return to unsigned?

Cryptography is not a panacea.

# 10.  Security Considerations

No IANA Considerations?