Opened 3 years ago

Closed 3 years ago

Last modified 5 weeks ago

#768 closed defect (fixed)

dns64 is breaking dnssec.

Reported by: mellon@… Owned by: bzeeb+ietf@…
Priority: tbd Milestone: ietf-090
Component: network Keywords:
Cc: My Current Location:
My MAC Address: My OS:

Description (last modified by Bill Fenner)

The dns64 resolver that is set up for ietf-nat64 appears to be doing synthesis even if the DO and CD flags are set in the query:

 saucy% dig +sigchase +edns=0 +dnssec +cdflag aaaa home.fugue.com.
 ./trusted-key.key:2: TTL set to prior TTL (5)
 ;; RRset to chase:
 home.fugue.com.         5       IN      AAAA    64:ff9b::ae3e:93b6

 Launch a query to find a RRset of type RRSIG for zone: home.fugue.com.

 ;; RRSIG is missing for continue validation: FAILED

This breaks any host that does NAT64 Prefix Discovery so as to do DNS64 synthesis with secure local DNSSEC validation. Is there some reason why this is enabled, or am I misunderstanding something? This would be enabled using the break-dnssec flag in the named.conf file, so if it is deliberately enabled, it should be visible; otherwise it could just be a bug.

Change history (22)

comment:1 Changed 3 years ago by llynch@…

Component: incomingnetwork
Owner: changed from llynch@… to Bill Fenner
Status: newassigned
Type: requestdefect

comment:2 Changed 3 years ago by mellon@…

BTW, this is not causing me any headaches at the moment--it's just something I noticed when I was checking what Simon said about DNS64 prefix discovery. So if you need sleep or have something better to do, don't waste your time worrying about this report.

Last edited 3 years ago by Bill Fenner (previous) (diff)

comment:3 Changed 3 years ago by Bill Fenner

Being basically ignorant of anything other than where the config file is stored, I observe:

options {
...
        dnssec-enable yes;
        dnssec-validation yes;
        dnssec-lookaside auto; 
...
        dns64 64:ff9b::/96 { 
                clients { 2001:67c:1231:998::/64; };
                # can't do otherwise until the clients can do the translation themsevles, right?
                break-dnssec yes;
        };
};

I'm up for a deeper discussion of the issues - which is the bigger breakage?

comment:4 Changed 3 years ago by anonymous

Obviously the real bug here is no AAAA records for the remote end, right? ;-) /SCNR

comment:5 Changed 3 years ago by Bill Fenner

Description: modified (diff)

comment:6 Changed 3 years ago by anonymous

We are talking http://tools.ietf.org/html/rfc6147#section-5.5 item 3 here.

To my best knowledge we currently cannot dynamically provide the translator prefix to the clients to do the translation themselves.
So either we cannot reach DNSsec secured destinations or we break DNSsec.

Welcome to the wonderful worlds of IETF standards not aligning and the believe in running code.

comment:7 Changed 3 years ago by mellon@…

On Jul 21, 2014, at 6:23 PM, IETF Meeting/NOC <tickets@meeting.ietf.org> wrote:
> Obviously the real bug here is no AAAA records for the remote end, right?

Obviously...

On the plus side, in order to make sure that the resolver wasn't just being insanely clever, I had to set up DNSSEC on my home domain.  Sadly, most of the A records I look up are not signed.

comment:8 Changed 3 years ago by mellon@…

On Jul 21, 2014, at 6:29 PM, IETF Meeting/NOC <tickets@meeting.ietf.org> wrote:
> To my best knowledge we currently cannot dynamically provide the
> translator prefix to the clients to do the translation themselves.
> So either we cannot reach DNSsec secured destinations or we break DNSsec.

Actually, all you have to do to provide your prefix is to do synthesis when the DO and CD flags aren't both set.   The WKN "ipv4only.arpa." returns an A record and no AAAA record, so you can assume that if you look it up and get an AAAA record, the leftmost 64 bits of the IPv6 address are the NAT64 prefix.   So the DNS64 operator doesn't need to do anything at all to make this work.

comment:9 Changed 3 years ago by anonymous

The discussion how to distribute the dns64 prefix is documented in http://tools.ietf.org/html/rfc7051#page-14 ; I am not aware of any solution.

Using "WKN"s like Android does ipv4.google.com and ipv6.google.com lookups and/or connects for testing address family reach abilities to my best knowledge is simply broken.

The question is: do we want to be able to connect to IPv4 only hosts on the NAT64 network if they are signed and people are asking with both DO/CD set or do we want them do not get to that destination? The RFC says the latter.

comment:10 Changed 3 years ago by bzeeb+ietf@…

trac kept logging me out; just so that people know who "anonymous" was, who was replying.

comment:11 Changed 3 years ago by mellon@…

On Jul 21, 2014, at 6:39 PM, IETF Meeting/NOC <tickets@meeting.ietf.org> wrote:
> The discussion how to distribute the dns64 prefix is documented in
> http://tools.ietf.org/html/rfc7051#page-14  ; I am not aware of any
> solution.

The solution is described on page 14, and also in RFC 7050.   And it works quite well.

> Using "WKN"s like Android does ipv4.google.com and ipv6.google.com lookups
> and/or connects for testing address family reach abilities to my best
> knowledge is simply broken.

ipv4only.arpa. is a WKN that is documented in RFC 7050 and that is present in the .arpa. zone now.   If you dig for it on a non-NAT64 network, you get no answer on AAAA.   On ietf-nat64, you get an answer, which contains the correct NAT64 prefix.   So it's not quite the same.   This is secure because the zone and the record are signed, so if they don't validate you don't trust the answer.

> The question is:  do we want to be able to connect to IPv4 only hosts on
> the NAT64 network if they are signed and people are asking with both DO/CD
> set or do we want them do not get to that destination?   The RFC says the
> latter.

That's not what I'm talking about.   I'm talking about connecting IPv6-capable hosts with local DNSSEC validation and DNS64 prefix discovery: the precise use case Simon discussed on the mailing list.

comment:12 Changed 3 years ago by anonymous

It's disabled.

comment:13 Changed 3 years ago by anonymous

So what local software actually does dnssec validation itself and dns64 discovery? Do you have examples? I am just curious.

comment:14 Changed 3 years ago by mellon@…

On Jul 21, 2014, at 6:58 PM, IETF Meeting/NOC <tickets@meeting.ietf.org> wrote:
> It's disabled.

Then the version of BIND you are using is broken.   Do you know what version you are using?   Maybe I can talk to the ISC folks and see what they know.

I don't know if anybody has an off-the-shelf implementation of DNSSEC+DNS64, but the reason I raised this issue is that I'd like to see us get to the point where if someone had one, it would work.   I don't see any upside to running a DNS64 resolver that does the wrong thing when the DO and CD flags are set.

comment:15 Changed 3 years ago by anonymous

I should have been more precise. It was on, as fender reported, it is *now* disabled; as in I commented out the break-dnssec yes; line.

        dns64 64:ff9b::/96 {
                clients { 2001:67c:1231:998::/64; };
                # can't do otherwise until the clients can do the translation themsevles, right?
                #break-dnssec yes;
                # disabled per ticket 768
        };

comment:16 Changed 3 years ago by bzeeb+ietf@…

If you still see broken behaviour I can upgrade bind9.9 to bind9.10 and see if that helps?

comment:17 Changed 3 years ago by mellon@…

On Jul 22, 2014, at 4:55 AM, IETF Meeting/NOC <tickets@meeting.ietf.org> wrote:
> I should have been more precise.  It was on, as fender reported, it is
> *now* disabled; as in I commented out the break-dnssec yes; line.

HAR!   Okay, thanks!   I took you to be saying the opposite. :)

comment:18 Changed 3 years ago by mellon@…

On Jul 22, 2014, at 4:56 AM, IETF Meeting/NOC <tickets@meeting.ietf.org> wrote:
> If you still see broken behaviour I can upgrade bind9.9 to bind9.10 and
> see if that helps?

I will test it again when I get back to the hotel.

comment:19 Changed 3 years ago by Bill Fenner

Owner: changed from Bill Fenner to bzeeb+ietf@…

comment:20 Changed 3 years ago by mellon@…

On Jul 22, 2014, at 6:44 AM, IETF Meeting/NOC <tickets@meeting.ietf.org> wrote:
> I will test it again when I get back to the hotel.

It is doing the right thing now.   Thanks for fixing this!

comment:21 Changed 3 years ago by Bill Fenner

Resolution: fixed
Status: assignedclosed

comment:22 Changed 5 weeks ago by Rick Alfvin

Milestone: ietf-90ietf-090

Milestone renamed

Note: See TracTickets for help on using tickets.