Re: DNSSEC migration sanity check
Not sure I understand why you need to do anything except change the authoritative NS records in the zone and in the delegation at the registrar. You also only really need to decrease the TTL on the NS records, not all of the records in the zone. Why touch any keys and the corresponding DS records? Are we missing some complication in your deployment? On Wed, Aug 19, 2020 at 11:44 AM John W. Blue via bind-users wrote: > > We are in the process of moving from one IPAM vendor to another. > > > > All of our zones are DNSSEC signed and the TTL’s have been lowered to 300 > seconds. > > > > At a high level, the playbook is to update the registrar with names/IP > addresses of the new servers and update the DSKEY. Depending on the time of > the day that the cutover actually happens at we know the process to request > of the registrar an out of band data push so the new servers will be seen by > the open Internet. > > > > A suggestion have been put forth that we should unsign our zones prior to > migration but I am skeptical of the benefits of doing so. > > > > Are we missing something obvious? > > > > John > > ___ > 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 ___ 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
DNSSEC migration sanity check
We are in the process of moving from one IPAM vendor to another. All of our zones are DNSSEC signed and the TTL's have been lowered to 300 seconds. At a high level, the playbook is to update the registrar with names/IP addresses of the new servers and update the DSKEY. Depending on the time of the day that the cutover actually happens at we know the process to request of the registrar an out of band data push so the new servers will be seen by the open Internet. A suggestion have been put forth that we should unsign our zones prior to migration but I am skeptical of the benefits of doing so. Are we missing something obvious? John ___ 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
Re: Error "Query section mismatch : got"
On 20 Aug 2020, at 00:41, Matus UHLAR - fantomas wrote: On Wed, Aug 19, 2020 at 7:42 AM Matus UHLAR - fantomas 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 NSEC2.212.125.in-addr.arpa. NS RRSIG NSEC 199.212.125.in-addr.arpa. 3600 IN RRSIG NSEC 13 5 3600 20200917160047 20200818150047 30887 125.in-addr.arpa. 5ixPuj/J+cDFSDwxy3MSMs1xkmpGrdzhrmjiodo6CkEBazwUxojGfIYU R5MNZCbDoMZEF4Fq8eL9lcsZgrBctA== ;; Received 321 bytes from 203.119.95.53#53(ns2.apnic.net) in 255 ms delegation from vietel to vietelidc: 0-24.199.212.125.in-addr.arpa. 86400 IN NS ns.viettelidc.com.vn. 0-24.199.212.125.in-addr.arpa. 86400 IN NS ns2.viettelidc.com.vn. 0-24.199.212.125.in-addr.arpa. 86400 IN NS ns1.viettelidc.com.vn. ;; Received 160 bytes from 203.113.188.2#53(dns2.vietel.com.vn) in 367 ms zone 199.212.125.in-addr.arpa. at vietelidc who is supposed to provide 0-24.199.212.125.in-addr.arpa: 199.212.125.in-addr.arpa. 2560 IN SOA ns.viettelidc.com.vn. hostmaster.199.212.125.in-addr.arpa. 1597850355 16384 2048 1048576 2560 ;; Received 129 bytes from 115.84.181.10#53(ns2.viettelidc.com.vn) in 291 ms vietelidc is in this case the problem: 1. they block DNS over TCP 2. they should have configured zone 0-24.199.212.125.in-addr.arpa although it's possible that viettelidc.com.vn asked vietel.com.vn to delegate 199.212.125.in-addr.arpa. and vietel.com.vn messed it up... -- Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/ Warning: I wish NOT to receive e-mail advertising to this address. Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu. If Barbie is so popular, why do you have to buy her friends? ___ 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
Re: Error "Query section mismatch : got"
> On 20 Aug 2020, at 00:41, Matus UHLAR - fantomas wrote:
>
>> On Wed, Aug 19, 2020 at 7:42 AM Matus UHLAR - fantomas
>> wrote:
>>> again, why you query for 250.0-24.199.212.125.in-addr.arpa
>>> under normal circumstances there's no point of querying that name.
>
> On 19.08.20 10:05, tale via bind-users wrote:
>> Well yes and no. While an individual user would typically not,
>> resolvers sure will. While trying to resolve
>> 250.199.212.125.in-addr.arpa, it will eventually get to
>> 250.199.212.125.in-addr.arpa CNAME 250.0-24.199.212.125.in-addr.arpa.
>
> my question is why would anyone do this, as this apparently does not make
> sense.
Presumably because they don’t know that APNIC can delegate the /24s that make
up the /17 independently of each other.
> someone (vietel) illogically delegated whole /24 subnet to broken servers:
>
> 199.212.125.in-addr.arpa. 86400 IN NS dns2.vietel.com.vn.
> 199.212.125.in-addr.arpa. 86400 IN NS dns1.vietel.com.vn.
>
> 0.199.212.125.in-addr.arpa has address 125.235.4.59
> 1.199.212.125.in-addr.arpa is an alias for 1.0-24.199.212.125.in-addr.arpa.
> ...
> 255.199.212.125.in-addr.arpa is an alias for
> 255.0-24.199.212.125.in-addr.arpa.
>
>
>> Then it will need to resolve the canonical name, and a response like
>> the original one that was shown will be clearly buggy.
>>
>> I say "possibly" because from my vantage, all three of
>> ns{,1,2}.viettelidc.com.vn, the authorities for
>> 0-24.199.212.125.in-addr.arpa, are giving fine answers right now (on
>> udp; blocked on tcp). This includes the originally reported problem
>> IP, 115.84.177.8
>
>
>
> --
> Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/
> Warning: I wish NOT to receive e-mail advertising to this address.
> Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu.
> Fucking windows! Bring Bill Gates! (Southpark the movie)
> ___
> Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
> from this list
>
> ISC funds the development of this software with paid support subscriptions.
> Contact us at https://www.isc.org/contact/ for more information.
>
>
> bind-users mailing list
> bind-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: ma...@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
Re: Error "Query section mismatch : got"
On Wed, Aug 19, 2020 at 7:42 AM Matus UHLAR - fantomas
wrote:
again, why you query for 250.0-24.199.212.125.in-addr.arpa
under normal circumstances there's no point of querying that name.
On 19.08.20 10:05, tale via bind-users wrote:
Well yes and no. While an individual user would typically not,
resolvers sure will. While trying to resolve
250.199.212.125.in-addr.arpa, it will eventually get to
250.199.212.125.in-addr.arpa CNAME 250.0-24.199.212.125.in-addr.arpa.
my question is why would anyone do this, as this apparently does not make
sense.
someone (vietel) illogically delegated whole /24 subnet to broken servers:
199.212.125.in-addr.arpa. 86400 IN NS dns2.vietel.com.vn.
199.212.125.in-addr.arpa. 86400 IN NS dns1.vietel.com.vn.
0.199.212.125.in-addr.arpa has address 125.235.4.59
1.199.212.125.in-addr.arpa is an alias for 1.0-24.199.212.125.in-addr.arpa.
...
255.199.212.125.in-addr.arpa is an alias for 255.0-24.199.212.125.in-addr.arpa.
Then it will need to resolve the canonical name, and a response like
the original one that was shown will be clearly buggy.
I say "possibly" because from my vantage, all three of
ns{,1,2}.viettelidc.com.vn, the authorities for
0-24.199.212.125.in-addr.arpa, are giving fine answers right now (on
udp; blocked on tcp). This includes the originally reported problem
IP, 115.84.177.8
--
Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/
Warning: I wish NOT to receive e-mail advertising to this address.
Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu.
Fucking windows! Bring Bill Gates! (Southpark the movie)
___
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
Re: Error "Query section mismatch : got"
On Wed, Aug 19, 2020 at 7:42 AM Matus UHLAR - fantomas
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
___
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
Re: Error "Query section mismatch : got"
On 19.08.20 17:40, Smile TV wrote: I query the PTR Resource Record that is hosted on DNS Server/ 115.84.177.8 (reverse zone: 250.0-24.199.212.125.in-addr.arpa). However, There is a difference between when querying directly the PTR RR and querying Any RR. The results of two case below: *Case 1: Query the PTR RR directly, i meet the error: "Question section mismatch" like:* dig @115.84.177.8 250.0-24.199.212.125.in-addr.arpa ptr ;; Question section mismatch: got 255.0.199.212.in-addr.arpa/PTR/IN ;; Question section mismatch: got 255.0.199.212.in-addr.arpa/PTR/IN ;; Question section mismatch: got 255.0.199.212.in-addr.arpa/PTR/IN What is the error "Query section mismatch"? and the why? Can anybody help me! you asked for: 250.0-24.199.212.125.in-addr.arpa but got: 255.0.199.212.in-addr.arpa that's different therefore the mismatch. Why do you query for 250.0-24.199.212.125.in-addr.arpa by the way? *Case 2: Query Any RR, the result like here* dig @115.84.177.8 250.0-24.199.212.125.in-addr.arpa any ; <<>> DiG 9.10.4-P3 <<>> @115.84.177.8 250.0-24.199.212.125.in-addr.arpa any ; (1 server found) ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 12424 ;; flags: qr aa rd; QUERY: 1, ANSWER: 2, AUTHORITY: 3, ADDITIONAL: 21 ;; WARNING: recursion requested but not available ;; QUESTION SECTION: ;250.0-24.199.212.125.in-addr.arpa. IN ANY ;; ANSWER SECTION: 250.0-24.199.212.125.in-addr.arpa. 360 IN PTR smtp.vss.gov.vn. 250.0-24.199.212.125.in-addr.arpa. 360 IN PTR baohiemxahoi.gov.vn. ;; AUTHORITY SECTION: 199.212.125.in-addr.arpa. 360 IN NS ns.viettelidc.com.vn. 199.212.125.in-addr.arpa. 360 IN NS ns1.viettelidc.com.vn. 199.212.125.in-addr.arpa. 360 IN NS ns2.viettelidc.com.vn. I got the same results for both queries, but UDP is allowed while TCP is refused. - no matter if I ask for any or for ptr. seems that default for 'any' is TCP, while for 'ptr' the default is UDP. TCP is required for working DNS - they should not block it. again, why you query for 250.0-24.199.212.125.in-addr.arpa ? under normal circumstances there's no point of querying that name. there -- Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/ Warning: I wish NOT to receive e-mail advertising to this address. Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu. Microsoft dick is soft to do no harm ___ 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
Error "Query section mismatch : got"
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 ___ 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
