Subject: conjoining dns-forgery-resilience with dns-0x20; also, rtt banding

From: Paul Vixie <[email-masked]>
Date: Tue, 11 Mar 2008 17:35:26 +0000

i said in the dnsext meeting just now that we should delay wglc on
dns-forgery-resilience until dns-0x20 can join it, be referenced by
it, and the two progress together.

furthermore:

isc also has a proposed addition to dns-forgery-resilience, having
to do with rtt banding and/or other forms of authority server mixing.
i'd like to see this proposed and discussed during the delay while
waiting for dns-0x20 to catch up.

to wit:

the tuple used to match non-servfail responses to outstanding requests
includes query id, authority server address, question name, question type,
and question class.  0x20 is a way to improve the question name's
uniqueness.  dan bernstein already showed us how to improve the query id's
uniqueness.  question class and type aren't subject to this improvement.
but, authority server address uniqueness can be improved.  i would like
dns-forgery-resilience to show all possible improvements to the uniqueness
of this tuple.

more from:

joao, jinmei, explorer, and marka were last seen talking about rtt banding;
i propose that one of them follow up this message with "isc's" current
thoughts on the topic of improving authority server address uniqueness.

--
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: bert hubert <[email-masked]>
Date: Wed, 12 Mar 2008 00:46:03 +0100

> it, and the two progress together.

I appreciate this effort, but I'm also sceptical enough to think it would be
wise to release forgery-resilience first, and have 0x20 update is. 

I've seen the amount of resistance forgery-resilience has caused in some
circles, I think it should stand on its own.

This is not to say I'm against 0x20, btw - it looks promising. But from a
practical standpoint, I'd prefer to have forgery-resilience passed, and have
0x20 be an update to it (in addition to specifying 0x20 of course).

I refer the esteemed workgroup participants to rfc 1925, paragraph 2, sub 5
- even though it doesn't strictly apply.

	Bert

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

---

From: Pekka Savola <[email-masked]>
Date: Wed, 12 Mar 2008 05:42:18 +0200 (EET)

> circles, I think it should stand on its own.

The usual time the IETF seems to need to iron out most glaring 
specification issues and wear down any resistance is 2-3years (+- 1 
year).  There was already some resistance and/or skepticisim at the 
meeting, so a timeline like this (unless author was very active in 
building a strong consensus behind the document) seems realistic.

I agree it's better to ship forgery-resilience now and having 0x20 
update it later, if necessary, seems like the right thing to do.

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

---

From: Olaf Kolkman <[email-masked]>
Date: Wed, 12 Mar 2008 07:24:10 -0400

On Mar 11, 2008, at 11:42 PM, Pekka Savola wrote:

> year).

But there are success stories of specifications that went from I-D to  
RFC in less time than a year.

This is a simple specification. Folk have been reviewing and  
implementing it. If the IETF needs 2-3 years to process a  
specification like 0x20 than... sigh...

As far as I understand there are some technical open issues but not  
much, it should be easy to iron those out. I would expect that a next  
revision is in such a state that it can be last called. This would  
involve some pressure from the editor and some pressure from the  
chair. It could well be that 0x20 will not reach consensus because  
people will never appreciate the beauty of its ugliness (Anybody saw  
the Marcel Duchamp gallery in the Museum yesterday?) but that is  
something that can be determined in less than 2-3 years.

I think it would be good if the docs where merged but my strategy  
would  be to last call the docs separately so that once it is clear  
they are both mature do the merging.

--Olaf

---

From: Pekka Savola <[email-masked]>
Date: Wed, 12 Mar 2008 14:58:37 +0200 (EET)

On Wed, 12 Mar 2008, Olaf Kolkman wrote:
>> specification issues and wear down any resistance is 2-3years (+- 1 year).
>
> But there are success stories of specifications that went from I-D to RFC in 
> less time than a year.

Unfortunately those seem to be the exceptions that prove the rule.. 
:-)

For example consider the dnsop-reflectors-are-evil document, which was 
supposedto be on fast-track but has been 2 months short of 2 years 
now? :-)

> This is a simple specification. Folk have been reviewing and implementing it. 
> If the IETF needs 2-3 years to process a specification like 0x20 than... 
> sigh...
...
> I think it would be good if the docs where merged but my strategy would  be 
> to last call the docs separately so that once it is clear they are both 
> mature do the merging.

But I agree a *LOT* of this depends on the WG chairs, authors and how 
strong consensus there is (and how much they are willing to compromise 
and spend energy to build) behind the document.

I could agree to your suggestion that we try to move quickly with 0x20 
provided that, as you suggested, that the decision to tie the fates of 
documents together is made at a later phase, and we don't 
significantly slow down the progress of forgery-resilience for this.

---

From: Olaf Kolkman <[email-masked]>
Date: Wed, 12 Mar 2008 09:43:53 -0400

On Mar 12, 2008, at 8:58 AM, Pekka Savola wrote:

> and we don't significantly slow down the progress of forgery- 
> resilience for this.

I was thinking that the reverse might actually happen, forgery slowing  
down 0x20 ;-)

--Olaf

---

From: Paul Vixie <[email-masked]>
Date: Wed, 12 Mar 2008 14:06:10 +0000

> > This is a simple specification. Folk have been reviewing and implementing
> > it. If the IETF needs 2-3 years to process a specification like 0x20
> > than... sigh...

RFC 2671 itself went from i-d to RFC in less than a year.  it CAN be done.

> > I think it would be good if the docs where merged but my strategy would
> > be to last call the docs separately so that once it is clear they are
> > both mature do the merging.

i didn't propose merging, and i don't think you mean merging.  i proposed,
and i think you mean, adding a dependency inside forgery-resilience, pointing
at 0x20.  now, if forgery-resilience specifies is an FYI or BCP, it can have
a pointer to 0x20 in its current i-d form, and be edited down the track if
0x20 gets an RFC number before forgery-resilience gets an RFC number.  but
if forgery-resilience is going to be an STD, then it can't reference 0x20
until 0x20 has an RFC number.  bert's counterproposal is that 0x20 proceed
independently, and that it update forgery-resilience.  i'm OK with that, and
with the corresponding proposal for rtt banding (write a new draft and have
it update forgery-resilience).  i would have preferred a single RFC issued
one time containing everything we knew at the moment.  forgery-resilience is
in a sense already out of date, but if there's value in publishing it even
knowing that it's already out of date, then by all means, let's publish it.

> From: Pekka Savola <[email-masked]>
...
> strong consensus there is (and how much they are willing to compromise and
> spend energy to build) behind the document.
> 
> documents together is made at a later phase, and we don't significantly
> slow down the progress of forgery-resilience for this.

0x20 only contains one protocol change.  i don't think it's controversial, or
to put it another way, i think we already have consensus on it.  in my opinion
we could WGLC 0x20 right now (assuming i submitted it to the ietf draftbot,
which i havn't yet since i missed the deadline).  here's the one thing in 0x20
that makes it have to be an STD vs. an FYI or BCP:

   5.2. It is strongly urged that the DNS specification be amended to
   require that the question section from the request MUST BE copied,
   exactly, bit for bit, into the question section of the response.  The
   DNS specification is silent on the matter of altering 0x20 bits in the
   question name when copying it from the request to the response, so, this
   change is "within the spirit."

   A change to the specification is necessary because while such bit for
   bit copying "happens to be" the universal practice today, we must warn
   all future responder implementors that the 0x20 bits, while not
   significant for name matching, are now in use as a "covert channel" by
   the requestor, for the purpose of increasing the identity of
   transactions.

noting that stuart cheshire has privately proposed to me an improvement of
the wording at http://sa.vix.com/~vixie/dns-0x20.txt, since a number of folks
at the dnsext meeting thought 0x20 would break binary labels, or alter the
meaning of labels by modifying characters that weren't ascii letters.  i'll
make that change and submit the text to the draftbot as soon as ietf week is
ended.

is there really any controversy around 0x20, that make it ineligible for an
almost instant WGLC?

---

From: Paul Vixie <[email-masked]>
Date: Wed, 12 Mar 2008 14:15:27 +0000

> I was thinking that the reverse might actually happen, forgery slowing

i was not proposing that 0x20 reference or depend upon forgery-resilience,
so this is a can't-happen.  the dark horse here is rtt banding.  if we don't
adopt that change to forgery-resilience, then we can WGLC both 0x20 and
forgery-resilience next monday when the ietf meeting is over.

---

From: bert hubert <[email-masked]>
Date: Wed, 12 Mar 2008 15:46:55 +0100

> forgery-resilience next monday when the ietf meeting is over.

Fwiw, I've done some rtt measurements in the past based on PowerDNS, it
turns out that at least my favorite operating system (Linux 2.6) plays fast
and loose with UDP timings, quite often sending a packet later than it
admitted, leading to a very rapid response.

This led to my 9ms ADSL connection reporting 5ms response times in a small
fraction of queries.

I'm not exactly sure what 'rtt banding' is, but I estimate it won't play
well with such badly reported timings. And unfortunately, computers (and
network drivers, and nics) positively suck for sub-10ms measurements. Even if
we call Linux buggy in this respect, it remains a challenge.

So I'm all in favour of last call for at least forgery-resilience soon. I'm
working over the last batch of minor nits reported, but those all appear to
be typographical or rephrasing of things.

	Bert

---

From: Florian Weimer <[email-masked]>
Date: Wed, 12 Mar 2008 16:12:38 +0100

> it, and the two progress together.

I don't think this is a good idea.  If there's an attempt to derail
one of those drafts, it affects both, so let's keep them as separate
as possible.  The 0x20 material is probably quite controversial, and
BCP 79 issues may still turn up.

0x20 seems to need far more testing than it got so far (Windows, DNS
load balancers, popular middleboxen come to my mind).  If 0x20 picks
up authority server address distribution, it will turn into a
significantly more complex beast, too.

-- 
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: Wed, 12 Mar 2008 15:47:55 +0000

> we call Linux buggy in this respect, it remains a challenge.

rest assured, the rtt banding discussion i overheard accounts for this kind of
slop.  most operating systems can't accurately measure things shorter than a
tick, and some can't come within 10ms.  "horseshows, hand grenades, and time."

---

From: Paul Vixie <[email-masked]>
Date: Wed, 12 Mar 2008 15:59:23 +0000

> ...  The 0x20 material is probably quite controversial, and

do tell.  i havn't seen or heard any controversy yet, just misunderstandings
because the draft's text is sloppy or inadequate, and folks saying it's ugly,
and folks saying why waste effort on this if we believe in dnssec long term.

> load balancers, popular middleboxen come to my mind).

i know of very few places where a caching recursive nameserver speaks through
middleboxes when reaching authority servers.  0x20 is definitely not middlebox
safe, which is why i don't recommend it for stub resolver use.  more testing
would be welcome -- i've been running it on my own nameservers for a couple
weeks now and have yet to trigger the name-mismatch syslog even after millions
of upstream transactions.  but i don't have a load balancer.  what's needed is
a BIND9 patch that lots of people can test in lots of topologies.

> If 0x20 picks up authority server address distribution, it will turn into a

authority server address distribution will not be part of the dns-0x20 draft,
it can either become a section in forgery-resilience, or become its own draft.

---

From: bert hubert <[email-masked]>
Date: Wed, 12 Mar 2008 17:38:21 +0100

On a related note, since when do we try to standardise or even mandate
untested behaviour?

'port hopping' and the various other techniques described in
forgery-resilience have been in wide use for 5 years or more.

I'm actually wondering what is in the drinking water in Phildelphia that we
are suddenly being so psyched up about standardising dns-0x20!

I'm going to do the last call for forgery-resilience soon, and I'd love to
look at dns-0x20 and rtt-banding and whatnot afterwards.

But please let's not try to get ahead of ourselves.

	Bert (who usually does not top quote)

On Wed, Mar 12, 2008 at 03:59:23PM +0000, Paul Vixie wrote:
> !DSPAM:47d805af176382039411530!

---

From: Paul Vixie <[email-masked]>
Date: Wed, 12 Mar 2008 17:00:35 +0000

> On a related note, since when do we try to standardise or even mandate

this isn't untested behaviour.

> forgery-resilience have been in wide use for 5 years or more.

are you proposing that we let 0x20 cook for a few months or years, then?

> are suddenly being so psyched up about standardising dns-0x20!

it happens to work.  if we don't get the standard clarified, then a new
implementation will be free to downcase (for example) the question name
when copying from the request to the response.  thus there is a need for
speed, and a demonstration of safety.

> But please let's not try to get ahead of ourselves.

how far behind ourselves would you feel comfortable being?

re:

> > ... more testing would be welcome -- i've been running it on my own
> > nameservers for a couple weeks now and have yet to trigger the
> > name-mismatch syslog even after millions of upstream transactions.  ...

---

From: David Conrad <[email-masked]>
Date: Wed, 12 Mar 2008 10:49:38 -0700

> since a number of folks
> at the dnsext meeting thought 0x20 would break binary labels,

Sorry?  Who cares?

Regards,
-drc

---

From: bert hubert <[email-masked]>
Date: Wed, 12 Mar 2008 18:47:00 +0100

> this isn't untested behaviour.

I appreciate the testing you've performed, but from bitter experience I know
how much corner cases hide on the internet. Many of which might not be
appearant from even millions of transactions.

> are you proposing that we let 0x20 cook for a few months or years, then?

Indeed I am, especially if we want not just to describe it (which does not
take an RFC), but say people SHOULD use it. Years might be too much, but
months are definitely too little.

There isn't even a public implementation as far as I know.

It is fine to add the rules you describe that make sure that dns-0x20 can
work, of course.

But please do not conjoin this with the boring words of
dns-forgery-resilience :-)

	Bert

---

From: Paul Vixie <[email-masked]>
Date: Wed, 12 Mar 2008 18:09:47 +0000

> appearant from even millions of transactions.

if there is a problem in some corner, and we don't encounter it frequently,
then it will be a bit like "delegation-only" -- once the mass of the installed
base stopped accepting anything except delegations from all TLD's except a few
that were known at the time, it became impossible for new non-delegation-only
TLDs to come into existence, unless they wanted to fight a long uphill battle.

so, practically speaking, the fact that i've not run into any non-copiers in
a few million upstream transactions, means that further testing is illuminative
but not decisive.

> There isn't even a public implementation as far as I know.

i think unbound has it in SVN now.  here's the code i used in my own
implementation.  a patch for BIND9 will be shortly forthcoming, i'm told.

/* Return some random bits, pulling them through an in-process entropy pool.
 */
u_int
my_random(int bits) {
        static u_long randbuf;          /* up to next 32 random bits */
        static int randbuf_len;         /* bits remaining in randbuf */
        static int recrypt;             /* reseed with true random bits then */
        u_long mask;
        u_int ret;

        if (bits >= NBBY * (int)sizeof(u_int)) {
                assert(bits <= NBBY * (int)sizeof(u_int));
                mask = (u_int)-1;
        } else {
                assert(bits >= 0);
                mask = (1 << bits) - 1;
        }
        if (randbuf_len < bits) {
                if (--recrypt <= 0) {
                        recrypt = 10000;
                        srandomdev();
                }
                randbuf = random();
                randbuf_len = NBBY * (int)sizeof(u_int);
        }
        randbuf_len -= bits;
        ret = randbuf & mask;
        randbuf >>= bits;
        return (ret);
}

/* Implement Dagon-style DNS name randomization.
 */
void
randomize_dns_name(u_char *nname) {
        int llen;

        while ((llen = *nname++) != 0) {
                int i;

                for (i = 0; i < llen; i++) {
                        int ch = *nname;

                        if (isascii(ch) && isalpha(ch)) {
                                if (my_random(1))
                                        ch |= 0x20;
                                else
                                        ch &= ~0x20;
                                *nname = ch;
                        }
                        nname++;
                }
        }
}

> It is fine to add the rules you describe that make sure that dns-0x20 can

that being the only important part (since it changes the protocol description
and has to be done speedily), i don't understand exactly what you'd like to
see delayed.

> dns-forgery-resilience :-)

perhaps if dns-forgery-resilience were renamed to dns-queryport-churn then i
would not feel a need to load it up with references to other methods for dns
forgery resilience.

---

From: Edward Lewis <[email-masked]>
Date: Wed, 12 Mar 2008 14:09:17 -0400

>it, and the two progress together.

My impression of 0x20 is that it

1) Merely requires a strengthening (spec-wise) of something that 
seems obvious and seems to be done widely/universally

2) Protects a lot but not everything (e.g., numeric/non-binary labels)

3) Is something that needn't be defined in a standard (much the same 
way resolvers choose authoritative servers.

So I don't agree that we should retard progress on forgery-resilience 
to tie it with 0x20.  We should have something that "clarifies" (if 
you will) the role of the Question section in a reply.  We could 
entertain a document that describes "the use of capitalization 
pattern of a qname in message uniqueness".

-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                                +1-571-434-5468
NeuStar

Never confuse activity with progress.  Activity pays more.

---

From: bert hubert <[email-masked]>
Date: Wed, 12 Mar 2008 21:02:32 +0100

> then it will be a bit like "delegation-only" -- once the mass of the installed

Ok, I've implemented dns-0x20 in the powerdns recursor as well, but I'm
seeing some side effects I worry about.

Just before sending out a question packet, I twiddle the 0x20 bit randomly,
and I now operate case sensitively on processing responses.

However, the output of 'dig' is now weird.

;; QUESTION SECTION:
;www.lwn.net.                   IN      A

;; ANSWER SECTION:
www.lwN.nET.            28798   IN      CNAME   lwN.nET.
lwN.nET.                1198    IN      A       66.216.68.48

I've added 'backmapping' so if I see the result of my mangling, I copy back
in the original untwiddled name, resulting in something like:

;; QUESTION SECTION:
;www.lwn.net.                   IN      A

;; ANSWER SECTION:
www.lwn.net.            28798   IN      CNAME   lwN.nET.
lwN.nET.                1198    IN      A       66.216.68.48

Should we map back everything we twiddled? Or should we trust stub resolvers
to be case insensitive?

> a few million upstream transactions, means that further testing is illuminative

I have over two billion queries and supposedly correct answers here I can
test with, which would generate more confidence.

But I still worry about client side issues - I don't have a representative
test for those.

	Bert

---

From: Paul Vixie <[email-masked]>
Date: Wed, 12 Mar 2008 20:25:18 +0000

> lwN.nET.                1198    IN      A       66.216.68.48

for me that comes out as

;; QUESTION SECTION:
;www.lwn.net.                   IN      A

;; ANSWER SECTION:
www.lwn.net.            28588   IN      CNAME   lwn.net.
lwn.net.                988     IN      A       66.216.68.48

because i "backmap" before decompressing, per a suggestion from wouters,
which was incorporated into http://sa.vix.com/~vixie/dns-0x20.txt a week
or so ago and looks like this:

   5.4. Requestors should take care to remember the original question name,
   so that following successful verification of the 0x20-randomized
   question name, the original can be copied into the response message
   before the other sections are uncompressed.  This is because compression
   pointers in the answer, authority, and additional section often point
   back to the question section, with the ugly result of copying the
   0x20-randomized bits into the cache, and into subsequent responses which
   include data from the cache.

> Should we map back everything we twiddled? Or should we trust stub resolvers

i don't think we should replace any part of the response except the question
name.  if the responder copies, than uses pointers, and in their copy they use
the upper/lowercaseness of the question name rather than the zone content, then
i think we're too far afield and we have to just let some ugly things happen.

> But I still worry about client side issues - I don't have a representative

my stub resolvers aren't seeing these 0x20 bits, thanks to wouters' idea.

---

From: Robert Elz <[email-masked]>
Date: Thu, 13 Mar 2008 03:43:24 +0700

Date:        Wed, 12 Mar 2008 14:06:10 +0000
    From:        Paul Vixie <[email-masked]>
    Message-ID:  <[email-masked]>

  | 0x20 only contains one protocol change.
  | i don't think it's controversial, or

You mean the protocol change?   That is, requiring unchanged question
section in the reply?   That's fine, it's what I always kind of assumed
was required anyway.

But the way you're proposing on using that?   While it is very clever,
even cute, it is also downright evil.   The a==A stuff that's in the
DNS is truly annoying, it should never have been done (though I understand
why it was), and it would be nice to be able to make it go away at some
far distant future point of time.

Doing this case flipping trick, and actually having implementations use
it in the wild would mean we could never rid ourselves of that botch to
the protocol.

Further, this trick doesn't help at all for the single most important
DNS lookup that's ever done - the query for the root nameservers.
Manage to forge a reply to that one and none of the others matter.
If anything, by making others harder to forge replies for, but leaving
this one untouched, you'd be shifting attacks more in that direction,
which I don't think would be a useful result.

Last, it results in just plain ugly replies - in the context of AXFR
I saw some mention of name case preservation, and how label compression
can make a mess of this.   I think it was marka who said that it's only
in the context of AXFR that anyone ever complains about this.   I beg to
differ - this bugs me no end on ordinary queries, and you're proposing
making it worse...

Please put this trick in the "look ma, no hands" category - treat it as
something to marvel at, laugh at, and avoid like the plague.

kre

ps: a better thing to be spending time on might be to redefine the DNS
packet format, and fix lots of the issues that we currently have that
are caused by this - I suspect it can be done in a way (kind of like EDNS0)
whereby the query format would appear compatible with basic old DNS, but
would signal advanced capability - once that's done, the reply can be
whatever will work best - this could fix multiple queries in one packet,
add as many ID bits as could ever be useful, and whatever else needs doing.

---

From: Robert Elz <[email-masked]>
Date: Thu, 13 Mar 2008 04:17:46 +0700

Date:        Wed, 12 Mar 2008 21:02:32 +0100
    From:        bert hubert <[email-masked]>
    Message-ID:  <[email-masked]>

  | Should we map back everything we twiddled? Or should we trust stub resolvers
  | to be case insensitive?

I don't think you should be doing this at all (as my previous message
probably made clear), but if you have to, twiddle the question back
as soon as you get (and have validated) the reply - before you expand
the labels in other sections.

kre

---

From: Paul Vixie <[email-masked]>
Date: Wed, 12 Mar 2008 21:29:03 +0000

> From: Robert Elz <[email-masked]>
> 
> section in the reply?

yes.

> That's fine, it's what I always kind of assumed was required anyway.

that's good news.  anybody else got a contrary opinion?  ed suggested making
that one bit of text into its own draft and progressing it directly.  anybody
opposed to that?

> But the way you're proposing on using that?  While it is very clever, even
> cute, it is also downright evil.  The a==A stuff that's in the DNS is truly
> annoying, it should never have been done (though I understand why it was),
> and it would be nice to be able to make it go away at some far distant
> future point of time.
> 
> Doing this case flipping trick, and actually having implementations use it
> in the wild would mean we could never rid ourselves of that botch to the
> protocol.

there's no way to make this go away, ever, except with a new label type, whose
definition will/would presumably be made to preclude this kind of evilness.

> Further, this trick doesn't help at all for the single most important DNS
> lookup that's ever done - the query for the root nameservers.  Manage to
> forge a reply to that one and none of the others matter.  If anything, by
> making others harder to forge replies for, but leaving this one untouched,
> you'd be shifting attacks more in that direction, which I don't think would
> be a useful result.

of course.  likewise hp.com is less secure than dec.com and so on.  bad idea,
bad design.  except that it's better than nothing.  to get actual security we
should deploy Secure DNS aka DNSSEC.  especially we should sign the root zone
and distribute the key widely.

> Last, it results in just plain ugly replies - in the context of AXFR I saw
> some mention of name case preservation, and how label compression can make a
> mess of this.  I think it was marka who said that it's only in the context
> of AXFR that anyone ever complains about this.  I beg to differ - this bugs
> me no end on ordinary queries, and you're proposing making it worse...

since we seem to agree that copying the question is what everybody does and
what everybody should keep doing and what should be clarified in the spec,
then you appear to be arguing that responses ought not use this copied
question as a compression pointer target.  sounds fine to me, if i'm reading
you correctly.  perhaps an "unless it would lead to truncation that would not
occur if the question section copied from the query were available as a 
compression pointer target" exemption, though in an increasingly EDNS0 world
i'm not sure we need to worry much about this as much.

if we uptake ed's suggestion (progress the responder-must-copy clarification
separately) then perhaps that draft would be a good place to recommend the
no-question-pointers logic as well.  (trying to conserver RFC numbers here.)

> something to marvel at, laugh at, and avoid like the plague.

we can't.  i'm already marvelling, i'm already laughing, but i'm not avoiding,
and my lack of avoidance is completely within the spec.  if a dns initiator
implementor can improve security with this trick, and remain within spec, you
can expect that some, if not many or all, will do so.  as a practical matter,
this cat was never in any bag.  there's no basis on which to forbid this, nor
any enforcement powers.

further, and this is the part i brought up in the philly meeting yesterday, we
just got our asses handed to us by amit klein, wrt PRNG state prediction.  how
many more times would we like this kind of thing to happen?  should we wait
until the next round of PRNG predictability attacks are described, before we
decide whether and how to improve transaction level unpredictability?  waiting
for DNSSEC means waiting for the U S Government to decide whether to sign the
root and who should hold the key.  maybe that's tomorrow, maybe it's in 2012.

we have a tuple <qname,qid,respaddr,reqaddr,reqport>.  bernstein showed us how
and why to randomize reqport.  klein and many others have showed us how and
why to randomize qid.  rtt banding is one way to randomize the respaddr.  more
than one upstream-facing reqaddr may be required at some point, chosen at
random.  the 0x20 bletcherous seething hack from hell randomizes the qname.

having just been through another qid scare, and not knowing when to expect
DNSSEC for root and .COM (assuming we decide what has to be done about the CD
bit, and that we deploy MSJ's key rollover, and NSEC3 proves to be deployable,
and assuming USG sets ICANN free next year, and assuming ICANN uses its new
freedom to sign the root zone, and assuming verisign can make a business case
for signing .COM, and so on)... i want to see every randomizable element of
the <qname,qid,respaddr,reqaddr,reqport> tuple actually get randomized.

> kre

vix

> packet format, and fix lots of the issues that we currently have that are
> caused by this - I suspect it can be done in a way (kind of like EDNS0)
> whatever will work best - this could fix multiple queries in one packet, add
> as many ID bits as could ever be useful, and whatever else needs doing.

i'm not reading that kind of ambition among the audience at this stage.  there
may be a later stage, but right now i predict that we'll fight, mostly, as we
stand.

---

From: "W.C.A. Wijngaards" <[email-masked]>
Date: Wed, 12 Mar 2008 22:54:36 +0100

Paul Vixie wrote:
|> some mention of name case preservation, and how label compression can
make a
|> mess of this.
| since we seem to agree that copying the question is what everybody
does and
| what everybody should keep doing and what should be clarified in the spec,
| then you appear to be arguing that responses ought not use this copied
| question as a compression pointer target.  sounds fine to me, if i'm
reading
| you correctly.  perhaps an "unless it would lead to truncation that
would not
| occur if the question section copied from the query were available as a
| compression pointer target" exemption, though in an increasingly EDNS0
world
| i'm not sure we need to worry much about this as much.
|
| if we uptake ed's suggestion (progress the responder-must-copy
clarification
| separately) then perhaps that draft would be a good place to recommend the
| no-question-pointers logic as well.  (trying to conserver RFC numbers
here.)

I would be against no-question-pointers text. It is perfectly ok for a
(authority, cache) server to compress to the question section. The
server can determine if it wants to do so (and if that smashes case).

If you feel the need for text:
Please note that the copied query name can differ in upper and lower
case, and therefore its use as a compression target depends on the
servers choices regarding compression.

Advancing 'copy the question section into the reply bit-for-bit' is fine
with me.

Best regards,
~   Wouter

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Wed, 12 Mar 2008 22:54:21 -0400

On Wed, Mar 12, 2008 at 02:06:10PM +0000,
 Paul Vixie <[email-masked]> wrote 

> is there really any controversy around 0x20, that make it ineligible for an

Call me a sissie but, for me, a two-weeks test at one site is not
enough, taking into account that it is a (potentially) incompatible
protocol change and that there is a wide variety of DNS stuff in the
wild.

---

From: Robert Elz <[email-masked]>
Date: Thu, 13 Mar 2008 10:01:36 +0700

Date:        Wed, 12 Mar 2008 21:29:03 +0000
    From:        Paul Vixie <[email-masked]>
    Message-ID:  <[email-masked]>

  | there's no way to make this go away, ever, except with a new label type,
  | whose definition will/would presumably be made to preclude this kind of
  | evilness.

Not true, there's nothing in the DNS currently (before your draft) which is
depending upon this "feature" - sure, implementations have to handle it,
but nothing is relying upon its existance (not in the DNS itself).

Thus, it can be changed.   It would take a very long time, and a process
of smaller steps, but it could be done.

It cannot be if we start to actually rely upon it however, so that's
what I'd suggest should not be done.

  | of course.  likewise hp.com is less secure than dec.com and so on.
  | bad idea, bad design.  except that it's better than nothing.

I actually disagree.    I think it is worse than nothing, as it
points the attacks at the worst possible place - that is, it motivates
attacking the place where most damage would be caused.

  | since we seem to agree that copying the question is what everybody does and
  | what everybody should keep doing and what should be clarified in the spec,
  | then you appear to be arguing that responses ought not use this copied
  | question as a compression pointer target.

No.  Though I wouldn't object to one that didn't.

  | we can't.  i'm already marvelling, i'm already laughing
  | but i'm not avoiding, and my lack of avoidance is completely within
  | the spec.

The place to start on eliminating (ascii only) case independance would
be to issue a spec that requires resolvers to always look up the exact name
passed (no case conversions, ever.)

Aside from your hack, that's what resolvers (that I know of) do now anyway,
so perhaps we should start with that, today.

Then you'd no longer be within spec...

kre

---

From: Florian Weimer <[email-masked]>
Date: Thu, 13 Mar 2008 11:26:56 +0100

* Paul Vixie:

> do tell.  i havn't seen or heard any controversy yet,

People have begun putting out press statements opposing 0x20.  I hope
you aren't too surprised.

> just misunderstandings because the draft's text is sloppy or
> inadequate, and folks saying it's ugly, and folks saying why waste
> effort on this if we believe in dnssec long term.

I like the idea, and I think it might work reasonably well, but it's
technically a backwards-incompatible protocol change.

Anyway, I would welcome almost *anything* which improves DNS security
and is deployable in the short term.  Extrapolating from the bits of
data I've got, I estimate that we will see large-scale attempts at
cache poisoning at a few major ISPs in two or three years.  Even if
those attacks do not succeed in injecting bad data, the denial of
service aspect alone is worrisome.

> i know of very few places where a caching recursive nameserver
> speaks through middleboxes when reaching authority servers.

It's a policy issue in a few places, I assume.  Everything has to pass
through firewalls and stuff.  People would run BGP across the IPS if
it they only could connect their WAN links to the IPS. 8-P

> 0x20 is definitely not middlebox safe, which is why i don't
> recommend it for stub resolver use.

And how is this not a show-stopper for a global configuration switch
in the name server, when you can't know the location of middleboxes?
On the other hand, these middleboxes need to be fixed for DNSSEC as
well, so this needs to be worked out anyway.

But I'm very much in favor of anything that gets us out of the current
state, which is so firmly focused on discouraging innovation.

---

From: Florian Weimer <[email-masked]>
Date: Thu, 13 Mar 2008 11:32:23 +0100

> way resolvers choose authoritative servers.

Huh?  Even if they are not suitable implementation guidance, standards
are an important help while deciding how to fix things that do not
work as expected.  If there's a standard that requires case
preservation, it's difficult to argue that case normalization is
kosher.

---

From: Edward Lewis <[email-masked]>
Date: Thu, 13 Mar 2008 09:39:38 -0400

>preservation, it's difficult to argue that case normalization is

IETF standards are written with the goal of achieving 
interoperability.  The element of 0x20 that has a concern about 
interoperability  is addressed in my comment #1.  What #3 refers to 
is how the local side (of the message exchange) twists the bits for 
it's own benefit, that is not an interoperability related issue.

Note that I used the word "standard" and not the word "document" in 
#3.  It would be fine and dandy to see this bit twiddling documented 
in a BCP or informational document.
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                                +1-571-434-5468
NeuStar

---

From: bert hubert <[email-masked]>
Date: Thu, 13 Mar 2008 19:15:48 +0100

> a few million upstream transactions, means that further testing is illuminative

I think my test data is a bit broader - after 40000 queries out of my 2
billion or so, I have:

19:06:19 Case mismatch '66.249.93.9' A: 'maPs.l.gOoglE.COM.' != 'maps.l.google.com.'
19:06:19 Case mismatch '66.249.93.9' A: 'MaPS.l.gOOgLE.COM.' != 'maps.l.google.com.'
19:06:20 Case mismatch '211.79.207.26' A: 'MoEVaX.Edu.tW.' != 'moevax.edu.tw.'
19:06:20 Case mismatch '216.102.246.43' AAAA: 'noEmAIL.Com.' != 'noemail.com.'
19:06:29 Case mismatch '64.233.161.9' A: 'ytIMg.l.GOOgLE.cOM.' != 'ytimg.l.google.com.'
19:06:29 Case mismatch '64.233.161.9' A: 'YTIMG.L.goOGle.COm.' != 'ytimg.l.google.com.'
19:06:31 Case mismatch '211.79.207.26' A: '123-240-206-152.CCTV.dyNAMIc.lsc.neT.tw.' != '123-240-206-152.cctv.dynamic.lsc.net.tw.'
19:06:40 Case mismatch '210.17.9.229' AAAA: 'POst.EcCrM.EPaPER.cOm.tw.' != 'post.eccrm.epaper.com.tw.'
19:06:48 Case mismatch '216.254.98.230' AAAA: 'GRanDmOTherSFoODs.Com.' != 'grandmothersfoods.com.'
19:06:51 Case mismatch '210.17.9.229' A: 'tCdNS.seed.net.tW.' != 'tcdns.seed.net.tw.'
19:06:55 Case mismatch '210.17.9.230' MX: 'lABOR.goV.tW.' != 'labor.gov.tw.'
19:06:58 Case mismatch '218.13.50.252' MX: '2299.cOM.' != '2299.com.'
19:07:02 Case mismatch '220.229.225.196' A: 'Dns2.TACOneT.com.tw.' != 'dns2.taconet.com.tw.'
19:07:02 Case mismatch '66.249.93.9' A: 'SB.l.GOogLe.cOM.' != 'sb.l.google.com.'
19:07:04 Case mismatch '63.246.15.134' PTR: '232.23.246.63.In-Addr.arpA.' != '232.23.246.63.in-addr.arpa.'
19:07:12 Case mismatch '216.148.215.122' A: 'aPple.aCcUwEaTher.COM.att-IDNS.nET.' != 'apple.accuweather.com.att-idns.net.'
19:07:28 Case mismatch '70.169.180.26' MX: 'PPrI.orG.' != 'ppri.org.'
19:07:30 Case mismatch '216.102.246.43' MX: 'jumo.COm.' != 'jumo.com.'
19:07:37 Case mismatch '220.229.225.196' A: 'NS1.kGex.COM.tW.' != 'ns1.kgex.com.tw.'
19:07:37 Case mismatch '205.216.134.37' MX: 'hOtmiaiL.cOm.' != 'hotmiail.com.'
19:07:43 Case mismatch '62.212.78.199' PTR: '180.87.212.62.In-adDR.arPa.' != '180.87.212.62.in-addr.arpa.'
19:07:45 Case mismatch '205.216.134.37' MX: 'hOtMIAIl.COM.' != 'hotmiail.com.'
19:07:45 Case mismatch '205.216.134.37' AAAA: 'HoTMIAIL.Com.' != 'hotmiail.com.'
19:07:48 Case mismatch '61.31.216.4' MX: 'PcHomE.cOM.Tw.' != 'pchome.com.tw.'
19:07:59 Case mismatch '66.206.3.3' PTR: '81.245.165.66.In-aDdr.ARPa.' != '81.245.165.66.in-addr.arpa.'
19:08:00 Case mismatch '66.249.93.9' A: 'Gmr-SMtP-In.L.googLe.cOM.' != 'gmr-smtp-in.l.google.com.'
19:08:03 Case mismatch '61.31.216.4' A: 'eNS2.neT-cHInEse.coM.TW.' != 'ens2.net-chinese.com.tw.'
19:08:03 Case mismatch '211.79.207.25' A: 'ENS1.NEt-cHinEsE.COm.tw.' != 'ens1.net-chinese.com.tw.'
19:08:03 Case mismatch '211.79.207.25' A: 'ens1.neT-ChinEse.COM.Tw.' != 'ens1.net-chinese.com.tw.'
19:08:03 Case mismatch '61.31.216.4' A: 'eNs1.neT-chiNesE.cOM.Tw.' != 'ens1.net-chinese.com.tw.'
19:08:13 Case mismatch '211.79.207.25' AAAA: '219-84-181-130-AdSl-TAN.DyNamIC.so-NEt.NET.Tw.' != '219-84-181-130-adsl-tan.dynamic.so-net.net.tw.'
19:08:13 Case mismatch '211.79.207.25' A: '219-84-181-130-aDsL-TAn.DyNAMIC.SO-nEt.NEt.Tw.' != '219-84-181-130-adsl-tan.dynamic.so-net.net.tw.'
19:08:17 Case mismatch '210.17.9.229' A: 'Dns.CONTReL.cOm.tW.' != 'dns.contrel.com.tw.'
19:08:19 Case mismatch '216.102.246.43' AAAA: 'hotRmAil.cOm.' != 'hotrmail.com.'
19:08:34 Case mismatch '208.36.171.11' PTR: '20.131.3.8.In-aDdR.ARpA.' != '20.131.3.8.in-addr.arpa.'
19:08:52 Case mismatch '62.212.78.199' A: 'ns5.LEASeWeB.nl.' != 'ns5.leaseweb.nl.'
19:08:52 Case mismatch '83.149.64.123' PTR: '68.46.17.85.IN-ADDR.ArPA.' != '68.46.17.85.in-addr.arpa.'
19:08:56 Case mismatch '210.17.9.229' A: 'nS2.SpArQ.cOm.tW.' != 'ns2.sparq.com.tw.'
19:09:00 Case mismatch '65.61.138.186' A: 'NeWtOn.cX.' != 'newton.cx.'
19:09:28 Case mismatch '210.17.9.229' A: '219-81-225-106.DYnamIC.TFn.nET.Tw.' != '219-81-225-106.dynamic.tfn.net.tw.'
19:09:34 Case mismatch '202.14.81.3' A: 'SMtp1.aPh.Gov.au.' != 'smtp1.aph.gov.au.'
19:09:44 Case mismatch '211.79.207.25' AAAA: 'MAil6.DNs168.COM.tW.' != 'mail6.dns168.com.tw.'

Which means that roughly one in every thousand *client* queries results in a
mismatch. Measured as a percentage of resolver queries, this ratio will be
higher.

I don't think the problems above are insurmountable, the Australian
government, the .tw registry and google will probably be reachable, and able
to address the issue.

But real ISP data does show dns-0x20 is not problem free.

	Bert

---

From: Paul Vixie <[email-masked]>
Date: Thu, 13 Mar 2008 19:07:28 +0000

> you aren't too surprised.

got URL's?

> in the name server, when you can't know the location of middleboxes?

if you are a recursive nameserver, then you'd use 0x20 except when talking
to a "forwarder".  if you are a stub resolver, then you're always talking
to a "forwarder".  so the rule would be, don't use 0x20 when talking to a
forwarder.  no special config logic needed.

---

From: Paul Vixie <[email-masked]>
Date: Thu, 13 Mar 2008 19:17:07 +0000

> But real ISP data does show dns-0x20 is not problem free.

that's wild.  but interesting and useful.

---

From: "W.C.A. Wijngaards" <[email-masked]>
Date: Thu, 13 Mar 2008 21:00:35 +0100

bert hubert wrote:
| On Wed, Mar 12, 2008 at 06:09:47PM +0000, Paul Vixie wrote:
|> so, practically speaking, the fact that i've not run into any
non-copiers in
|> a few million upstream transactions, means that further testing is
illuminative
|> but not decisive.
|
| I think my test data is a bit broader - after 40000 queries out of my 2
| billion or so, I have:
|
| 19:06:19 Case mismatch '66.249.93.9' A: 'maPs.l.gOoglE.COM.' !=
'maps.l.google.com.'

I do not understand, are the authoritative servers for maps.l.google.com
not copying the query section to the answer?
You seem to imply this is working from a stored set of data - how does
that include the algorithm used by the authority server?

If I dig @a.l.google.com maps.l.gOOgle.com then the reply is perfectly
fine for 0x20 use. Also for b to g.l.google.com. Does this mean that
google has fixed (or upgraded) their servers between your stored data
(at 7PM) and now (21PM) ?

| But real ISP data does show dns-0x20 is not problem free.

But where is the problem?

Best regards,
~   Wouter

---

From: Jelte Jansen <[email-masked]>
Date: Thu, 13 Mar 2008 17:10:57 -0400

> (at 7PM) and now (21PM) ?

not always, try a few times:

jelte@xod ~
% repeat 5 dig @a.l.google.com maps.l.gOOgle.com | grep \; | grep maps
; <<>> DiG 9.4.2 <<>> @a.l.google.com maps.l.gOOgle.com
;maps.l.gOOgle.com.		IN	A
; <<>> DiG 9.4.2 <<>> @a.l.google.com maps.l.gOOgle.com
;maps.l.gOOgle.com.		IN	A
; <<>> DiG 9.4.2 <<>> @a.l.google.com maps.l.gOOgle.com
;maps.l.google.com.		IN	A
; <<>> DiG 9.4.2 <<>> @a.l.google.com maps.l.gOOgle.com
;maps.l.google.com.		IN	A
; <<>> DiG 9.4.2 <<>> @a.l.google.com maps.l.gOOgle.com
;maps.l.google.com.		IN	A
jelte@xod ~
%

Jelte

---

From: Brian Dickson <[email-masked]>
Date: Thu, 13 Mar 2008 18:54:50 -0400

Paul Vixie wrote:
> indeed.  here are some other examples from my own server logs, which i hadn't
> been checking in recent days, but which i've beefed up and looked at based on
> bert's report here.
>
> qname mismatch ("5.80.97.67.in-addr.arpa" != "5.80.97.67.In-aDdR.aRPa")
> qname mismatch ("ASPMX.L.GOOGLE.COM" != "aspmx.L.gOOGle.CoM")
>
> most distressing.  this means dns-0x20, and the standards change it
> recommends, are controversial after all, which means it'll either never be a
> standard, or, that it will get turned into a negotiated EDNS option, and that
> it'll take some years for DNSEXT and IETF to process it.  i'm not even sure
> that an FYI could be published in the face of this kind of raw data.
>
>   

I'm interested in seeing more details corresponding to the raw data, if 
that is feasible to obtain.
Can you do some fingerprinting on the servers serving up these answers?

However, I definitely don't want us to collectively give up too soon...

I think the benefits of 0x20 are substantial enough to warrant more 
investigation on the underlying issue(s), e.g. possibly identifying 
whether this is a middle-box issue.

Are there no modifications to 0x20 that can achieve the good results 
when literal copying occurs, without breaking things when it doesn't?

For instance, resolvers getting back answers that don't match, 
indicating a lower trust value on the answer, such as by marking the 
answer as non-authoritative, even if the answer would otherwise have 
been considered authoritative?

Would that modification result in non-breakage, but preferring answers 
that hono(u)r the 0x20 function?

Just wondering...

Brian Dickson

---

From: Paul Vixie <[email-masked]>
Date: Thu, 13 Mar 2008 23:20:21 +0000

> > ... means dns-0x20, and the standards change it recommends, are
> > controversial after all, which means it'll either never be a standard, ...
> 
> I'm interested in seeing more details corresponding to the raw data, if that
> is feasible to obtain.  Can you do some fingerprinting on the servers
> serving up these answers?

i don't think so.  some are behind load balancers, and so, do not always
answer the wrong way.  i suppose that with frequency analysis we could try
to guess which one that answers a certain way also fingerprints a certain
way.

> However, I definitely don't want us to collectively give up too soon...

me neither.  i think this is going to be a tough luck scenario, with or
without IETF standards support for "must always copy".  some of us are going
to deploy 0x20 and let the pain fall where it may.  now that i know it's a
load balancing issue i may decide to repeat failed queries once or twice to
see if i get a better result.  this will look like a ddos to the authorities,
especially if a lot of people do it.

> investigation on the underlying issue(s), e.g. possibly identifying whether
> this is a middle-box issue.

agreed.

> Are there no modifications to 0x20 that can achieve the good results when
> literal copying occurs, without breaking things when it doesn't?

no.  if you have modality, then the modality becomes the target.

> For instance, resolvers getting back answers that don't match, indicating a
> lower trust value on the answer, such as by marking the answer as
> non-authoritative, even if the answer would otherwise have been considered
> authoritative?

if someone is able to get you to cache an A RR for www.microsoft.com or maybe
asia9.akadns.net and you follow it when chasing delegations or you hand it out
when asked a question about it, then you're screwed.  credibility levels only
matter when deciding whether to replace something in the cache with something
you've been offered.  they don't help when you have nothing to compare against.

> Would that modification result in non-breakage, but preferring answers that
> hono(u)r the 0x20 function?
> 
> Just wondering...

i think you're right that it's worth studying the servers who downcase or 
otherwise don't perfectly copy the question section.  i also think that a lot
of us are going to implement dns-0x20 even without standards support, and that
the natural way to be sure that you've hit a bad load balancer is to map the
response to a FORMERR and just try other servers.  (which is what i was doing,
which is why i didn't notice that this was a problem until i saw bert's
results.)

---

From: Josh Littlefield <[email-masked]>
Date: Thu, 13 Mar 2008 19:28:01 -0400

Michael Graff wrote:
> EDNS0 echo option for the win.
>
> Which is a per query "server please echo these bits" option.

If we're going to need EDNS to ask for echoing so that we can support 
0x20, or for anything else related to this, why not just use EDNS to 
carry an extended transaction ID (or cookie) instead?  I think the 
beauty of 0x20 was that it pretty much already worked with no 
negotiation.  Once you need negotiation, you don't need this hack (a 
term I use with the greatest affection).

-josh

>
> Until dnssec comes out of course.
>
> --Michael
>
-- 
=====================================================================
Josh Littlefield                                  Cisco Systems, Inc.
[email-masked]                             1414 Massachusetts Avenue
tel: 978-936-1379  fax: 978-936-2226       Boxborough, MA  01719-2205

---

From: Paul Vixie <[email-masked]>
Date: Thu, 13 Mar 2008 23:32:18 +0000

> Until dnssec comes out of course.

what makes anybody think that the load balancers are going to implement
this, such that initiator-side state about the responder's cookie will
be useful for verifying future transactions against the same responder
(where a responder identity is being naively mapped to an ip address?)
clearly the time domain of responder identity is exactly one packet.

what makes anybody think that this echo option could be uptaken faster
than dnssec would be?  the advantage to dns-0x20 is that it required
only one party, the initiator, to upgrade code in order to enable the
new feature.  and that's assuming that an attacker can't use truncation
as a reason why they didn't include a matching OPT RR and cookie, thus
forcing the initiator to assume/hopefor the best while getting reamed.

---

From: Brian Dickson <[email-masked]>
Date: Thu, 13 Mar 2008 19:37:41 -0400

> to guess which one that answers a certain way also fingerprints a certain

What if your fingerprint request was 0x20 twiddled?
You should see immediate correlation between identity and non-literal 
copying. (Apologies to SCO-bashers. ;-))

> you've been offered.  they don't help when you have nothing to compare against.

I'm thinking more along the lines of, not only return the non-AA result 
to the client, but to also *not* cache
the response (not even the authority section).

It has the result of un-amplifying the injection of bad data, by not 
caching it. Thus, a resolver receiving
injected data would only ever give out a single bad answer.

It also results in a strong bias towards "good" answers if multiple 
exposed NS instances differ in their
0x20 status, allowing caching of "good" NS instances preferentially for 
subsequent RR lookups.
(This, in the case where the results come from non-bad-guy sources, that 
differ in 0x20 results.)

Not caching non-0x20 answers makes bad guys have to spend more 
effort/energy towards 0x20 resolvers
than they would towards non 0x20 resolvers. So, resolver operators would 
have Darwinian pressure to
deploy 0x20, at least, since they would both benefit from better quality 
answers and mostly being protected
against bad answers, as well as from being less likely to be potential 
targets for such injection activity.
Bad guys use Occam's Razor as well.

You don't have to out-run the bear, if you can out-run your friends. :-)

> which is why i didn't notice that this was a problem until i saw bert's

Out of curiosity - have you and Bert looked at the zones you're seeing 
non-0x20-compatible answers,
to see if any such zones *always* return the bad answers?

I'd be curious to know if the FORMERR technique is known to be good 
(eventually works) or is known
to fail for some (very small percentage of) zones... and if so, what 
ones have been found and what their
fingerprints show.

Brian

---

From: Michael Graff <[email-masked]>
Date: Thu, 13 Mar 2008 19:44:18 -0400

I didn't expect negotiation to occur. Honestly with a seemingly small  
number of auth servers doing the bad thing finding out what those are  
would be good. Fixing hopefully one implementation vs changing every  
server out there is good.

--Michael

On Mar 13, 2008, at 19:28, Josh Littlefield <[email-masked]> wrote:

> If we're going to need EDNS to ask for echoing so that we can  
> support 0x20, or for anything else related to this, why not just use  
> EDNS to carry an extended transaction ID (or cookie) instead?  I  
> think the beauty of 0x20 was that it pretty much already worked with  
> no negotiation.  Once you need negotiation, you don't need this hack  
> (a term I use with the greatest affection).
>
> -josh
>
>>

---

From: Paul Vixie <[email-masked]>
Date: Fri, 14 Mar 2008 00:17:53 +0000

> >> that is feasible to obtain.  Can you do some fingerprinting on the
> >> servers serving up these answers?
> >
> What if your fingerprint request was 0x20 twiddled?  You should see
> immediate correlation between identity and non-literal copying. (Apologies
> to SCO-bashers. ;-))

perhaps roy arends of fpdns fame will work up a patch for this use.

> > if someone is able to get you to cache an A RR for www.microsoft.com or
> > maybe asia9.akadns.net and you follow it when chasing delegations or you
> > hand it out when asked a question about it, then you're screwed.
> > credibility levels only matter when deciding whether to replace something
> > in the cache with something you've been offered.  they don't help when you
> > have nothing to compare against.
> 
> I'm thinking more along the lines of, not only return the non-AA result to
> the client, but to also *not* cache the response (not even the authority
> section).

then if your client is a recursive server using you as a forwarder, they are
poisoned.  if they are a web browser who caches their dns results, they are
poisoned.  (consider a www.paypal.com IN A infection in that light.)

> It has the result of un-amplifying the injection of bad data, by not caching
> it. Thus, a resolver receiving injected data would only ever give out a
> single bad answer.

see above.  just because you don't cache it doesn't mean it won't be cached.
any loophole like this becomes the new target of new attacks.  making it rare
or difficult doesn't help.

> > otherwise don't perfectly copy the question section.  i also think that a
> > lot of us are going to implement dns-0x20 even without standards support,
> > and that the natural way to be sure that you've hit a bad load balancer is
> > to map the response to a FORMERR and just try other servers.  (which is
> > what i was doing, which is why i didn't notice that this was a problem
> > until i saw bert's results.)
> 
> non-0x20-compatible answers, to see if any such zones *always* return the
> bad answers?

at least in the case of google, it's known to be a pulsar.  bert and i both
posted lists of domains, so any of them can be checked for this behaviour.

> (eventually works) or is known to fail for some (very small percentage of)
> zones... and if so, what ones have been found and what their fingerprints
> show.

that's a good question.  i'll instrument that.  somebody get with roy arends
on the fpdns patch?

---

From: Robert Elz <[email-masked]>
Date: Fri, 14 Mar 2008 07:29:37 +0700

Date:        Thu, 13 Mar 2008 21:18:50 +0000
    From:        Paul Vixie <[email-masked]>
    Message-ID:  <[email-masked]>

  | i apologize to all for the wild goose chase.

Don't, that's all useful, and I still believe that the planned change to
the spec to require the question section in the answer to be identical to
the question section in the query would be a good thing to do.

Servers shouldn't be messing with the case of the ascii letters in the
query any more than resolvers should, everyone should just be passing through
what they're handed.

It would also be interesting to find out just why the servers are behaving
as they seem to be - clearly a server could be doing something like
down-casing all incoming queries to make matching easier, but that would
affect all queries, not just some of them.

I'd be kind of tempted to guess that what might be happening is the
server sending a cached reply (I just answered that question, here is
the reply again) - with just the first 4 bytes of the DNS header updated
based upon the new query.

The "multiple servers at the same address behaving differently" is certainly
a plausible guess for google, or hotmail, but it's kind of hard to believe
that for some of the other reported cases (eg: I really don't believe that
ns1.aph.gov.au (202.14.81.3) is hiding a whole bunch of differing servers.)

kre

---

From: Francis Dupont <[email-masked]>
Date: Fri, 14 Mar 2008 03:17:52 +0100

In your previous mail you wrote:

   
   
=> it is useful with DNSSEC too because it limits DoS from outside
the path attackers. As DNSSEC can imply some expensive crypto ops
it could become a good idea to use this (EDNS0 cookie) even with DNSSEC.

Thanks

[email-masked]

PS: please note a cookie can be stateless, i.e., in place of keeping it
the sender can recompute it and check if it gets the same value.

---

From: Brian Dickson <[email-masked]>
Date: Fri, 14 Mar 2008 00:39:20 -0400

> perhaps roy arends of fpdns fame will work up a patch for this use.
I checked; doing simple 'dig @${server} ch txt HoStNaMe.bind' (or 
VeRsIoN.bind) does a quick and dirty test for both the 0x20 sense, and 
what the box claims to be.

YMMV.

Brian

---

From: Paul Vixie <[email-masked]>
Date: Fri, 14 Mar 2008 04:50:25 +0000

> Don't, that's all useful, and I still believe that the planned change to the
> spec to require the question section in the answer to be identical to the
> question section in the query would be a good thing to do.
> 
> Servers shouldn't be messing with the case of the ascii letters in the query
> any more than resolvers should, everyone should just be passing through what
> they're handed.

i appreciate your supportive words here, but the technical truth of the matter
is that responders who downcase or otherwise muck with the 0x20 bits of the
ASCII letters of question names while copying them from request to response
are not, currently or historically, broken.  they don't hurt interoperability,
they only hurt expansion.  the rule they break is postel's on being
conservative and liberal at the right time.

note, i am perfectly willing to follow ed lewis' advice from a few days ago,
and split dns-0x20 into two drafts, one for the standards track that just
clarifies the "must always copy" behaviour, and one for the FYI track that
talks about randomizing 0x20 bits in a requestor (and comparing them in the
responses).  if the WG supports the idea of invalidating these non-copying
nameservers, then we can still do it.

i'm feeling some hopelessness simply because i've been through a couple of
ietf protocol wars now, and several times now my positions have been overrun
by stormtroops of the lords of entropy.  calling something a clarification
when it will break something that wasn't broken before, is dangerous work.

> affect all queries, not just some of them.

i think we're likely to find middleboxes in almost every case, and hardly
ever servers.  a packet-flossing firewall box might strip out the 0x20 bits
of udp/53 as it passes through because its designer thinks it'll otherwise
be used as a covert channel by bad guys.  (whereas we want it for good guys.)

> I'd be kind of tempted to guess that what might be happening is the server
> sending a cached reply (I just answered that question, here is the reply
> again) - with just the first 4 bytes of the DNS header updated based upon
> the new query.

honestly, that's what i expected NSD to do, and i was surprised and ecstatic
when i saw that they interpreted RFC 1035 in the same way as the rest of us.
and so, if someone somewhere is keeping copies of past responses, in the way
you say, then it's an implementation whose innards have never been described
or bragged about.

> ns1.aph.gov.au (202.14.81.3) is hiding a whole bunch of differing servers.)

i know what you mean.  now that i'm logging the stuff properly, i can hand
off data to fpdns, if roy arends agrees to patch it so that it uses dns-0x20
and can thus simultaneously fingerprint the implementation and test for "must
always copy" within a single transaction (thus avoiding load balancers.)

---

From: Paul Vixie <[email-masked]>
Date: Fri, 14 Mar 2008 04:52:56 +0000

> VeRsIoN.bind) does a quick and dirty test for both the 0x20 sense, and what
> the box claims to be.

i wouldn't treat the results as indicative, since the answer never comes
from cache in that case.  (and not all servers implement the .BIND tld.)

---

From: Paul Vixie <[email-masked]>
Date: Fri, 14 Mar 2008 04:59:05 +0000

> Then, what about doing a TCP connection, do multiple queries over that TCP
> session, one for the thing you think will come from the cache, the other for
> hostname.bind or server.id or anything else used by fpdns?  (We're talking
> immediate/short term, like now, as opposed to very near term, as in hacking
> fpdns to add in 0x20 support).

all that would provably discover is the percentage of authority servers who
are not reachable by, or do not answer, tcp.  which would be interesting but
not instructive to this purpose.

---

From: Brian Dickson <[email-masked]>
Date: Fri, 14 Mar 2008 00:56:59 -0400

> from cache in that case.  (and not all servers implement the .BIND tld.)

Then, what about doing a TCP connection, do multiple queries over that 
TCP session, one for the thing you think will come from the cache, the 
other for hostname.bind or server.id or anything else used by fpdns?
(We're talking immediate/short term, like now, as opposed to very near 
term, as in hacking fpdns to add in 0x20 support).

Brian

---

From: Florian Weimer <[email-masked]>
Date: Fri, 14 Mar 2008 09:32:55 +0100

* Paul Vixie:

>> People have begun putting out press statements opposing 0x20.
>
> got URL's?

German only, sorry: <http://www.heise.de/newsticker/meldung/104988>

Perhaps Peter can provide an authoritative translation of his
comments?

> forwarder.  no special config logic needed.

I feared that there are middleboxes in front of authoritative servers.
There are many places which require mediation of *any* packet by some
sort of IDS/IPS box, no matter what the performance impact is.

---

From: Michael Graff <[email-masked]>
Date: Fri, 14 Mar 2008 08:37:45 -0400

--Michael

> sort of IDS/IPS box, no matter what the performance impact is.

And of course they make it difficult if not impossible for fpdns to  
guess what is really there. Fpdns results should be taken with a few  
pounds of salt.

---

From: Francis Dupont <[email-masked]>
Date: Fri, 14 Mar 2008 14:01:04 +0100

=> oops, I read this as the EDNS0 cookie idea. Of course if
we have to define a new EDNS0 option the cookie idea is the
right one (here cookie is the simple transaction ID extension).

Thanks

---

From: Paul Vixie <[email-masked]>
Date: Fri, 14 Mar 2008 15:22:08 +0000

> German only, sorry: <http://www.heise.de/newsticker/meldung/104988>

that article is just a summary of these discussions, and is not critical in
an editorial sense, more in a reporting sense.  (because discussions here
have included some critical comments, and the article describes these.)

> sort of IDS/IPS box, no matter what the performance impact is.

in those cases, the middleboxes will have to be removed or reprogrammed.  we
cannot make ourselves hostages to the bad decisions of a few ignorant and
misguided vendors.

---

From: bert hubert <[email-masked]>
Date: Fri, 14 Mar 2008 20:58:15 +0100

> nameservers, then we can still do it.

One thing we could ponder is to modify forgery-resilience to state (or
'clarify') that authoritative nameservers MUST do a bitwise copy of the
question field, in order to facilitate possible future 0x20-like
randomisation efforts.

But this all depends on the WG reaction - if this is controversial, and
forgery-resilience becomes controversial in turn, I (modestly) think
the ensuing delay of this draft would be a loss.

0x20 can then follow at leasure, as a separate effort - we've written down
the requirement in that case.
	
Thoughts?

	Bert

---

From: Michael Graff <[email-masked]>
Date: Thu, 13 Mar 2008 17:30:38 -0500

[ Moderators note: Post was moderated, either because it was posted by
   a non-subscriber, or because it was over 20K.  
   With the massive amount of spam, it is easy to miss and therefore 
   delete relevant posts by non-subscribers. 
   Please fix your subscription addresses. ]

> it could become a good idea to use this (EDNS0 cookie) even with DNSSEC.

I specifically did not call these 'cookies' to avoid conflicting with the 'dns 
cookie' draft.  :)

I suppose I can call them 'resolver tokens' or something, but really all I am 
looking for here is some bit of data I can send to the auth server and 
(reasonably) expect to get a reply with it included.  The OPT record is 
omitted from dnssec signatures, so it being lost is not going to be 
sufficient to cause us to drop packets on the floor, unless when edns0 
becomes manditory we include this option as manditory as well.

I am not holding my breath.

--Michael
Spam detection software, running on the system "mail.ogud.com", has
identified this incoming email as possible spam.  The original message
has been attached to this so you can view it (if it isn't spam) or label
similar future email.  If you have any questions, see
The administrator of that system for details.

Content preview:  [ Moderators note: Post was moderated, either because it was
   posted by a non-subscriber, or because it was over 20K. With the massive
  amount of spam, it is easy to miss and therefore delete relevant posts by
  non-subscribers. Please fix your subscription addresses. ] [...] 

Content analysis details:   (2.5 points, 4.0 required)

 pts rule name              description
---- ---------------------- --------------------------------------------------
 3.4 HEADER_SPAM            Bulk email fingerprint (header-based) found
 1.3 DATE_IN_PAST_03_06     Date: is 3 to 6 hours before Received: date
-2.3 BAYES_00               BODY: Bayesian spam probability is 0 to 1%
                            [score: 0.0000]
 0.1 RDNS_NONE              Delivered to trusted network by a host with no rDNS

---

From: Michael Graff <[email-masked]>
Date: Thu, 13 Mar 2008 10:34:53 -0500

> that include the algorithm used by the authority server?

It turns out it depends on who behind each l.google.com name server responds:

; <<>> DiG 9.4.1-P1 <<>> @a.l.google.com mAps.L.GoOgLe.CoM
;mAps.L.GoOgLe.CoM.             IN      A
; <<>> DiG 9.4.1-P1 <<>> @b.l.google.com mAps.L.GoOgLe.CoM
;maps.l.google.com.             IN      A
; <<>> DiG 9.4.1-P1 <<>> @c.l.google.com mAps.L.GoOgLe.CoM
;mAps.L.GoOgLe.CoM.             IN      A
; <<>> DiG 9.4.1-P1 <<>> @d.l.google.com mAps.L.GoOgLe.CoM
;mAps.L.GoOgLe.CoM.             IN      A
; <<>> DiG 9.4.1-P1 <<>> @e.l.google.com mAps.L.GoOgLe.CoM
;maps.l.google.com.             IN      A
; <<>> DiG 9.4.1-P1 <<>> @f.l.google.com mAps.L.GoOgLe.CoM
;mAps.L.GoOgLe.CoM.             IN      A
; <<>> DiG 9.4.1-P1 <<>> @g.l.google.com mAps.L.GoOgLe.CoM
;mAps.L.GoOgLe.CoM.             IN      A

(running script again)

; <<>> DiG 9.4.1-P1 <<>> @a.l.google.com mAps.L.GoOgLe.CoM
;mAps.L.GoOgLe.CoM.             IN      A
; <<>> DiG 9.4.1-P1 <<>> @b.l.google.com mAps.L.GoOgLe.CoM
;mAps.L.GoOgLe.CoM.             IN      A
; <<>> DiG 9.4.1-P1 <<>> @c.l.google.com mAps.L.GoOgLe.CoM
;mAps.L.GoOgLe.CoM.             IN      A
; <<>> DiG 9.4.1-P1 <<>> @d.l.google.com mAps.L.GoOgLe.CoM
;mAps.L.GoOgLe.CoM.             IN      A
; <<>> DiG 9.4.1-P1 <<>> @e.l.google.com mAps.L.GoOgLe.CoM
;maps.l.google.com.             IN      A
; <<>> DiG 9.4.1-P1 <<>> @f.l.google.com mAps.L.GoOgLe.CoM
;mAps.L.GoOgLe.CoM.             IN      A
; <<>> DiG 9.4.1-P1 <<>> @g.l.google.com mAps.L.GoOgLe.CoM
;mAps.L.GoOgLe.CoM.             IN      A

(so far, "e" varies)

; <<>> DiG 9.4.1-P1 <<>> @a.l.google.com mAps.L.GoOgLe.CoM
;mAps.L.GoOgLe.CoM.             IN      A
; <<>> DiG 9.4.1-P1 <<>> @b.l.google.com mAps.L.GoOgLe.CoM
;mAps.L.GoOgLe.CoM.             IN      A
; <<>> DiG 9.4.1-P1 <<>> @c.l.google.com mAps.L.GoOgLe.CoM
;maps.l.google.com.             IN      A
; <<>> DiG 9.4.1-P1 <<>> @d.l.google.com mAps.L.GoOgLe.CoM
;mAps.L.GoOgLe.CoM.             IN      A
; <<>> DiG 9.4.1-P1 <<>> @e.l.google.com mAps.L.GoOgLe.CoM
;mAps.L.GoOgLe.CoM.             IN      A
; <<>> DiG 9.4.1-P1 <<>> @f.l.google.com mAps.L.GoOgLe.CoM
;maps.l.google.com.             IN      A
; <<>> DiG 9.4.1-P1 <<>> @g.l.google.com mAps.L.GoOgLe.CoM
;mAps.L.GoOgLe.CoM.             IN      A

(c, e, f)

Running this script enough will eventually show that all of them vary.

I suspect they have multiple name server types sitting behind each of these 
addresses, and one copies, one does not.

Note that no matter what, they do not compress using the query-name:

; <<>> DiG 9.4.1-P1 <<>> @a.l.google.com mAps.L.GoOgLe.CoM
;mAps.L.GoOgLe.CoM.             IN      A
maps.l.google.com.      300     IN      A       72.14.221.147
maps.l.google.com.      300     IN      A       72.14.221.104
maps.l.google.com.      300     IN      A       72.14.221.103
maps.l.google.com.      300     IN      A       72.14.221.99

---

From: Michael Graff <[email-masked]>
Date: Thu, 13 Mar 2008 19:16:53 -0500

> be used as a covert channel by bad guys.  (whereas we want it for good

While I suspect some firewalls will strip things for this reason, I suspect 
the servers that really handle a small number of records and use pre-compiled 
responses are the ones that are doing the unfortunate things we're finding.

I note that MOST servers will use the qname for compression, so if you mangle 
the domain name, you see things like:

qname = FlAmE.OrG
answer = FlAmE.OrG ns dns01.FlAmE.OrG

etc.

In Google's case, when it does copy the question, it still returns all 
lowercase google.com names.  This hints to me that it is using pre-compiled 
responses, with the compression pointers starting at the first name in the 
pre-compiled blob, and perhaps has two iterations/implementations of DNS 
servers behind a balancer framework.

--Michael

---

From: Paul Vixie <[email-masked]>
Date: Fri, 14 Mar 2008 21:11:04 +0000

> > note, i am perfectly willing to follow ed lewis' advice ...
> 

re-reading http://tools.ietf.org/html/draft-ietf-dnsext-forgery-resilience-02
just now, i am struck by the mismatch between the meaning of the words in 4.1
and the name of the section for 4.1.  can you consider renaming this section,
or moving most of the words to some other section?

that aside, i see no updates to RFC 1034 except in section 9.  i suggest that
you change

	o  Question (name and type)

to say

	o  Question (name, class and type)

or ideally to say

	o  Question name (compared case-insensitively)

	o  Question class

	o  Question type

in the latter case you would add the following subsection:

	Additionally, servers must always copy the question section
	from the request to the response, without modifications of
	any kind, including but not limited to changing the ASCII
	upper/lower case status of any character of the question name.

and also the following subsubsection after "Assure that its choices...":

	o  Requestor can use the 0x20 bits of any ASCII letter (A-Z, a-z)
	   in the question name as an additional source of transaction
	   identity, perhaps by randomizing them, as long as such
	   randomization is undone in the response before decompression.

and this, in the same spot:

	o  If a requestor is multihomed or otherwise has the ability to
	   transmit and receive datagrams using more than one IP address,
	   then an IP address can be chosen at random in order to increase
	   an attacker's difficulty in guessing what address to flood.

and this, in the same spot:

	o  If a requestor knows more than one authority server address for
	   a particular zone, then it should choose one randomly in order
	   to increase an attacker's difficulty in guessing a spoofed
	   source address.  If authority server RTT is being measured and
	   used to "sort" addresses in order of "closeness", then, these
	   should be grouped into RTT bands of approximately 100ms, and
	   randomized within these bands.

you can remove this text:

   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.

since it merely restates RFC 1035 and does not update or clarify anything.

you should add this text in that spot:

   If any attribute of the question contained in a response mismatches that
   attribute of the question in the request, then the question is semantically
   invalid, and should be treated the same as if it had been syntactically
   invalid (a so-called "format error").

> forgery-resilience becomes controversial in turn, I (modestly) think the
> ensuing delay of this draft would be a loss.

understood, and i don't blame you.  but i hope the WG yawns, rolls over, says
"OK by me", and allows the above modifications, which will then recommend that
every requestor randomize every randomizable member of the
      <respaddr,reqaddr,reqport,qid,qname,qclass,qtype>
tuple used for matching answers to questions, and require that any server who
downcases or otherwise modifies a qname, stop doing so.

> the requirement in that case.

i'm still hoping to do this in a single RFC that gathers all current knowledge
on this topic.  dns-0x20 would not even need to be published, in any form, if
the above modifications were made.

---

From: bert hubert <[email-masked]>
Date: Sat, 15 Mar 2008 14:27:37 +0100

> or moving most of the words to some other section?

Wow - I'm amazed I nor anybody before you noticed this glaring error.

> 	o  Question name (compared case-insensitively)

Done - kept question class and type on one line though.

> 	upper/lower case status of any character of the question name.

I've put this in, pending reaction from the WG.

> 	   randomization is undone in the response before decompression.

This is one bit too far - we now state that authoritative servers must do
bitwise copy, which is a new requirement (if present in spirit), and
immediately state that it is ok to rely on this behaviour.

> 	   an attacker's difficulty in guessing what address to flood.

Done.

> 	   randomized within these bands.

Isn't this a bit overbearing? I understand the sentiment but it is usually
better not to be too exact in defining implementor behaviour.

> since it merely restates RFC 1035 and does not update or clarify anything.

Are you sure? This is the paragraph that was explicitly inserted to prevent
nameservers from being vulnerable to the birthday attack caused by having
identical questions with differing id's in flight.

The idea being that this wasn't stated anywhere else. But I'm no 1035
scholar.

>    invalid (a so-called "format error").

Are you sure this adds anything?

> the above modifications were made.

My current feeling is that it would be ok for us to clarify that servers
should do a bitwise copy, something that indeed was in the spirit of 1035
already.

So much so in fact that PowerDNS added support for spoofing in the correct
case for answers derived from the whole packet cache in revision '2':

     2        ahu       cached->spoofQuestion(p->qdomain); // for correct case

Which was before 2002-11-27.

However, while we could describe the 0x20 extra randomisation, it is a
bridge too far for me to standardise it as being instantly kosher. 

How about something that indicates that resolvers could do it, but with the
caveat that it can cause problems until all auth servers are in compliance
with the bitwise copy addition?

The alternative is to leave 0x20 as a separate draft for a while, so we can
safely state that the new world order that bitwise copies are mandatory has
been around long enough.

In the meantime, we could approach google, the .tw registry and the few
other holdouts to see what they can do.

Your suggestions I could apply immediately are in
http://adsl-xs4all.ds9a.nl/cgi-bin/resilience.fcgi/changeset/16

Thoughts?

---

From: Paul Vixie <[email-masked]>
Date: Sat, 15 Mar 2008 16:49:29 +0000

> immediately state that it is ok to rely on this behaviour.

either the rfc believes what it says, consistently and throughout, or not.

> better not to be too exact in defining implementor behaviour.

try this:

	o  If a requestor knows more than one authority server address for
	   a particular zone, then it should choose one randomly in order
	   to increase an attacker's difficulty in guessing a spoofed
	   source address.  If authority server RTT is being measured and
	   used to "sort" addresses in order of "closeness", then, some
	   method must be used to preserve randomness in selection, such
	   as RTT banding.

> The idea being that this wasn't stated anywhere else. But I'm no 1035

try this:

   Note that selection of a query ID is part of the transformation of a user
   request into a query (described in RFC 1035 7.1) rather than part of the
   transmission of the query to name servers (described in RFC 1035 7.2) and
   as such, the same query ID must be present on all retransmissions of a
   given query to a given server.  Similar care must be taken to preserve the
   request's source IP address and source UDP port number.  If a server has
   multiple addresses (that is, its NS RR points to multiple A and AAAA RRs)
   then the stability of query ID and requestor UDP port number must be
   preserved across all transmissions and retransmissions to all addresses
   of that server.

   However, if a user request ultimately causes queries to be transmitted to
   multiple name servers (that is, different NS RR values) due to nonresponse
   or errored response from the first name server chosen, then each server
   SHOULD be sent a new query, having its own randomly chosen query ID, UDP
   source port, question name 0x20 values, and potentially its own requestor
   source IP address.
   
that is, if we're going to fix what's wrong with RFC 1035 on this topic, it's
a bigger job than restating implications.

> >    If any attribute of the question contained in a response mismatches
> >    that attribute of the question in the request, then the question is
> >    semantically invalid, and should be treated the same as if it had been
> >    syntactically invalid (a so-called "format error").
> 

yes, because otherwise a requestor would ignore this response outright, such
that it would not choose its next server until its current request times out.
this is a tradeoff between "when under attack, a requestor should become more
aggressive about trying other servers" vs. "when speaking through a middlebox,
a requestor should experience long timeouts and low performance."  i chose the
first alternative because trying other servers yields better security, it
closes and opens more transmission contexts, faster, each with its own random
UDP ports and so on.  note that by not waiting for the first response, an
ttack will result in more lookup failures, and that DNS in general will be
more fragile.

i'm imagining this poor damned non-DNSSEC resolver flinging a query into the
great beyond, and then standing its ground while a whole lot of similar
looking responses storm back at it, which it has to delicately examine, and
each of them can try harder than the last to look like what's desired.  i'm
not liking the odds.

however, in times of high port churn it's easy to imagine that a late response
to an earlier question arrives, not as a blizzard but as a singleton.  so, in
the draft, perhaps these words would be better than the above:

   If any attribute of the question contained in a response mismatches
   that attribute of the question in the request, then the entire response
   is semantically invalid, and if an unreasonably high number (say, a dozen)
   such responses are encountered, then the requestor should behave as though
   a syntactically invalid response (a so-called "format error") had been
   received, which would normally lead to trying the next available server.

> with the bitwise copy addition?

then the RFC should describe the behaviour and set a date.  RFC 1 mentions
dates, so, these documents don't have to be completely timeless.  or, say 
something like "randomizing the 0x20 bits may lead to resolution failures
in the short term, since some responders and middleboxes strip these bits
when copying the question from the request to the response, so, requestors
are advised to be tolerant of mismatches, for example, by retrying three or
four times, with different query ID, UDP port, and 0x20 values, if all of
a zone's name servers seem to be stripping the 0x20 values out of questions."

the goal here is to penalize 0x20-strippers by sending them more traffic,
while making the spoofer's goal harder, since spoofers will have to win a
query-ID and UDP-port (and server-address and client-address) race not once
or twice but "three or four times" before they can successfully poison us.

> http://adsl-xs4all.ds9a.nl/cgi-bin/resilience.fcgi/changeset/16

i really feel that the security level delta between "nothing" and "randomize
some things" is smaller than the delta between "randomize some things" and
"randomize everything".  so, to me, there is no point to a two-RFC solution.

---

From: bert hubert <[email-masked]>
Date: Sat, 15 Mar 2008 18:36:36 +0100

Paul,

I'm splitting my answer in to two keep things clear, which I hope will
prevent WG-fatigue from developing further. First the 0x20 mix-in, I'll
reply separately to your other points.

> "randomize everything".  so, to me, there is no point to a two-RFC solution.

So we are back to 'conjoin forgery resilience with dns-0x20', with the
addition that since discovering that it does break things, we should first
mandate bit-for-bit copying, and set a date at which point everybody is free
to disregard case-variant answers.

Before the cut-off date, we exhort implementations to be lenient and do
repetitive queries to non-case-preserving servers, so as to gather some
extra bits of security, even though they break dns-0x20.

To me the above is bound to be so controversial that I predict it will sink
the forgery resilience draft.

So for me there are two ways we can go from here:

1) We form consensus that the above is non-controversial, and that people
will still form rough consensus on last call if the above dns-0x20 rules are
implemented in the forgery resilience draft

2) We only leave in the bit-for-bit copy 'MUST' in there (which doesn't
hurt), and go for last call on forgery resilience.

So, dear workgroup, please ponder the (non-)controversiality of dns-0x20 as
outlined above.

	Bert

---

From: Paul Vixie <[email-masked]>
Date: Sat, 15 Mar 2008 17:44:01 +0000

> reply separately to your other points.

splitting it into two has the unfortunate side effect of removing my "run
the race more than once" suggestion, which allows servers to bit-strip 0x20
at the cost of having to answer every question multiple times.  that may be

---

From: bert hubert <[email-masked]>
Date: Sat, 15 Mar 2008 18:47:17 +0100

> the difference needed to get a positive answer to your question here:

No, it was in there:

I just summarised it rather briefly. 

	Bert

---

From: Paul Vixie <[email-masked]>
Date: Sat, 15 Mar 2008 18:17:20 +0000

> I just summarised it rather briefly. 

too briefly, then.  what i wrote was that one has to try all of a zone's
servers before retrying any, if the basis is 0x20 failure, and then a given
server has to solve the QID and UDP Port puzzle at least three or four times
before we'll believe that it's a 0x20 bit stripper.

---

From: Danny Mayer <[email-masked]>
Date: Sat, 15 Mar 2008 21:37:28 -0400

> tick, and some can't come within 10ms.  "horseshows, hand grenades, and time."

This is why NTP does interpolation and adjust the frequency of the clock 
the way it does. In the end the accuracy that NTP provides takes the 
limitations of the CPU's clock into account and keeps it accurate.

Danny

---

From: Paul Vixie <[email-masked]>
Date: Sun, 16 Mar 2008 04:24:41 +0000

> limitations of the CPU's clock into account and keeps it accurate.

and indeed, ntp does a fine job at maintaining accuracy for an absolute
clock.  but it won't do anything to improve the accuracy of relative
timers and time-differences if the hardware and kernel are sloppy.

---

From: Paul Vixie <[email-masked]>
Date: Tue, 18 Mar 2008 02:23:43 +0000

> servers choices regarding compression.

because this isn't relevant to the topic of dns-0x20, i left it completely out.