> Ok, I've implemented dns-0x20 in the powerdns recursor as well, but I'm
> seeing some side effects I worry about.
> ...
> 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


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
> to be case insensitive?


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
> test for those.


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

--
to unsubscribe send a message to namedroppers-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: