Mailing List Archive: nsp: ipv6

Interesting A10 GSLB interop problem

Index | Next | Previous | View Threaded

gbonser at seven

Oct 23, 2011, 5:48 PM

Post #1 of 9 (1028 views)
Permalink

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"

gbonser at seven

Oct 23, 2011, 5:55 PM

Post #2 of 9 (975 views)
Permalink

RE: Interesting A10 GSLB interop problem [In reply to]

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 [mailto:ipv6-
> ops-bounces+gbonser=seven.com [at] lists] On Behalf Of George
> Bonser
> Sent: Sunday, October 23, 2011 5:49 PM
> To: ipv6-ops [at] lists
> 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"
>
>
>

jbates at brightok

Oct 23, 2011, 7:13 PM

Post #3 of 9 (977 views)
Permalink

Re: Interesting A10 GSLB interop problem [In reply to]

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 [mailto:ipv6-
>> ops-bounces+gbonser=seven.com [at] lists] On Behalf Of George
>> Bonser
>> Sent: Sunday, October 23, 2011 5:49 PM
>> To: ipv6-ops [at] lists
>> 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"
>>
>>
>>

gbonser at seven

Oct 23, 2011, 7:59 PM

Post #4 of 9 (1010 views)
Permalink

RE: Interesting A10 GSLB interop problem [In reply to]

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 [mailto:ipv6-ops-bounces+gbonser=seven.com [at] lists] On Behalf Of Jack Bates
Sent: Sunday, October 23, 2011 7:13 PM
To: ipv6-ops [at] lists
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<mailto:ipv6-ops-bounces+gbonser=seven.com [at] lists> [mailto:ipv6-

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

Bonser

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

To: ipv6-ops [at] lists<mailto:ipv6-ops [at] lists>

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"

jbates at brightok

Oct 23, 2011, 8:16 PM

Post #5 of 9 (975 views)
Permalink

Re: Interesting A10 GSLB interop problem [In reply to]

On 10/23/2011 9:59 PM, George Bonser wrote:
>
> 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.
>

What happens if you are replacing the A record, and not shifting to a
CNAME? Surely it wouldn't reply to an AAAA request with an A record. I'm
wondering if this is something specific to the usage of a CNAME.

Jack

gbonser at seven

Oct 25, 2011, 10:15 AM

Post #6 of 9 (966 views)
Permalink

RE: Interesting A10 GSLB interop problem [In reply to]

> >
> > 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.
> >
>
> What happens if you are replacing the A record, and not shifting to a
> CNAME? Surely it wouldn't reply to an AAAA request with an A record.
> I'm
> wondering if this is something specific to the usage of a CNAME.
>
>
> Jack

The idea here is that you have an A record that points to a VIP. If the VIP is down, the system returns a CNAME to a different name which acts as a fallback. What this CNAME does in this specific case is scatters clients across the remaining VIPs that provide the service for a period of at least 2 hours.

So basically a client has a VIP that services its geographical area if the service IP in its geographical area goes unavailable, the client gets a CNAME with a TTL of 7200 that round robins it to one of the remaining IPs for the same service but outside its geographical area. So if the east coast VIP fails, it might get sent to the Midwest of the West coast for two hours and then it will try again. This prevents a service that has been down for a while from getting slammed suddenly by all of its users coming back all at once. They will come back gradually over a period of two hours once the service is restored.

The problem is that if a client makes an AAAA request and there is no IPv6 address associated with the service VIP, the system handles it as if it were down and gives the CNAME out instead of handling it as if there just isn't a v6 IP and giving NOERR with a reference to the A record.

This causes the client's DNS server to cache the 7200 TTL failover CNAME resulting in all clients using that DNS server to go into the failure mitigation mode when there is no failure.

What I believe the correct response should be is:

If an AAAA request arrives for a gslb service-ip that does not have an associated IPv6 address it should get a NOERR response with the A record in the "additional" section.

If an AAAA request arrives for a gslb service-ip that DOES have an associated IPv6 address and that service-ip is down, then it should get the CNAME.

jhp at jhprins

Oct 25, 2011, 4:36 PM

Post #7 of 9 (955 views)
Permalink

Re: Interesting A10 GSLB interop problem [In reply to]

On 10/24/2011 02:48 AM, George Bonser wrote:
> 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"

To me it looks like the problem is that the GSLB should return a NOERR
on the AAAA request with an empty answer. Returning a ERR on a AAAA
request is wrong if it is only because you don't have a AAAA record.
(RFC 4074)

Jan Hugo Prins

gbonser at seven

Oct 26, 2011, 12:03 AM

Post #8 of 9 (951 views)
Permalink

RE: Interesting A10 GSLB interop problem [In reply to]

> To me it looks like the problem is that the GSLB should return a NOERR
> on the AAAA request with an empty answer. Returning a ERR on a AAAA
> request is wrong if it is only because you don't have a AAAA record.
> (RFC 4074)
>
> Jan Hugo Prins

That would be acceptable, too, but adding the A record in the additional might result in saving a lookup later. The point is that if a service doesn't have an IPv6 address, the GSLB unit shouldn't return the fallback CNAME as CNAMEs are common to both IPv4 and IPv6. It should only return the fallback CNAME if the resource has a V6 address but is down. If it doesn't have a v6 IP it can't be "broken", it simply needs to be redirected to the v4 IP.

jbates at brightok

Oct 26, 2011, 9:27 AM

Post #9 of 9 (957 views)
Permalink

Re: Interesting A10 GSLB interop problem [In reply to]

On 10/26/2011 2:03 AM, George Bonser wrote:
> That would be acceptable, too, but adding the A record in the
> additional might result in saving a lookup later. The point is that if
> a service doesn't have an IPv6 address, the GSLB unit shouldn't return
> the fallback CNAME as CNAMEs are common to both IPv4 and IPv6. It
> should only return the fallback CNAME if the resource has a V6 address
> but is down. If it doesn't have a v6 IP it can't be "broken", it
> simply needs to be redirected to the v4 IP.

Is there not a command to tell it that there isn't any IPv6? (ie,
disable IPv6 support for this zone)

This is the problem with using CNAME. Even if you were using IPv6, using
CNAME means that if IPv4 or IPv6 breaks, both will be sent to the
backup. This could be problematic in a situation where primary IPv4 is
good, backup IPv4 is bad, primary IPv6 is bad, backup IPv6 is good. By
using CNAME, you are fate sharing the protocols.

Don't get me wrong, there are GSLB situations where CNAME is great,
primarily in geolocation functions. In failover situations, it's
horrible. A/AAAA record replacement would be the ideal mechanism. So
ideally, you'd have CNAME geolocation, and then A/AAAA determination of
the new domain based on service availability for each protocol
independently. I'm disappointed A10 didn't adopt the approach (perhaps
because IPv6 was just hacked in without reconsideration of the entire
solution when utilizing a multi-protocol environment).

Jack

Index | Next | Previous | View Threaded

Interested in having your list archived? Contact Gossamer Threads