Your IP:

Our Forums Have Moved!

Visit our new forums at https://community.opendns.com/forums/ to post on topics and read the latest content. These forums are now read-only archives.

K-12 Forums

Talk with other K-12 network administrators in your state.

Or see all states.

Categories

Vanilla 1.1.4 is a product of Lussumo. More Information: Documentation, Community Support.

This discussion has been inactive for longer than 30 days, and is thus closed.
    • CommentAuthorHomeNet
    • CommentTimeJun 10th 2010 edited
     permalink
    My OpenDNS shortcuts used to work on both my desktop and laptop with IE7. Now, all of a sudden they don't work because IE now is adding "http://" in front of the shortcut name.

    For instance, I'll type "star" to take me to the Toronto Star site, which always worked before. IE then adds "http://" and it ends up as "http://star/" in the address bar, which of course causes me to end up with the famous "Internet Explorer cannot display the webpage" error.

    I've been trying to find info on how to disable this feature, either via the registry or IE option settings, but am having no luck. It must've been added in an IE patch or update, because everything was working without a hitch before and it's happening on both of my computers. Anyone have any ideas?
    • CommentAuthorRed Prince
    • CommentTimeJun 10th 2010
     permalink
    It makes no difference to OpenDNS because DNS does not see the protocol the browser intends to use.
    • CommentAuthorrotblitz
    • CommentTimeJun 10th 2010
     permalink
    Check and compare these settings: http://www.opendns.com/support/article/121
    Also, Tools > Internet Options > Advanced
    Search from the Address bar: Just display the results in the main window.
    • CommentAuthorHomeNet
    • CommentTimeJun 10th 2010 edited
     permalink
    Hey, thanks for the replies.

    Red Prince: I realize it's not an issue with OpenDNS, but with IE itself. It automatically places "http://" in front of the shortcut name after clicking the GO button, making IE think it's an incomplete URL, which of course then causes an error. I'm trying to find a way to disable/prevent IE from doing that.

    rotblitz: Yes, I tried that and all the other knowledge base advice I could pull up. Remember, though, it was working before on both machines and I haven't changed anything on either machine since.
    • CommentAuthorrotblitz
    • CommentTimeJun 10th 2010 edited
     permalink
    "I haven't changed anything on either machine since."

    This doesn't prove anything. Not the user, but Windows itself is the main modifier all the time. It can be far quicker and more efficient than a human...
    If you don't believe me, simply run RegMon and FileMon from SysInternals for a few minutes, and you will be freaking out...
    You will never ever even be able to follow the changes by reading quickly through them!
    • CommentAuthorHomeNet
    • CommentTimeJun 10th 2010 edited
     permalink
    Heh heh, yeah I've seen RegMon in action. It is truly awe inspiring.

    I mentioned that I didn't change anything in order to get across that all IE settings were still set as recommended by all OpenDNS support documentation, as they were before when it was working. I'm convinced something was altered by a Windows or IE update patch, as I mentioned. Shouldn't there be a registry setting or something where I can elect to NOT have the http:// prefix supplied automatically? There's this regkey HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\URL\DefaultPrefix, but removing the http:// only causes another error.
    • CommentAuthorrotblitz
    • CommentTimeJun 10th 2010 edited
     permalink
    I'm not sure if *this* is the reg key for auto-completion in IE.
    Whatever, try with an empty string to see if it works.
    Ah, btw, I do not recall what browser, but I also get the shortcuts occasionally expanded to "http://shortcut/" - but the shortcuts work nevertheless.

    Also, did you check the option "Apply my shortcuts to this network"?
    https://www.opendns.com/dashboard/settings/0/advanced
    • CommentAuthorverdy_p
    • CommentTimeJun 10th 2010 edited
     permalink
    This is ridiculous : for a shortcut name to cause OpenDNS to display the associated site that your configured, it has to be transformed in an URL, which MUST at some given time determine the applicable protocol. Adding the HTTP protocol specifier comes only from the default, not adding it would not bring to any workable URL, and your shortcuts would not even work.

    You may configure IE so that shortcut keywords will be transformed in another way than implying the HTTP protocol. Notably you can configure it so that it will use a default search engine, where the keyword your typed will be submitted.

    This search engine is not necessarily online, it may be within a local search engine, or within a toolbar addon. My opinion is that the simplest and safest option is to just append http:// and nothing else.

    By doing so, your keyword will be interepreted as a hostname to resolve, and if you have configured correctly your DNS to OpenDSN servers, the OpenDSN servers will see your hostname resolution request and, according to your source IP, will identify you and will look for the shortcuts you have configured in your OpenDNS account.

    If the shortcut with the "http://" prefix is not made explicitly visible, it does not mean that the browser does not use it. If it connects you to somewhere, your shortcut will have been converted into a valid URL anyway, with some protocol.

    And if the HTTP protocol is effectively used, there is necessarily a default non-empty path added with it (the last slash appended after your keyword), because the HTTP protocol REQUIRES a non-empty path (it cannot work without it : see the standard RFC's ; the RFC that describes the "http:" URI-scheme, as well as the "https:", "ftp:", "ftps:" and "file:" URI-schemes, explicitly says that if the required path is missing/empty, the default path to use MUST be "/" without any extra suffix).

    If you no longer get the site that you had associated with your shortcut keyword in your OpenDNS account, it is most likely that:

    - (1) either your PC (or internet router) is NOT configured to use OpenDNS but instead the DNS servers of your ISP (that cannot and should not resolve this keyword as a hostname) : this is a problem in your network installation (TCP/IP parameters for the IP addresses of DNS servers). Most likely, you have changed these network settings on your PC to use the default DHCP parameters instead of the two addresses documented here, and the DHCP server of your router does not configure your PC with the IP addresses of OpenDNS DNS servers ; possibly your DSL/cable router was reconfigured by your ISP so that the router will forward your DNS requests to the DNS servers of your ISP instead of those of OpenDNS;

    - (2) or your public IP address on the Internet is not recognized by the DNS servers of OpenDNS in a way that allows it to access to your own preferences where the shortcuts are configured, and so there's no valid domain name or URL to associate to the shortcut keyword: most likely the OpenDNS updater application is not running in your system taskbar, and OpenDNS has not received any authenticated confirmation of your public IP since too long.

    In other words: check your PC and network installation. OpenDNS is clearly not the source of your installation problem. And the browser installation or windows update is also not the cause of your problem.

    Conclusion: IE (or any other browser) does NOT break any OpenDNS shortcut if it converts your keyword into a valid HTTP URL where the keyword is used as the hostname. This is completely standard and expected, and this is exactly the way that OpenDNS support these keyword shortcuts.
    • CommentAuthorHomeNet
    • CommentTimeJun 10th 2010
     permalink
    rotblitz: No go with the empty string. "Apply my shortcuts to this network" is checked. All other settings are as they should be according to OpenDNS documentation. I'm also running the OpenDNS updater which indicates all is well and always shows the most current IP address. You mentioned a browser where this same thing happened but the shortcuts opened anyway...? Hmmm, well it was only a theory that the issue was being caused by the "http://" prefix being added. Maybe I'm wrong and it's something else(?) But the final URL is always "http://[shortcut name]/" (no .com or .anything else) when the browser throws the error page.
    • CommentAuthorHomeNet
    • CommentTimeJun 10th 2010
     permalink
    verdy: Not sure how to respond to your reply. What is ridiculous? This issue? Or my theory as to why?
    • CommentAuthorverdy_p
    • CommentTimeJun 10th 2010
     permalink
    @HomeNet: your theory about the "http://" prefix (which IS really expected here and NOT the cause of your problem)...

    Reread the 2 final solutions I gave above:

    - Check your router configuration (or if your router cannot be configured, the configuration of TCP/IP on your PC) to make sure that you still use the two I addresses for the DNS servers operated by OpenDNS,

    - and if the OpenDNS updater application is running on your Windows, notably if your public IP address is dynamic and not fixed (you may have removed this helper application from autostart, if so your IP will not be authenticated as yours, and OpenDNS cannot resolve your private shortcuts and will just use the global settins to display its search guide for your keywords). If you don't use the helper application, you will need to vicit this site and authenticate on it to update the status of your current IP address and reassociate it with your OpenDNS account for a while.
    • CommentAuthorverdy_p
    • CommentTimeJun 10th 2010
     permalink
    To diagnose if your network configuration is OK, there's a topic explaining this:

    With your browser, visit: http://welcome.opendns.com/

    If you are using OpenDNS DNS servers, the DNS lookup response is:
    Name: www.opendns.com
    Address: 208.67.219.101
    Aliases: welcome.opendns.com

    whereas, if you are not using the OpenDNS servers, then the response is:
    Name: www.opendns.com
    Address: 208.67.219.99
    Aliases: welcome.opendns.com

    So, in fact, your browser will go to different sites (i.e. distinct IP addresses with distinct webserver despite they match the same domain name, with the same URL using it), depending on whether or not you are using OpenDNS.

    And accordingly, when you reach the site, they redirect you to:

    - either: http://www.opendns.com/welcome/
    (if your network configuration on your PC or router is OK to use the correct DNS servers : your shortcuts configured in your OpenDNS account should then work)

    - or: http://www.opendns.com/welcome/oops
    (if you're using any DNS servers other than those of OpenDNS : your shortcuts will certainly not work at all)

    There's a topic here dedicated to such diagnostic.
    • CommentAuthorverdy_p
    • CommentTimeJun 10th 2010
     permalink
    Note also that there's another network configuration which may cause your shortcuts (simple keywords NOT containing any '.' dot) to not work at all:

    This is when your PC is configured within a domain, and this domain is part of the DNS search path. In this case, all domain names that do not contain any dot will not be resolved with the root domain (the only domain where OpenDNS will attempt to resolve these shortcuts), but within the configured domains in your DNS search path.

    There are also configuration options for the LanMan/CIFS/Netbios resolution of these host names, if you are within a Windows domain (as setup by your enterprise network administrator), which may disable any attempt to resolve these simple names outside of your private domain (in this case, only the domain names within a restricted list of public Internet TLDs approved by your administrator (such as .com, .net, .org, .info, and ccTLDs like .uk) will get resolved by a DNS server on the Internet: this setup is part of Windows group policy and you may not have access to this configuration if you're not a local administrator of your PC or if you are logged on using the user account within your enterprise domain.

    How do you know if you use a private DNS search path ?

    - Start Menu > Run > "cmd" to open a command line window
    - type "nslookup" followed by Enter
    - type "set all" followed by Enter
    you should see a line with "srchlist=" followed by nothing else. If you see some domain name in this line, you have an alternate list of subdomains within which your keywords will be looked up (ask to your network admin about the domains listed there).
    - type Ctrl+D to exit the nslookup prompt, then you can close the cmd window.

    Note that some malwares or adwares or toolbars insert their own domain names in this DNS search path...
    • CommentAuthorHomeNet
    • CommentTimeJun 10th 2010
     permalink
    verdy: Yes, the router is configured to both 208.67.222.222 and 208.67.220.220 and the OpenDNS updater is still listed in MSConfig as a startup program (the box is checked), it's currently running and is showing my current IP Address. Typing in http://welcome.opendns.com/ in the address bar takes me to http://www.opendns.com/welcome/.

    As I've said, everything was working fine a couple of mornings ago and *literally* later that day suddenly not working anymore (or since). I changed nothing in between and did nothing out of the ordinary. It was working on both PC's and then stopped working on both PC's, just a few hours later.
    • CommentAuthorHomeNet
    • CommentTimeJun 10th 2010
     permalink
    verdy: Using the command prompt, I followed your directions. The default server is listed as resolver1.opendns.com, address: 208.67.222.222

    For "srchlist=" it says "no-domain-set.bellcanada" (bellcanada is my ISP).
    • CommentAuthorverdy_p
    • CommentTimeJun 10th 2010
     permalink
    So may be your OpenDNS account is not correctly configured in the helper application, and OpenDNS still does not recognizes the public IP address used by your PC when connected to the Internet, because your IP address updates are failing (account misconfigured ? Open the help application, and check the account settings, and try to reupdate manually, then test your keyword).

    It may happen that:
    - your browser is currently using another account (from its cached form data and cookies) than what you have configured in the OpenDNS helper application,
    - or you have mixed the location configuration between your home and your work, if your PC is mobile or multihomed (using several network interfaces with distinct IP configurations, including when a VPN virtual interface to connect you to your enterprise private network).

    Make sure that the account displayed in your browser when visiting this site matches the account configured in the helper application (which may be publishing and updating the wrong IP address from the wrong network interface)...
    • CommentAuthorverdy_p
    • CommentTimeJun 10th 2010
     permalink
    the DNS searchlist is clearly the cause of your problem : your keywords are currently getting resolved as subdomains within a non-existing domain "no-domain-set.bellcanada".

    So if you have configured "mail" as a shortcut to your favorite webmail, instead of going to the URL that you have configured, it gets resolved as "mail.no-domain-set.bellcanada", which the OpenDNS DNS servers will not resolve as a shortcut.

    You have to clear this search-list, which may in fact be configured via the DHCP server of your router : Bell Canada may have changed the configuration of your router.

    You have to remove this incorrect domain name from the network name of your PC (which should just be a single keyword without any dot, or only a final dot)

    Open the Windows "System" configuration panel, you should see the short name of your PC (used by NetBios and Windows file sharing on your local LAN) and its full name (used on larger networks including the Internet) : both should be equal, the full name should not contain any domain name extension).

    Your PC should be a member of a workgroup, not a member of a Windows domain with a domain name (the DNS suffix should be empty, it is specified in the advanced settings, but that will work only if you have a Windows domain server configured on your LAN running its own DNS server, a.k.a. "Active Directory" in more recent versions of Windows Server).

    If you can, remove this bogous domain name assigned in your router configuration (because it gets advertized to your PC via DHCP) ; or if you still can't do that, disable its embedded DHCP server, or configure your PC to not use this DHCP server, by configuring the PC's TCP/IP settings manually with static addresses.

    I don't know your ISP or the type of router you use or the way Bell Canada configures it for you. So I can't help you more to configure your router.
    • CommentAuthorrotblitz
    • CommentTimeJun 10th 2010 edited
     permalink
    @verdy_p
    Just to eliminate this rumour:
    Using OpenDNS shortcuts is dependent on using OpenDNS for lookups in no way.
    Did you know?

    However, your "web" IP address must be registered with an OpenDNS network to make it work. If you go through the browser specific instructions, they all end up having the OpenDNS Guide ("http://guide.opendns.com/?url=") defined as default for searches from the address bar. That's all!

    If you type a term without dots and dashes in the address bar (shortcut or what else), then it goes to the OpenDNS Guide. This again checks if a related shortcut is defined for your IP address. If yes, it WebHop-redirects to this URL (which can be kind of any protocol valid for that browser: http, https, ftp, ...). If not, the Guide itself offers its service...

    And yes, the DNS suffixes can be really impacting serveral kind of things around DNS and searches from the address bar...
    • CommentAuthorverdy_p
    • CommentTimeJun 10th 2010
     permalink
    @roblitz:
    the OpenDNS shortcuts DO depend on OpenDNS to perform the lookup. They will only work when OpenDNS will resolve this non-existant domain names as "CNAME nxdomain.opendns.com", i.e. as an aliased name of a subdomain of opendns.com.

    They work this way because the webserver running on host "nxdomain.opendns.com" and port 80 will intercept the HTTP requests coming from the browsers trying to get the page at "http://(keyword)/", and because the HTTP protocol will transmit the intended host name, the "(keyword)" as a plain-text part of the HTTP transaction (specified in the "Host:" header just after the "GET / HTTP/1.1" query line)

    Then the webserver on "nxdomain.opendns.com" will see the intended host name (in fact the keyword), and then will return an HTTP response performing a HTTP redirect to the URL that was specified in your user account for this keyword. But this will ONLY work if:

    - (1) and the OpenDNS servers are effectively used to resolve the "(keyword)" host name as "CNAME nxdomain.opendns.com", when the "(keyword)" is not recognized as an existing Internet domain name by these DNS servers operated by OpenDNS.

    - (2) your public IP address is recognized (so it must have been updated recently). Otherwise you'll get the Guide page (if you are still existing OpenDNS as your effective DNS servers)

    So this point (1) contradicts what you say about the "rumour". What you said is true only for the 2nd condition which is relevant ONLY if condition (1) is first met. If condition (1) is not fulfilled, you'll see neither the OpenDNS Guide page, nor the expected target of the user-configured shortcut, even if the helper application is running and updating your IP correctly.

    Visibly, the OpenDNS helper application for Windows does not fully tests if the network configuration is correct : notably here the DNS search list, to see if it contains valid domain names that are fully and recursively managed by a working and accessible DNS server, which should handle itself all DNS requests forwardings itself for all domain names that it does not manage itself. This search list configuration may exist not only on Windows but in *nix/Linux systems as well, because this configuration originates from *nix.

    Visibly you misunderstand how the shortcuts really work and seem to assume that there's some invisible "magic" to transform a keyword (interpreted as an unrelated hostname) into an OpenDNS.com URL, a transform in which the helper application plays absolutely no role: keyword shortcuts can even work without this helper application, as long as your IP is authenticated and updated (you can do this online by visiting the website and logging on it to confirm your IP).

    It is impossible for OpenDNS to capture and reroute your IP traffic to their webservers, OpenDNS cannot reroute this traffic from your ISP, and the basic registration of your IP is not a rerouting configuration order and it does not modify the way your browser or OS performs its HTTP requests. You need more lectures to see how TCP/IP works, how HTTP works, and how URLs are used, transformed and resolved to connect you on some server on the Internet.
    • CommentAuthorrotblitz
    • CommentTimeJun 10th 2010 edited
     permalink
    "the OpenDNS shortcuts DO depend on OpenDNS to perform the lookup."

    No, else I would not be able to use my shortcuts from everywhere, no matter if using OpenDNS for DNS lookups or not. However, the (non-OpenDNS) DNS service you're using *must* return NXDOMAIN to activate the address bar search at all to go to the defined default search engine OpenDNS Guide. When using OpenDNS, you are redirected to the Guide (from hit-nxdomain.opendns.com) without the need to receive an NXDOMAIN. That's the only unimportant difference, but doesn't change the result: your shortcuts taking effect.

    Instead of saying "it does not work" (with far too many words :wink:), simply try it out, and you will find it working. :cool:
    • CommentAuthorverdy_p
    • CommentTimeJun 11th 2010
     permalink
    @roblitz:
    Yes you can use your shortcuts through an URL with a form like "http://guide.opendns.com?url=(keyword)"

    But the true shortcuts that users want is being able to type ONLY the "(keyword)" in the address bar of their browser, and then being redirected to such URL.

    And this depends on either:

    - using OpenDNS as the DNS server (so that it will resolve the "(keyword)" hostname as an alias in the opendns.com instead of returning a NXDOMAIN error to the query performed by the DNS client (it is the server running at "nxdomain.opendns.com" that will return that URL).

    - or: possibly using a plugin in the browser or configuration, instructing it to use opendns as the default search engine (to insert the inexistant host name within the query parameters of a OpenDNS Guide search URL) ; OpenDNS does not distribute such plugin, and the OpenDNS helper application is not doing that (it is completely independant of the type of browser used ; the only role of the OpenDNS helper application is to regularly authenticate your public IP, and update it regularly before the association between this public IP and your user account expires ; you can check the list of plugins in your browser, it is not listed there).

    You'll easily note that the shortcuts can work with any kind of HTTP client (such as "wget http://(keyword)/") and even through a manual implementation of HTTP using TCP, Telnet for example ("telnet (keyword) 80" return; "GET / HTTP/1.1" return; "Host: (keyword)" return twice;)

    You can test it even without performing any TCP session ("nslookup (keyword)" should return an IP address of nxdomain.opendns.com, that you can then use in the Telnet session above, replacing the first (keyword) occurence on the telnet command line by this IP address, or by "nxdomain.opendns.com", emulating this way exactly what the HTTP protocol does).

    But all this is not what users expect from a shortcut : a simple keyword typed in an address bar, and that must be converted into a working URL within the opendns.com domain to perform the conversion of the shortcut into the expected target URL.

    Of course when doing all this, your public IP used when connecting to the opendns web server must have been first registered ; otherwise the nxdomain.opendns.com will not be able to identify you and won't know how to convert your shortcut. May be this webserver could be able to identify you with a browser cookie from any previous use of this redirecting webservice with the same browser on the same machine, even if your public IP was not updated recently; after all it would expose no additional privacy problem (given that you are already identifying yourself, to OpenDNS when updating your IP, but in an very weak way; the cookie authentication method may be more secure to protect your private target URLs from later reuse of your shortcut by someone else reusing your previous public IP address, or if there are several distinct users of the same public IP on your private LAN).
    • CommentAuthorHomeNet
    • CommentTimeJun 11th 2010
     permalink
    Yikes. My head! My head!

    Okay, so I've tried shortcuts with Firefox on both PC's. And the shortcuts work perfectly in Firefox. I switch over to IE...and still the same problem as before. So Firefox: Yes. IE: No. Same results on both machines.

    If it works with FF, should it then not work with IE...? Because this means everything is configured properly, no?
    • CommentAuthorverdy_p
    • CommentTimeJun 11th 2010 edited
     permalink
    Don't you have an installed plugin/toolbar/addon/search assistant in IE which may interfere?
    What happens if you use IE in its "failsafe" mode that disables all plugins?
    • CommentAuthorverdy_p
    • CommentTimeJun 11th 2010 edited
     permalink
    I have found somthing interesting on the OpenDNS DNS server however, when trying to resolve non-existent domains:

    - if you perform a name lookup with type=A+AAAA, or type=A or type=AAAA, the DNS server will correctly return the expected "CNAME hit-nxdomain.opendns.com" record, with a OK error status (in fact already resolved recursively as a IPv4 address), so shortcuts will work (the reply is a "A 67.215.65.132" record, it is non-authoritative as it should, and it has lifetime=0 so it is temporary as it really should, it can only be used immediately by the browser and it will not enter in the local or intermediary DNS client cache and will expire any pre-existing address in this cache).

    - if the name lookup is performed with type=ANY, the DNS server will unexpectedly return a NXDOMAIN error status (not returning the expected IP address and not any other record type), so the shortcut won't resolve at all. May be IE is performin a type=ANY lookup for resolving domain names used in the HTTP/HTTPS protocol (and then IE will sort the various results to find one or several that may be used to resolve the name), where other browsers are performing a type=A+AAAA lookup for these same hostname.

    Why doesn't the OpenDNS return a temporary CNAME record (or at least an A record in the default recursive mode) in both cases ? Here is what I get with nslookup on Windows, with advanced debug mode (set d2), for query type=ANY and type=A+AAAA:

    > set type=A+AAAA
    > site
    Serveur : resolver1.opendns.com
    Address: 208.67.222.222
    ------------
    SendRequest(), len 22
    HEADER:
    opcode = QUERY, id = 7, rcode = NOERROR
    header flags: query, want recursion
    questions = 1, answers = 0, authority records = 0, additional = 0
    QUESTIONS:
    site, type = A, class = IN
    ------------
    Got answer (38 bytes):
    HEADER:
    opcode = QUERY, id = 7, rcode = NOERROR
    header flags: response, want recursion, recursion avail.
    questions = 1, answers = 1, authority records = 0, additional = 0
    QUESTIONS:
    site, type = A, class = IN
    ANSWERS:
    -> site
    type = A, class = IN, dlen = 4
    internet address = 67.215.65.132
    ttl = 0 (0 secs)
    ------------
    Got non authoritative answer:
    SendRequest(), len 22
    HEADER:
    opcode = QUERY, id = 8, rcode = NOERROR
    header flags: query, want recursion
    questions = 1, answers = 0, authority records = 0, additional = 0
    QUESTIONS:
    site, type = AAAA, class = IN
    ------------
    Got answer (22 bytes):
    HEADER:
    opcode = QUERY, id = 8, rcode = NOERROR
    header flags: response, want recursion, recursion avail.
    questions = 1, answers = 0, authority records = 0, additional = 0
    QUESTIONS:
    site, type = AAAA, class = IN
    ------------

    So yes it resolves the unexisting "site" domain name when performing name lookup with type=A+AAAA. However:

    > set type=ANY
    > site
    Serveur : resolver1.opendns.com
    Address: 208.67.222.222
    ------------
    SendRequest(), len 22
    HEADER:
    opcode = QUERY, id = 9, rcode = NOERROR
    header flags: query, want recursion
    questions = 1, answers = 0, authority records = 0, additional = 0
    QUESTIONS:
    site, type = ANY, class = IN
    ------------
    Got answer (22 bytes):
    HEADER:
    opcode = QUERY, id = 9, rcode = NXDOMAIN
    header flags: response, want recursion, recursion avail.
    questions = 1, answers = 0, authority records = 0, additional = 0
    QUESTIONS:
    site, type = ANY, class = IN
    ------------

    This looks inconsistant, as TYPE=ANY should return a superset of the replies returned by more specific type=A or type=AAAA or type=A+AAAA. And visibly, the DNS forgets to return the expected CNAME record here, even when requesting it explicitly with type=CNAME:


    > set type=CNAME
    > site
    Serveur : resolver1.opendns.com
    Address: 208.67.222.222
    ------------
    SendRequest(), len 22
    HEADER:
    opcode = QUERY, id = 10, rcode = NOERROR
    header flags: query, want recursion
    questions = 1, answers = 0, authority records = 0, additional = 0
    QUESTIONS:
    site, type = CNAME, class = IN
    ------------
    Got answer (22 bytes):
    HEADER:
    opcode = QUERY, id = 10, rcode = NXDOMAIN
    header flags: response, want recursion, recursion avail.
    questions = 1, answers = 0, authority records = 0, additional = 0
    QUESTIONS:
    site, type = CNAME, class = IN
    ------------

    And the Windows "ping" tool apparently performs its name lookup with query type=ANY, so it will also fail to resolve shortcuts.

    Something may have changed recently on OpenDNS, because in the past it returned CNAME records and was consistant between query type=ANY and query type=A.
    • CommentAuthorverdy_p
    • CommentTimeJun 11th 2010
     permalink
    And the OpenDNS DNS servers also no longer support the non-recursive lookup requests (we get rcode=REFUSED, even for existing domains and for any query type=A or type=A+AAAA, instead of the expected rcode=NXDOMAIN).
    • CommentAuthorverdy_p
    • CommentTimeJun 11th 2010
     permalink
    And the OpenDNS DNS servers also now truncate from all its positive anwsers the "additional" records (not matching the request directly, but that may be returned for indicating the source of the data: notably the addresses of the source name servers from which the mandatory answers are supposed to come).

    Such truncation of answers also severely reduces the security and reliability of OpenDNS, because its replies can no longer be checked.

    It seems that this was done to reduce the volume of answers returned by its name servers, but this will require clients to perform additional lookups to get the additional records and assert these answers. If the clients do that automatically because they expect these extra records associated to distinct but related domain names, this will in fact increase the traffic on OpenDNS servers, that will have to support more queries, so this type of "optimization" is most probably wrong, and will finally increase the number of roundtrips and the latence for name resolutions, and finally as well the total traffic (in bytes or in number of requests) supported by the DNS server.

    [It's true that a browser will typically not perform such check, as it will just use internally a "gethostsbyname()" call to its local socket API, just to retrieve some IP addresses for use with the HTTP protocol, and for such use, a browser does not need other matching record types such as SOA and MX records, so a simple web browser may effectively try to optimize its DNS traffic by using a more selective type=A+AAAA query, or type=A query on IPv4-only systems, instead of a type=ANY query that will return extra records not absolutely needed by HTTP.]
    • CommentAuthorrotblitz
    • CommentTimeJun 11th 2010 edited
     permalink
    "it is the server running at "nxdomain.opendns.com" that will return that URL"
    There is no domain nxdomain.opendns.com. As I mentioned already above, it is hit-nxdomain.opendns.com. And it does not return an URL, but performs an HTTP redirect to guide.opendns.com.

    "possibly using a plugin in the browser or configuration"
    There is no plug-in, it is pure configuration. I have documented this multiple times here in the forum already.

    "You'll easily note that the shortcuts can work with..." - Yes, I know. I use it.

    "you can then use in the Telnet session above" - No, telnet has no idea of HTTP redirects. You can, however, use it to construct the full command line to possibly spawn a telnet process with all arguments.

    "it has lifetime=0 so it is temporary as it really should" - Yes, I know. This TTL=0 (and other very short TTLs) has occasionally been discussed here. However, there is no common sense about this practice - e.g. it prevents from FastFlux detection!

    "May be IE is performin a type=ANY lookup for resolving domain names"
    No, browsers do not have a reason to perform any other lookups than A and AAAA. Therefore OpenDNS returns NXDOMAIN for any other query types, because no HTTP redirect can take place here. Think especially also about MX, TXT and SPF...

    "Why doesn't the OpenDNS return a temporary CNAME record..."
    You didn't get the point. OpenDNS must return a fake response for browsers (A and AAAA), the queried domain name and a "wrong" IP address (the one of hit-nxdomain.opendns.com) to make the browsers believe they are going to connect to the correct site.

    "TYPE=ANY should return a superset of the replies"
    Most authoritative nameservers are configured in a way to return only a minimum of information nowadays for security reasons.

    "And the Windows "ping" tool apparently performs its name lookup with query type=ANY"
    Good point! Ping, tracert & Co. follow the normal operating system lookup order:
    Windows: local resolver cache, hosts file, DNS, WINS, NetBIOS name cache, NetBIOS, lmhosts file.
    Therefore these tools are for DNS analysis eligible in no way. The logic is the same for browsers and most other clients, with e.g. mail programs and DNSBL clients being an exception. And all these raise A (and some also AAAA) lookups only. They don't need anything else, just a number for a name.

    "Something may have changed recently on OpenDNS"
    I'm using OpenDNS since November 2007 - no change since then...

    "the OpenDNS DNS servers also now truncate from all its positive anwsers the "additional" records"
    This may be to stay compatible with the DNSSEC/EDNS0 policy of the root servers?

    "this will require clients to perform additional lookups to get the additional records"
    Nope, I would not know "normal" client applications interested in such "unimportant" details. These are just the special tools like nslookup, dig, host & Co. (and guys like you and me) ever querying these details.

    Finally - @HomeNet
    "If it works with FF, should it then not work with IE...?"
    Yes, it does. I'm pretty sure you didn't configure it completely.
    Does it go to the Guide when you enter a search term without dots (i.e. not a shortcut!) into the address bar? Or what else happens?
    • CommentAuthorHomeNet
    • CommentTimeJun 11th 2010 edited
     permalink
    First of all, thank you both for the time you're spending on this. I do appreciate it.

    @verdy: Tried IE in safe mode (although I have no add-ins installed other than what is included with IE). No dice.

    @rotblitz: No, IE doesn't go to the Guide when entering a non-shortcut search term. It throws the same error page the shortcuts throw. If I enter "paris hilton", for instance, it ends up as "http://paris%20hilton/" over the error message.

    FF worked pretty well right out of the box on both my machines (the OpenDNS updater is installed on both desktop & laptop). And—I know I've said this, like, a dozen times, forgive me—IE7 *was* working with shortcuts for a long time, then suddenly stopped. So it must've been configured properly to start with, yes? Something got changed. And because it happened on both machines at the same time (same day), I tend to think an IE patch is the culprit, since I keep both religiously up to date. Or maybe something was changed on the router (not by me) as verdy_p mused. But then FF handles the shortcuts with the current router config...and 'round & 'round we goes...
    • CommentAuthorrotblitz
    • CommentTimeJun 11th 2010 edited
     permalink
    After all I must agree with you, it looks like as if your issue is really IE7 related and could well be caused by recent MS patches. Especially as I just got the chance to uniquely reproduce your issues with an IE7 (otherwise I'm at IE8 and prefer using FF anyway). I will test this out further and will come back to report my results...

    Edit:
    Weird "mail -> https://www.gmx.net/" does *not* work, whereas "google -> https://ssl.scroogle.org/" does work! One would not see a principal difference between these shortcuts, right?
    Btw, the "mail" shortcut lets me land at "http://guide.opendns.com/?url=mail", after it has shown "http://mail/" for a while...

    After further trials: all my shortcuts work, with and without parameter. "mail" seems to be the only one currently not working. Weird...
    Whatever, they all show first "http://shortcut/", then "http://guide.opendns.com/?url=shortcut" and finally they almost go to the target URL, except "mail".

    Does this help? Maybe try with other shortcuts? Or reenter the not working ones? Or what?

    Edit2:
    Ha, solved (for me): GMX doesn't support SSL any longer, at least not just now, so there is no way to redirect...
    I need to amend my "mail" shortcut to "http://".
    Sorry, I'm afraid this will not really help you then. :sad:

    Edit3: @verdy_p
    Ah, worth to emphasize: I did all this testing above *without* using OpenDNS for DNS lookups, but using a different DNS service (ISP), ha? :devil:
    And the shortcuts worked nevertheless! :cool:
    • CommentAuthorHomeNet
    • CommentTimeJun 11th 2010
     permalink
    I'm gonna try upgrading to IE 8 and see what happens.

    To be cont'd...
    • CommentAuthorHomeNet
    • CommentTimeJun 11th 2010
     permalink
    Both machines now upgraded to IE8—but that did not solve the shortcut problem. Oh well, I was intending to upgrade to 8 one of these days anyway.

    I don't know why this is such a big deal to me. I guess because I get caught up in the challenge. I hate letting the computer "win" (LOL). I've resolved a lot of the PC stupidness that pops up out of the blue from time to time just by sheer determination.
    • CommentAuthorrotblitz
    • CommentTimeJun 11th 2010
     permalink
    As it works so fluently with IE7 and IE8 for me, it just can be a problem on your end, really. Too bad that I can't come around the corner to solve this for you...

    As you said you followed the KB articles, now try this forum thread:
    http://forums.opendns.com/comments.php?DiscussionID=3501
    This is more than a year ago, when another French OpenDNS user educated me how to solve the shortcut issue in IE, thankfully. Hopefully it can help you now.
    I'm afraid this is all I can do for you...
    • CommentAuthorverdy_p
    • CommentTimeJun 11th 2010
     permalink
    Yes but the exposed solution is for IE only: it consists in registering another default search engine in IE settings, and to give it the URL of the opendns guide.

    This is not really a "shortcut" (it will break if you select another search engine in IE than OpenDNS, and cannot be used to create shortcut icons), but a search facility of the browser, that the browser will use when any URL typed in the address bar fails to resolve or when it does not have the correct URL syntax.

    You have similar facilities in Firefox and other browsers that allow users to cusomize their search bar...

    But yes, if you want to get personal URLs for these shortcuts, you need to be loggged on the webservice that will run your search requests, or to have a non-expired authentication cookie for that website on your PC (in which case the OpenDNS helper app to register your IP would not even be needed, the cookie method being much more secure and more personal than the very weak IP identification which may be shared by several distinct users : you may not want that the other users on your LAN, that are sharing the same public IP address as you, know where your simple shortcuts such as "dating", "sex" or "porn", or "favs", or even "work" are going to...).
    • CommentAuthorverdy_p
    • CommentTimeJun 11th 2010
     permalink
    I've tracked what my IE8 instalaltion (on Windows 7) was doing, and effectively it performs a type=ANY resolution request where as Firefox and Chrome perfom type=A and type=AAAA resolution requests.

    This means that OpenDNS shortcuts do not fully work as expected in IE, without an assistance (i.e. configuring IE for your favorite search engine)

    Yes, they worked in the past (including in URLs like "http://keyword/", but OpenDNS no longer resolve type=ANY requests for domain names that don't exist, whereas it still resolves them with type=A (and then returns the IP address of its webserver "hit-nxdomain.opendns.com" which will redirect your browser to the OpenDNS guide).

    There must have been a decision to no longer support these type=ANY requests for non-existing domain, because all web browsers offer now other alternatives (notably configuring your favorite search engine). But if this is the reason, why does OpenDSN still resolve these non-existing domains with type=A requests ? For me this is inconsistant and non standard.
    • CommentAuthorHomeNet
    • CommentTimeJun 11th 2010 edited
     permalink
    @rotblitz: I did check out the info in your link a few days ago, but wasn't crazy about changing my search default just to get the shortcuts working again. Is there a way to set the default search provider for the address bar to OpenDNS, but leave the default search provider for the search bar as Google?
    • CommentAuthorrotblitz
    • CommentTimeJun 11th 2010 edited
     permalink
    No, there isn't. And yes, this is how I run my IEs all the time since then. Also, I generally do not search from the address bar, but from the search bar. This is what and why they have created it.
    • CommentAuthorHomeNet
    • CommentTimeJun 12th 2010
     permalink
    I never search from the address bar either, I like using the little search bar in the corner. Following the directions in the link you provided DID get the shortcuts working, so now I have to decide if I can live with OpenDNS as my default, which is pure anal-ness on my part—I totally cop to it :)

    In the meantime, Firefox seems kinda cool, I've been test driving it. It runs better, looks better, feels better, even smells better (okay, I made that last one up). I like some of the add-ons available too. I'll give it a try for a few weeks and see how it goes.

    And thanks again for your time. I appreciate your being willing to "come around the corner" to help!

This discussion has been inactive for longer than 30 days, and is thus closed.