Turning domains into IPv6-only with NAT64

[kasperd]

I am considering a setup with NAT64, in which I would like to force clients to use IPv6 by making all domains be IPv6 only.

I installed bind9 and downloaded the BIND 9 Administrator Reference Manual. Finding instructions in the manual on how to setup DNS64 was easy. I managed to get DNS64 working after just a few minutes.

But in that configuration clients can still lookup A records. I'd like to configure the server such that for any domain, which has an A record, it will reply with no record.

First I tried deny-answer-addresses { 0.0.0.0/0; }. That did stop it from responding with A records. But instead of giving no record in the reply, it would give SERVFAIL. Even worse, it also broke DNS64. It appears it filters the responses it gets from authoritative servers and not the replies it sends to clients. So even though the reply would be permitted after conversion, it is not send because it is invalid before conversion.

Next I looked at Response Policy Zone Rewriting. But the format appears to only allow me to specify one policy per domain and not per record type.

Is there a better solution than setting up two instances where the first does DNS64, and the second uses the first as forwarder and uses deny-answer-addresses?

[kasperd]

I figured out how to make a domain IPv6 only through RPZ rewriting. However it turns out to suffer from the same problem with ordering as deny-answer-addresses. It won't do DNS64 with an IPv4 address denied by the policy even if the result IPv6 address is permitted.

So the only thing I really gained from RPZ rewriting was that it can report that the domain exists but has no A records. In that case it does however produce some really strange authority records.

I also found that the way the policy is applied to ANY queries is a bit strange. Normally an ANY query will report all the cached records for the name. If none are cached an ANY query will be sent to the authoritative server, and the client will receive all the records.

If my policy doesn't accept the A record, then all records will be deleted from the ANY reply if there is an A record. So starting from empty cache, the ANY query will be sent to the authoritative server, all records will be cached and none will be sent to the client, because the A record is not permitted by the policy. If OTOH starting from an empty cache I first query for another record type, then that record will be cached and send in response to ANY queries. So it is possible to get replies to the ANY queries, but even that stops working again, if a client queries for the A record. Then the A record will be cached, and the server will no longer send any replies in response to ANY queries.

I guess filter-aaaa-on-v4 has a more sensible behaviour, except it does the opposite from what I want. But I am not going to test that option as it is not in the build I am using, and I don't want to compile it to test something that does the opposite of what I want.

[snarked]

I think you may need different views.  What you want does not appear to lend itself to a single context.

[kasperd]

I think you may need different views.  What you want does not appear to lend itself to a single context.

Views appears to be designed to allow the DNS server to send different replies to different clients. That is not what I try to achieve. Regardless of which client queries my DNS server, I want it to see all domains as IPv6 only, as long as the original domain had at least an A record or an AAAA record.

I'm not saying it is impossible to do it using views, but I just have no idea how it would be done using views. Can you elaborate on what sort of configuration you had in mind?

[snarked]

Views may be what you want.  You're not thinking.

One view:  IPv6 clients querying - Those you will answer with IPv6 addresses ONLY.  Problem solved.

Another view:  IPv4 clients querying - Those asking for AAAA records (or something non-addressed like SOA, MX, etc.) are not a problem.  Answer as above.

Yet another view:  IPv4 clients querying for A-RRs.  Those are the ones you don't want to answer.

You also want to use the preferred-glue clauses for the additional section as well (preferring AAAA over A).

[kasperd]

Yet another view:  IPv4 clients querying for A-RRs.  Those are the ones you don't want to answer.

According to the documentation views can filter on the transport IP addresses as well as on the recursion bit. But it gives no way of filtering on the query type.

[snarked]

I suggest you keep reading the documentation.  There may not be a filter per se, but there is a section that deals with query types in there somewhere....

[kasperd]

there is a section that deals with query types in there somewhere....

Which manual are you looking at? Because that section is not in the BIND 9 Administrator Reference Manual I'm looking at.

[snarked]

The last time I looked at the manual, it was for BIND 9.9.0.  The current version is now 9.9.1-P3.

I don't believe that 9.6.x and earlier versions have the features you will need.

[kasperd]

The last time I looked at the manual, it was for BIND 9.9.0.  The current version is now 9.9.1-P3.

I am looking at http://ftp.isc.org/isc/bind9/cur/9.9/doc/arm/Bv9ARM.pdf (sha1sum eeea6db8ff1c8fc2dcd46fcbef9ef66c62d9ab9a). There is no section about query types in that document. (There is a section with a list of all the resource types, which can be put in a zone file, but that is not related to my question.)

I don't believe that 9.6.x and earlier versions have the features you will need.

I read some page suggesting, I need version 9.8 or later to get dns64 support. The package I installed only says bind9, I don't know which subversion. But it has dns64 support, so it must be either 9.8, 9.9, or a version patched by the distribution.

Either way, so far I haven't found any discrepancy between the documentation and what is actually installed.

[broquea]

You could always: strings /usr/sbin/named|grep version (assuming that is where your binary is installed) to try and verify version. Also under ubuntu: aptitude show bind9

[kasperd]

Also under ubuntu: aptitude show bind9

Probably there is a way to see it using software available in the default install, I just don't know which. But I found I could use: dig -t txt -c ch version.bind

It said 9.8.1-P1

But which version I have installed is not really important at this time. First I'd like to find out if there is any version of bind, which can even do the job. Once I know of a way to configure it, then I'll install whatever version is required to make it work.

[snarked]

Bind manual:
6.2.16.6 deals with query addresses.  Therefore, that part is done if you're using multiple views.
6.2.16.18 additional section caching.  You probably want that turned off for IPv4 queries.

I may have been thinking of 6.2.16.19 - content filtering, but I realize that deals with incoming answers, not outgoing ones.  I might also have been thinking of RRset ordering in 6.2.16.14, but that doesn't allow for dropping answers.

You also definently want the option "preferred-glue" set to AAAA so that if you do have additional records, the AAAA records will always be first if A records are also present.

Look at the "dns64" option on page 59.  Is that the part you say you got working?

[kasperd]

Look at the "dns64" option on page 59.  Is that the part you say you got working?

Yes, that part I got working.

What I did not succeed in was removing the A record after generating the synthetic AAAA record. All the methods I tried so far would remove the A record before synthesizing the AAAA record, thus it was never able to synthesize an AAAA record.

[snarked]

Why not permanently remove the A record and manually put in its AAAA equivalent?