need a temp workaround for dns64 when A is available and AAAA SERVFAILs

[Veaceslav Revutchi]

I need to provide DNS64 on a caching resolver for a project (MS direct
access). It will mostly be resolving internal names, most of which are
delegated to an LB. The requests will be arriving over v4 only (nat64
already in place).

Here is the setup:

for simplicity I will show one authoritative server and one LB.

NS1  (authoritative for “example.com”, running bind9.7)
LB    (F5, should be authoritative for  “lbi.example.com”, in reality as we
discovered recently is authoritative for “example.com”)

NS1 delegates lbi.example.com to LB.

A typical record on NS1 looks like this:

intranet.example.com   CNAME   intranet.lbi.example.com.
(the final answer comes from LB).

my-dns64-resolver  (bind 9.9.2p1) acts as secondary for example.com (zone
transfer from NS1).

My resolver is able to resolve A records fine (such as
intranet.lbi.example.com). When I ask for the same name as AAAA it returns
SERVFAIL and “DNS format error, invalid response” gets logged on the
resolver.  The reason for that is the LB returning “example.com” as SOA in
the AUTHORITY SECTION when it should be returning “lbi.example.com”.

As a result of this I don’t get my synthesized v6 record even though the A
records is there.


Unfortunately it will take a while before the LB team fixes the authority
problem. I am looking for a workaround to get my dns64 resolver to generate
those synthetic AAAA responses for the clients even when it gets that
invalid AAAA response from the LB.

Any ideas appreciated.

Slava.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.isc.org/pipermail/bind-users/attachments/20140506/20197306/attachment.html>