From Newsgroup: comp.protocols.dns.bind

--000000000000a808bd05ad38a3df
Content-Type: text/plain; charset="UTF-8"

Hi all!

I query the PTR Resource Record that is hosted on DNS Server/
115.84.177.8 (reverse zone: 250.0-24.199.212.125.in-addr.arpa). However,
There is a difference between when querying directly the PTR RR and
querying Any RR.
The results of two case below:
*Case 1: Query the PTR RR directly, i meet the error: "Question section mismatch" like:*

dig @115.84.177.8 250.0-24.199.212.125.in-addr.arpa ptr
;; Question section mismatch: got 255.0.199.212.in-addr.arpa/PTR/IN
;; Question section mismatch: got 255.0.199.212.in-addr.arpa/PTR/IN
;; Question section mismatch: got 255.0.199.212.in-addr.arpa/PTR/IN

*Case 2: Query Any RR, the result like here*

dig @115.84.177.8 250.0-24.199.212.125.in-addr.arpa any

; <<>> DiG 9.10.4-P3 <<>> @115.84.177.8 250.0-24.199.212.125.in-addr.arpa
any
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 12424
;; flags: qr aa rd; QUERY: 1, ANSWER: 2, AUTHORITY: 3, ADDITIONAL: 21
;; WARNING: recursion requested but not available

;; QUESTION SECTION:
;250.0-24.199.212.125.in-addr.arpa. IN ANY

;; 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.

What is the error "Query section mismatch"? and the why? Can anybody help
me!

Thanks !
Chinhlk

--000000000000a808bd05ad38a3df
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div>Hi all!<br></div><div><br></div><div><div>=C2=A0=C2= =A0=C2=A0 I query the PTR Resource Record that is hosted on DNS Server/ 115.84.177.8

(reverse zone:=20
250.0-24.199.212.125.in-addr.arpa). However, There is a difference between = when querying directly the PTR RR and querying Any RR.</div><div>=C2=A0=C2= =A0=C2=A0 The results of two case below:</div><div><b>Case 1: Query the PTR=
RR directly, i meet the error: &quot;Question section mismatch&quot; like:= </b><br></div><div><br></div><div>=C2=A0dig @<a href=3D"http://115.84.177.8= ">115.84.177.8</a> 250.0-24.199.212.125.in-addr.arpa ptr<br>;;<span style= =3D"background-color:rgb(255,255,0)"> Question section mismatch:</span> got=
255.0.199.212.in-addr.arpa/PTR/IN<br>;; Question section mismatch: got 255= .0.199.212.in-addr.arpa/PTR/IN<br>;; Question section mismatch: got 255.0.1= 99.212.in-addr.arpa/PTR/IN<br></div><div><br></div><div><b>Case 2: Query An=
y RR, the result like here</b><br></div><div><br></div><div>=C2=A0dig @<a h= ref=3D"http://115.84.177.8">115.84.177.8</a> 250.0-24.199.212.125.in-addr.a= rpa any<br><br>; &lt;&lt;&gt;&gt; DiG 9.10.4-P3 &lt;&lt;&gt;&gt; @<a href= =3D"http://115.84.177.8">115.84.177.8</a> 250.0-24.199.212.125.in-addr.arpa=
any<br>; (1 server found)<br>;; global options: +cmd<br>;; Got answer:<br>=
;; -&gt;&gt;HEADER&lt;&lt;- opcode: QUERY, status: NOERROR, id: 12424<br>;;=
flags: qr aa rd; QUERY: 1, ANSWER: 2, AUTHORITY: 3, ADDITIONAL: 21<br>;; W= ARNING: recursion requested but not available<br><br>;; QUESTION SECTION:<b= r>;250.0-24.199.212.125.in-addr.arpa. IN =C2=A0ANY<br><br><span style=3D"ba= ckground-color:rgb(255,255,0)">;; ANSWER SECTION:<br>250.0-24.199.212.125.i= n-addr.arpa. 360 IN PTR =C2=A0 <a href=3D"http://smtp.vss.gov.vn">smtp.vss.= gov.vn</a>.<br>250.0-24.199.212.125.in-addr.arpa. 360 IN PTR =C2=A0 <a href= =3D"http://baohiemxahoi.gov.vn">baohiemxahoi.gov.vn</a>.<br></span><br>;; A= UTHORITY SECTION:<br>199.212.125.in-addr.arpa. 360 =C2=A0 IN =C2=A0 =C2=A0 = =C2=A0NS =C2=A0 =C2=A0 =C2=A0<a href=3D"http://ns.viettelidc.com.vn">ns.vie= ttelidc.com.vn</a>.<br>199.212.125.in-addr.arpa. 360 =C2=A0 IN =C2=A0 =C2=
=A0 =C2=A0NS =C2=A0 =C2=A0 =C2=A0<a href=3D"http://ns1.viettelidc.com.vn">n= s1.viettelidc.com.vn</a>.<br>199.212.125.in-addr.arpa. 360 =C2=A0 IN =C2=A0=
=C2=A0 =C2=A0NS =C2=A0 =C2=A0 =C2=A0<a href=3D"http://ns2.viettelidc.com.v= n">ns2.viettelidc.com.vn</a>.<br></div><div><br></div><div>What is the erro=
r &quot;Query section mismatch&quot;? and the why? Can anybody help me!<br>= </div><div><br></div><div>Thanks !</div><div>Chinhlk<br></div></div></div>

--000000000000a808bd05ad38a3df--
--- Synchronet 3.21d-Linux NewsLink 1.2

From Newsgroup: comp.protocols.dns.bind

On 19.08.20 17:40, Smile TV wrote:

I query the PTR Resource Record that is hosted on DNS Server/
115.84.177.8 (reverse zone: 250.0-24.199.212.125.in-addr.arpa). However, >There is a difference between when querying directly the PTR RR and
querying Any RR.
The results of two case below:
*Case 1: Query the PTR RR directly, i meet the error: "Question section >mismatch" like:*

dig @115.84.177.8 250.0-24.199.212.125.in-addr.arpa ptr
;; Question section mismatch: got 255.0.199.212.in-addr.arpa/PTR/IN
;; Question section mismatch: got 255.0.199.212.in-addr.arpa/PTR/IN
;; Question section mismatch: got 255.0.199.212.in-addr.arpa/PTR/IN

What is the error "Query section mismatch"? and the why? Can anybody help
me!

you asked for:
250.0-24.199.212.125.in-addr.arpa
but got:
255.0.199.212.in-addr.arpa

that's different therefore the mismatch.


Why do you query for 250.0-24.199.212.125.in-addr.arpa by the way?

*Case 2: Query Any RR, the result like here*

dig @115.84.177.8 250.0-24.199.212.125.in-addr.arpa any

; <<>> DiG 9.10.4-P3 <<>> @115.84.177.8 250.0-24.199.212.125.in-addr.arpa
any
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 12424
;; flags: qr aa rd; QUERY: 1, ANSWER: 2, AUTHORITY: 3, ADDITIONAL: 21
;; WARNING: recursion requested but not available

;; QUESTION SECTION:
;250.0-24.199.212.125.in-addr.arpa. IN ANY

;; 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.

I got the same results for both queries, but UDP is allowed while TCP is refused.
- no matter if I ask for any or for ptr.

seems that default for 'any' is TCP, while for 'ptr' the default is UDP.

TCP is required for working DNS - they should not block it.


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.


there
--
Matus UHLAR - fantomas, uhlar@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.
Microsoft dick is soft to do no harm
--- Synchronet 3.21d-Linux NewsLink 1.2

From Newsgroup: comp.protocols.dns.bind

On Wed, Aug 19, 2020 at 7:42 AM Matus UHLAR - fantomas
<uhlar@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.

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.
Then it will need to resolve the canonical name, and a response like
the original one that was shown will be clearly buggy.

I say "possibly" because from my vantage, all three of ns{,1,2}.viettelidc.com.vn, the authorities for
0-24.199.212.125.in-addr.arpa, are giving fine answers right now (on
udp; blocked on tcp). This includes the originally reported problem
IP, 115.84.177.8
--
tale
--- Synchronet 3.21d-Linux NewsLink 1.2

From Newsgroup: comp.protocols.dns.bind

On Wed, Aug 19, 2020 at 7:42 AM Matus UHLAR - fantomas
<uhlar@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.

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.

Then it will need to resolve the canonical name, and a response like
the original one that was shown will be clearly buggy.

I say "possibly" because from my vantage, all three of >ns{,1,2}.viettelidc.com.vn, the authorities for >0-24.199.212.125.in-addr.arpa, are giving fine answers right now (on
udp; blocked on tcp). This includes the originally reported problem
IP, 115.84.177.8

--
Matus UHLAR - fantomas, uhlar@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.
Fucking windows! Bring Bill Gates! (Southpark the movie)
--- Synchronet 3.21d-Linux NewsLink 1.2

From Newsgroup: comp.protocols.dns.bind

On 20 Aug 2020, at 00:41, Matus UHLAR - fantomas <uhlar@fantomas.sk> wrote:

On Wed, Aug 19, 2020 at 7:42 AM Matus UHLAR - fantomas
<uhlar@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.

Presumably because they donrCOt know that APNIC can delegate the /24s that make up the /17 independently of each other.

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.

Then it will need to resolve the canonical name, and a response like
the original one that was shown will be clearly buggy.

I say "possibly" because from my vantage, all three of
ns{,1,2}.viettelidc.com.vn, the authorities for
0-24.199.212.125.in-addr.arpa, are giving fine answers right now (on
udp; blocked on tcp). This includes the originally reported problem
IP, 115.84.177.8

--
Matus UHLAR - fantomas, uhlar@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.
Fucking windows! Bring Bill Gates! (Southpark the movie) _______________________________________________
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

--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: marka@isc.org
--- Synchronet 3.21d-Linux NewsLink 1.2

From Newsgroup: comp.protocols.dns.bind

On 20 Aug 2020, at 00:41, Matus UHLAR - fantomas <uhlar@fantomas.sk> wrote: >>

On Wed, Aug 19, 2020 at 7:42 AM Matus UHLAR - fantomas
<uhlar@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 donrCOt 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, uhlar@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?
--- Synchronet 3.21d-Linux NewsLink 1.2

From Newsgroup: comp.protocols.dns.bind

On 21.08.20 09:28, Smile TV wrote:

my question is why would anyone do this, as this apparently does not make
sense.

Because when I was from a server that was querying the reverse record >250.199.212.125.in-addr.arpa it gave an error with the "SERVFAIL" error
code so I tried to query directly to the hosting that managed it to
determine the cause.

your query of course makes sense under there curcumstances.

But delegating /24 subnet using RFC2317 delegation is useless, because in
fact you can delegate whole /24 directly

On Wed, Aug 19, 2020 at 7:42 AM Matus UHLAR - fantomas
<uhlar@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.

On 20 Aug 2020, at 00:41, Matus UHLAR - fantomas <uhlar@fantomas.sk>
wrote:
my question is why would anyone do this, as this apparently does not make >> > sense.

V|ao Th 4, 19 thg 8, 2020 va|Co lu|Uc 22:00 Mark Andrews <marka@isc.org> -a|u >vib|+t:

Presumably because they donrCOt know that APNIC can delegate the /24s that >> make
up the /17 independently of each other.

--
Matus UHLAR - fantomas, uhlar@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.
How does cat play with mouse? cat /dev/mouse
--- Synchronet 3.21d-Linux NewsLink 1.2