4

I recently got a new domain (lets call it testdomain.extample) from Route53 on Amazon. I further have a classic load balancer from AWS that I want requests to be forwarded to when somebody visits www.testdomain.example.

Under hosted zones on Route53 I went over instructions to set NS, SOA (Amazon adds a bunch of ns-xxx.* hostnames for NS and one for SOA). I also added an A type record and added my load balancer (from a dropdown) to it as specified in the documentation.

When I run dig on my domain this is what I see (I don't see an answer section as I see for other working websites). It is about 12 hours since I updated on AWS. The browser shows "server IP address could not be found." error. Is there something I am missing in all of this? 

>>> dig www.mytestdomain.example

; <<>> DiG 9.10.6 <<>> www.mytestdomain.example
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 3567
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512
;; QUESTION SECTION:
;www.mytestdomain.example.  IN  A

;; Query time: 161 msec
;; SERVER: 192.0.2.75#53(192.0.2.75)
;; WHEN: Tue Apr 23 05:44:21 PDT 2019
;; MSG SIZE  rcvd: 52
Patrick Mevzek
  • 9,921
  • 7
  • 32
  • 43
user2399453
  • 149
  • 1
  • 1
  • 3
  • 2
    "Is there something I am missing in all of this? " 1) Do not (badly, I edited your post) obfuscate names and IP addresses, this makes basically anyone unable to help you 2) a browser is useless to test DNS resolution problems, `dig` is fine but 3) when using `dig` **ALWAYS** specify (with its `@` flag) which nameserver you query because with that 4) "It is about 12 hours since I updated on AWS." there is no need to wait, if you query the **authoritative** nameservers on your domain the changes should appear immediately. – Patrick Mevzek Apr 23 '19 at 23:58
  • 2
    Based on "Amazon adds a bunch of ns-xxx.* hostnames for NS and one for SOA" - which seems to surprise you - I am **guessing** you may have forgotten an important step: you need, through your registrar, to update your domain so that it has the relevant nameservers (the ones added by your provider) as authoritative on it and to be published on the parent zone, controlled by the registry (which is why you need to go through your registrar). Until you do that, direct queries to the authoritative nameservers may work but basically the domain will not globally as there is no "link" from parent. – Patrick Mevzek Apr 24 '19 at 00:00
  • 1
    2 useful online debugging tool that may give you better explanations: https://www.zonemaster.net/ and https://dnsviz.net/. Use them extensively, specifically if you do not master `dig` parameters and output. – Patrick Mevzek Apr 24 '19 at 00:00
  • Thanks for the helpful comments. I got closer to understanding the problem after doing some experiments. I think the issue is that I had deleted the hosted zone in between and recreated it in route 53. When I do dig +trace I see 4 NS entries that do not match what I have set in R53 on AWS. However if I use the NS entry in AWS to do a dig @ then it correctly routes to my load balancer. So the question then is how do I fix the bad NS entries that seem to be outside AWS? Is it something that propagates and updates over time? – user2399453 Apr 24 '19 at 06:54

1 Answers1

5

There is no answer section because your query went unanswered, 

;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 3567
                                       ^^^^^^^^

check the status section: the name server returned an error code and you get the SERVFAIL error response. That is typically the result of a nameserver or your zone not having been configured correctly.

Note: In many cases it may be necessary to know the actual domain name in order to answer DNS questions. See What information should I include or obfuscate in my posts?

HBruijn
  • 77,029
  • 24
  • 135
  • 201
  • 2
    "That is typically the result of a nameserver or your zone not having been configured correctly. " or a DNSSEC related problem. Which indeed is impossible to separate between the two because the OP badly and unnecessarily obfuscated the name. – Patrick Mevzek Apr 23 '19 at 23:54