In message <9C0A9641-1FDC-4456-95DC-C12536CDF22C@xxxxxxxxx>, =?utf-8?Q?=F0=9F=9 4=93Dan_Wing?= writes: > On Dec 4, 2014, at 9:00 PM, Mark Andrews <marka@xxxxxxx> wrote: > > > In message <74DF5B53-055C-4235-A8FA-E8B38E007F45@xxxxxxxxxxx>, Ted > Lemon writes > > : > >> On Dec 4, 2014, at 10:02 PM, George Michaelson <ggm@xxxxxxxxxxxx> > 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@xxxxxxx