• 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.18a-Linux NewsLink 1.113
  • 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.18a-Linux NewsLink 1.113
  • 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.18a-Linux NewsLink 1.113
  • 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.18a-Linux NewsLink 1.113
  • 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 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, 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.18a-Linux NewsLink 1.113
  • 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 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, 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.18a-Linux NewsLink 1.113
  • From Smile TV@chinhlk.ptit@gmail.com to bind-users on Fri Aug 21 09:20:36 2020
    From Newsgroup: comp.protocols.dns.bind

    --0000000000000a3b5805ad59e5c7
    Content-Type: text/plain; charset="UTF-8"
    Content-Transfer-Encoding: quoted-printable

    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=C3=A0o Th 4, 19 thg 8, 2020 va=CC=80o lu=CC=81c 22:25 Matus UHLAR - fanto= mas <
    uhlar@fantomas.sk> =C4=91=C3=A3 vi=E1=BA=BFt:

    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 don=E2=80=99t 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. N=
    S
    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=3D=3D
    ;; 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? _______________________________________________
    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


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

    <div dir=3D"ltr"><div>
    <span class=3D"gmail-tlid-translation gmail-translation" lang=3D"en"><span = title=3D"" class=3D"gmail-">As for Viettel, I don&#39;t know how they confi= gure it.</span><br><span title=3D"" class=3D"gmail-">But when I use a serve=
    r 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=3D"background-color:rgb(255,255,0)">15.84.177.8 250.0-24.19= 9.212.125.in-addr.arpa ptr</span></div>; (1 server found)<br>;; global opti= ons: +cmd<br>;; Got answer:<br>;; -&gt;&gt;HEADER&lt;&lt;- opcode: QUERY, s= tatus: NOERROR, id: 52626<br>;; flags: qr aa rd; QUERY: 1, ANSWER: 2, AUTHO= RITY: 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 =C2= =A0PTR<br><br><span style=3D"background-color:rgb(255,255,0)">;; ANSWER SEC= TION:<br>250.0-24.199.212.125.in-addr.arpa. 360 IN PTR =C2=A0 <a href=3D"ht= tp://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>.</span><br><br>;; AUTHORITY SECTION:<br>199.212.125.in-addr.arp=
    a. 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.viettelidc.com.vn</a>.<br>199.212.125.in-addr.a= rpa. 360 =C2=A0 IN =C2=A0 =C2=A0 =C2=A0NS =C2=A0 =C2=A0 =C2=A0<a href=3D"ht= tp://ns1.viettelidc.com.vn">ns1.viettelidc.com.vn</a>.<br>199.212.125.in-ad= dr.arpa. 360 =C2=A0 IN =C2=A0 =C2=A0 =C2=A0NS =C2=A0 =C2=A0 =C2=A0<a href= =3D"http://ns2.viettelidc.com.vn">ns2.viettelidc.com.vn</a>.<br><br>;; Quer=
    y 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 =C2=A0rcvd: 175</div><div><br></d= iv><div>Chinhlk<br></div></div><br><div class=3D"gmail_quote"><div dir=3D"l= tr" class=3D"gmail_attr">V=C3=A0o Th 4, 19 thg 8, 2020 va=CC=80o lu=CC=81c = 22:25 Matus UHLAR - fantomas &lt;<a href=3D"mailto:uhlar@fantomas.sk">uhlar= @fantomas.sk</a>&gt; =C4=91=C3=A3 vi=E1=BA=BFt:<br></div><blockquote class= =3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rg= b(204,204,204);padding-left:1ex">&gt;&gt; On 20 Aug 2020, at 00:41, Matus U= HLAR - fantomas &lt;<a href=3D"mailto:uhlar@fantomas.sk" target=3D"_blank">= uhlar@fantomas.sk</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=3D"mailto:uhlar@fantomas.sk" target=3D"_blank">uhl= ar@fantomas.sk</a>&gt; wrote:<br>
    &gt;&gt;&gt;&gt; again, why you query for 250.0-24.199.212.125.in-addr.arpa=

    &gt;&gt;&gt;&gt; under normal circumstances there&#39;s no point of queryin=
    g 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.=C2=A0 =C2=A0While an individual user would ty= pically not,<br>
    &gt;&gt;&gt; resolvers sure will.=C2=A0 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-add= r.arpa.<br>
    &gt;&gt;<br>
    &gt;&gt; my question is why would anyone do this, as this apparently does n=
    ot make<br>
    &gt;&gt; sense.<br>

    On 20.08.20 00:59, Mark Andrews wrote:<br>
    &gt;Presumably because they don=E2=80=99t 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=C2=A0 =C2=A0 =C2=A0 NS=C2=A0 = =C2=A0 =C2=A0 <a href=3D"http://dns2.vietel.com.vn" rel=3D"noreferrer" targ= et=3D"_blank">dns2.vietel.com.vn</a>.<br>
    &gt;&gt; 199.212.125.in-addr.arpa. 86400 IN=C2=A0 =C2=A0 =C2=A0 NS=C2=A0 = =C2=A0 =C2=A0 <a href=3D"http://dns1.vietel.com.vn" rel=3D"noreferrer" targ= et=3D"_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-a= ddr.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=C2=A0 =C2=A0 =C2=A0 NS=C2=A0 =C2=A0 =C2=
    =A0 <a href=3D"http://dns2.vietel.com.vn" rel=3D"noreferrer" target=3D"_bla= nk">dns2.vietel.com.vn</a>.<br>
    199.212.125.in-addr.arpa. 86400 IN=C2=A0 =C2=A0 =C2=A0 NS=C2=A0 =C2=A0 =C2=
    =A0 <a href=3D"http://dns1.vietel.com.vn" rel=3D"noreferrer" target=3D"_bla= nk">dns1.vietel.com.vn</a>.<br>
    199.212.125.in-addr.arpa. 3600=C2=A0 IN=C2=A0 =C2=A0 =C2=A0 NSEC=C2=A0 =C2=
    =A0 2.212.125.in-addr.arpa. NS RRSIG NSEC<br>
    199.212.125.in-addr.arpa. 3600=C2=A0 IN=C2=A0 =C2=A0 =C2=A0 RRSIG=C2=A0 =C2= =A0NSEC 13 5 3600 20200917160047 20200818150047 30887 125.in-addr.arpa. 5ix= Puj/J+cDFSDwxy3MSMs1xkmpGrdzhrmjiodo6CkEBazwUxojGfIYU R5MNZCbDoMZEF4Fq8eL9l= csZgrBctA=3D=3D<br>
    ;; Received 321 bytes from 203.119.95.53#53(<a href=3D"http://ns2.apnic.net=
    " rel=3D"noreferrer" target=3D"_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=C2=A0 =C2=A0 =C2=A0 <a href=3D"h= ttp://ns.viettelidc.com.vn" rel=3D"noreferrer" target=3D"_blank">ns.viettel= idc.com.vn</a>.<br>
    0-24.199.212.125.in-addr.arpa. 86400 IN NS=C2=A0 =C2=A0 =C2=A0 <a href=3D"h= ttp://ns2.viettelidc.com.vn" rel=3D"noreferrer" target=3D"_blank">ns2.viett= elidc.com.vn</a>.<br>
    0-24.199.212.125.in-addr.arpa. 86400 IN NS=C2=A0 =C2=A0 =C2=A0 <a href=3D"h= ttp://ns1.viettelidc.com.vn" rel=3D"noreferrer" target=3D"_blank">ns1.viett= elidc.com.vn</a>.<br>
    ;; Received 160 bytes from 203.113.188.2#53(<a href=3D"http://dns2.vietel.c= om.vn" rel=3D"noreferrer" target=3D"_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=C2=A0 IN=C2=A0 =C2=A0 =C2=A0 SOA=C2=A0 =C2=
    =A0 =C2=A0<a href=3D"http://ns.viettelidc.com.vn" rel=3D"noreferrer" target= =3D"_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=3D"http://ns2.viettelid= c.com.vn" rel=3D"noreferrer" target=3D"_blank">ns2.viettelidc.com.vn</a>) i=
    n 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=3D"http://viettelidc.com.vn" rel=3D= "noreferrer" target=3D"_blank">viettelidc.com.vn</a> asked <a href=3D"http:= //vietel.com.vn" rel=3D"noreferrer" target=3D"_blank">vietel.com.vn</a> to = delegate 199.212.125.in-addr.arpa.<br>
    and <a href=3D"http://vietel.com.vn" rel=3D"noreferrer" target=3D"_blank">v= ietel.com.vn</a> messed it up...<br>



    -- <br>
    Matus UHLAR - fantomas, <a href=3D"mailto:uhlar@fantomas.sk" target=3D"_bla= nk">uhlar@fantomas.sk</a> ; <a href=3D"http://www.fantomas.sk/" rel=3D"nore= ferrer" target=3D"_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=3D"https://lists.isc.org/mailman/listinfo/bind-users" = rel=3D"noreferrer" target=3D"_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=3D"https://www.isc.org/contact/" rel=3D"noreferrer" = target=3D"_blank">https://www.isc.org/contact/</a> for more information.<br=



    bind-users mailing list<br>
    <a href=3D"mailto:bind-users@lists.isc.org" target=3D"_blank">bind-users@li= sts.isc.org</a><br>
    <a href=3D"https://lists.isc.org/mailman/listinfo/bind-users" rel=3D"norefe= rrer" target=3D"_blank">https://lists.isc.org/mailman/listinfo/bind-users</= a><br>
    </blockquote></div>

    --0000000000000a3b5805ad59e5c7--
    --- Synchronet 3.18a-Linux NewsLink 1.113
  • From Smile TV@chinhlk.ptit@gmail.com to Mark Andrews on Fri Aug 21 09:28:12 2020
    From Newsgroup: comp.protocols.dns.bind

    --00000000000032e6cd05ad5a003b
    Content-Type: text/plain; charset="UTF-8"
    Content-Transfer-Encoding: quoted-printable

    my question is why would anyone do this, as this apparently does not mak=
    e
    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=C3=A0o Th 4, 19 thg 8, 2020 va=CC=80o lu=CC=81c 22:00 Mark Andrews <marka= @isc.org> =C4=91=C3=A3
    vi=E1=BA=BFt:



    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 ma=
    ke
    sense.

    Presumably because they don=E2=80=99t know that APNIC can delegate the /2=
    4s 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

    _______________________________________________
    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


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

    <div dir=3D"ltr"><div>
    <span class=3D"gmail-im">&gt; my question is why would anyone do this, as t= his apparently does not make<br>
    &gt; sense.</span> <br></div><div><br></div><div>
    <span class=3D"gmail-tlid-translation gmail-translation" lang=3D"en"><span = title=3D"" class=3D"gmail-">Because when I was from a server that was query= ing the reverse record 250.199.212.125.in-addr.arpa it gave an error with t=
    he &quot;SERVFAIL&quot; error code so I tried to query directly to the host= ing that managed it to determine the cause.</span></span>

    </div></div><br><div class=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail_= attr">V=C3=A0o Th 4, 19 thg 8, 2020 va=CC=80o lu=CC=81c 22:00 Mark Andrews = &lt;<a href=3D"mailto:marka@isc.org">marka@isc.org</a>&gt; =C4=91=C3=A3 vi= =E1=BA=BFt:<br></div><blockquote class=3D"gmail_quote" style=3D"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=3D"mailto= :uhlar@fantomas.sk" target=3D"_blank">uhlar@fantomas.sk</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=3D"mailto:uhlar@fantomas.sk" target=3D"_blank">uhlar@f= antomas.sk</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 th=
    at name.<br>
    &gt; <br>
    &gt; On 19.08.20 10:05, tale via bind-users wrote:<br>
    &gt;&gt; Well yes and no.=C2=A0 =C2=A0While an individual user would typica= lly not,<br>
    &gt;&gt; resolvers sure will.=C2=A0 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.ar= pa.<br>
    &gt; <br>
    &gt; my question is why would anyone do this, as this apparently does not m= ake<br>
    &gt; sense.<br>

    Presumably because they don=E2=80=99t 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 serv= ers:<br>
    &gt; <br>
    &gt; 199.212.125.in-addr.arpa. 86400 IN=C2=A0 =C2=A0 =C2=A0 NS=C2=A0 =C2=A0=
    =C2=A0 <a href=3D"http://dns2.vietel.com.vn" rel=3D"noreferrer" target=3D"= _blank">dns2.vietel.com.vn</a>.<br>
    &gt; 199.212.125.in-addr.arpa. 86400 IN=C2=A0 =C2=A0 =C2=A0 NS=C2=A0 =C2=A0=
    =C2=A0 <a href=3D"http://dns1.vietel.com.vn" rel=3D"noreferrer" target=3D"= _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-a= ddr.arpa.<br>
    &gt; <br>
    &gt; <br>
    &gt;&gt; Then it will need to resolve the canonical name, and a response li= ke<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<b=

    &gt;&gt; ns{,1,2}.<a href=3D"http://viettelidc.com.vn" rel=3D"noreferrer" t= arget=3D"_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).=C2=A0 =C2=A0This includes the originally rep= orted problem<br>
    &gt;&gt; IP, 115.84.177.8<br>
    &gt; <br>
    &gt; <br>
    &gt; <br>
    &gt; -- <br>
    &gt; Matus UHLAR - fantomas, <a href=3D"mailto:uhlar@fantomas.sk" target=3D= "_blank">uhlar@fantomas.sk</a> ; <a href=3D"http://www.fantomas.sk/" rel=3D= "noreferrer" target=3D"_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.<b=

    &gt; Fucking windows! Bring Bill Gates! (Southpark the movie)<br>
    &gt; _______________________________________________<br>
    &gt; Please visit <a href=3D"https://lists.isc.org/mailman/listinfo/bind-us= ers" rel=3D"noreferrer" target=3D"_blank">https://lists.isc.org/mailman/lis= tinfo/bind-users</a> to unsubscribe from this list<br>
    &gt; <br>
    &gt; ISC funds the development of this software with paid support subscript= ions. Contact us at <a href=3D"https://www.isc.org/contact/" rel=3D"norefer= rer" target=3D"_blank">https://www.isc.org/contact/</a> for more informatio= n.<br>
    &gt; <br>
    &gt; <br>
    &gt; bind-users mailing list<br>
    &gt; <a href=3D"mailto:bind-users@lists.isc.org" target=3D"_blank">bind-use= rs@lists.isc.org</a><br>
    &gt; <a href=3D"https://lists.isc.org/mailman/listinfo/bind-users" rel=3D"n= oreferrer" target=3D"_blank">https://lists.isc.org/mailman/listinfo/bind-us= ers</a><br>

    -- <br>
    Mark Andrews, ISC<br>
    1 Seymour St., Dundas Valley, NSW 2117, Australia<br>
    PHONE: +61 2 9871 4742=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 INTE= RNET: <a href=3D"mailto:marka@isc.org" target=3D"_blank">marka@isc.org</a><=


    _______________________________________________<br>
    Please visit <a href=3D"https://lists.isc.org/mailman/listinfo/bind-users" = rel=3D"noreferrer" target=3D"_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=3D"https://www.isc.org/contact/" rel=3D"noreferrer" = target=3D"_blank">https://www.isc.org/contact/</a> for more information.<br=



    bind-users mailing list<br>
    <a href=3D"mailto:bind-users@lists.isc.org" target=3D"_blank">bind-users@li= sts.isc.org</a><br>
    <a href=3D"https://lists.isc.org/mailman/listinfo/bind-users" rel=3D"norefe= rrer" target=3D"_blank">https://lists.isc.org/mailman/listinfo/bind-users</= a><br>
    </blockquote></div>

    --00000000000032e6cd05ad5a003b--
    --- Synchronet 3.18a-Linux NewsLink 1.113
  • 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ào Th 4, 19 thg 8, 2020 vào lúc 22:00 Mark Andrews <marka@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, 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.18a-Linux NewsLink 1.113