none
DNS lookup failures - DNS suffix issue and "malformed packet" response RRS feed

  • Question

  • Bit of strange issue and one I'd love to blame on the networking. For background, we have a VPN between us and a partner, it's configured for any-any traffic and has worked without issue for about 2 years. I can't say with complete confidence that the problem started when the partner firewall gave up and had to be replaced...I believe it did.

    The essence of the problem is that for the two PCs at the remote site they're unable to use DNS for name resolution, initial tests with nslookup reported "non-existent domain". I did some research, checked the reverse lookup zone, etc. and no farther forward. Here's my discovery log:

    Step 1: Domain Controller Investigation

    I tested the behaviour on a few differing domain controllers to ensure consistency. I first checked the DNS configuration and the reverse lookup zone.

    I traced the connection from a client on the partner network, a client PC (192.168.178.12), which is exhibiting the exact same behaviour as a server there. What became apparent was that client was trying to resolve the name against the wrong DNS suffix, root.domain instead of child.root.comain

    So it looked like a case of an incorrect client DNS suffix, strange though why this was working and was also now affecting the server too. So I checked the DNS suffix and search order, all fine. I even forced the DNS suffix to just root.child.domain, and still the error was being exhibited.

    So the next step was to check another server configured over a similar VPN with the same DNS configuration. That worked fine.

    Step 2: Client Investigation

    As discussed, I’d already checked the client configuration and that was as expected and aligned to our clients at our own site and across other VPN sites. The clients use static IP configuration, so IP and DNS config is as we’d expect. So next was to check whether the client was actually sending a request with an invalid suffix despite the client configuration.

    The request is being constructed correctly, it has the correct DNS suffix, a standard UDP packet using port 53 (DNS).

    However the response, as you’ll see from the first screenshot, is reporting being a malformed packet.

    Why that’s occurred is where I’m stuck, maybe the response is misleading, it does say No such name, which could mean it just couldn’t resolve.

    Step 3: What Next?

    I did dabble many years ago through the CCNA programme but now I'm very much an infrastructure person so I'd like to blame the networking and some manipulation or the like. Teams at both ends have had a look and claim not to see any issues so I'd welcome any ideas, what else I can check to prove where the issue lies.

    Many thanks

    Tuesday, March 14, 2017 8:49 PM

Answers

  • Thanks Anne for the offer of assistance. We had monitored both ends and the server wasn't receiving the correct query.

    The fear was that as we use a partner and this is a shared appliance that supports the VPN, that unless we could prove where the problem lays they would be unable to investigate in any depth.

    In the end the partner volunteered to re-establish our VPN on another appliance and this has resolved the issue, so there was an issue somewhere with the request being manipulated.

    All resolved.

    • Marked as answer by iainjo33 Thursday, March 23, 2017 7:47 AM
    Thursday, March 23, 2017 7:47 AM

All replies

  • Hi iainjo,

    Could you provide an ipconfig/all screenshot on the affected clients?

    To determine which point has issue, we may capture traffic both on the client and DNS server, check if the clients send query with correct format, if server receive the query with correct format, if sever response the query with correct query, if the client receive the response with correct format.

    Best Regards,

    Anne


    Please remember to mark the replies as answers if they help.
    If you have feedback for TechNet Subscriber Support, contact tnmff@microsoft.com.

    Thursday, March 16, 2017 8:52 AM
    Moderator
  • Thanks Anne for the offer of assistance. We had monitored both ends and the server wasn't receiving the correct query.

    The fear was that as we use a partner and this is a shared appliance that supports the VPN, that unless we could prove where the problem lays they would be unable to investigate in any depth.

    In the end the partner volunteered to re-establish our VPN on another appliance and this has resolved the issue, so there was an issue somewhere with the request being manipulated.

    All resolved.

    • Marked as answer by iainjo33 Thursday, March 23, 2017 7:47 AM
    Thursday, March 23, 2017 7:47 AM