RE: about the dig
I guess not, since it does not work ;-) After deleting all entries, did you : 1) dig @dns.name. ... or 2) dig @IP.address or 3) No @... argument used at all ? In cases 1 3, dig will need data from /etc/resolv.conf. Only in case 2 dig can do without. Kind regards, Marc Lampo -Original Message- From: Feng He [mailto:short...@gmail.com] Sent: 19 July 2011 07:33 AM To: bind-users@lists.isc.org Subject: about the dig Hi list, When I deleted all the entries in /etc/resolv.conf (I am using Linux), dig can't work. I was thinking since dig is a standard resolver, it should have the capibility to follow the referrel from root, thus it will work fine even there is no system dns resolving. Am I right? Thanks. ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: about the dig
at least from my point dig hostname +trace should work even if there is no resolv.conf entries. On Tue, Jul 19, 2011 at 1:39 PM, Marc Lampo marc.la...@eurid.eu wrote: I guess not, since it does not work ;-) After deleting all entries, did you : 1) dig @dns.name. ... or 2) dig @IP.address or 3) No @... argument used at all ? In cases 1 3, dig will need data from /etc/resolv.conf. Only in case 2 dig can do without. Kind regards, Marc Lampo -Original Message- From: Feng He [mailto:short...@gmail.com] Sent: 19 July 2011 07:33 AM To: bind-users@lists.isc.org Subject: about the dig Hi list, When I deleted all the entries in /etc/resolv.conf (I am using Linux), dig can't work. I was thinking since dig is a standard resolver, it should have the capibility to follow the referrel from root, thus it will work fine even there is no system dns resolving. Am I right? Thanks. ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: about the dig
On Tue, Jul 19, 2011 at 12:32 PM, Feng He short...@gmail.com wrote: Hi list, When I deleted all the entries in /etc/resolv.conf (I am using Linux), dig can't work. I was thinking since dig is a standard resolver, what makes you think that? From the man page dig (domain information groper) is a flexible tool for interrogating DNS name servers. It performs DNS lookups and displays the answers that are returned from the name server(s) that were queried. it should have the capibility to follow the referrel from root, thus it will work fine even there is no system dns resolving. A resolver software capable of recursive operation should work fine. dig's not it. Am I right? Also from the man page: Unless it is told to query a specific name server, dig will try each of the servers listed in /etc/resolv.conf. So something like dig google.com @8.8.8.8 would work even without any entries on /etc/resolv.conf, but if you don't tell it to use a specific name server it won't work. -- Fajar ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: about the dig
On Tue, Jul 19, 2011 at 1:50 PM, Marc Lampo marc.la...@eurid.eu wrote: the list cannot be built-in, because some organisations work with an internal root. The local caching name server is the only one to know those new root's.) I don't think so. BIND 9 has the built-in root list. ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: about the dig
Hi there, On Tue, 19 Jul 2011 wrote: When I deleted all the entries in /etc/resolv.conf (I am using Linux), dig can't work. I was thinking since dig is a standard resolver... man resolv.conf If this file doesn't exist the only name server to be queried will be on the local machine; the domain name is determined from the hostname and the domain search path is constructed from the domain name. -- 73, Ged. ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Patching bind for additional stats - any tips?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I am very interested in hearing what you are looking for. I have some thoughts about performance measurements, mostly to answer the age-old question, Are my servers working well? Would you release the patches, and if so, would you be willing to work with the ISC BIND 9 team to see if we can find common ground and perhaps get your patches into BIND 9 releases quickly? - --Michael On 7/18/11 8:13 PM, Alex Kolchinski wrote: Hi everyone - I'm at Google and currently starting on a mini-project to get some more insight into how our BIND servers are performing. Our first thoughts on how to add logging on metrics we're interested in are currently to patch BIND to spit out the wanted stats directly from BIND (data on each query, perhaps aggregated). An alternative to this would be to try to match the incoming and outgoing request and response packets and amass the data from that, but our attempts at data gathering through sniffing have given unreliable results. (One alternative I've stumbled upon is DSC - http://dns.measurement-factory.com/tools/dsc/ - but I'm not sure yet how appropriate or effective it would be for our needs, so if anyone has any thoughts, that would be much appreciated.) I've never worked with BIND before, so I'm looking over the code right now figuring out which approach is going to be the most effective and straightforward. Does anyone have any experience with something similar and/or suggestions on approaches or considerations to think about? It's looking like if the patch is going to be the way to go, simply modifying BIND's stats-outputting functionality should be a good way to extend what statistics we're getting, although I'm not sure on that count either. Any thoughts? Thanks, everyone -Alex ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJOJTzQAAoJEDRzoY2A7tzbJqYH/1wfTSTp9VBz+VTurD4pJDpi Zsr2JY+jo/G6VPluAN5G1ZnjqvtVlmqoagSBy5nRtA0qkp9kGiWWboDA5b3uEnEK sqeAy7ns0j8Mp8Lp8i5WyxMSm1QiPQUO93sLoQqMcWwWVcVsw/oWM0OZnucvR/a2 puLR865BmFTtgp0gg/nzaCrls2J+8kY8nxmo2iSAEfn17v0H3T9DqHNwhFR3D4f6 /7V8nP8Ts0F0RRMPLLkx7K4qGNjTy7ha24P+2gzK/w/TkTbVLCXv8UJHK08f3TEM uW5LQJnsrOFxLDWHsXUrzS323sLQtQo616Rbw2PZwBM7Cx4x0UNgLFgAjlSzUU8= =D35/ -END PGP SIGNATURE- ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
authoritative server is not caching?
Hello, I want to make sure that if the authoritative server won't cache anything even if the authoritative answer from itself? Coz I saw the book Pro DNS and BIND says: The (authoritative) name server does not cache. thanks. Une messagerie gratuite, garantie à vie et des services en plus, ça vous tente ? Je crée ma boîte mail www.laposte.net ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: about the dig
On Tue, Jul 19, 2011 at 2:47 PM, G.W. Haywood b...@jubileegroup.co.uk wrote: man resolv.conf If this file doesn't exist the only name server to be queried will be on the local machine; the domain name is determined from the hostname and the domain search path is constructed from the domain name. Nothing around the resolv.conf, I was talking about dig. Thanks. ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: about the dig
On 07/19/2011 06:32 AM, Feng He wrote: Hi list, When I deleted all the entries in /etc/resolv.conf (I am using Linux), dig can't work. I was thinking since dig is a standard resolver, it should have the capibility to follow the referrel from root, thus it will work fine even there is no system dns resolving. Am I right? No. dig is a test tool. It is not a recursive resolver. It does not contain a list of root hints, and always starts a query at a nameserver you give it, either explicitly via the @server command line, or implicitly via /etc/resolv.conf Even when doing +trace. ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: authoritative server is not caching?
On 2011-07-19 11:40, pa...@laposte.net wrote: Hello, I want to make sure that if the authoritative server won't cache anything even if the authoritative answer from itself? Coz I saw the book Pro DNS and BIND says: The (authoritative) name server does not cache. Authoritative server cannot cache anser from itself. Cache is for answers a server has received from somewhere, while authoritative answers come directly from zone data. Torinthiel ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: authoritative server is not caching?
On Tue, Jul 19, 2011 at 11:40:02AM +0200, pa...@laposte.net pa...@laposte.net wrote a message of 11 lines which said: I want to make sure that if the authoritative server won't cache anything even if the authoritative answer from itself? I'm sorry but this sentence seems quite difficult to parse. ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: about the dig
On 7/19/2011 1:16 AM, Feng He wrote: On Tue, Jul 19, 2011 at 1:50 PM, Marc Lampomarc.la...@eurid.eu wrote: the list cannot be built-in, because some organisations work with an internal root. The local caching name server is the only one to know those new root's.) I don't think so. BIND 9 has the built-in root list. BIND is the name of a collection of DNS related software and consists of many pieces, which named and dig are but two of them. To the best of my knowledge, only named has a root list built-in, which can be overwritten by the proper use of config directives in named.conf. Lyle Giese LCR Computer Services, Inc. ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
bind version problem
Hi, If Bind version of primary dns is bind-libs-9.3.6-16.P1.el5 and for secondary dns bind-9.5.0-29.b2.fc9.i386. Is there create any problem?? Is it mandatory the same version for primary and secondary DNS. Regards - Mahmud ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: bind version problem
On 7/19/11 9:30 AM, almah...@ranksitt.net almah...@ranksitt.net wrote: Hi, If Bind version of primary dns is bind-libs-9.3.6-16.P1.el5 and for secondary dns bind-9.5.0-29.b2.fc9.i386. Is there create any problem?? In general, it creates no problem. If you happen to use an RR for which support was added in 9.5, then you might have odd results. Is it mandatory the same version for primary and secondary DNS. No. It's not even mandatory that the primary and secondary both be running bind. -- Daniel J McDonald, CCIE # 2495, CISSP # 78281 ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: about the dig
Feng: I think G.W is pointing out that in the absence of resolv.conf, dig uses the localhost to connect to the bind server. Just tcpdump the loopback interface, and you will see it. So the reason resolution works is because you are running bind on that server. It would not work on any client which isn't running bind. We generally put the entry in so we know where our DNS requests are going, the loopback or a real interface. In doesn't have to be that way, you don't have to use the bind server on the box itself. On 7/19/11 3:54 AM, Feng He wrote: On Tue, Jul 19, 2011 at 2:47 PM, G.W. Haywood b...@jubileegroup.co.uk wrote: man resolv.conf If this file doesn't exist the only name server to be queried will be on the local machine; the domain name is determined from the hostname and the domain search path is constructed from the domain name. Nothing around the resolv.conf, I was talking about dig. Thanks. ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users -- eugene tsuno NOAA Boulder/NOC 325 broadway, boulder,co 80305 303-497-6392 ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: bind version problem
On Tue, Jul 19, 2011 at 08:30:17PM +0600, almah...@ranksitt.net almah...@ranksitt.net wrote a message of 18 lines which said: Is it mandatory the same version for primary and secondary DNS. It is not even mandatory for all the authoritative name servers to run BIND. They can be of different brands. That's the beauty of standard protocols. ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
AAAA type query invalidates A records in name server cache
All, anyone experiencing the same behavior? Seen on BIND 9.5.2-P2 and BIND 9.8.0-P4 ns11:~ # nslookup -querytype=A xserv.ins.dell.com. . Non-authoritative answer: Name: xserv.ins.dell.com Address: 143.166.148.118 All ok. ns11:~ # nslookup -querytype= xserv.ins.dell.com. . ** server can't find xserv.ins.dell.com.: NXDOMAIN Now even the A queries fail. ns11:~ # nslookup -querytype=A xserv.ins.dell.com. . ** server can't find xserv.ins.dell.com.: NXDOMAIN Keeps failing until TTL timeout or rndc flushname xserv.ins.dell.com. ns11:~ # nslookup -querytype=A xserv.ins.dell.com. . Non-authoritative answer: Name: xserv.ins.dell.com Address: 143.166.148.118 Thanks, Patrick -- This e-mail message and any attachments are of a confidential nature. The information is intended for the named addressee exclusively. If you are not the addressee, you may not electronically disseminate, otherwise distribute or copy this e-mail message, and you may also not use it for any purpose. Please notify the sender immediately if you have received this e-mail message by mistake, and delete this e-mail message and its attachments. E-mail transmissions could be lost, intercepted, corrupted or destroyed. They could arrive late or incomplete, or could even contain viruses. Confidentiality and reliability of the information so transmitted cannot be guaranteed. Rothschild Bank therefore does not accept any liability or responsibility for errors or omissions regarding the information transmitted through e-mail. If verification of the information transmitted through e-mail is required, please ask for postal delivery by contacting Rothschild Bank.. This e-mail message is provided for information purposes only. It should not be construed as an offer or solicitation to buy or sell any financial instruments or services. It is not to be made available to US persons and is not to be circulated within the USA. ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: bind version problem
If Bind version of primary dns is bind-libs-9.3.6-16.P1.el5 and for secondary dns bind-9.5.0-29.b2.fc9.i386. Something wrong there: libs vs. server, but I assume you mean server for both. Is it mandatory the same version for primary and secondary DNS. Not unless you rely on a particular feature of the higher version. -JP ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
RE: about the dig
Or as previously pointed out it WILL work if you specify a name server at invocation. That is to say you MUST either do dig @server... OR have a resolve.conf that specifies servers to attempt if not specified at invocation. (And before anyone else says it - You can of course still specify a server at invocation to bypass the ones in /etc/resolv.conf.) -Original Message- From: bind-users-bounces+jlightner=water@lists.isc.org [mailto:bind-users-bounces+jlightner=water@lists.isc.org] On Behalf Of eugene tsuno Sent: Tuesday, July 19, 2011 10:53 AM To: bind-users@lists.isc.org Subject: Re: about the dig Feng: I think G.W is pointing out that in the absence of resolv.conf, dig uses the localhost to connect to the bind server. Just tcpdump the loopback interface, and you will see it. So the reason resolution works is because you are running bind on that server. It would not work on any client which isn't running bind. We generally put the entry in so we know where our DNS requests are going, the loopback or a real interface. In doesn't have to be that way, you don't have to use the bind server on the box itself. On 7/19/11 3:54 AM, Feng He wrote: On Tue, Jul 19, 2011 at 2:47 PM, G.W. Haywood b...@jubileegroup.co.uk wrote: man resolv.conf If this file doesn't exist the only name server to be queried will be on the local machine; the domain name is determined from the hostname and the domain search path is constructed from the domain name. Nothing around the resolv.conf, I was talking about dig. Thanks. ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users -- eugene tsuno NOAA Boulder/NOC 325 broadway, boulder,co 80305 303-497-6392 ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users Proud partner. Susan G. Komen for the Cure. Please consider our environment before printing this e-mail or attachments. -- CONFIDENTIALITY NOTICE: This e-mail may contain privileged or confidential information and is for the sole use of the intended recipient(s). If you are not the intended recipient, any disclosure, copying, distribution, or use of the contents of this information is prohibited and may be unlawful. If you have received this electronic transmission in error, please reply immediately to the sender that you have received the message in error, and delete it. Thank you. -- ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: AAAA type query invalidates A records in name server cache
On Tue, Jul 19, 2011 at 04:58:53PM +0200, mailsecurity wrote: All, anyone experiencing the same behavior? I hope so, because that's the correct behavior. Dell's nameserver is broken: http://tools.ietf.org/html/rfc4074 Common Misbehavior Against DNS Queries for IPv6 Addresses - May 2005 4.2. Return Name Error This type of server returns a response with RCODE 3 (Name Error) to a query for an RR, indicating that it does not have any RRs of any type for the queried name. With this response, the stub resolver may immediately give up and never fall back. Even if the resolver retries with a query for an A RR, the negative response for the name has been cached in the caching server, and the caching server will simply return the negative response. As a result, the stub resolver considers this to be a fatal error in name resolution. fpdns says that Dell's servers are BIND, wonder if that's accurate, and if so, how ancient a release, to have this bug? Bill. ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: AAAA type query invalidates A records in name server cache
This is because Dell has incorrectly configured their F5 GTM load balancers to return NXDOMAIN on a query instead of NOERROR (this is configurable on a per-wideip basis in the GTM configuration - at least in present versions. In earlier versions you had to ensure that you had a record of some type matching the wideip name in the BIND configuration so that when the GTM passed the query back to BIND it would return NOERROR). -Tim On Tue, Jul 19, 2011 at 7:58 AM, mailsecurity mailsecur...@rothschildbank.com wrote: All, anyone experiencing the same behavior? Seen on BIND 9.5.2-P2 and BIND 9.8.0-P4 ns11:~ # nslookup -querytype=A xserv.ins.dell.com. ….. Non-authoritative answer: Name: xserv.ins.dell.com Address: 143.166.148.118 All ok. ns11:~ # nslookup -querytype= xserv.ins.dell.com. ….. ** server can't find xserv.ins.dell.com.: NXDOMAIN Now even the A queries fail. ns11:~ # nslookup -querytype=A xserv.ins.dell.com. ….. ** server can't find xserv.ins.dell.com.: NXDOMAIN Keeps failing until TTL timeout or rndc flushname xserv.ins.dell.com. ns11:~ # nslookup -querytype=A xserv.ins.dell.com. ….. Non-authoritative answer: Name: xserv.ins.dell.com Address: 143.166.148.118 Thanks, Patrick -- This e-mail message and any attachments are of a confidential nature. The information is intended for the named addressee exclusively. If you are not the addressee, you may not electronically disseminate, otherwise distribute or copy this e-mail message, and you may also not use it for any purpose. Please notify the sender immediately if you have received this e-mail message by mistake, and delete this e-mail message and its attachments. E-mail transmissions could be lost, intercepted, corrupted or destroyed. They could arrive late or incomplete, or could even contain viruses. Confidentiality and reliability of the information so transmitted cannot be guaranteed. Rothschild Bank therefore does not accept any liability or responsibility for errors or omissions regarding the information transmitted through e-mail. If verification of the information transmitted through e-mail is required, please ask for postal delivery by contacting Rothschild Bank. This e-mail message is provided for information purposes only. It should not be construed as an offer or solicitation to buy or sell any financial instruments or services. It is not to be made available to US persons and is not to be circulated within the USA. ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
RE: AAAA type query invalidates A records in name server cache
Will escalate via our Dell contact. Keep you posted about my success. Regards, Patrick -- This e-mail message and any attachments are of a confidential nature. The information is intended for the named addressee exclusively. If you are not the addressee, you may not electronically disseminate, otherwise distribute or copy this e-mail message, and you may also not use it for any purpose. Please notify the sender immediately if you have received this e-mail message by mistake, and delete this e-mail message and its attachments. E-mail transmissions could be lost, intercepted, corrupted or destroyed. They could arrive late or incomplete, or could even contain viruses. Confidentiality and reliability of the information so transmitted cannot be guaranteed. Rothschild Bank therefore does not accept any liability or responsibility for errors or omissions regarding the information transmitted through e-mail. If verification of the information transmitted through e-mail is required, please ask for postal delivery by contacting Rothschild Bank.. This e-mail message is provided for information purposes only. It should not be construed as an offer or solicitation to buy or sell any financial instruments or services. It is not to be made available to US persons and is not to be circulated within the USA. ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: sort list and view
On 7/18/2011 11:42 PM, AMANI MOHAMED BIN SUWAIF wrote:
Hi,
I have the below scenario
_TCP.EXAMPLE.COMIN SRV1005060primary-sbg.example.com
_TCP.EXAMPLE.COMIN SRV2005060
secondary-sbg.example.com
I have 2 IP ranges and 2 SBGs host, my intention is
for client in IP range1
primary-sbg INA1.1.1.1
secondary-sbgINA2.2.2.2
for client in IP range2
primary-sbg INA2.2.2.2
secondary-sbgINA1.1.1.1
can this be achieved without using a views?
I thought this can be solved just by a sortlist, where
primary-sbgINA1.1.1.1
primary-sbgINA2.2.2.2
secondary-sbgINA2.2.2.2
secondary-sbgINA1.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)RANGEPRIMARY(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
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
from this list
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Re: sort list and view
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.COMIN SRV1005060primary-sbg.example.com
_TCP.EXAMPLE.COMIN SRV2005060
secondary-sbg.example.com
I have 2 IP ranges and 2 SBGs host, my intention is
for client in IP range1
primary-sbg INA1.1.1.1
secondary-sbgINA2.2.2.2
for client in IP range2
primary-sbg INA2.2.2.2
secondary-sbgINA1.1.1.1
can this be achieved without using a views?
I thought this can be solved just by a sortlist, where
primary-sbgINA1.1.1.1
primary-sbgINA2.2.2.2
secondary-sbgINA2.2.2.2
secondary-sbgINA1.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)RANGEPRIMARY(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
___
Please visithttps://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
from this list
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
from this list
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
