As for Viettel, I don't know how they configure it. But when I use a server on another network, the result is as follows:
; <<>> DiG 9.6-ESV-R8 <<>> @115.84.177.8 250.0-24.199.212.125.in-addr.arpa ptr ; (1 server found) ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 52626 ;; flags: qr aa rd; QUERY: 1, ANSWER: 2, AUTHORITY: 3, ADDITIONAL: 0 ;; WARNING: recursion requested but not available ;; QUESTION SECTION: ;250.0-24.199.212.125.in-addr.arpa. IN PTR ;; ANSWER SECTION: 250.0-24.199.212.125.in-addr.arpa. 360 IN PTR smtp.vss.gov.vn. 250.0-24.199.212.125.in-addr.arpa. 360 IN PTR baohiemxahoi.gov.vn. ;; AUTHORITY SECTION: 199.212.125.in-addr.arpa. 360 IN NS ns.viettelidc.com.vn. 199.212.125.in-addr.arpa. 360 IN NS ns1.viettelidc.com.vn. 199.212.125.in-addr.arpa. 360 IN NS ns2.viettelidc.com.vn. ;; Query time: 26 msec ;; SERVER: 115.84.177.8#53(115.84.177.8) ;; WHEN: Fri Aug 21 09:18:35 2020 ;; MSG SIZE rcvd: 175 Chinhlk Vào Th 4, 19 thg 8, 2020 vào lúc 22:25 Matus UHLAR - fantomas < uh...@fantomas.sk> đã viết: > >> On 20 Aug 2020, at 00:41, Matus UHLAR - fantomas <uh...@fantomas.sk> > wrote: > >> > >>> On Wed, Aug 19, 2020 at 7:42 AM Matus UHLAR - fantomas > >>> <uh...@fantomas.sk> wrote: > >>>> again, why you query for 250.0-24.199.212.125.in-addr.arpa > >>>> under normal circumstances there's no point of querying that name. > >> > >> On 19.08.20 10:05, tale via bind-users wrote: > >>> Well yes and no. While an individual user would typically not, > >>> resolvers sure will. While trying to resolve > >>> 250.199.212.125.in-addr.arpa, it will eventually get to > >>> 250.199.212.125.in-addr.arpa CNAME 250.0-24.199.212.125.in-addr.arpa. > >> > >> my question is why would anyone do this, as this apparently does not > make > >> sense. > > On 20.08.20 00:59, Mark Andrews wrote: > >Presumably because they don’t know that APNIC can delegate the /24s that > make > >up the /17 independently of each other. > > even if not, they can fetch whole /24 from their customer (requiring > customer to add their NSes as long). > > but, yes, in case of very incompetent customer they can require such > delegation. > > > >> someone (vietel) illogically delegated whole /24 subnet to broken > servers: > >> > >> 199.212.125.in-addr.arpa. 86400 IN NS dns2.vietel.com.vn. > >> 199.212.125.in-addr.arpa. 86400 IN NS dns1.vietel.com.vn. > >> > >> 0.199.212.125.in-addr.arpa has address 125.235.4.59 > >> 1.199.212.125.in-addr.arpa is an alias for > 1.0-24.199.212.125.in-addr.arpa. > >> ... > >> 255.199.212.125.in-addr.arpa is an alias for > 255.0-24.199.212.125.in-addr.arpa. > > delegation from apnic to vietel: > > 199.212.125.in-addr.arpa. 86400 IN NS dns2.vietel.com.vn. > 199.212.125.in-addr.arpa. 86400 IN NS dns1.vietel.com.vn. > 199.212.125.in-addr.arpa. 3600 IN NSEC 2.212.125.in-addr.arpa. NS > RRSIG NSEC > 199.212.125.in-addr.arpa. 3600 IN RRSIG NSEC 13 5 3600 > 20200917160047 20200818150047 30887 125.in-addr.arpa. > 5ixPuj/J+cDFSDwxy3MSMs1xkmpGrdzhrmjiodo6CkEBazwUxojGfIYU > R5MNZCbDoMZEF4Fq8eL9lcsZgrBctA== > ;; Received 321 bytes from 203.119.95.53#53(ns2.apnic.net) in 255 ms > > delegation from vietel to vietelidc: > > 0-24.199.212.125.in-addr.arpa. 86400 IN NS ns.viettelidc.com.vn. > 0-24.199.212.125.in-addr.arpa. 86400 IN NS ns2.viettelidc.com.vn. > 0-24.199.212.125.in-addr.arpa. 86400 IN NS ns1.viettelidc.com.vn. > ;; Received 160 bytes from 203.113.188.2#53(dns2.vietel.com.vn) in 367 ms > > > zone 199.212.125.in-addr.arpa. at vietelidc who is supposed to provide > 0-24.199.212.125.in-addr.arpa: > > 199.212.125.in-addr.arpa. 2560 IN SOA ns.viettelidc.com.vn. > hostmaster.199.212.125.in-addr.arpa. 1597850355 16384 2048 1048576 2560 > ;; Received 129 bytes from 115.84.181.10#53(ns2.viettelidc.com.vn) in 291 > ms > > > vietelidc is in this case the problem: > > 1. they block DNS over TCP > 2. they should have configured zone 0-24.199.212.125.in-addr.arpa > > although it's possible that viettelidc.com.vn asked vietel.com.vn to > delegate 199.212.125.in-addr.arpa. > and vietel.com.vn messed it up... > > > > -- > Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/ > Warning: I wish NOT to receive e-mail advertising to this address. > Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu. > If Barbie is so popular, why do you have to buy her friends? > _______________________________________________ > Please visit https://lists.isc.org/mailman/listinfo/bind-users to > unsubscribe from this list > > ISC funds the development of this software with paid support > subscriptions. Contact us at https://www.isc.org/contact/ for more > information. > > > bind-users mailing list > bind-users@lists.isc.org > https://lists.isc.org/mailman/listinfo/bind-users >
_______________________________________________ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
