In message <9C0A9641-1FDC-4456-95DC-C12536CDF22C(_at_)cisco(_dot_)com>,
=?utf-8?Q?=F0=9F=9
4=93Dan_Wing?= writes:
On Dec 4, 2014, at 9:00 PM, Mark Andrews <marka(_at_)isc(_dot_)org> wrote:
In message <74DF5B53-055C-4235-A8FA-E8B38E007F45(_at_)nominum(_dot_)com>,
Ted
Lemon writes
:
On Dec 4, 2014, at 10:02 PM, George Michaelson
<ggm(_at_)algebras(_dot_)org>
wrote:
Hang on.. the deployment of DNSSEC backed applications is a bit iffy
if
we depend on deployment of DNS based tricks to cover for V4/V6
interoperation surely?
DNS64 can be done by the client, in which case DNSSEC validation can be
performed _before_ translating the IPv4 address from the A record into
an
IPv6 address in the NAT64 prefix.
Which requires every DNSSEC aware client to also be DNS64 aware.
I though we were trying to remove NAT kludges requires that they
be kept forever.
The BEHAVE working group was unable to find any other approach to get
DNSSEC and NAT64 to work together. If you have a proposal, please share.
Which should have been a reason to reject DNS64 and NAT64 as anything
other than a interim measure.
RFC 6147 also get DNSSEC signalling completely wrong. There is NO
combination of bits that indicates validation will / will not occur.
Yes, you reported that as an errata on 2012-05-30. It was rejected on
basis of "Changes that are clearly modifications to the intended
consensus, or
involve large textual changes, should be Rejected.",
http://www.rfc-editor.org/errata_search.php?rfc=6147.
Which doesn't mean I am wrong or that RFC 6147 is correct. Just
that you want to put your fingers in your ears and go "na na na I
can't hear you".
If something is wrong it should be acknowledged regardless of the
size of the error. This is a error in fact. This is not a matter
of opinion.
A client can be validating with both CD=0 and CD=1 queries.
In fact it is better for a recursive validating client to use CD=0
queries than CD=1 queries in the presence of a attack as the recursive
server then filters out the forged responses it is getting rather
than passing them through to the validating stub client. It only
falls back to CD=1 on SERVFAIL in case that SERVFAIL was a result
of a bad trust anchor or a bad clock in the resursive server.
For completeness one can also start with CD=1 and retry with CD=0
on validation failure. This should cause the recursive server to
issue new queries and validate them before passing them onto the
client.
There is no perfect CD state for a recursive validating client to
send and I've state as much many times.
Always send CD=1 is wrong. When you have a daisy chain of servers
the ultimate client looses control of when validation is or isn't
done in the intermeditate servers. Unfortunately dnsext had a chair
that refused to reopen discussion on this issue. Yes, consenus
gets things wrong.
The CD state of a outbound query should match the state of the
inbound query that triggered it.
All recursive servers need to validate.
A client can on validate if it sets DO=1. DO=1 does not mean that
a client will be validating.
Additionally the discover mechanism for the DNS64 parameters is to
say the least baroque. It would have been much simpler to add a
EDNS option so the nameserver could actually return them or the
addresses it would have otherwise returned if DO=1 is set. These
could be cached along with the NODATA response by intermediate
nameservers.
That does appear a nice approach for a DNS64-aware client to learn the
NAT64 prefix.
-d
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: marka(_at_)isc(_dot_)org