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