Failing to resolve seacom.mu domain from google public dns .

95 views
Skip to first unread message

wkam...@gmail.com

unread,
May 18, 2018, 10:16:15 AM5/18/18
to public-dns-discuss
We failing to query resources on the seacom.mu network from google dns servers , however whilst using other public  DNS servers  we can . Please can you check if there is a issue . Please see results below .



thecomputer:~ watz$ traceroute -d 8.8.8.8
traceroute to 8.8.8.8 (8.8.8.8), 64 hops max, 52 byte packets
 1  192.168.3.254 (192.168.3.254)  3.894 ms  2.294 ms  1.882 ms
 2  ge-0-3-990.or-01-jnb.za.seacomnet.com (105.28.96.254)  2.504 ms  1.675 ms  1.297 ms
 3  vl-24.es-07-jnb.za.seacomnet.com (105.27.115.5)  6.035 ms  3.309 ms  2.847 ms
 4  xe-0-0-25.es-35-jnb.za.seacomnet.com (105.16.10.145)  9.287 ms  3.312 ms  4.002 ms
 5  xe-0-2-0.er-06-jnb.za.seacomnet.com (105.16.9.237)  2.832 ms  2.414 ms  2.074 ms
 6  xe-0-0-0-4.cr-01-jnb.za.seacomnet.com (105.16.9.141)  4.709 ms
    xe-0-1-0-0.cr-02-jnb.za.seacomnet.com (105.16.10.237)  10.627 ms  9.558 ms
 7  ae-4-0.pp-01-jnb.za.seacomnet.com (105.16.29.8)  4.509 ms
    ae-3-0.pp-01-jnb.za.seacomnet.com (105.16.28.8)  5.445 ms  4.213 ms
 8  72.14.194.70 (72.14.194.70)  4.603 ms  2.785 ms  6.473 ms
 9  72.14.239.117 (72.14.239.117)  2.783 ms
    72.14.239.53 (72.14.239.53)  5.093 ms
    72.14.239.117 (72.14.239.117)  2.753 ms
10  google-public-dns-a.google.com (8.8.8.8)  2.469 ms  2.590 ms  2.574 ms
thecomputer:~ watz$

thecomputer:~ watz$ nslookup -debug seacom.mu 8.8.8.8
Server: 8.8.8.8
Address: 8.8.8.8#53

------------
    QUESTIONS:
seacom.mu, type = A, class = IN
    ANSWERS:
    AUTHORITY RECORDS:
    ADDITIONAL RECORDS:
------------
** server can't find seacom.mu: SERVFAIL


thecomputer:~ watz$ nslookup -debug -type=AAAA seacom.mu 2001:4860:4860::8888
Server: 2001:4860:4860::8888
Address: 2001:4860:4860::8888#53

------------
    QUESTIONS:
seacom.mu, type = AAAA, class = IN
    ANSWERS:
    AUTHORITY RECORDS:
    ADDITIONAL RECORDS:
------------
** server can't find seacom.mu: SERVFAIL


thecomputer:~ watz$ nslookup -debug seacom.mu 4.2.2.1
Server: 4.2.2.1
Address: 4.2.2.1#53

------------
    QUESTIONS:
seacom.mu, type = A, class = IN
    ANSWERS:
    AUTHORITY RECORDS:
    ADDITIONAL RECORDS:
------------
** server can't find seacom.mu: SERVFAIL


thecomputer:~ watz$
thecomputer:~ watz$ nslookup -debug seacom.mu 9.9.9.9
Server: 9.9.9.9
Address: 9.9.9.9#53

------------
    QUESTIONS:
seacom.mu, type = A, class = IN
    ANSWERS:
    ->  seacom.mu
internet address = 105.16.115.2
ttl = 14400
    AUTHORITY RECORDS:
    ADDITIONAL RECORDS:
------------
Non-authoritative answer:
Name: seacom.mu
Address: 105.16.115.2

Alex Dupuy

unread,
May 18, 2018, 11:35:27 AM5/18/18
to public-dns-discuss
Your delegation records return two name servers that resolve to the same IPv4 address. You can't expect this to work well, but it is hopeless when the IPv4 address is unreachable, and the IPv6 addresses (although they resolve the name server names) return REFUSED for the seacom.mu zone.

Get a working IPv4 address (or remove it) and add the seacom.mu zone to the IPv6 name servers.

$ dig +trace seacom.mu | tail -7
; Received 643 bytes from 199.7.83.42#53(l.root-servers.net) in 11 ms

;; Received 87 bytes from 204.61.216.10#53(udns1.tld.mu) in 4 ms

;; connection timed out; no servers could be reached

$ checkdelegation seacomnet.com
parent zone com:
ns3.seacomnet.com. 172800 AAAA 2c0f:feb0::3
ns3.seacomnet.com. 172800 A 41.87.126.253
ns4.seacomnet.com. 172800 AAAA 2c0f:feb0::4
ns4.seacomnet.com. 172800 A 41.87.127.253


; <<>> DiG 9.10.6 <<>> ns3.seacomnet.com. @41.87.126.253
;; global options: +cmd
;; connection timed out; no servers could be reached

$ dig +short ns3.seacomnet.com. @2c0f:feb0::4
41.87.126.253

$ dig AAAA +short ns4.seacomnet.com. @2c0f:feb0::3
2c0f:feb0::4

$ dig +nostats seacomnet.mu @2c0f:feb0::4

; <<>> DiG 9.10.6 <<>> +nostats seacomnet.mu @2c0f:feb0::4
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: REFUSED, id: 17433
;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1
;; WARNING: recursion requested but not available

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:

wkam...@gmail.com

unread,
May 19, 2018, 12:20:36 PM5/19/18
to public-dns-discuss
HI
Thanks for the response

ns3 and ns4 do not resolve to the same IP addresses. Please notice that one is .126. and the other is .127. Please check and confirm this.

Secondly, can you do a traceroute to our authoritative name servers to show us where packets could be getting filtered, if at all? do this both on IPv4 and IPv6.


Proof to show that other networks are not affected apart from Google, below is the same query (that Google did and failed) from a server in Seattle, that is on a completely different network:

psg.com:/usr/home/mtinka> dig ns3.seacomnet.com. @41.87.126.253

; <<>> DiG 9.10.7 <<>> ns3.seacomnet.com. @41.87.126.253
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 26979
;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 4
;; WARNING: recursion requested but not available

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;ns3.seacomnet.com. IN A

;; ANSWER SECTION:
ns3.seacomnet.com. 14400 IN A 41.87.126.253

;; AUTHORITY SECTION:
seacomnet.com. 14400 IN NS ns3.seacomnet.com.
seacomnet.com. 14400 IN NS ns4.seacomnet.com.

;; ADDITIONAL SECTION:
ns4.seacomnet.com. 14400 IN A 41.87.127.253
ns3.seacomnet.com. 14400 IN AAAA 2c0f:feb0::3
ns4.seacomnet.com. 14400 IN AAAA 2c0f:feb0::4

;; Query time: 134 msec
;; SERVER: 41.87.126.253#53(41.87.126.253)
;; WHEN: Sat May 19 14:43:18 UTC 2018
;; MSG SIZE rcvd: 166

psg.com:/usr/home/mtinka>

I've also added some routing information from Seattle:

psg.com:/usr/home/mtinka> traceroute -I ns3.seacomnet.com
traceroute to ns3.seacomnet.com (41.87.126.253), 64 hops max, 48 byte packets
1 r0.sea.rg.net (147.28.0.4) 0.166 ms 0.115 ms 0.116 ms
2 ge-100-0-0-15.r05.sttlwa01.us.bb.gin.ntt.net (165.254.106.17) 0.478 ms 0.469 ms 0.476 ms
3 * * *
4 ae-0.r24.nycmny01.us.bb.gin.ntt.net (129.250.4.14) 72.604 ms * 72.507 ms
5 ae-9.r24.londen12.uk.bb.gin.ntt.net (129.250.2.19) 138.366 ms 154.543 ms 138.307 ms
6 ae-21.r00.londen10.uk.bb.gin.ntt.net (129.250.4.24) 136.548 ms 136.509 ms 136.357 ms
7 213.130.48.218 (213.130.48.218) 136.007 ms 136.032 ms 136.000 ms
8 ge-0-0-0.pr-02-lhr.uk.seacomnet.com (105.16.35.7) 136.129 ms 136.132 ms 136.107 ms
9 ns3.seacomnet.com (41.87.126.253) 134.069 ms 133.968 ms 134.107 ms
psg.com:/usr/home/mtinka>

psg.com:/usr/home/mtinka> traceroute -I ns4.seacomnet.com
traceroute to ns4.seacomnet.com (41.87.127.253), 64 hops max, 48 byte packets
1 r0.sea.rg.net (147.28.0.4) 0.119 ms 0.126 ms 0.119 ms
2 ge-100-0-0-15.r05.sttlwa01.us.bb.gin.ntt.net (165.254.106.17) 0.539 ms 0.753 ms 0.468 ms
3 ae-2.r22.sttlwa01.us.bb.gin.ntt.net (129.250.2.44) 0.624 ms 0.729 ms 1.353 ms
4 ae-0.r24.nycmny01.us.bb.gin.ntt.net (129.250.4.14) 74.590 ms 82.656 ms 74.561 ms
5 ae-9.r24.londen12.uk.bb.gin.ntt.net (129.250.2.19) 140.381 ms 156.709 ms 140.516 ms
6 ae-21.r00.londen10.uk.bb.gin.ntt.net (129.250.4.24) 138.327 ms 138.662 ms 138.409 ms
7 213.130.48.218 (213.130.48.218) 138.065 ms 138.078 ms 138.056 ms
8 ge-0-0-1.pr-02-lhr.uk.seacomnet.com (105.16.34.7) 136.025 ms 136.024 ms 136.020 ms
9 ns4.seacomnet.com (41.87.127.253) 138.289 ms 138.222 ms 138.402 ms
psg.com:/usr/home/mtinka>


Alex Dupuy

unread,
May 20, 2018, 5:20:46 PM5/20/18
to public-dns-discuss
wka... wrote:
ns3 and ns4 do not resolve to the same IP addresses. Please  notice that one is .126. and the other is .127. Please check and confirm this.

Yes, you're right. This was an oversight on my part, but doesn't affect the problem.

Secondly, can you do a  traceroute to our authoritative name servers to show us where packets could be getting filtered, if at all?  do this both on IPv4 and IPv6.

I can ping all four addresses from Google networks (but cannot easily test from the specific IP addresses used for querying authoritative servers—https://developers.google.com/speed/public-dns/faq#locations):

$ sudo ping -4 -qc 3 ns3.seacomnet.com
PING ns3.seacomnet.com (41.87.126.253) 56(84) bytes of data.
--- ns3.seacomnet.com ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2003ms
rtt min/avg/max/mdev = 103.637/103.735/103.817/0.379 ms

$ sudo ping -4 -qc 3 ns4.seacomnet.com
PING ns4.seacomnet.com (41.87.127.253) 56(84) bytes of data.
--- ns4.seacomnet.com ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2003ms
rtt min/avg/max/mdev = 103.581/105.329/108.689/2.391 ms

$ sudo ping -6 -qc 3 ns3.seacomnet.com
PING ns3.seacomnet.com(ns3-6.seacomnet.com (2c0f:feb0::3)) 56 data bytes
--- ns3.seacomnet.com ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2002ms
rtt min/avg/max/mdev = 106.298/110.134/112.293/2.719 ms

$ sudo ping -6 -qc 3 ns4.seacomnet.com
PING ns4.seacomnet.com(2c0f:feb0::4) 56 data bytes
--- ns4.seacomnet.com ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 5205ms
rtt min/avg/max/mdev = 106.503/106.566/106.652/0.062 ms

Running traceroute -U (by default this sends UDP/53 packets that are not actually DNS requests, rather than ICMP packets sent with -I) shows that traffic is reaching your name server IP addresses:

$ sudo traceroute -nU ns3.seacomnet.com | sed 2,12d
traceroute to ns3.seacomnet.com (41.87.126.253), 30 hops max, 60 byte packets
12  105.16.6.5  105.135 ms  103.759 ms  103.549 ms
13  105.16.33.6  103.750 ms 105.16.32.6  103.353 ms 105.16.33.7  103.366 ms
14  41.87.126.253  103.729 ms  104.100 ms  104.080 ms

$ sudo traceroute -nU ns4.seacomnet.com | sed 2,12d
traceroute to ns4.seacomnet.com (41.87.127.253), 30 hops max, 60 byte packets
12  105.16.6.5  103.756 ms  103.668 ms  103.559 ms
13  105.16.33.6  103.494 ms  103.752 ms 105.16.32.6  103.340 ms
14  41.87.127.253  103.597 ms  103.943 ms  103.787 ms

$ sudo traceroute6 -nU ns3.seacomnet.com | sed 2,10d
traceroute to ns3.seacomnet.com (2c0f:feb0::3), 30 hops max, 80 byte packets
10  2001:4860::9:4001:c35  184.923 ms 2001:4860::9:4001:c34  103.110 ms  103.415 ms
11  2001:4860:0:12e0::7  103.635 ms  103.402 ms 2c0f:feb0:1:1::5  103.391 ms
12  2c0f:feb0:1:1::5  103.764 ms  103.675 ms  103.626 ms
13  2c0f:feb0::3  108.129 ms 2c0f:feb0:d::1:6  106.139 ms 2c0f:feb0::3  108.244 ms

$ sudo traceroute6 -nU ns4.seacomnet.com | sed 2,10d
traceroute to ns4.seacomnet.com (2c0f:feb0::4), 30 hops max, 80 byte packets
10  2001:4860::9:4001:c35  103.433 ms 2001:4860::9:4001:c34  103.081 ms 2001:4860::9:4001:c35  103.517 ms
11  2c0f:feb0:1:1::5  103.855 ms  104.214 ms  104.063 ms
12  2c0f:feb0:1:1::5  104.114 ms  104.027 ms 2c0f:feb0:d::7  106.209 ms
13  2c0f:feb0:d::7  106.580 ms 2c0f:feb0:d::6  108.061 ms 2c0f:feb0::4  106.778 ms

When I used the Google Public DNS query site (https://dns.google.com/query?name=seacom.mu&type=A&dnssec=true) I got a successful answer, with the following comment:

Response from 41.87.126.253; 3312ms resolution time exceeds 2 seconds; some clients may time out.

Disabling DNSSEC validation (https://dns.google.com/query?name=seacom.mu&type=A&dnssec=false) eliminates that warning.
The problem seems to be the fact that when Google Public DNS queries your name servers with DNSSEC_OK (DO) in EDNS, it never receives the response, presumably because the response is too large and IP fragmentation takes place, and firewalls on your network are blocking both IPv4 and IPv6 fragments. Google Public DNS initially sends queries with DNSSEC OK set, but will retry without EDNS after a while if no response is received).

$ dig +dnssec +norec seacom.mu @ns3.seacomnet.com
; <<>> DiG 9.11.2-P1-1-Debian <<>> +dnssec +norec seacom.mu @ns3.seacomnet.com
;; global options: +cmd
;; connection timed out; no servers could be reached

$ dig -6 +dnssec +norec seacom.mu @ns4.seacomnet.com
; <<>> DiG 9.11.2-P1-1-Debian <<>> -6 +dnssec +norec seacom.mu @ns4.seacomnet.com
;; global options: +cmd
;; connection timed out; no servers could be reached

$ kdig +nocrypto +tcp +dnssec +norec seacom.mu @ns3.seacomnet.com
;; ->>HEADER<<- opcode: QUERY; status: NOERROR; id: 28503
;; Flags: qr aa; QUERY: 1; ANSWER: 2; AUTHORITY: 3; ADDITIONAL: 9

;; EDNS PSEUDOSECTION:
;; Version: 0; flags: do; UDP size: 4096 B; ext-rcode: NOERROR

;; QUESTION SECTION:
;; seacom.mu.                   IN      A

;; ANSWER SECTION:
seacom.mu.              14400   IN      A       105.16.115.2
seacom.mu.              14400   IN      RRSIG   A 7 2 14400 20180617230001 20180518230001 41447 seacom.mu. [omitted]

;; AUTHORITY SECTION:
seacom.mu.              14400   IN      NS      ns4.seacomnet.com.
seacom.mu.              14400   IN      NS      ns3.seacomnet.com.
seacom.mu.              14400   IN      RRSIG   NS 7 2 14400 20180617230001 20180518230001 41447 seacom.mu. [omitted]

;; ADDITIONAL SECTION:
ns3.seacomnet.com.      14400   IN      AAAA    2c0f:feb0::3
ns4.seacomnet.com.      14400   IN      AAAA    2c0f:feb0::4
ns3.seacomnet.com.      14400   IN      A       41.87.126.253
ns4.seacomnet.com.      14400   IN      A       41.87.127.253
ns3.seacomnet.com.      14400   IN      RRSIG   A 7 3 14400 20180617230000 20180518230000 51497 seacomnet.com. [omitted]
ns3.seacomnet.com.      14400   IN      RRSIG   AAAA 7 3 14400 20180617230000 20180518230000 51497 seacomnet.com. [omitted]
ns4.seacomnet.com.      14400   IN      RRSIG   A 7 3 14400 20180617230000 20180518230000 51497 seacomnet.com. [omitted]
ns4.seacomnet.com.      14400   IN      RRSIG   AAAA 7 3 14400 20180617230000 20180518230000 51497 seacomnet.com. [omitted]

;; Received 3013 B
;; Time 2018-05-20 16:51:09 EDT
;; From 2c0f:feb0::3@53(TCP) in 106.6 ms

Note that the DNSSEC signatures in the response aren't (currently) useful since your domain does not have a corresponding DS record in the parent .MU TLD zone that would enable DNSSEC validation.

You could improve the performance of your domain by either
  • Adding a DS record for seacom.mu in the .MU TLD, and enabling minimal-responses (BIND: https://serverfault.com/a/74971, similar options may exist for other name server software)
  • Disabling DNSSEC signatures for the seacom.mu zone, so that responses are not so large that they need to be fragmented.
However, Google Public DNS does seem to be resolving your domain, as long as you wait a bit longer than 3 seconds to get an answer.


wkam...@gmail.com

unread,
May 20, 2018, 5:22:31 PM5/20/18
to public-dns-discuss
HI Team
Please close this ticket . We have resolved this on our side ,and we able to query SEACOM infrastructure using google DNS .
Reply all
Reply to author
Forward
0 new messages