1.1.1.1 DNS in Belarus cannot resolve some domains serviced by Basnet

[user17131]

If I try to resolve bas-net.by site via 1.1.1.1 from workstation in Belarus, it fails. If I try to do the same from outside of Belarus, it resolved successfully. The same issue is for other sites in *.org.by domain zone (serviced by Basnet).

This looks like to be issue in the configuraiton of local 1.1.1.1 node in Belarus.

$ host bas-net.by 1.1.1.1
Using domain server:
Name: 1.1.1.1
Address: 1.1.1.1#53
Aliases: 

Host bas-net.by not found: 2(SERVFAIL)
$ host bas-net.by 8.8.8.8
Using domain server:
Name: 8.8.8.8
Address: 8.8.8.8#53
Aliases: 

bas-net.by has address 80.94.169.5
bas-net.by mail is handled by 10 spameat2.bas-net.by.
bas-net.by mail is handled by 20 spameat1.bas-net.by.
$ host google.com 1.1.1.1
Using domain server:
Name: 1.1.1.1
Address: 1.1.1.1#53
Aliases: 

google.com has address 142.250.185.174
google.com has IPv6 address 2a00:1450:4001:82f::200e
google.com mail is handled by 10 aspmx.l.google.com.
google.com mail is handled by 50 alt4.aspmx.l.google.com.
google.com mail is handled by 30 alt2.aspmx.l.google.com.
google.com mail is handled by 40 alt3.aspmx.l.google.com.
google.com mail is handled by 20 alt1.aspmx.l.google.com.

$ traceroute 1.1.1.1
traceroute to 1.1.1.1 (1.1.1.1), 30 hops max, 60 byte packets
 1  192.168.9.1 (192.168.9.1)  78.748 ms  78.673 ms  78.638 ms
 2  192.168.100.1 (192.168.100.1)  78.607 ms  78.613 ms  78.582 ms
 3  mm-1-0-127-178.mogilev.dynamic.pppoe.byfly.by (178.127.0.1)  82.750 ms  82.718 ms  82.686 ms
 4  93.84.80.49 (93.84.80.49)  83.055 ms 93.84.80.53 (93.84.80.53)  83.713 ms  84.771 ms
 5  core1.net.belpak.by (93.85.80.45)  82.985 ms  91.236 ms  91.207 ms
 6  ie2.net.belpak.by (93.85.80.54)  83.554 ms ie2.net.belpak.by (93.85.80.42)  112.187 ms  112.042 ms
 7  core.net.belpak.by (93.85.252.15)  111.969 ms  111.925 ms *
 8  10.100.10.1 (10.100.10.1)  111.743 ms 173-224-57-86.mck.beltelecom.by (86.57.224.173)  6.289 ms 10.100.10.1 (10.100.10.1)  6.207 ms
 9  91.149.176.210 (91.149.176.210)  6.173 ms  6.131 ms  7.025 ms
10  91.149.176.235 (91.149.176.235)  108.990 ms  108.944 ms  108.883 ms
11  one.one.one.one (1.1.1.1)  108.198 ms  108.153 ms  6.619 ms

[user75610]

Hi!

This seems related to an observation I have made. On January 4th ccTLD .by have changed all of their nameservers and created a circular dependency for their TLD nameservers. I have discussed this briefly on DNS-OARC’s dns-operations mailinglist. The circular redundancy is created due to the different TTL in the glue records in the root zone compared to the TTL in the auth zone itself (2days <-> 10min).

Here is my quick analysis (i am spacing hostnames as this thing here wouldnt let me post more than 4 links …wtf)

`–snip–
for a few days I have worked on an issue we see with our Bind resolvers of different versions regarding resolving addresses under .by. I assume it is not Bind’s fault at all but the result of a circular dependency in .by after a change of the Auth NS beginning of January but let me explain what I see.

If I start on an empty cache I query the Root NS for .by and get back these Auth NS with originally 2d TTL:

by. 130511 IN NS dns1. tld.becloudby. com.
by. 130511 IN NS dns3. tld.becloudby .com.
by. 130511 IN NS dns2. tld.becloudby. com.
by. 130511 IN NS dns5. tld.becloudby .com.
by. 130511 IN NS dns4. tld.becloudby. com.

They come with Glue A records:

dns5.tld.becloudby. com. 172800 IN A 54.180.35.203
dns4.tld.becloudby .com. 172800 IN A 184.72.17.94
dns2.tld.becloudby . com. 172800 IN A 93.125.25.73
dns1.tld.becloudby. com. 172800 IN A 93.125.25.72
dns3.tld.becloudby. com. 172800 IN A 185.98.83.4

The becloudby.com is maintained by two nameservers:

;; QUESTION SECTION:
;dns1.tld.becloudby. com. IN A

;; AUTHORITY SECTION:
becloudby. com. 172800 IN NS u1. hoster.by.
becloudby .com. 172800 IN NS u2 .hoster.by.

These machines u1+u2.hoster.by have these IP addresses:

;; QUESTION SECTION:
;u1.hoster.by. IN A

;; AUTHORITY SECTION:
hoster.by. 3600 IN NS dns2. hoster.by.
hoster.by. 3600 IN NS dns1 .hoster.by.

Asking one of them for the IP of u1.hoster.by:

;; QUESTION SECTION:
;u1.hoster.by. IN A

;; ANSWER SECTION:
u1. hoster.by. 3600 IN A 93.125.30.201

These nameservers are again under the .by TLD. If we query them for the IP of the .by TLD servers, we get a TTL of 600 and an IP:

~$ dig +norec dns1. tld.becloudby. com a @93.125.30.201 # Asking u1.hoster.by for dns1.tld.becloudy.com

;; ANSWER SECTION:
dns1.tld.becloudby. com. 600 IN A 93.125.25.72

Which now has a TTL of 600 as opposed to the TTL that the Root NS gave us (2 days).
This entry overwrites the previously received Glue A record for dns1.tld.becloudby.com which TTL is now 600.

If this cache entry expires, the following steps happen:

• We need to ask again u1.hoster.by for this IP address. This works as its TTL is longer (3600s) and we still know that IP.
• Once the cache entry of u1.hoster.by expires also, we need to go back to dns1.hoster.by and ask for the IP of u1.hoster.by. This entry is also 3600s and would expire now or later.
• Once dns1.hoster.by is expired, we still had the 2 days TTL entry for .by in our cache but without the Glues as the 2d glues have been overwritten by the 600s responses for dns1.tld.becloudby.com (reminder: the Auth NS for .BY).

So what we have left in cache are NS entries for the .BY nameservers but without IP addresses which causes a SERVFAIL in Bind. Seems to me like there is a circular dependency between those servers which is not obvious to a lot of users if e.g. their resolvers use the glues parent-centric like Google’s 8.8.8.8 NS).
–snap–
`
Guess this doesn’t help but I think someone from ccTLD .BY should take a look at this.

Cheers
Sascha

[mvavrusa]

Hi, the bas-net.by (and basnet.by) nameservers are not reachable from our PoP in Belarus. I tried to send an email to basnet to see if there’s any network filtering happening. I forwarded bas-net.by and basnet.by elsewhere as a workaround, but that’s probably not going to cover all the domains they host.