1. Forum
  2. Usenet
  3. COMP.PROTOCOLS.DNS.BIND

  • Error "Query section mismatch : got"

    From Smile TV@21:1/5 to All on Wed Aug 19 17:40:03 2020
    Copy: [email protected]

    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

    <div dir="ltr"><div>Hi all!<br></div><div><br></div><div><div>    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.</div><div>    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> dig @<a href="http://115.84.177.8">115.84.177.8</a> 250.0-24.199.212.125.in-addr.arpa ptr<br>;;<span style="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.199.212.in-addr.arpa/PTR/IN<br></div><div><br></div><div><b>Case 2: Query Any RR, the result like here</b><
    </div><div><br></div><div> dig @<a href="http://115.84.177.8">115.84.177.8</a> 250.0-24.199.212.125.in-addr.arpa any<br><br>; &lt;&lt;&gt;&gt; DiG 9.10.4-P3 &lt;&lt;&gt;&gt; @<a href="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>;; WARNING: recursion
    requested but not available<br><br>;; QUESTION SECTION:<br>;250.0-24.199.212.125.in-addr.arpa. IN  ANY<br><br><span style="background-color:rgb(255,255,0)">;; ANSWER SECTION:<br>250.0-24.199.212.125.in-addr.arpa. 360 IN PTR   <a href="http://smtp.vss.
    gov.vn">smtp.vss.gov.vn</a>.<br>250.0-24.199.212.125.in-addr.arpa. 360 IN PTR   <a href="http://baohiemxahoi.gov.vn">baohiemxahoi.gov.vn</a>.<br></span><br>;; AUTHORITY SECTION:<br>199.212.125.in-addr.arpa. 360   IN      NS      <a href="http://
    ns.viettelidc.com.vn">ns.viettelidc.com.vn</a>.<br>199.212.125.in-addr.arpa. 360   IN      NS      <a href="http://ns1.viettelidc.com.vn">ns1.viettelidc.com.vn</a>.<br>199.212.125.in-addr.arpa. 360   IN      NS      <a href="http://ns2.
    viettelidc.com.vn">ns2.viettelidc.com.vn</a>.<br></div><div><br></div><div>What is the error &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>

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Matus UHLAR - fantomas@21:1/5 to Smile TV on Wed Aug 19 13:41:33 2020
    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, [email protected] ; 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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From tale@21:1/5 to bind-users on Wed Aug 19 10:05:50 2020
    On Wed, Aug 19, 2020 at 7:42 AM Matus UHLAR - fantomas
    <[email protected]> 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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Matus UHLAR - fantomas@21:1/5 to tale via bind-users on Wed Aug 19 16:41:10 2020
    On Wed, Aug 19, 2020 at 7:42 AM Matus UHLAR - fantomas
    <[email protected]> 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, [email protected] ; 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)

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Mark Andrews@21:1/5 to Matus UHLAR - fantomas on Thu Aug 20 00:59:56 2020
    Copy: [email protected]

    On 20 Aug 2020, at 00:41, Matus UHLAR - fantomas <[email protected]> wrote:

    On Wed, Aug 19, 2020 at 7:42 AM Matus UHLAR - fantomas
    <[email protected]> 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, [email protected] ; 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
    [email protected]
    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: [email protected]

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Matus UHLAR - fantomas@21:1/5 to Mark Andrews on Wed Aug 19 17:24:38 2020
    On 20 Aug 2020, at 00:41, Matus UHLAR - fantomas <[email protected]> wrote: >>
    On Wed, Aug 19, 2020 at 7:42 AM Matus UHLAR - fantomas
    <[email protected]> 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, [email protected] ; 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?

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Smile TV@21:1/5 to Mark Andrews on Fri Aug 21 09:28:12 2020
    Copy: [email protected] (Matus UHLAR - fantomas)
    Copy: [email protected]

    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 <[email protected]> đã viết:



    On 20 Aug 2020, at 00:41, Matus UHLAR - fantomas <[email protected]>
    wrote:

    On Wed, Aug 19, 2020 at 7:42 AM Matus UHLAR - fantomas
    <[email protected]> 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, [email protected] ; 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
    [email protected]
    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: [email protected]

    _______________________________________________
    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
    [email protected]
    https://lists.isc.org/mailman/listinfo/bind-users


    <div dir="ltr"><div>
    <span class="gmail-im">&gt; my question is why would anyone do this, as this apparently does not make<br>
    &gt; sense.</span> <br></div><div><br></div><div>
    <span class="gmail-tlid-translation gmail-translation" lang="en"><span title="" class="gmail-">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 &quot;SERVFAIL&quot; error code so
    I tried to query directly to the hosting that managed it to determine the cause.</span></span>

    </div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">Vào Th 4, 19 thg 8, 2020 vào lúc 22:00 Mark Andrews &lt;<a href="mailto:[email protected]">[email protected]</a>&gt; đã viết:<br></div><blockquote class="gmail_quote" style="
    margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><br>

    &gt; On 20 Aug 2020, at 00:41, Matus UHLAR - fantomas &lt;<a href="mailto:[email protected]" target="_blank">[email protected]</a>&gt; wrote:<br>
    &gt; <br>
    &gt;&gt; On Wed, Aug 19, 2020 at 7:42 AM Matus UHLAR - fantomas<br>
    &gt;&gt; &lt;<a href="mailto:[email protected]" target="_blank">[email protected]</a>&gt; wrote:<br>
    &gt;&gt;&gt; again, why you query for 250.0-24.199.212.125.in-addr.arpa<br> &gt;&gt;&gt; under normal circumstances there&#39;s no point of querying that name.<br>
    &gt; <br>
    &gt; On 19.08.20 10:05, tale via bind-users wrote:<br>
    &gt;&gt; Well yes and no.   While an individual user would typically not,<br> &gt;&gt; resolvers sure will.  While trying to resolve<br>
    &gt;&gt; 250.199.212.125.in-addr.arpa, it will eventually get to<br>
    &gt;&gt; 250.199.212.125.in-addr.arpa CNAME 250.0-24.199.212.125.in-addr.arpa.<br>
    &gt; <br>
    &gt; my question is why would anyone do this, as this apparently does not make<br>
    &gt; sense.<br>

    Presumably because they don’t know that APNIC can delegate the /24s that make<br>
    up the /17 independently of each other.<br>

    &gt; someone (vietel) illogically delegated whole /24 subnet to broken servers:<br>
    &gt; <br>
    &gt; 199.212.125.in-addr.arpa. 86400 IN      NS      <a href="http://dns2.vietel.com.vn" rel="noreferrer" target="_blank">dns2.vietel.com.vn</a>.<br>
    &gt; 199.212.125.in-addr.arpa. 86400 IN      NS      <a href="http://dns1.vietel.com.vn" rel="noreferrer" target="_blank">dns1.vietel.com.vn</a>.<br>
    &gt; <br>
    &gt; 0.199.212.125.in-addr.arpa has address 125.235.4.59<br>
    &gt; 1.199.212.125.in-addr.arpa is an alias for 1.0-24.199.212.125.in-addr.arpa.<br>
    &gt; ...<br>
    &gt; 255.199.212.125.in-addr.arpa is an alias for 255.0-24.199.212.125.in-addr.arpa.<br>
    &gt; <br>
    &gt; <br>
    &gt;&gt; Then it will need to resolve the canonical name, and a response like<br>
    &gt;&gt; the original one that was shown will be clearly buggy.<br>
    &gt;&gt; <br>
    &gt;&gt; I say &quot;possibly&quot; because from my vantage, all three of<br> &gt;&gt; ns{,1,2}.<a href="http://viettelidc.com.vn" rel="noreferrer" target="_blank">viettelidc.com.vn</a>, the authorities for<br>
    &gt;&gt; 0-24.199.212.125.in-addr.arpa, are giving fine answers right now (on<br>
    &gt;&gt; udp; blocked on tcp).   This includes the originally reported problem<br>
    &gt;&gt; IP, 115.84.177.8<br>
    &gt; <br>
    &gt; <br>
    &gt; <br>
    &gt; -- <br>
    &gt; Matus UHLAR - fantomas, <a href="mailto:[email protected]" target="_blank">[email protected]</a> ; <a href="http://www.fantomas.sk/" rel="noreferrer" target="_blank">http://www.fantomas.sk/</a><br>
    &gt; Warning: I wish NOT to receive e-mail advertising to this address.<br> &gt; Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu.<br> &gt; Fucking windows! Bring Bill Gates! (Southpark the movie)<br>
    &gt; _______________________________________________<br>
    &gt; Please visit <a href="https://lists.isc.org/mailman/listinfo/bind-users" rel="noreferrer" target="_blank">https://lists.isc.org/mailman/listinfo/bind-users</a> to unsubscribe from this list<br>
    &gt; <br>
    &gt; ISC funds the development of this software with paid support subscriptions. Contact us at <a href="https://www.isc.org/contact/" rel="noreferrer" target="_blank">https://www.isc.org/contact/</a> for more information.<br>
    &gt; <br>
    &gt; <br>
    &gt; bind-users mailing list<br>
    &gt; <a href="mailto:[email protected]" target="_blank">[email protected]</a><br>
    &gt; <a href="https://lists.isc.org/mailman/listinfo/bind-users" rel="noreferrer" target="_blank">https://lists.isc.org/mailman/listinfo/bind-users</a><br>

    -- <br>
    Mark Andrews, ISC<br>
    1 Seymour St., Dundas Valley, NSW 2117, Australia<br>
    PHONE: +61 2 9871 4742              INTERNET: <a href="mailto:[email protected]" target="_blank">[email protected]</a><br>

    _______________________________________________<br>
    Please visit <a href="https://lists.isc.org/mailman/listinfo/bind-users" rel="noreferrer" target="_blank">https://lists.isc.org/mailman/listinfo/bind-users</a> to unsubscribe from this list<br>

    ISC funds the development of this software with paid support subscriptions. Contact us at <a href="https://www.isc.org/contact/" rel="noreferrer" target="_blank">https://www.isc.org/contact/</a> for more information.<br>


    bind-users mailing list<br>
    <a href="mailto:[email protected]" target="_blank">[email protected]</a><br>
    <a href="https://lists.isc.org/mailman/listinfo/bind-users" rel="noreferrer" target="_blank">https://lists.isc.org/mailman/listinfo/bind-users</a><br>
    </blockquote></div>

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Smile TV@21:1/5 to All on Fri Aug 21 09:20:36 2020
    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 < [email protected]> đã viết:

    On 20 Aug 2020, at 00:41, Matus UHLAR - fantomas <[email protected]> wrote:

    On Wed, Aug 19, 2020 at 7:42 AM Matus UHLAR - fantomas
    <[email protected]> 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, [email protected] ; 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
    [email protected]
    https://lists.isc.org/mailman/listinfo/bind-users


    <div dir="ltr"><div>
    <span class="gmail-tlid-translation gmail-translation" lang="en"><span title="" class="gmail-">As for Viettel, I don&#39;t know how they configure it.</span><br><span title="" class="gmail-">But when I use a server on another network, the result is as
    follows:</span></span>

    </div><div><br></div><div>; &lt;&lt;&gt;&gt; DiG 9.6-ESV-R8 &lt;&lt;&gt;&gt; @1<span style="background-color:rgb(255,255,0)">15.84.177.8 250.0-24.199.212.125.in-addr.arpa ptr</span></div>; (1 server found)<br>;; global options: +cmd<br>;; Got answer:<br>;
    ; -&gt;&gt;HEADER&lt;&lt;- opcode: QUERY, status: NOERROR, id: 52626<br>;; flags: qr aa rd; QUERY: 1, ANSWER: 2, AUTHORITY: 3, ADDITIONAL: 0<br>;; WARNING: recursion requested but not available<br><br>;; QUESTION SECTION:<br>;250.0-24.199.212.125.in-addr.
    arpa. IN  PTR<br><br><span style="background-color:rgb(255,255,0)">;; ANSWER SECTION:<br>250.0-24.199.212.125.in-addr.arpa. 360 IN PTR   <a href="http://smtp.vss.gov.vn">smtp.vss.gov.vn</a>.<br>250.0-24.199.212.125.in-addr.arpa. 360 IN PTR   <a href="
    http://baohiemxahoi.gov.vn">baohiemxahoi.gov.vn</a>.</span><br><br>;; AUTHORITY SECTION:<br>199.212.125.in-addr.arpa. 360   IN      NS      <a href="http://ns.viettelidc.com.vn">ns.viettelidc.com.vn</a>.<br>199.212.125.in-addr.arpa. 360   IN    
     NS      <a href="http://ns1.viettelidc.com.vn">ns1.viettelidc.com.vn</a>.<br>199.212.125.in-addr.arpa. 360   IN      NS      <a href="http://ns2.viettelidc.com.vn">ns2.viettelidc.com.vn</a>.<br><br>;; Query time: 26 msec<br>;; SERVER: 115.84.
    177.8#53(115.84.177.8)<br>;; WHEN: Fri Aug 21 09:18:35 2020<br><div>;; MSG SIZE  rcvd: 175</div><div><br></div><div>Chinhlk<br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">Vào Th 4, 19 thg 8, 2020 vào lúc 22:25 Matus
    UHLAR - fantomas &lt;<a href="mailto:[email protected]">[email protected]</a>&gt; đã viết:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">&gt;&gt; On 20 Aug 2020, at
    00:41, Matus UHLAR - fantomas &lt;<a href="mailto:[email protected]" target="_blank">[email protected]</a>&gt; wrote:<br>
    &gt;&gt;<br>
    &gt;&gt;&gt; On Wed, Aug 19, 2020 at 7:42 AM Matus UHLAR - fantomas<br> &gt;&gt;&gt; &lt;<a href="mailto:[email protected]" target="_blank">[email protected]</a>&gt; wrote:<br>
    &gt;&gt;&gt;&gt; again, why you query for 250.0-24.199.212.125.in-addr.arpa<br> &gt;&gt;&gt;&gt; under normal circumstances there&#39;s no point of querying that name.<br>
    &gt;&gt;<br>
    &gt;&gt; On 19.08.20 10:05, tale via bind-users wrote:<br>
    &gt;&gt;&gt; Well yes and no.   While an individual user would typically not,<br>
    &gt;&gt;&gt; resolvers sure will.  While trying to resolve<br>
    &gt;&gt;&gt; 250.199.212.125.in-addr.arpa, it will eventually get to<br> &gt;&gt;&gt; 250.199.212.125.in-addr.arpa CNAME 250.0-24.199.212.125.in-addr.arpa.<br>
    &gt;&gt;<br>
    &gt;&gt; my question is why would anyone do this, as this apparently does not make<br>
    &gt;&gt; sense.<br>

    On 20.08.20 00:59, Mark Andrews wrote:<br>
    &gt;Presumably because they don’t know that APNIC can delegate the /24s that make<br>
    &gt;up the /17 independently of each other.<br>

    even if not, they can fetch whole /24 from their customer (requiring<br> customer to add their NSes as long).<br>

    but, yes, in case of very incompetent customer they can require such<br> delegation.<br>


    &gt;&gt; someone (vietel) illogically delegated whole /24 subnet to broken servers:<br>
    &gt;&gt;<br>
    &gt;&gt; 199.212.125.in-addr.arpa. 86400 IN      NS      <a href="http://dns2.vietel.com.vn" rel="noreferrer" target="_blank">dns2.vietel.com.vn</a>.<br>
    &gt;&gt; 199.212.125.in-addr.arpa. 86400 IN      NS      <a href="http://dns1.vietel.com.vn" rel="noreferrer" target="_blank">dns1.vietel.com.vn</a>.<br>
    &gt;&gt;<br>
    &gt;&gt; 0.199.212.125.in-addr.arpa has address 125.235.4.59<br>
    &gt;&gt; 1.199.212.125.in-addr.arpa is an alias for 1.0-24.199.212.125.in-addr.arpa.<br>
    &gt;&gt; ...<br>
    &gt;&gt; 255.199.212.125.in-addr.arpa is an alias for 255.0-24.199.212.125.in-addr.arpa.<br>

    delegation from apnic to vietel:<br>

    199.212.125.in-addr.arpa. 86400 IN      NS      <a href="http://dns2.vietel.com.vn" rel="noreferrer" target="_blank">dns2.vietel.com.vn</a>.<br>
    199.212.125.in-addr.arpa. 86400 IN      NS      <a href="http://dns1.vietel.com.vn" rel="noreferrer" target="_blank">dns1.vietel.com.vn</a>.<br>
    199.212.125.in-addr.arpa. 3600  IN      NSEC    2.212.125.in-addr.arpa. NS RRSIG NSEC<br>
    199.212.125.in-addr.arpa. 3600  IN      RRSIG   NSEC 13 5 3600 20200917160047 20200818150047 30887 125.in-addr.arpa. 5ixPuj/J+cDFSDwxy3MSMs1xkmpGrdzhrmjiodo6CkEBazwUxojGfIYU R5MNZCbDoMZEF4Fq8eL9lcsZgrBctA==<br>
    ;; Received 321 bytes from 203.119.95.53#53(<a href="http://ns2.apnic.net" rel="noreferrer" target="_blank">ns2.apnic.net</a>) in 255 ms<br>

    delegation from vietel to vietelidc:<br>

    0-24.199.212.125.in-addr.arpa. 86400 IN NS      <a href="http://ns.viettelidc.com.vn" rel="noreferrer" target="_blank">ns.viettelidc.com.vn</a>.<br>
    0-24.199.212.125.in-addr.arpa. 86400 IN NS      <a href="http://ns2.viettelidc.com.vn" rel="noreferrer" target="_blank">ns2.viettelidc.com.vn</a>.<br>
    0-24.199.212.125.in-addr.arpa. 86400 IN NS      <a href="http://ns1.viettelidc.com.vn" rel="noreferrer" target="_blank">ns1.viettelidc.com.vn</a>.<br>
    ;; Received 160 bytes from 203.113.188.2#53(<a href="http://dns2.vietel.com.vn" rel="noreferrer" target="_blank">dns2.vietel.com.vn</a>) in 367 ms<br>


    zone 199.212.125.in-addr.arpa. at vietelidc who is supposed to provide<br> 0-24.199.212.125.in-addr.arpa:<br>

    199.212.125.in-addr.arpa. 2560  IN      SOA     <a href="http://ns.viettelidc.com.vn" rel="noreferrer" target="_blank">ns.viettelidc.com.vn</a>. hostmaster.199.212.125.in-addr.arpa. 1597850355 16384 2048 1048576 2560<br>
    ;; Received 129 bytes from 115.84.181.10#53(<a href="http://ns2.viettelidc.com.vn" rel="noreferrer" target="_blank">ns2.viettelidc.com.vn</a>) in 291 ms<br>


    vietelidc is in this case the problem:<br>

    1. they block DNS over TCP<br>
    2. they should have configured zone 0-24.199.212.125.in-addr.arpa<br>

    although it&#39;s possible that <a href="http://viettelidc.com.vn" rel="noreferrer" target="_blank">viettelidc.com.vn</a> asked <a href="http://vietel.com.vn" rel="noreferrer" target="_blank">vietel.com.vn</a> to delegate 199.212.125.in-addr.arpa.<br>
    and <a href="http://vietel.com.vn" rel="noreferrer" target="_blank">vietel.com.vn</a> messed it up...<br>



    -- <br>
    Matus UHLAR - fantomas, <a href="mailto:[email protected]" target="_blank">[email protected]</a> ; <a href="http://www.fantomas.sk/" rel="noreferrer" target="_blank">http://www.fantomas.sk/</a><br>
    Warning: I wish NOT to receive e-mail advertising to this address.<br> Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu.<br>
    If Barbie is so popular, why do you have to buy her friends?<br> _______________________________________________<br>
    Please visit <a href="https://lists.isc.org/mailman/listinfo/bind-users" rel="noreferrer" target="_blank">https://lists.isc.org/mailman/listinfo/bind-users</a> to unsubscribe from this list<br>

    ISC funds the development of this software with paid support subscriptions. Contact us at <a href="https://www.isc.org/contact/" rel="noreferrer" target="_blank">https://www.isc.org/contact/</a> for more information.<br>


    bind-users mailing list<br>
    <a href="mailto:[email protected]" target="_blank">[email protected]</a><br>
    <a href="https://lists.isc.org/mailman/listinfo/bind-users" rel="noreferrer" target="_blank">https://lists.isc.org/mailman/listinfo/bind-users</a><br>
    </blockquote></div>

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Matus UHLAR - fantomas@21:1/5 to Smile TV on Fri Aug 21 11:40:41 2020
    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
    <[email protected]> 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 <[email protected]>
    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 <[email protected]> đã >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, [email protected] ; 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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)