sort list and view
Kevin Darcy
kcd at chrysler.com
Wed Jul 20 17:23:10 UTC 2011
On 7/20/2011 1:15 AM, AMANI M. BIN SUWAIF wrote:
> Hi,
>
> The problem is that fail-over between A records is not standard and
> might/might not work with various SIP clients. On the other hand SRV
> in my opinion has been designed with that in mind, that's why the
> additional complexity with 2 SRV records.
>
>
> Thanks & Regards,
>
> *Amani*
>
>
>
> On 7/20/2011 2:50 AM, Kevin Darcy wrote:
>> On 7/18/2011 11:42 PM, AMANI MOHAMED BIN SUWAIF wrote:
>>> Hi,
>>>
>>> I have the below scenario
>>>
>>> _TCP.EXAMPLE.COM IN SRV 10 0 5060
>>> primary-sbg.example.com
>>> _TCP.EXAMPLE.COM IN SRV 20 0 5060
>>> secondary-sbg.example.com
>>>
>>> I have 2 IP ranges and 2 SBGs host, my intention is
>>>
>>> for client in IP range1
>>> primary-sbg IN A 1.1.1.1
>>> secondary-sbg IN A 2.2.2.2
>>>
>>> for client in IP range2
>>> primary-sbg IN A 2.2.2.2
>>> secondary-sbg IN A 1.1.1.1
>>>
>>> can this be achieved without using a views?
>>>
>>> I thought this can be solved just by a sortlist, where
>>> primary-sbg IN A 1.1.1.1
>>> primary-sbg IN A 2.2.2.2
>>> secondary-sbg IN A 2.2.2.2
>>> secondary-sbg IN A 1.1.1.1
>>>
>>> and then introduce the sortlist, which sorts the position of IP
>>> addresses based on the IP range client comes from?
>>> something like,
>>>
>>> sortlist {
>>> {
>>> IPRANGE1; // 1st client IP selection matches any of these
>>> {1.1.1.1; // return any of these response IPs as 1st preference
>>> };
>>> {
>>> IPRANGE2; // 1st client IP selection matches any of these
>>> {2.2.2.2; // return any of these response IPs as 1st preference
>>> };
>>> };
>>>
>>> but in this case,
>>> client from IPRANGE1 receive 1.1.1.1 as a first choice for both
>>> primary-sbg and secondary-sbg
>>> and
>>> client from IPRANGE2 receive 2.2.2.2 as a first choice for both
>>> primary-sbg and secondary-sbg
>>> which is not the intention. sortlist doesn't not consider domain name.
>>> The intention is to have primary SBG for first iprange act as a
>>> secondary SBG for the second ip range and vice verse and in similar
>>> manner for multiple IP ranges and SBGs. Problem with views is that
>>> anytime this setup gets bigger and we will have additional ip ranges
>>> and additional SBGs, it will require additional views...
>>>
>>> (LOC)RANGE PRIMARY(LOC) SECONDARY(LOC)
>>> (L1)IPRANGE1 SBG1(L1) SBG6(L2)
>>> (L1)IPRANGE2 SBG2(L1) SBG7(L2)
>>> (L1)IPRANGE3 SBG3(L1) SBG8(L2)
>>> (L1)IPRANGE4 SBG4(L1) SBG9(L2)
>>> (L1)IPRANGE5 SBG5(L1) SBG10(L2)
>>>
>>> (L2)IPRANGE6 SBG6(L2) SBG1(L1)
>>> (L2)IPRANGE7 SBG7(L2) SBG2(L1)
>>> (L2)IPRANGE8 SBG8(L2) SBG3(L1)
>>> (L2)IPRANGE9 SBG9(L2) SBG4(L1)
>>> (L2)IPRANGE10 SBG10(L2) SBG5(L1)
>>>
>>> half of the SBGs is in one location (L1) and half in other (L2),
>>> that's why it is important that for clients from ranges in one
>>> location, first half of SBGs is preferred, and for other clients
>>> from second location other half of SBGs is preferred. Client
>>> configuration should be uniformed (same SRV) regardless the location.
>> Are you over-engineering this? If the A-record failover by your
>> client is fast enough you might only need 1 SRV record, and then
>> sortlisting will work fine (subject to the usual caveats: as long as
>> you can control the sortlist config of every resolver your clients
>> will use, and keep them in sync).
>>
>>
>>
>> - Kevin
Well, you could always stand up some virtual IPs on the same servers (or
possibly NAT it upstream) and then perform some *fancy* sortlisting, e.g.
for clients in IP range1
primary-sbg 1.1.1.1, 2.2.2.3
secondary-sbg 2.2.2.2, 1.1.1.2
for clients in IP range2
primary-sbg 2.2.2.3, 1.1.1.1
secondary-sbg 1.1.1.2, 2.2.2.2
That way range1 clients would always fail over -- via SRV failover or
A-record failover -- from the 1.1.1.x server to the 2.2.2.x server and
range2 clients would always fail over from the 2.2.2.x server to the
1.1.1.x server.
Bear in mind that "view"s, i.e. giving different answers to the same DNS
query, depending on the client, is not something which is (as far as I'm
aware) sanctioned by the Internet Standards, but A-record failover was
specified as far back as RFC 1123 (1989):
"2.3 Applications on Multihomed hosts
When the remote host is multihomed, the name-to-address translation will
return a list of alternative IP addresses. As specified in Section
6.1.3.4, this list should be in order of decreasing preference.
Application protocol implementations SHOULD be prepared to try multiple
addresses from the list until success is obtained. More specific
requirements for SMTP are given in Section 5.3.4. "
2.3 Applications on Multihomed hosts
When the remote host is multihomed, the name-to-address
translation will return a list of alternative IP addresses. As
specified in Section 6.1.3.4, this list should be in order of
decreasing preference. Application protocol implementations
SHOULD be prepared to try multiple addresses from the list until
success is obtained. More specific requirements for SMTP are
given in Section 5.3.4.
So if you're worried about what is "standard" and what isn't, you should
cast your lot with A-record failover and *not* any "view" trickery.
- Kevin
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.isc.org/pipermail/bind-users/attachments/20110720/67b7a55d/attachment.html>
More information about the bind-users
mailing list