1

I'm operating a server that makes large numbers of DNS lookups, (bind sits at 24% CPU utilisation - it's handling outbound email for thousands of users) however "skynet.be" are not responding to our DNS requests.

This is not a DNS problem. their DNS servers are up and giving good responses to other parts of the internet, just not to the part I'm calling from.

A tcp traceroute on port 53 to their servers dies somewhere in skynet controlled territory. (Please, no jokes about "John Connor") The same traceroute from a different part of the internet works just fine making 2 more hops to reach their DNS server.

Email to [email protected] just gets me an auto-response with a non-functional URL. [email protected] bounces, and [email protected] seems to be a black-hole.

Bind is configured to do recursive lookups starting at the root-servers the Linode's DNS forwarders also fail to resolve skynet.be.

I can't use google DNS (even if I wanted to) as we exceed their rate-limit, and when that happens they start lying to us.

What steps should I take?

Is INOC DBA worth a try? - I have an AS number and a SIP system, but I have not yet to connected it to INOC. would this use be considered abusive? also the ~12 hour time-zone difference, and possibly language barrier could be inconvenient.

Maybe run the DNS traffic though a VPN or configure BIND to use one of our other servers in a different location as a forwarder to resolve only skynet.be - is that practical?

Improve this question
4
  • 2
    The SOA record suggests [email protected] but good luck with that...
    – Michael Hampton
    Feb 7, 2017 at 1:45
  • 2
    WHOIS contact details are also worth a shot.
    – Andrew B
    Feb 7, 2017 at 4:44
  • @AndrewB that worked :) - I mean it got my message to a human. they gave me another email address to contact.
    – user313114
    Feb 10, 2017 at 2:05
  • the other email address bounced offering yet another email address
    – user313114
    Feb 20, 2017 at 21:17

1 Answer 1

Reset to default
-1

A tcptraceroute on port 53 is not really the best tool to diagnose DNS problems. Because DNS uses UDP a lot, and, even if it is an error, some people do filter TCP/53. Do you have more specific information on what does not work, like dig queries and replies ? Network pcaps ? Anything that can be reproduced ?

It won't solve your problem to find out who to contact, but maybe it could shed a light on the problem you have and in all cases the party you will contact surely will ask for some evidences.

Improve this answer
5
  • I get nothing back on UDP. UDP is like that, either it works or it doen't
    – user313114
    Feb 7, 2017 at 20:43
  • anyone who's blocking TCP DNS, isn't using SPF, or any of the other "recent" inventions that require large DNS responses.
    – user313114
    Feb 7, 2017 at 20:45
  • I've seen ICMP based traceroutes given completely different results to TCP based ones.
    – user313114
    Feb 7, 2017 at 20:46
  • I was not recommending to use ICMP either. DNS uses in theory UDP and TCP, in practice a lot of UDP. You should diagnose things using dig to start. You still fail to give specific queries for which you did not get any reply. The problem may not be where you think it is, if you give specifically the steps you did, someone else could reproduce them and see if they get the same problem or not.
    – Patrick Mevzek
    Feb 7, 2017 at 20:50
  • as I can't reach the server it makes no difference at all what packets I send towards it. FWIW dig @195.238.25.138 skynet.be gets me ;; connection timed out; no servers could be reached. which is why I went to tcptraceroute.
    – user313114
    Feb 7, 2017 at 21:29

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .