Groups | Search | Server Info | Login | Register
Groups > comp.protocols.dns.bind > #16053
| From | tale <d.lawrence@salesforce.com> |
|---|---|
| Newsgroups | comp.protocols.dns.bind |
| Subject | Re: Error "Query section mismatch : got" |
| Date | 2020-08-19 10:05 -0400 |
| Message-ID | <mailman.807.1597845926.942.bind-users@lists.isc.org> (permalink) |
| References | <CA+N48Xf8vKph42T4xq_KgnwjzpQV1YVboWztm6CmPcMok6_GQA@mail.gmail.com> <20200819114133.GA6272@fantomas.sk> <CAGrdBBuZgP3oR3Q5zJjR6W-p8zB3GD-ggYPp0CFXE6mAdPfYiA@mail.gmail.com> |
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
Back to comp.protocols.dns.bind | Previous | Next | Find similar
Re: Error "Query section mismatch : got" tale <d.lawrence@salesforce.com> - 2020-08-19 10:05 -0400
csiph-web