[SOLVED] DNS not behaving well anymore

mjbradakis · 10-14-2019, 11:19 PM

Here's my OS:

Linux bradakis.com 5.2.18-200.fc30.x86_64 #1 SMP Tue Oct 1 13:14:07 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux

Here's my named version:

BIND 9.11.10-RedHat-9.11.10-1.fc30 (Extended Support Version) <id:9390ecc>

Here's one of my DNS zone files:

$ORIGIN com.
wasatchfoodies 3600 IN SOA wasatchfoodies.com. postmaster.wasatchfoodies.com. (
2019070500 20800 900 360000 86400 )
3600 IN NS ns.wasatchfoodies.com.
3600 IN A 50.198.190.18
3600 IN MX 10 wasatchfoodies.com.
3600 IN MX 20 bradakis.com.
$ORIGIN wasatchfoodies.com.
localhost 3600 IN A 127.0.0.1
www 3600 IN A 50.198.190.18
ns 3600 IN A 50.198.190.18

And this:

[root@bradakis named]# named-checkzone wasatchfoodies.com ./wf
zone wasatchfoodies.com/IN: loaded serial 2019070500
OK

But if one goes to dnsstuff.com and runs a report on that domain it claims a failure due to no SOA record, and a failure due to no MX records. But it worked with this configuration file for quite some time, used to get no fails. And it is not just this domain, but all of them run from my server. I can not figure out what changed, why this is happening.

Any clues on how and where to track this down?

mjb.

bathory · 10-15-2019, 02:11 AM

Quote:

But if one goes to dnsstuff.com and runs a report on that domain it claims a failure due to no SOA record, and a failure due to no MX records. But it worked with this configuration file for quite some time, used to get no fails. And it is not just this domain, but all of them run from my server. I can not figure out what changed, why this is happening.

Any clues on how and where to track this down?

A, NS and MX queries give a SERVFAIL from here, e.g.:

Code:

dig wasatchfoodies.com @50.198.190.18

; <<>> DiG 9.14.6 <<>> wasatchfoodies.com @50.198.190.18
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 35075
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
; COOKIE: 97839151de7b726f4c890d945da56f2c19f9388e6ed69e18 (good)
;; QUESTION SECTION:
;wasatchfoodies.com.		IN	A

;; Query time: 4892 msec
;; SERVER: 50.198.190.18#53(50.198.190.18)
;; WHEN: Tue Oct 15 10:03:08 EEST 2019
;; MSG SIZE  rcvd: 75

So apparently you have some errors in the zone file.
Please re-post the zone file, removing the 2 $ORIGIN (unnecessary) and the localhost RRs.
And put the zone file inside CODE tags to keep indenting.

Regards

mjbradakis · 10-15-2019, 03:32 AM

An odd observation. On bradakis.com I can run 'dig whatever_host' and it works just fine, using bradakis.com as the DNS server. But 'dig bradakis.com' takes a long time to finally return a SERVFAIL error. This is frustrating.

mjb.

bathory · 10-15-2019, 04:33 AM

Quote:

Originally Posted by mjbradakis

An odd observation. On bradakis.com I can run 'dig whatever_host' and it works just fine, using bradakis.com as the DNS server. But 'dig bradakis.com' takes a long time to finally return a SERVFAIL error. This is frustrating.

mjb.

Working as a caching dns, does not mean that it will also work as an authoritative one.

Without config files, just running a trace, looks like you don't have any A RRs for the 2 nameservers of bradakis.com:

Code:

dig bradakis.com +trace
<-snip->
couldn't get address for 'ns1.bradakis.com': not found
couldn't get address for 'ns2.bradakis.com': not found
dig: couldn't get address for 'ns1.bradakis.com': no more

Also ns2 does not even listen, or it's blocked by a firewall:

Code:

dig bradakis.com @50.198.190.17

; <<>> DiG 9.14.6 <<>> ns1.bradakis.com @50.198.190.17
;; global options: +cmd
;; connection timed out; no servers could be reached

Ser Olmy · 10-15-2019, 05:12 AM

Quote:

Originally Posted by mjbradakis

An odd observation. On bradakis.com I can run 'dig whatever_host' and it works just fine, using bradakis.com as the DNS server. But 'dig bradakis.com' takes a long time to finally return a SERVFAIL error. This is frustrating.

Your domain is wasatchfoodies.com, and your name server is ns.wasatchfoodies.com.

There are two problems with this setup:

Your NS record points to a name within the same zone. This is perfectly legal, but results in a chicken-and-egg problem: You can't resolve records in the domain wasatchfoodies.com without querying ns.wasatchfoodies.com, and you can't query the latter because you can't resolve any records in the former.

For this to work, you need a glue record; an extra A record in the .com TLD, pointing to the IP address of ns.wasatchfoodies.com. Which leads us to the second issue:
There exists an official Internet policy that says every domain needs at least two authoritative name servers (see paragraph #2 in section 4.1 of RFC 1034). With only one, the registrar should refuse to create the necessary pointers (and glue records, if required) in the TLD.

Perhaps your registrar failed to enforce the name server redundancy requirement policy until recently.

mjbradakis · 10-15-2019, 03:56 PM

Okay, I found out what happened. Yes, ns1.bradakis.com is in the bradakis.com domain, obviously. But ns2.bradakis.com is on another host in another domain. It was rebooted a few days ago after a power outage that lasted longer than the UPS could cover. It came up with port 53 blocked, so it was not serving up DNS info for bradakis.com.

So all the domains with the zone files that have been working fine for years are working fine once more. But I do have to look into the glue record with the domain registrar, it seems.

mjb.