- 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?