NAT64 and DNSSec

[marcelo bagnulo <marcelo@it.uc3m.es>]

Hi,

I am trying to define the rerquirements on new generation of NAT64 boxes 
w.r.t. DNSsec according to the disucssion we had in Philadelphia.

It seems clear that one strong candidate solution will use synthetic DNS 
records. It seems clear that these records are hardly compatible with 
DNSSec. Let's try to figure out what level of compatibility is 
reasonable to require.

- Types of communications:

We have v4 initiated communications and v6 intiiated communications.
In v6 initiated communications, the DNS reply will be recieved by a 
v6-only node and will contain a AAAA record. This will be a synthetic 
AAAA record containe a v6 address. It is possible that the v6 address is 
some for of v4 mapped addresses, so it would be possible to validate the 
synthtic AAAA record from the original A record, (if the v6 prefix is 
well known)
In v4 initiated communications, we are not so lucky, cause the reply 
will be a synthtic A record, contianing a v4 address, that is likely to 
be the one of the translator, and has no relation with the original v6 
address.

- Levels of support.

- Level 0: we don't anything special in the synthetic DNS reply. the 
translator just drops the DNSSec information and creates the synthethic 
DNS RR. the host recives it and doesn't know it is synthetic DNS RR. If 
it tries to validate it, it won't be able to do that, cause there is no 
DNSSec information. this may result in additional difficulties in DNSSec 
deployments, since if the usage of NAT64 boxes becomes pervasive, then 
unsigned DNS replies will become common and hosts need to accept them, 
since this is how the NAT64 boxes generate them.

- Level 1: We could add a tag on the DNS reply, EDNS0, marking these as 
synthetic RR, so the receiving host knows these are fake but that it 
should accept them anyway. this doesn't really solve the problem 
described above, but at least DNS semantics are preserved, since 
synthtic RR are explicitly marked and receivers know about that. 
(Questio for DNS guys, do normal hosts accept DNS replies contianing 
EDNS0 tags that they don't know? or they drop these replies?)

- Level 2: another option is to include both the EDNS0 tag and also the 
original information of the original RR, including the original address 
and the signature information. this would allow to verify the original 
packet, but then we need to verify the binding between the original 
address and the one actually included int eh synthetic DNS RR. In the 
case of v6 initiated communications, this is possible cause the v6 
address included in the synthtic record is related to the original v4 
address. In the v4 initiated communication, i am not sure how useful 
would that be.

- Level 3: extend DNSsec verification to soemwhere near the reciver. 
This would mean that it is not the NAT64 that generates the synthtic DNS 
RR but some other box, closer to the receiver does that, prior DNSSec 
verification. the problem with this approach is how the other box gets 
the address information that should be included int he synthetic RR. As 
above, in the v6 initiated case it may be possible cause the v6 address 
can be constructed from the v4 address, but in the v4 initated case, we 
need some for of communication with the NAT box, which is hardly a good 
idea.

- Level 4: generate the synthetic RR locally in the receiving node. this 
would be perfect, but is simply incopatible with the requirement of not 
modifying v4 nodes.

so, my questions are:
- are there any other levels of support/options?
- If not, what level should we require?

Regards, marcelo