Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Error "Query section mismatch : got"

492 views
Skip to first unread message

Smile TV

unread,
Aug 19, 2020, 6:41:13 AM8/19/20
to bind-...@lists.isc.org, hoa...@vnnic.vn
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

Matus UHLAR - fantomas

unread,
Aug 19, 2020, 7:41:49 AM8/19/20
to bind-...@lists.isc.org
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, 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.
Microsoft dick is soft to do no harm

tale

unread,
Aug 19, 2020, 10:06:15 AM8/19/20
to bind-users
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.
>

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

Matus UHLAR - fantomas

unread,
Aug 19, 2020, 10:41:23 AM8/19/20
to bind-...@lists.isc.org
>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.

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, 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.
Fucking windows! Bring Bill Gates! (Southpark the movie)

Mark Andrews

unread,
Aug 19, 2020, 11:00:08 AM8/19/20
to Matus UHLAR - fantomas, bind-...@lists.isc.org


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

Presumably because they don’t 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, 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.
> 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-...@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: ma...@isc.org

Matus UHLAR - fantomas

unread,
Aug 19, 2020, 11:24:51 AM8/19/20
to bind-...@lists.isc.org
>> 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?

Smile TV

unread,
Aug 20, 2020, 10:21:45 PM8/20/20
to bind-...@lists.isc.org
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:

Smile TV

unread,
Aug 20, 2020, 10:29:24 PM8/20/20
to Mark Andrews, Matus UHLAR - fantomas, bind-...@lists.isc.org
> 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.

Vào Th 4, 19 thg 8, 2020 vào lúc 22:00 Mark Andrews <ma...@isc.org> đã 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.

Presumably because they don’t 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, 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.
> 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-...@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: ma...@isc.org

Matus UHLAR - fantomas

unread,
Aug 21, 2020, 5:40:55 AM8/21/20
to bind-...@lists.isc.org
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
>> >> <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.

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

>Vào Th 4, 19 thg 8, 2020 vào lúc 22:00 Mark Andrews <ma...@isc.org> đã
>viết:
>> Presumably because they don’t know that APNIC can delegate the /24s that
>> make
>> up the /17 independently of each other.


--
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.
How does cat play with mouse? cat /dev/mouse
0 new messages