• Error "Query section mismatch : got"

    From Smile TV@chinhlk.ptit@gmail.com to bind-users on Wed Aug 19 17:40:03 2020
    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 Matus UHLAR - fantomas@uhlar@fantomas.sk to bind-users on Wed Aug 19 13:41:33 2020
    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 tale@d.lawrence@salesforce.com to bind-users on Wed Aug 19 10:05:50 2020
    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 Matus UHLAR - fantomas@uhlar@fantomas.sk to bind-users on Wed Aug 19 16:41:10 2020
    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 Mark Andrews@marka@isc.org to Matus UHLAR - fantomas on Thu Aug 20 00:59:56 2020
    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 Matus UHLAR - fantomas@uhlar@fantomas.sk to bind-users on Wed Aug 19 17:24:38 2020
    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 Matus UHLAR - fantomas@uhlar@fantomas.sk to bind-users on Fri Aug 21 11:40:41 2020
    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