-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?

Axsuul
  • 101
  • 1
  • 3
  • 12
  • 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 03:15
  • Also see: [Should we host our own nameservers?](http://serverfault.com/questions/23744/should-we-host-our-own-nameservers) – Andrew B Sep 30 '14 at 03: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 06: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! http://trp.do/s/fe6eKQ9mFkKahAxHv – Axsuul Oct 01 '14 at 06:48
  • @Axsuul The one thing that stands out to me is that your nameserver is denying the existance of `NS` records for that domain name. From the response it looks like you actually have a root zone (`.`) set up rather than a zone by the name you mentioned. (That empty response includes `. 2560 IN SOA ns. hostmaster. 1411742341 16384 2048 1048576 2560`) – Håkan Lindqvist Oct 01 '14 at 17:24
  • @HåkanLindqvist Ah ok interesting, what sort of effect will that have? – Axsuul Oct 01 '14 at 22:21
  • @Axsuul The effect of that may not necessarily match the problem described in the question but if someone looks up `example.com NS` they will from then on know for a fact that there are no `NS` records, which seems like a potentially very bad thing for subsequent queries. – Håkan Lindqvist Oct 12 '14 at 09:39

1 Answers1

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.

Andrew B
  • 31,858
  • 12
  • 90
  • 128