Or do what should have been done in the first place and be a unlisted secondary of 1.66.136.193.in-addr.arpa. This way David you track the changes your ISP makes to the zone as customers come and go. Your ISP should let you transfer this zone as it is REQUIRED for your reverse lookups to work when you are temporally disconnected.
Any ISP that offers these delegations should be allowing their customers to transfer the zone that contains the CNAMEs for the customer address space by default. Mark > On 4 Nov 2022, at 16:36, Grant Taylor via bind-users > <bind-users@lists.isc.org> wrote: > > On 11/4/22 10:07 AM, David Carvalho via bind-users wrote: >> My reverse zone file > > What is the origin of your zone file? 0-28.66.136.193.in-addr.arpa.? > >> 1.0-28.66.136.193.in-addr.arpa. IN A 193.136.66.1 > > You seem to be using RFC 2317 Classless IN-ADDR.ARPA delegation. > > As such, your reverse DNS is /dependent/ upon the parent zone; > 66.136.193.in-addr.arpa., where the Classless IN-ADDR.ARPA delegation CNAME > records exist. E.g. > > 1.66.136.193.in-addr.arpa. IN CNAME 1.0-28.66.136.193.in-addr.arpa. > > It is likely this -- almost certainly -- external dependency was missing > while your Internet connections was down that prevented your systems from > being able to resolve reverse DNS. > > Two options come to mind: > > 1) Create a bogus 66.136.193.in-addr.arpa. zone locally to host the 2317 > CNAMEs. -- This will likely have some side effects that need to be > mitigated. > 2) Leverage Response Policy Zone(s) to try to influence the lookup as others > suggested. E.g. cause 1.66.136.193.in-addr.arpa. to become > 1.0-28.66.136.193.in-addr.arpa. locally. -- I'd have to read about how to > do this. > > Aside: I see no need for 1.0-28.66.136.193.in-addr.arpa. to have an A > record. But I don't see any problem with having it either. > >> 1.0-28.66.136.193.in-addr.arpa. IN A 193.136.66.1 >> ; Reverse mapping >> 1 IN PTR dns.di.ubi.pt. >> ... > > These are the types of PTR records that I would expect to see in a reverse > DNS context. > > > > -- > Grant. . . . > unix || die > > -- > 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 -- 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
