-1

I currently host a TinyDNS server that serves DNS requests for all domains with nameservers that point to the server. The data configuration file is:

.
+*:1.2.3.4

with 1.2.3.4 being the IP of the server. It's intended to be a wildcard DNS server (any nameserver that points to this server will return A records that point to itself).

However, DNS lookups have been really slow for these domains when attempting to access the website on the domain and I have been experiencing this on different devices and networks (sometimes up to 10 seconds). Are the DNS records that are propagating from my DNS server somehow malformed? Here is an example domain: http://trp.do/s/

EDIT:

I know it's a DNS issue and not a website issue by inserting various headers with timestamps at different points within the request and response stack. They are within ms whereas the actual request from start to finish is around 5-10 seconds. When using Google Chrome, it appears to be stuck on "Resolving Host" on the bottom left as well. I've dug deeper and used Rack-Mini-Profiler @ https://github.com/MiniProfiler/rack-mini-profiler to profile the requests and listed Domain Lookup in the range of 5-10 seconds as well. So that's why I'm fairly confident it's a DNS issue and not a website performance issue.

Addressing the concerns of the single point of failure, I'm aware of it but don't think it should be affecting performance on a consistent level.

My burning question is... can a malformed DNS record even cause a situation like this?

closed as off-topic by Andrew B, Ward, Giovanni Tirloni, Cristian Ciupitu, MadHatter Oct 2 '14 at 20:58

This question appears to be off-topic. The users who voted to close gave this specific reason:

  • "Questions must demonstrate a minimal understanding of the problem being solved. Try including attempted solutions, why they didn't work, and the expected results. See How can I ask better questions on Server Fault? for further guidance." – Andrew B, Ward, Giovanni Tirloni, Cristian Ciupitu, MadHatter
If this question can be reworded to fit the rules in the help center, please edit the question.

  • 3
    1) Please define "really slow". Are you properly differentiating between DNS slowness and website slowness? What research have you done to demonstrate this? Show, don't tell. 2) Both nameservers are pointing at the same IP address. This is a brittle configuration that is both a single point of failure, and unforgiving of network problems between client and server -- which may or may not be related to your described issue. Please take a step back from hosting your own DNS and read a book on the basic subject matter. – Andrew B Sep 30 '14 at 3:15
  • Also see: Should we host our own nameservers? – Andrew B Sep 30 '14 at 3:36
  • Do you have a new example, it appears that the trp.do domain has been delegated elsewhere now (ns{1,2,3,4}.linode.com)? What I wonder is if tinydns deals properly with EDNS0 queries. From what I know tinydns is pretty outdated (last release in 2001, but with some third party patches available) so I don't really know what the expectations should be? If it fails to understand the initial queries, maybe that could lead to some strange issues? – Håkan Lindqvist Sep 30 '14 at 6:07
  • @Håkan The trp.do link used to contain the name of one of his domains but the link has "self-destructed" already. – Andrew B Sep 30 '14 at 13:39
  • @HåkanLindqvist Sorry about that, can you try this, thanks in advance! trp.do/s/fe6eKQ9mFkKahAxHv – Axsuul Oct 1 '14 at 6:48
1

A malformed response from an individual authoritative server is unlikely to cause this problem. Whether the first server is taking too long to reply and times out, or the reply is malformed (truncated, mangled, etc.), the recursive DNS server can retry with the next authoritative nameserver. If all servers return bogus data, there is a major problem somewhere.

This assumes that you are following best practices and operating multiple nameservers that are georedundant. Your configuration fails this standard on both counts. It may seem like I'm beating a dead horse here, but it's truly the basics of DNS: this configuration places your company assets in jeopardy and you are basically at the mercy of whatever network events happen between everyone on the internet and your single geoisolated server.

Start by fixing this problem. Until you have addressed it, everything else is kind of moot. The 5-10 second delay may very well be due to the resolver library attempting to append your search suffixes to the original (failed) query, but the current config is fundamentally broken and kinda pointless to troubleshoot further at the moment.

Not the answer you're looking for? Browse other questions tagged or ask your own question.