[Unbound-users] No failover in stub-zone?

[W.C.A. Wijngaards]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi Andreas,

On 07/10/2012 01:02 PM, lst_hoe02 at kwsoft.de wrote:
> 
> Zitat von "W.C.A. Wijngaards" <wouter at nlnetlabs.nl>:
> 
>> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
>> 
>> Hi Andreas,
>> 
>> On 07/09/2012 10:52 PM, lst_hoe02 at kwsoft.de wrote:
>>> Hello
>>> 
>>> we have on our border dns recursor (unbound 1.4.17) some 
>>> stub-zones mostly for PTR lookups for our internal AS112
>>> addresses like this:
>>> 
>>> stub-zone: name: "10.in-addr.arpa" stub-addr: 
>>> <IP-first-internal-NS> stub-addr: <IP-second-internal-NS>
>> 
>> unbound will divide the load amongst the addresses. It will
>> randomise with RTT banding.
>> 
>>> Today the first internal NS went down and most reverse lookups
>>> slow to crawl. I expexted unbound would notice the failure and
>>> simply only use the second after some time like it did with
>>> normal lookups when skipping unavailable NS.
>>> 
>>> Is this expected behaviour or have i done something wrong?
>> 
>> The second server also fails?
>> 
>> Unbound should try both servers (randomly if they are working,
>> for 50% load on both of them).
>> 
> 
> No, the second was available, and yes it looks like Unbound was 
> balancing because some lookups where fast and some timeout. As far
> as i know Unbound does skip unresponsive servers when doing
> "normal" lookups (no stub-zones) and i suspected Unbound doing the
> same for the stub-zone servers. Might this be possible as a feature
> in the future? I think the same rules should apply for stub-zones
> as for all lookups, no?

This is the way it is implemented today.  Unbound can failover for
stub-zones (and forward-zones) if nameservers do not respond and stops
asking if they are down.

Best regards,
   Wouter

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQIcBAEBAgAGBQJP/BKYAAoJEJ9vHC1+BF+NrMoP/0ylSjGtlgI0dH2XsqTMiiEN
t80Bs/1bsScEN1XlfVBg2dTp/wo0STygXxf11p0eKw7RnEsq2YiS2yOeXVv+uN3s
dIEwuWs1eqgdZkgnSBj2AdlULtVLQ5ab6DkKaGXxJbl8hwMljxf8xOUzINZTbVJU
RoCofLpVAFB+rfOZpzqa5Pmb3BtKMyAg6ZnWCqIPLSH5aBgO2VzX2oWB9sybRq6c
77D2qp78P8EvMyXY6V30+KtxHcdc0TRDQzFT3ilyTWYMpRtYEeK2Lwb0oQZjQtGZ
WxEPGwnSJ8VcHA5uVeYOLXUWX49OvTUvHyrt+qmsThaCA/3nzUkgMBEuEluEyb1M
xeCRor4M+2BrG4xsDuE8JzaLpYenzwyWUkwm3r4dQaDzOjgw+MtRP7Tn2NSQenci
2k9yZHwlIbxiZM58XhmjYZip/McyAQbt1PLhKtxuM0XTbOMdzzY5OGkGLE1Sj92E
rAyGr/CL7/pOUL/OKo2Mxj9e2RDQPA1ZZoFRaKmv27IBd8xhnhzLhJpv+gyPrRTS
gyfsKpLh3mLiXMw7v5CuS7iagHbEMgivLmtrVSbRkhwcA+AugVjZo+f3n/hYjf3j
xaLWIcFx3Wrf0/YcKRHzi1bga2FL595exKjOCSjVGFvdMYh/ie4y1KCtEY5DjuY1
1SHUm16gGMbfOmyFaDf+
=qm5c
-----END PGP SIGNATURE-----