DNS SERVFAIL Error for normal dig but no error with +trace

Question

I've configured a new zone (IDN domain) at my authoritative DNS server, but it dosesn't work, when I try to troubleshiit using DIG command i receive "SERVFAIL"

dig.exe @8.8.8.8 xn--mgba6g.xn--ngbsg9e a

; <<>> DiG 9.12.3 <<>> @8.8.8.8 xn----zmcaaaqc9f5a4icedb.xn--mgberp4a5d4ar a ; (1 server found) ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 64359 ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1

but when i add +trace option it works fine!

dig.exe @8.8.8.8 xn--mgba6g.xn--ngbsg9e a +trace

I know this option is going iterative from the root down to my auth. DNS, but why the normal resolution is not working, i'm not using my resolver i'm trying from all known DNSs such as google (8.8.8.8)

Answer 1

xn--ngbsg9e is not a valid TLD, it does not appear in IANA root list at https://www.iana.org/domains/root/db.

@ and +trace are mutually exclusive: with +trace dig will start from root nameservers, so @ option is ignored.

Both with and without +trace dig will give you NXDOMAIN for this domain since its TLD does not exist. If you get any other kind of result it means something on your network is messing with DNS packets and like rewriting NXDOMAIN to point to some wildcard host.

Show your full replies.

Mine is:

$ dig @8.8.8.8 xn--mgba6g.xn--ngbsg9e a

; <<>> DiG 9.12.0 <<>> @8.8.8.8 xn--mgba6g.xn--ngbsg9e a
; (1 server found)
;; global options: +cmd
;; Sending:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 5105
;; flags: rd ad; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
; COOKIE: a6e60ed1fe2c4eef
;; QUESTION SECTION:
;xn--mgba6g.xn--ngbsg9e.    IN A

;; QUERY SIZE: 63

;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 5105
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512
;; QUESTION SECTION:
;xn--mgba6g.xn--ngbsg9e.    IN A

;; AUTHORITY SECTION:
.           23h59m59s IN SOA a.root-servers.net. nstld.verisign-grs.com. (
                2019021400 ; serial
                1800       ; refresh (30 minutes)
                900        ; retry (15 minutes)
                604800     ; expire (1 week)
                86400      ; minimum (1 day)
                )

;; Query time: 122 msec
;; SERVER: 8.8.8.8#53(8.8.8.8)
;; WHEN: Thu Feb 14 09:33:50 EST 2019
;; MSG SIZE  rcvd: 126

Now your example seems to speak also about xn----zmcaaaqc9f5a4icedb.xn--mgberp4a5d4ar, which is completely different. This TLD exists. But as you can see on http://dnsviz.net/d/xn----zmcaaaqc9f5a4icedb.xn--mgberp4a5d4ar/dnssec/ you have a DNS configuration problem. The set of nameservers recorded at parent (registry) for your domain do not match what your zone lists. You will need to go through your registrar and fix your DNS issues by making sure to use the exact same list of nameservers.

Registry has:

$ dig @n.nic.net.sa xn----zmcaaaqc9f5a4icedb.xn--mgberp4a5d4ar NS | grep "IN NS "
xn----zmcaaaqc9f5a4icedb.xn--mgberp4a5d4ar. 1h IN NS nslab1.saudi.net.sa.
xn----zmcaaaqc9f5a4icedb.xn--mgberp4a5d4ar. 1h IN NS nslab2.saudi.net.sa.

But asking these two nameservers:

• nslab1.saudi.net.sa does not seem to reply at all
• the other one gives: xn----zmcaaaqc9f5a4icedb.xn--mgberp4a5d4ar. 5m IN NS nslab1.saudi.net.sa.

(only one NS, not two).

So you need to fix both your nameservers and the content they serve.

Also you have a DNSSEC issue, the DS key published at parent does not correspond to any DNSKEY in your zone:

$ dig @n.nic.net.sa xn----zmcaaaqc9f5a4icedb.xn--mgberp4a5d4ar DS +multi

; <<>> DiG 9.12.0 <<>> @n.nic.net.sa xn----zmcaaaqc9f5a4icedb.xn--mgberp4a5d4ar DS +multi

[..]

;; ANSWER SECTION:
xn----zmcaaaqc9f5a4icedb.xn--mgberp4a5d4ar. 1h IN DS 23364 7 1 (
                42774D487FB256B3A9DBC9B1ACDBF128F0773C22 )

But:

$ dig @nslab2.saudi.net.sa xn----zmcaaaqc9f5a4icedb.xn--mgberp4a5d4ar DNSKEY gives NOERROR but no data, meaning you do not have a DNSKEY record in your zone.

You need first to remove the DS record at parent, it will only hinder your effort to put back your DNS in a working way.

PS: 8.8.8.8 is not the only public nameserver in the world, please use others too (or even better a local one!) like 1.1.1.1 or 9.9.9.9 or 80.80.80.80 or 64.6.64.6