[Unbound-users] Resolving of some special host very slow

[Wouter Wijngaards]

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

Hi,

On 03/06/2014 02:31 PM, lst_hoe02 at kwsoft.de wrote:
> 
> Zitat von staticsafe <me at staticsafe.ca>:
> 
>> On 3/5/2014 08:24, lst_hoe02 at kwsoft.de wrote:
>>> 
>>> Hello,
>>> 
>>> today we discovered a hostname which is very slow to resolv
>>> with Unbound 1.4.21 as validating resolver. It works fine with
>>> all knid of other resolvers and oddly enough even with another
>>> Unbound instance. The host in question is esta.cbp.dhs.gov and
>>> resolve time after it is not in the cache range from around 2
>>> to 5 seconds. I have take a tcpdump and can only see that the
>>> first answer come much faster but Unbound keeps asking for the
>>> same A record on different nameservers again and again.
>>> 
>>> Any idea what is going wrong?

The zone is not signed, but it is hosted on the same servers that also
host its parent zone, which is signed.  Unbound is searching for
dnssec information.  Then it does not find it.  Then it tries to build
a chain of trust and finds the nsec3optout and then you get the answer.

Apart from a lot of traffic to those servers, as it is trying all of
them for every query, it should actually work fairly fast.  Are these
servers somehow blocking access to you (with timeouts) ?

Since the servers are all responsive (for me, from an IETF address),
and in total the resolution is very fast (not near 5-10 sec), I think
something else is going one.  This could have been triggered by the
extra traffic that unbound sends towards those servers because it is
trying to find out the co-hosted-parent problem as well as an optout
that happens while it did not see the optout-referral.

Looking for workarounds, try domain-insecure for cbp.dhs.gov.

Best regards,
   Wouter

>>> 
>>> Thanks
>>> 
>>> Andreas
>> 
>> Noticing the same issue:
>> 
>> [root at lasciel system]# time dig esta.cbp.dhs.gov @::1
>> 
>> ; <<>> DiG 9.9.2-P2 <<>> esta.cbp.dhs.gov @::1 ;; global options:
>> +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status:
>> NOERROR, id: 33583 ;; flags: qr rd ra; QUERY: 1, ANSWER: 1,
>> AUTHORITY: 0, ADDITIONAL: 1
>> 
>> ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4096 ;;
>> QUESTION SECTION: ;esta.cbp.dhs.gov.              IN      A
>> 
>> ;; ANSWER SECTION: esta.cbp.dhs.gov.       900     IN      A
>> 216.81.87.20
>> 
>> ;; Query time: 2097 msec ;; SERVER: ::1#53(::1) ;; WHEN: Wed Mar
>> 5 12:42:40 2014 ;; MSG SIZE  rcvd: 61
>> 
>> 
>> real    0m12.201s user    0m0.060s sys     0m0.010s
>> 
>> [root at ferrovax ~]# time dig esta.cbp.dhs.gov
>> 
>> ; <<>> DiG 9.9.5 <<>> esta.cbp.dhs.gov ;; global options: +cmd ;;
>> Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id:
>> 14872 ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 8,
>> ADDITIONAL: 1
>> 
>> ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4096 ;;
>> QUESTION SECTION: ;esta.cbp.dhs.gov.              IN      A
>> 
>> ;; ANSWER SECTION: esta.cbp.dhs.gov.       900     IN      A
>> 216.81.87.20
>> 
>> ;; AUTHORITY SECTION: dhs.gov.                86398   IN      NS
>> use1.akam.net. dhs.gov.                86398   IN      NS
>> use3.akam.net. dhs.gov.                86398   IN      NS
>> usw4.akam.net. dhs.gov.                86398   IN      NS
>> asia2.akam.net. dhs.gov.                86398   IN      NS
>> eur2.akam.net. dhs.gov.                86398   IN      NS
>> usc2.akam.net. dhs.gov.                86398   IN      NS
>> usw3.akam.net. dhs.gov.                86398   IN      NS
>> asia3.akam.net.
>> 
>> ;; Query time: 2406 msec ;; SERVER: ::1#53(::1) ;; WHEN: Wed Mar
>> 05 17:43:57 UTC 2014 ;; MSG SIZE  rcvd: 223
>> 
>> 
>> real    0m2.519s user    0m0.009s sys     0m0.103s
>> 
>> First one is against an unbound instance, second is against a
>> BIND instance.
>> 
>> Perhaps one of the authoritative NSes are slow to respond for
>> whatever reason?
> 
> These are the values we got on the second (faster) Unbound
> instance. On the primary we have > 4 seconds which lead to timeout
> on the downstream resolver, so the host is not accessible from time
> to time :-( It would be nice to know if we have any chance to get
> this fixed by excluding some NS or pin something in the cache,
> because i doubt they will fix whatever might be on theri side.
> 
> Regards
> 
> Andreas
> 
> 
> 
> _______________________________________________ Unbound-users
> mailing list Unbound-users at unbound.net 
> http://unbound.nlnetlabs.nl/mailman/listinfo/unbound-users
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQIcBAEBAgAGBQJTGLXZAAoJEJ9vHC1+BF+N+TQQAIY8gTtehOMHNTCKLJFZjCNV
Dq7FfXzZ0fRctE1mCeSgc+xvt8CWRMzqgrNtVsjd0oaqPLvK62H2+VoVyZRbculT
7j3zvMZ5N/VTZwDVRnyXOaJ8UKnP6hIeffYRA37yO7AYeSPH9hGxqtTet46kpFPR
a+QgD5eQi3LOwNGRpMeMsOsv59bCdLXaVdHafj5H2rXpmWzaNkmnop/Y2FXo4jM6
T5OyllmYpPFbG7KAF8MH9aPz0SU1eeOVzypzkTppfPqGu+A9orcrnSeC64HQsEPq
Zlh9cLieZf/iHRN515QBpEUod3lXc/Uv3L7FhKcUPF/N5CGFDSHxF0M0dfu3zWSQ
BNKRb7OmZwbKH69aVqZflElJmsVD86fKow4aDx/rRiG5M2dbG22HUB49hLkNFT01
sunqGRz1INW7X+JPQQhD7oSvlulD3NHjQIKbdPXdFo9EoN8CUqD1eTTDGA8MGnxE
WY0420ZiPDJsztqPodIUkMe4x7eJ92UjWCBpefZj/tMsPVjUXEjDJo3Jkt9b63Gi
liUWwHT8Gio9zqQoAMd2BtJyTUU8TQP1jZYWsCuyEF9X87umVPpt7vxlLDZ8PJo1
5AGr1SMeZ/U4qQ6YuTFzM9SJ5bPKiEDw5tL1/jVR0/Ghiym1FZUqd7G/6GXMeixL
nST8OfoETTteDBK7SmmZ
=hRN5
-----END PGP SIGNATURE-----