OpenDNS Updater (Windows) confused by me having two different DNS servers

Comments

8 comments

  • Avatar
    rotblitz (Edited )

    The first problem is that you cannot mix DNS services on the end user devices, e.g. your router's address and the domain controller address.  And the second problem is that you cannot run the Updater on a computer where you have possibly different internet connections, one through AD and another through a router.  You would have to use your routers and/or the domain controller as update clients, or you had to use a more sophisticated updater like Marc's Updater which is able to update based on the network the computer is in.

    The NXDOMAIN responses indiate that you don't use OpenDNS at all, but another DNS service.  Copy & paste the complete plain text output of the following diagnostic commands to here, from a PC where it doesn't work as expected and where you run the Updater.

    nslookup -type=txt debug.opendns.com.
    nslookup whoami.akamai.net.
    netsh interface ipv4 show config

     

    0
    Comment actions Permalink
  • Avatar
    libove

    Hi rotblitz. Thanks for responding.

    So, there are two things going on:
    1. The OpenDNS Updater is not designed for this situation (two DNS servers, each one on a different network/ different Internet connection). Shame. I'll look into Marc's Updater.
    2. The NXDOMAINs. Focusing on only that below.

    I wonder about the "not using OpenDNS at all". I saw that in other threads.

    On network #1 all clients point to the AD DC; the AD DC points to itself (it's running an AD integrated DNS server); its Forwarders are only OpenDNS 208.67.222.222, 208.67.220.220, so there shouldn't be any possibility of not using OpenDNS on that network (and that's the network on which the DNS queries for myip.opendos.com often result in NXDOMAIN).

    So, here's a curiosity: I run the OpenDNS Updater on network #1 on the AD DC, and it works reliably. 
    In fact, I don't think I see any errors from the OpenDNS Updater - just the strange behavior (now explained above) from OpenDNS Updater running on a host which has two different DNS servers configured (on different networks, with different Internet connections).

    The NXDOMAINs come back from NSLOOKUP queries run on the AD DC, not (insofar as I can see) in the OpenDNS Updater.

    Actually, now that I've updated network #2's clients to use only either the AD DC (on network #1, which we know produces NXDOMAIN on queries of myip.opendns.com) or to an updated DNS configuration on network #2's router (to Forward only to OpenDNS' servers) on all clients on network #2 I always only get NXDOMAIN.

    Testing various things in various places, there is no doubt that the problem is somewhere in the interaction between myip.opendns.com and the DNS server on the AD DC. My network #1 router (a Mikrotik device) is pointed to the AD DC DNS server, and it 100% returns NXDOMAIN to the query myip.opendns.com.
    In fact, NSLOOKUP running locally on the AD DC also 100% produces NXDOMAIN. (The once-in-a-while correct responses that I'd gotten before don't seem to be happening now at all. I think those were happening only on network #2 before, and only when sometimes the DNS Forwarder was the ISP's, which I've now eliminated entirely).

    So, I think the focus is on how queries for myip.opendns.com interact with a Windows AD DC DNS server (Windows Server 2012R2).

    Below are the outputs that you requested, on the AD DC. 
    Many thanks,
    -Jay

     

    C:\>nslookup -type=txt debug.opendns.com.
    Server: localhost
    Address: ::1

    Non-authoritative answer:
    debug.opendns.com text =

    "server r5.cdg1"
    debug.opendns.com text =

    "flags 20 0 40 3950000002000001001"
    debug.opendns.com text =

    "originid 1359535"
    debug.opendns.com text =

    "actype 2"
    debug.opendns.com text =

    "bundle 833356"
    debug.opendns.com text =

    "source 62.83.249.222:52760"

     

     

    C:\>nslookup whoami.akamai.net.
    Server: localhost
    Address: ::1

    Non-authoritative answer:
    Name: whoami.akamai.net
    Address: 217.149.97.154

     

     


    C:\>netsh interface ipv4 show config

    Configuration for interface "TeamViewer VPN"
    DHCP enabled: Yes
    IP Address: 169.254.168.33
    Subnet Prefix: 169.254.0.0/16 (mask 255.255.0.0)
    InterfaceMetric: 30
    DNS servers configured through DHCP: None
    Register with which suffix: Primary only
    WINS servers configured through DHCP: None

    Configuration for interface "vEthernet (Virtual Switch 1 RTL8139)"
    DHCP enabled: Yes
    IP Address: 169.254.115.229
    Subnet Prefix: 169.254.0.0/16 (mask 255.255.0.0)
    InterfaceMetric: 5
    Statically Configured DNS Servers: 127.0.0.1
    Register with which suffix: None
    WINS servers configured through DHCP: None

    Configuration for interface "Ethernet 2"
    DHCP enabled: No
    IP Address: 192.168.255.8
    Subnet Prefix: 192.168.255.0/26 (mask 255.255.255.192)
    Default Gateway: 192.168.255.7
    Gateway Metric: 1
    InterfaceMetric: 10
    Statically Configured DNS Servers: 192.168.255.8
    127.0.0.1
    Register with which suffix: Primary only
    Statically Configured WINS Servers: None

    Configuration for interface "Loopback Pseudo-Interface 1"
    DHCP enabled: No
    IP Address: 127.0.0.1
    Subnet Prefix: 127.0.0.0/8 (mask 255.0.0.0)
    InterfaceMetric: 50
    Statically Configured DNS Servers: None
    Register with which suffix: Primary only
    Statically Configured WINS Servers: None

     

    0
    Comment actions Permalink
  • Avatar
    rotblitz (Edited )

    At the end it counts what's up on the end user devices, not so much on the AD DC.  A DNS query (TXT record) for debug.opendns.com is equivalent to a DNS query (A record) for myip.opendns.com, but the first gives out more information.  myip.opendns.com is being used especially by the Updater to see if your IP address(es) has changed and would not have returned NXDOMAIN in this situation.

    Your output for debug.opendns.com (TXT) shows that you used OpenDNS at this time, through your AD DNSv6 server (::1) and your gateway 62.83.249.222.  Not so sure about the query to whoami.akamai.net (A), because 217.149.97.154 is not listed as a router address in front of an OpenDNS data center (https://www.opendns.com/data-center-locations/).  It could be that this query didn't reach OpenDNS.

    I'm concerned about

    Configuration for interface "Ethernet 2"
    Statically Configured DNS Servers: 192.168.255.8
                                                          127.0.0.1

    It's not a good idea to mix DNS services, 127.0.0.1 (localhost) as your AD DNS server, and 192.168.255.8 as another, because you do not have control over what DNS service is being used, and you may get inconsistent and random results.  And if 192.168.255.8 is the LAN IP address of your DC (as it seems to be), then it still doesn't make sense to configure it as DNS server address.

    I suggest to clean up and simplify your configuration and to make the end user devices manually switchable between AD DHCP (where the AD DC's address is mandatory as DNS server address for taking AD effect) and the router's DHCP and related DNS server address, maybe with AD through VPN tunnel.  This is not only needed in view of DNS, but especially in view of AD.

    0
    Comment actions Permalink
  • Avatar
    libove

    Hi, apologies, I should have clarified - 192.1682.255.8 is the LAN IP address of the AD DC, so it's the same in this case as 127.0.0.1, no mixing going on. I'm honestly not sure why the AD DC's own IP configuration has both its 127.0.0.1 loopback and its 192.168.255.8 local LAN IP address configured, but even though it's extra, it shouldn't cause a wrong answer to be returned, right?

    Nothing on network #1 relies on the ISP's router's DNS service (unless the ISP is transparently proxying, which I don't think it is in this case, but I can't be absolutely sure).

     

    That the DNS lookup for whoami.akamai.net did not seem to use OpenDNS' servers is very strange. We see that it asked ::1, which is the AD DC, and I'm fairly sure that the AD DC only Forwards to OpenDNS' servers. (At least, looking in the Windows AD integrated DNS server settings, the only Forwarders are 208.67.222.222 and 208.67.220.220).

     

    I agree that my network #2 clients' DNS configurations are not ideal. The problem is the need to work (at all) when for whatever reason the (single point of failure, beyond several other single point of failure network components) AD DC on network #1 might not be available. Since Windows clients cannot be configured to have preferential and fallback DNS servers, I'm stuck with AD related DNS lookups intermittently not working so well, which on this very simple Domain isn't that big a deal (I hacked around the principal problem by hardcoding the AD DC's IP address in the network #2 clients' local Hosts files).

    So, we're still left with the mystery of why we're seeing NXDOMAINs. And why the lookup of whoami.akamai.net returned something that wasn't what you expected.

    Thanks again.

    0
    Comment actions Permalink
  • Avatar
    rotblitz (Edited )

    As I said, I didn't expect to see an NXDOMAIN result according to the TXT lookup for debug.opendns.com which does the same as and more than an A lookup for myip.opendns.com.  On what machine do you see those?  On the AD DC?

    Where ever and whenever you see this, post the output of the following commands at this time on this machine (in essence the same as before):

    nslookup -type=txt debug.opendns.com.
    nslookup myip.opendns.com.
    nslookup whoami.akamai.net.
    netsh interface ipv4 show config

     

    0
    Comment actions Permalink
  • Avatar
    libove

     

     

    As of right now, on the AD DC, the debug.opendns.com queries all seem to return the expected:

    Microsoft Windows [Version 6.3.9600]
    (c) 2013 Microsoft Corporation. All rights reserved.

    C:\Windows\System32>host -t txt debug.opendns.com
    debug.opendns.com descriptive text "server r4.cdg1"
    debug.opendns.com descriptive text "flags 20 0 40 3950000002000001001"
    debug.opendns.com descriptive text "originid 1359535"
    debug.opendns.com descriptive text "actype 2"
    debug.opendns.com descriptive text "bundle 833356"
    debug.opendns.com descriptive text "source 62.83.249.222:52322"

    C:\Windows\System32>host -t txt debug.opendns.com
    debug.opendns.com descriptive text "server r2.cdg1"
    debug.opendns.com descriptive text "flags 20 0 40 3950000002000001001"
    debug.opendns.com descriptive text "originid 1359535"
    debug.opendns.com descriptive text "actype 2"
    debug.opendns.com descriptive text "bundle 833356"
    debug.opendns.com descriptive text "source 62.83.249.222:52732"

    C:\Windows\System32>host -t txt debug.opendns.com
    debug.opendns.com descriptive text "server r4.cdg1"
    debug.opendns.com descriptive text "flags 20 0 40 3950000002000001001"
    debug.opendns.com descriptive text "originid 1359535"
    debug.opendns.com descriptive text "actype 2"
    debug.opendns.com descriptive text "bundle 833356"
    debug.opendns.com descriptive text "source 62.83.249.222:51876"

    C:\Windows\System32>nslookup
    Default Server: localhost
    Address: ::1

    > set q=txt
    > debug.opendns.com.
    Server: localhost
    Address: ::1

    Non-authoritative answer:
    debug.opendns.com text =

    "server r3.cdg1"
    debug.opendns.com text =

    "flags 20 0 40 3950000002000001001"
    debug.opendns.com text =

    "originid 1359535"
    debug.opendns.com text =

    "actype 2"
    debug.opendns.com text =

    "bundle 833356"
    debug.opendns.com text =

    "source 62.83.249.222:53767"
    > debug.opendns.com.
    Server: localhost
    Address: ::1

    Non-authoritative answer:
    debug.opendns.com text =

    "server r3.cdg1"
    debug.opendns.com text =

    "flags 20 0 40 3950000002000001001"
    debug.opendns.com text =

    "originid 1359535"
    debug.opendns.com text =

    "actype 2"
    debug.opendns.com text =

    "bundle 833356"
    debug.opendns.com text =

    "source 62.83.249.222:52428"

     

    WHEREAS on the same AD DC the lookup for myip.opendns.com still products NXDOMAINs AND ALSO does this weird thing that I've noticed before of giving a different response the "first time" compared to all immediately subsequent queries:

    C:\Windows\System32>host myip.opendns.com
    myip.opendns.com has address 62.83.249.222
    Host myip.opendns.com not found: 3(NXDOMAIN)
    Host myip.opendns.com not found: 3(NXDOMAIN)

    C:\Windows\System32>host myip.opendns.com
    Host myip.opendns.com not found: 3(NXDOMAIN)

    C:\Windows\System32>host myip.opendns.com
    Host myip.opendns.com not found: 3(NXDOMAIN)

     

    Interestingly, if I specify an OpenDNS Server as the requested resolver on a lookup command, it reliably produces the one-correct-answer-plus-two-NXDOMAINs:

    C:\Windows\System32>host myip.opendns.com. 208.67.222.222
    Using domain server:
    Name: 208.67.222.222
    Address: 208.67.222.222#53
    Aliases:

    myip.opendns.com has address 62.83.249.222
    Host myip.opendns.com not found: 3(NXDOMAIN)
    Host myip.opendns.com not found: 3(NXDOMAIN)

     

    Doing that again, with verbose:

    C:\Windows\System32>host -v myip.opendns.com. 208.67.222.222
    Trying "myip.opendns.com"
    Using domain server:
    Name: 208.67.222.222
    Address: 208.67.222.222#53
    Aliases:

    ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 32339
    ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0

    ;; QUESTION SECTION:
    ;myip.opendns.com. IN A

    ;; ANSWER SECTION:
    myip.opendns.com. 0 IN A 62.83.249.222

    Received 50 bytes from 208.67.222.222#53 in 161 ms
    Trying "myip.opendns.com"
    Host myip.opendns.com not found: 3(NXDOMAIN)
    Received 102 bytes from 208.67.222.222#53 in 41 ms
    Received 102 bytes from 208.67.222.222#53 in 44 ms
    Trying "myip.opendns.com"
    Host myip.opendns.com not found: 3(NXDOMAIN)
    Received 102 bytes from 208.67.222.222#53 in 34 ms
    Received 102 bytes from 208.67.222.222#53 in 38 ms

     

    A bit more testing, turning on TCP mode and disabling recursion:

    C:\Windows\System32>host -vrT myip.opendns.com. 208.67.222.222
    Trying "myip.opendns.com"
    Using domain server:
    Name: 208.67.222.222
    Address: 208.67.222.222#53
    Aliases:

    ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 59355
    ;; flags: qr ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0

    ;; QUESTION SECTION:
    ;myip.opendns.com. IN A

    ;; ANSWER SECTION:
    myip.opendns.com. 0 IN A 62.83.249.222

    Received 50 bytes from 208.67.222.222#53 in 160 ms
    Trying "myip.opendns.com"
    Host myip.opendns.com not found: 3(NXDOMAIN)
    Received 102 bytes from 208.67.222.222#53 in 33 ms
    Received 102 bytes from 208.67.222.222#53 in 37 ms
    Trying "myip.opendns.com"
    Host myip.opendns.com not found: 2(SERVFAIL)
    Received 34 bytes from 208.67.222.222#53 in 33 ms

    STILL doing three queries instead of one. And now with a combination of success, NXDOMAIN, and SERVFAIL.
    I don't know how to read this. 

    Aha, I captured and analyzed packets (love Wireshark).
    The single NS lookup (using the "host" command) actually sends more than one query:
    1. IN A myip.opendns.com - succeeds
    2. IN AAAA  myip.opendns.com - NXDOMAIN (I suppose as expected)
    3. IN MX myip.opendns.com - SERVFAIL (not sure why, but not a query we're interested in).

    So, that explains the extras (which are unneeded AAAA and MX lookups).

     

    It doesn't explain, though, the difference between the first and subsequent queries:

    Note that the first query produces a correct answer AND TWO NXDOMAINs, and subsequent queries product ONLY a SINGLE NXDOMAIN.

    This has been consistent. I'm not sure how long I have to wait before the first response above (one correct answer plus two NXDOMAINs) will recur, but I've seen it several times during days when we've been looking at this situation.

    Here's another test - I was watching Wireshark while I did this:

    C:\Windows\System32>nslookup myip.opendns.com
    Server: localhost
    Address: ::1

    Non-authoritative answer:
    Name: myip.opendns.com
    Address: 62.83.249.222


    C:\Windows\System32>nslookup myip.opendns.com
    Server: localhost
    Address: ::1

    *** localhost can't find myip.opendns.com: Non-existent domain

    C:\Windows\System32>nslookup myip.opendns.com
    Server: localhost
    Address: ::1

    *** localhost can't find myip.opendns.com: Non-existent domain

     

    Wireshark saw the first nslookup in this test (IN A query followed by response), but the nslookup command apparently did not actually send a query over the wire for the two subsequent commands. I guess there may be an internal DNS cache (unaffected by IPCONFIG/FLUSHDNS) from which nslookup is pulling a (why?) cached negative answer.

    And it seems that 'host' does the same thing, so it's not just baked into the command binary, but in some Windows DLL that both the Windows NSLOOKUP and the Cygwin 'host' commands call.

     

    Then you asked for:

    C:\Windows\System32>nslookup whoami.akamai.net.
    Server: localhost
    Address: ::1

    Non-authoritative answer:
    Name: whoami.akamai.net
    Address: 213.192.202.211

     

    A reminder, on the AD DC, there are several interfaces, summarising:

    Ethernet adapter TeamViewer VPN: (not connected, not running; has no IP address, has no DNS servers configured; should have no effect on NS lookups)

    Ethernet adapter vEthernet (Virtual Switch 1 RTL8139): Hyper-V Virtual Ethernet Adapter #2, has only an Autoconfig 169.254... IP address; points to DNS servers ::1 and 127.0.0.1, should have no effect on NS lookups

    Ethernet adapter Ethernet 2: This is the main physical Ethernet adapter of the AD DC. It has the IP address 192.168.255.8. It's own DNS servers are configured as ::1, 192.168.255.8, and 127.0.0.1. Although as agreed the 192.168.255.8 is extra, it shouldn't cause errors.

    Three isatap Tunnel adapters, all in active, no IP nor DNS configured.

     

    So, NS lookups run locally on the AD DC should try "three" DNS servers, which are all different ways of addressing the DC itself (::1, 127.0.0.1, 192.168.255.8).

     

    The AD DC's own DNS Server is setup with only the Forwarders 208.67.222.222, 208.67.220.220.

     

    Finally, mostly repeating the above I guess, you had asked for:

    C:\Windows\System32>netsh interface ipv4 show config

    Configuration for interface "TeamViewer VPN"
    DHCP enabled: Yes
    IP Address: 169.254.168.33
    Subnet Prefix: 169.254.0.0/16 (mask 255.255.0.0)
    InterfaceMetric: 30
    DNS servers configured through DHCP: None
    Register with which suffix: Primary only
    WINS servers configured through DHCP: None

    Configuration for interface "vEthernet (Virtual Switch 1 RTL8139)"
    DHCP enabled: Yes
    IP Address: 169.254.115.229
    Subnet Prefix: 169.254.0.0/16 (mask 255.255.0.0)
    InterfaceMetric: 5
    Statically Configured DNS Servers: 127.0.0.1
    Register with which suffix: None
    WINS servers configured through DHCP: None

    Configuration for interface "Ethernet 2"
    DHCP enabled: No
    IP Address: 192.168.255.8
    Subnet Prefix: 192.168.255.0/26 (mask 255.255.255.192)
    Default Gateway: 192.168.255.7
    Gateway Metric: 1
    InterfaceMetric: 10
    Statically Configured DNS Servers: 192.168.255.8
    127.0.0.1
    Register with which suffix: Primary only
    Statically Configured WINS Servers: None

    Configuration for interface "Loopback Pseudo-Interface 1"
    DHCP enabled: No
    IP Address: 127.0.0.1
    Subnet Prefix: 127.0.0.0/8 (mask 255.0.0.0)
    InterfaceMetric: 50
    Statically Configured DNS Servers: None
    Register with which suffix: Primary only
    Statically Configured WINS Servers: None

     

    All of the above is on the AD DC on network #1.

    Now, on another workstation on network #1, not the AD DC:

    C:\>host myip.opendns.com.
    myip.opendns.com has address 62.83.249.222
    Host myip.opendns.com not found: 3(NXDOMAIN)
    Host myip.opendns.com not found: 3(NXDOMAIN)

    C:\>host myip.opendns.com.
    Host myip.opendns.com. not found: 3(NXDOMAIN)

    C:\>host myip.opendns.com.
    Host myip.opendns.com. not found: 3(NXDOMAIN)

    Here we see that same weird first sort of works as expected, immediate subsequent do not.

     

    This other workstation on network #1 has one active physical Ethernet interface, with DNS points to 192.168.255.8 (the AD DC).
    It also has several inactive virtual interfaces (VMware, TAP, VPN), of which the two VMware virtual interfaces have these DNS servers listed:
    DNS Servers . . . . . . . . . . . : fec0:0:0:ffff::1%1
                                                  fec0:0:0:ffff::2%1
                                                  fec0:0:0:ffff::3%1

    I assume that shouldn't affect anything.

    More results from this other workstation:

    C:\>nslookup -type=txt debug.opendns.com.
    Server: reset8.ad3.felines.org
    Address: 192.168.255.8

    Non-authoritative answer:
    debug.opendns.com text =

    "server r4.cdg1"
    debug.opendns.com text =

    "flags 20 0 40 3950000002000001001"
    debug.opendns.com text =

    "originid 1359535"
    debug.opendns.com text =

    "actype 2"
    debug.opendns.com text =

    "bundle 833356"
    debug.opendns.com text =

    "source 62.83.249.222:62353"

     

    C:\>nslookup whoami.akamai.net.
    Server: reset8.ad3.felines.org
    Address: 192.168.255.8

    Non-authoritative answer:
    Name: whoami.akamai.net
    Address: 156.208.182.255

    (this is consistent over several repeated executions)

     

    And, for completeness:

    C:\>netsh interface ipv4 show config

    Configuration for interface "Ethernet 2"
    DHCP enabled: Yes
    IP Address: 192.168.255.37
    Subnet Prefix: 192.168.255.0/26 (mask 255.255.255.192)
    Default Gateway: 192.168.255.7
    Gateway Metric: 0
    InterfaceMetric: 25
    DNS servers configured through DHCP: 192.168.255.8
    Register with which suffix: Primary only
    WINS servers configured through DHCP: None

    Configuration for interface "Ethernet 3"
    DHCP enabled: Yes
    InterfaceMetric: 35
    DNS servers configured through DHCP: None
    Register with which suffix: Primary only
    WINS servers configured through DHCP: None

    Configuration for interface "VMware Network Adapter VMnet1"
    DHCP enabled: Yes
    IP Address: 192.168.140.1
    Subnet Prefix: 192.168.140.0/24 (mask 255.255.255.0)
    InterfaceMetric: 35
    DNS servers configured through DHCP: None
    Register with which suffix: Primary only
    WINS servers configured through DHCP: None

    Configuration for interface "VMware Network Adapter VMnet8"
    DHCP enabled: Yes
    IP Address: 192.168.118.1
    Subnet Prefix: 192.168.118.0/24 (mask 255.255.255.0)
    InterfaceMetric: 35
    DNS servers configured through DHCP: None
    Register with which suffix: Primary only
    WINS servers configured through DHCP: 192.168.118.2

    Configuration for interface "Ethernet 4"
    DHCP enabled: Yes
    InterfaceMetric: 55
    DNS servers configured through DHCP: None
    Register with which suffix: Primary only
    WINS servers configured through DHCP: None

    Configuration for interface "Loopback Pseudo-Interface 1"
    DHCP enabled: No
    IP Address: 127.0.0.1
    Subnet Prefix: 127.0.0.0/8 (mask 255.0.0.0)
    InterfaceMetric: 75
    Statically Configured DNS Servers: None
    Register with which suffix: Primary only
    Statically Configured WINS Servers: None

     

    Does this all tell us anything? I remain confused about the inconsistency between initial and subsequent myip.opendns.com lookup results, on both the AD DC and this second client workstation on the same network #1.

    thanks again.

     

    0
    Comment actions Permalink
  • Avatar
    rotblitz

    I'm afraid I cannot help further.  Someone else?

    0
    Comment actions Permalink
  • Avatar
    libove

    Thank you anyway, rotblitz, your efforts are much appreciated.

    0
    Comment actions Permalink

Please sign in to leave a comment.