Interesting A10 GSLB interop problem

[George Bonser]

Nah, I have tried both.

When it gets a AAAA request for a vip that has only a v4 address, it either returns nothing or if there is a fallback cname, issues the cname.

If the name is the same as the A record and there is no v6 address, it should simply return noerr and give the v4 IP.  It doesn't work in proxy mode and it is working in a subdomain model, actually.  I simplified it for that example.

Problem is that if you have an A record with a fallback cname, it will always hit the fallback cname when an AAAA record is asked for.  In the case where you have a client that is making its requests through a local dns server, that server will cache that result giving that fallback cname to all requesters of A records after that one client makes its AAAA request.

The problem isn't so much the mishandling of the AAAA records, per se, as it is the fact that the mishandling of them messes up future v4 A record requests by clients using the same DNS server due to the caching of the CNAME.  I have even reduced the cname TTL to 10 seconds but you still end up with any v4 clients that make a request to the local DNS server getting scattered to the failover VIPs during that 10 second period after an AAAA request.  That can be a substantial number of requests.



From: ipv6-ops-bounces+gbonser=seven.com at lists.cluenet.de [mailto:ipv6-ops-bounces+gbonser=seven.com at lists.cluenet.de] On Behalf Of Jack Bates
Sent: Sunday, October 23, 2011 7:13 PM
To: ipv6-ops at lists.cluenet.de
Subject: Re: Interesting A10 GSLB interop problem

Perhaps that's why the website says, "Note: The AX is not recommended as a full DNS server replacement "

I suspect using a subdomain model or proxy model would overcome these problems.

On 10/23/2011 7:55 PM, George Bonser wrote:

And just to add, the desired behavior would be:



If an AAAA request is received and if there is no IPv6 address for a VIP resource, if the VIP is up, return NOERR with the A record.  If the VIP is down, return the as-replace cname record.



If an AAAA request is received and if there is an IPv6 address for a VIP resource, if the VIP is up, return the IPv6 address.  If the VIP is down, return the as-replace cname record.







-----Original Message-----

From: ipv6-ops-bounces+gbonser=seven.com at lists.cluenet.de<mailto:ipv6-ops-bounces+gbonser=seven.com at lists.cluenet.de> [mailto:ipv6-

ops-bounces+gbonser=seven.com at lists.cluenet.de<mailto:ops-bounces+gbonser=seven.com at lists.cluenet.de>] On Behalf Of George

Bonser

Sent: Sunday, October 23, 2011 5:49 PM

To: ipv6-ops at lists.cluenet.de<mailto:ipv6-ops at lists.cluenet.de>

Subject: Interesting A10 GSLB interop problem



I ran across an interesting problem when using an A10 for GSLB with

IPv4 only resources.



So assume the following configuration:



gslb zone example.com

 policy foo

 ttl 7200

 service http foo

        dns-cname-record fail.example.com as-replace

        dns-a-record foo-vip ttl 600



GSLB is operating in server mode, not proxy mode.



The purpose if this config is that if a user requests foo.example.com

and it is down, it (and all other users using that DNS server) is

diverted to fail.example.com for a period of two hours.  Foo-vip has

only an IPv4 address.



Assume a client makes a request for an A record.  The local DNS server

will request an A record and get back the record for foo.example.com

and everything works as planned.



The problem comes in when a client device makes a request for an AAAA

record.  As there is no ipv6 address for foo-vip, the client's local

DNS server receives the fail.example.com CNAME which lives for two

hours.



A subsequent client making an IPv4 request after the 600 second TTL of

the A record receives the "fail.example.com" CNAME (or the local DNS

server performs a recursive lookup on its behalf) and it gets the

failover address and will continue getting it for as long as clients

make AAAA requests to the GSLB.



There is apparently no way to configure the A10 GSLB to say "if there

is no IPv6 record for a VIP but there is an IPv4 address, return NOERR

with the A record"









-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.cluenet.de/pipermail/ipv6-ops/attachments/20111024/c3b3f300/attachment.htm>