Re: Anycast DNS - LB/LTM

2012-03-10 Thread David Klein
Exactly. The script runs inside the LTM, and wraps "nslookup" or "dig". It
should output a distinct output for success, and another distinct output
for failure. It should only check the pool members, not the VIPA itself. If
the pool is empty, the LTM will stop advertise the VIPA.


 -DTK


On Fri, Mar 9, 2012 at 1:16 PM, ju wusuo  wrote:

> so the script would run on the LTM, it will periodically check each
> physical DNS node, if one cannot resolve then takes it out of the pool; it
> will also check the VIP, if the VIP cannot resolve, pool is empty or LTM
> issue, stop the advertising?
>
>   --
> *From:* David Klein 
> *To:* ju wusuo 
> *Cc:* "bind-users@lists.isc.org" 
> *Sent:* Wednesday, March 7, 2012 11:18 PM
> *Subject:* Re: Anycast DNS
>
>
> You would need to create a custom script to use as your monitor, which
> does a lookup of an address that you know will always be in your domain. If
> that fails, force-down/inactive the node, and tie this script as a monitor
> to the pool holding the DNS server nodes.
>
> You can advertise the /32 containing the VIPA to the up-stream router via
> either OSPF or IBGP, and if the pool goes empty, stop advertising the route
> (the only option is stop advertising, not actively withdraw the route,
> since that could cause a massive reconvergence cycle in your
> enterprise-wide RIB, if done wrong, just because of a flapping interface).
>
>
>
> HTH,
>
>  -DTK
>
>
> On Wed, Mar 7, 2012 at 2:34 PM, ju wusuo  wrote:
>
>
> thanks everyone for all responses with the great inputs ..
>
> now if I want to put the DNS servers behind LBs, 1) would the LTMs be able
> to announce the routes dynamically for the DNS servers, and a VIP can be
> withdrawn when the site is gone? 2) would the LTMs be able to detect a DNS
> service failure and stop sending over DNS queries, i.e., in the case a
> named is still up but just not able to resolve names (assuming LTM can
> detect a named is down)?
>
>
> ___
> 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
>
>
>
>
> --
>
> david t. klein
>
> Cisco Certified Network Associate (CSCO11281885)
> Linux Professional Institute Certification (LPI000165615)
> Redhat Certified Engineer (805009745938860)
>
> Quis custodiet ipsos custodes?
>
>
>
>
>
>


-- 

david t. klein

Cisco Certified Network Associate (CSCO11281885)
Linux Professional Institute Certification (LPI000165615)
Redhat Certified Engineer (805009745938860)

Quis custodiet ipsos custodes?
___
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: dig -t txt output variation

2012-03-10 Thread Kevin Darcy

On 3/9/2012 5:42 PM, Mark Andrews wrote:

In message, "M. Meadows" writes:

We've noticed that the following command gets a variable result:

dig -t txt exacttarget.com @ns2.exacttarget.com +short

We get 2 results from this. Seems to be somewhat random. They are:

"v=3Dspf1 a mx ip4:207.250.79.101 ip4:207.67.98.192/27 ip4:72.18.216.98 inc=
lude:cust-spf.exacttarget.com include:salesforce.com include:message1-spf-i=
nc.exacttarget.com include:hotels-spf-inc.exacttarget.com ip4:206.246.157.1=
  -all"
"spf2.0/pra ip4:207.250.79.101 ip4:207.67.98.192/27 ip4:72.18.216.98 includ=
e:cust-senderid.exacttarget.com include:salesforce.com include:message1-sen=
derid-inc.exacttarget.com include:hotels-senderid-inc.exacttarget.com ip4:2=
06.246.157.1 -all"


And=20

"spf2.0/pra ip4:207.250.79.101 ip4:207.67.98.192/27 ip4:72.18.216.98 includ=
e:cust-senderid.exacttarget.com include:salesforce.com include:message1-sen=
derid-inc.exacttarget.com include:hotels-senderid-inc.exacttarget.com ip4:2=
06.246.157.1 -all"
"v=3Dspf1 a mx ip4:207.250.79.101 ip4:207.67.98.192/27 ip4:72.18.216.98 inc=
lude:cust-spf.exacttarget.com include:salesforce.com include:message1-spf-i=
nc.exacttarget.com include:hotels-spf-inc.exacttarget.com ip4:206.246.157.1=
  -all"


So ... the text output flips. Sometimes the spf1 entry is first ... sometim=
es it's second.

We are aware of at least one application that sees the spf2.0 (if it's firs=
t) and returns a neutral result for SPF testing. If the spf1 is first in th=
e feedback it gets a pass for SPF.=20

The application is broken.
True, and the breakage goes very deep indeed. "spf2.0" isn't SPF at all; 
it's Sender ID, a very different animal from SPF. See 
http://www.openspf.org/SPF_vs_Sender_ID




- 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