Skip to main content
A
Anonymous
September 24, 2015
Answered

Trouble downloading Adobe Air

  • September 24, 2015
  • 1 reply
  • 1547 views

We are having trouble downloading Adobe Air from the link on the Adobe home page.  The link goes to "http://airdownload.adobe.com/air/win/download/19.0/AdobeAIRInstaller.exe".  When our Bind DNS server looks up airdownload.adobe.com, it gets a CNAME "airdownload.wip4.adobe.com.".  When it looks this up, it gets a CNAME "airdownload.adobe.com.edgesuite.net.wip4.adobe.com."  I believe this should be "airdownload.adobe.com.edgesuite.net.".  It looks like the server is returning a relative domain name, so the name of the zone "wip4.adobe.com" is being added to the end of the CNAME.  DNS resolution for help.adobe.com is also not working from our DNS servers.  I get a different response if I query airdownload.adobe.com from a different IP address.  I think there may be a misconfiguration with the dynamic DNS setup for airdownload.wip4.adobe.com.  I have packet captures showing the query for airdownload.wip4.adobe.com and the response from one of the authoritative DNS servers for wip4.adobe.com if I can get somebody to take a look at it.

    This topic has been closed for replies.
    Correct answer

    We found the cause of the DNS issue we were experiencing.  Some DNS resource records in adobe.com have CNAMES in the wip4.adobe.com domain (airdownload.wip4.adobe.com, help.wip4.adobe.com, and download.adobe.com are the ones I know of).  The nameservers for this domain (du1gtm001.adobe.com, da1gtm001.adobe.com, and sj1gtm001.adobe.com) don't seem to handle EDNS options they are not expecting in DNS queries.  We recently upgraded our caching nameservers to Bind 9.10.x, and this introduced a new EDNS option called "Source Identity Token" or SIT.  If you are using Bind 9.10, you can test this by running these two queries from your nameserver:

    This query will fail if you have a recent version of Bind:

    dig +sit @sj1gtm001.adobe.com. airdownload.wip4.adobe.com.

    This query should work:

    dig +nosit @sj1gtm001.adobe.com. airdownload.wip4.adobe.com.

    This appears to be an issue with the nameservers for wip4.adobe.com.  As a workaround, we disabled SIT globally on our nameservers by adding the following to the "options" section in named.conf:

    request-sit no;

    Here are a couple of links to a discussionson the bind-users list about this issue that led me to this workaround:

    problem resolving ardownload.adobe.com --enable-sit harmful?

    R: Question about swupdl.adobe.com‌

    This last link suggested a different workaround by disabling SIT for each affected nameserver, but there are a small number of other nameservers with similar issues:

    server 192.150.16.247 { request-sit no; };

    server 192.150.19.247 { request-sit no; };

    server 193.104.215.247 { request-sit no; };

    1 reply

    M
    meedja
    Participant
    October 2, 2015

    I have the same issue.

    Running an installer that requires air fails with the message

    'This application requires a version of Adobe Air which cannot be found. Please download the latest version of the runtime from http://www.adobe.com/go/getair or contact the application author for an updated version'

    Navigating to the specified URL and clicking the 'download now' button attempts to load this file;

    http://airdownload.adobe.com/air/win/download/19.0/AdobeAIRInstaller.exe

    But fails with the following browser error;

    Hmm, we can’t reach this page.

    Try this

    Effectively, Air runtime is inaccessible?

    Can this be resolved???

    A
    Anonymous
    Correct answer
    October 2, 2015

    We found the cause of the DNS issue we were experiencing.  Some DNS resource records in adobe.com have CNAMES in the wip4.adobe.com domain (airdownload.wip4.adobe.com, help.wip4.adobe.com, and download.adobe.com are the ones I know of).  The nameservers for this domain (du1gtm001.adobe.com, da1gtm001.adobe.com, and sj1gtm001.adobe.com) don't seem to handle EDNS options they are not expecting in DNS queries.  We recently upgraded our caching nameservers to Bind 9.10.x, and this introduced a new EDNS option called "Source Identity Token" or SIT.  If you are using Bind 9.10, you can test this by running these two queries from your nameserver:

    This query will fail if you have a recent version of Bind:

    dig +sit @sj1gtm001.adobe.com. airdownload.wip4.adobe.com.

    This query should work:

    dig +nosit @sj1gtm001.adobe.com. airdownload.wip4.adobe.com.

    This appears to be an issue with the nameservers for wip4.adobe.com.  As a workaround, we disabled SIT globally on our nameservers by adding the following to the "options" section in named.conf:

    request-sit no;

    Here are a couple of links to a discussionson the bind-users list about this issue that led me to this workaround:

    problem resolving ardownload.adobe.com --enable-sit harmful?

    R: Question about swupdl.adobe.com‌

    This last link suggested a different workaround by disabling SIT for each affected nameserver, but there are a small number of other nameservers with similar issues:

    server 192.150.16.247 { request-sit no; };

    server 192.150.19.247 { request-sit no; };

    server 193.104.215.247 { request-sit no; };

    Terms & ConditionsAccessibility statement
    Using the community Terms of use Privacy Cookie preferences Do not sell or share my personal information ad choicesAdChoices