when youtube-dl sends too many dns request to find video quality, dns server blocks the host running youtube-dl temporarily

[ghost]

The issue at hand is that when youtube-dl is trying more than one quality paramter on its own, it keeps making DNS-requests, because those requests became too many in a short span of time, the host running youtube-dl gets any DNS requests from it blocked.
please look into it.

Please follow the guide below

• You will be asked some questions and requested to provide some information, please read them carefully and answer honestly
• Put an x into all the boxes [ ] relevant to your issue (like that [x])
• Use Preview tab to see how your issue will actually look like

---

Make sure you are using the latest version: run youtube-dl --version and ensure your version is 2017.07.23. If it's not read this FAQ entry and update. Issues with outdated version will be rejected.

• I've verified and I assure that I'm running youtube-dl 2017.07.23

Before submitting an issue make sure you have:

• At least skimmed through README and most notably FAQ and BUGS sections
• Searched the bugtracker for similar issues including closed ones

What is the purpose of your issue?

• Bug report (encountered problems with youtube-dl)
• Site support request (request for adding support for a new site)
• Feature request (request for a new functionality)
• Question
• Other

---

The following sections concretize particular purposed issues, you can erase any section (the contents between triple ---) not applicable to your issue

---

If the purpose of this issue is a bug report, site support request or you are not completely sure provide the full verbose output as follows:

Add -v flag to your command line you run youtube-dl with, copy the whole output and insert it here. It should look similar to one below (replace it with your log inserted between triple ```):

$ youtube-dl -v <your command line>
[debug] System config: []
[debug] User config: []
[debug] Command-line args: [u'-v', u'http://www.youtube.com/watch?v=BaW_jenozKcj']
[debug] Encodings: locale cp1251, fs mbcs, out cp866, pref cp1251
[debug] youtube-dl version 2017.07.23
[debug] Python version 2.7.11 - Windows-2003Server-5.2.3790-SP2
[debug] exe versions: ffmpeg N-75573-g1d0487f, ffprobe N-75573-g1d0487f, rtmpdump 2.4
[debug] Proxy map: {}
...
<end of log>

---

If the purpose of this issue is a site support request please provide all kinds of example URLs support for which should be included (replace following example URLs by yours):

• Single video: https://www.youtube.com/watch?v=BaW_jenozKc
• Single video: https://youtu.be/BaW_jenozKc
• Playlist: https://www.youtube.com/playlist?list=PL4lCao7KL_QFVb7Iudeipvc2BCavECqzc

Note that youtube-dl does not support sites dedicated to copyright infringement. In order for site support request to be accepted all provided example URLs should not violate any copyrights.

---

Description of your issue, suggested solution and other information

Explanation of your issue in arbitrary form goes here. Please make sure the description is worded well enough to be understood. Provide as much context and examples as possible.
If work on your issue requires account credentials please provide them or explain how one can obtain them.

[yan12125]

Which URL are you trying to download? Please paste a verbose log.

[ghost]

its not the URL i'm trying to download that is blocking me, it is my DNS server that blocks me when there are too many DNS requests happening when youtube-dl is running and trying to guess a quality for the video its downloading.

[dstftw]

Fix your DNS server obviously. youtube-dl is not any different from any other software in making DNS requests.

[ghost]

is it possible to make youtube-dl retain the answers for the DNS queries it makes for a short period of time 4 to 10 seconds?
I have no permission/control over my DNS server

[yan12125]

retain the answers for the DNS queries it makes for a short period

That's a system-level work, where upper applications like youtube-dl or even Python can't do much.

By the way, you may want to check out my proof-of-concept patch yan12125@0cdc798 that adds an option --dns-servers. You can then choose a caching DNS server like dnsmasq or an external normal DNS server.

[remitamine]

a better solution would be to add support for HTTP persistent connection(HTTP keep-alive), it would help to improve performance in general and mostly for http/https fragment downloading.

[yan12125]

Persistent HTTP sounds better, but seems it's not going to be implemented in CPython in near future (http://bugs.python.org/issue9740)

[remitamine]

but seems it's not going to be implemented in CPython in near future (http://bugs.python.org/issue9740)

requests does supports HTTP persistent connection using the urllib3 Connection pooling, so it's possible to add support without depending on CPython implementation.

[yan12125]

That's a great suggestion. However, the culture in youtube-dl is reducing external dependencies unless there's a BIG problem. I vote for changing it if there's going to be a discussion.

[remitamine]

However, the culture in youtube-dl is reducing external dependencies unless there's a BIG problem. I vote for changing it if there's going to be a discussion.

it doesn't have to be a hard dependency, it can be used as an optional dependecy by creating a wrapper that will use urllib3 if it's available and fallback to urllib/urllib2(like what's been done with pycrypto).

[yan12125]

I'm afraid that co-existing of two backends would make codes extremely complicated and unreadable. If it turns out that switching between urllib/urllib2 and urllib3 is easy (ex: without numerous function wrappers), that would be a good choice.

[remitamine]

there is actually an old approche compatible with urllib/urllib2 by using a diffrent handler, but as the code is old, so it might require to be updated, it was used by urlgrabber before switching to pycurl(https://stackoverflow.com/questions/1037406/python-urllib2-with-keep-alive).
no sure about the compatibilty between public domain and LGPL.

[yan12125]

IMO it's better to use mature libraries like requests/urllib3 instead of importing rarely tested codes from random places. Also, using only urllib3 is better than supporting two backends. I hope the culture here can change one day.

About the license issue:

1. IIRC LGPL codes can't be used in public domain projects
2. Depending on libraries with incompatible licenses is never a problem. The whole code base remains public domain. In released binaries, only youtube-dl.exe bundles external dependencies, and it's already not pure public domain as it contains Python runtime. Adding LGPL files does not make things worse.