Re: Reverse lookups not working when Internet connection failed.
On 11/7/22 9:45 AM, Fred Morris wrote: The PUBLIC DNS is not secure against eavesdropping or parallel construction and never will be. Even if the information is out there, I believe there is an exposure risk for ISPs if they do something that makes it /easy/ to correlate customer / client resources. An ISP's lawyer won't care if the customer advertises their own IP space on their website as long as the ISP is not the one to expose such information. That being said -- I assume -- we are all adults here and we can make our own informed decisions. :-) -- Grant. . . . unix || die smime.p7s Description: S/MIME Cryptographic Signature -- 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: Reverse lookups not working when Internet connection failed.
"Problems"... On Sun, 6 Nov 2022, Grant Taylor via bind-users wrote: On 11/6/22 6:39 AM, Matus UHLAR - fantomas wrote: alternatively they can choose to 0/28.66.136.193.in-addr.arpa. or 0-15.66.136.193.in-addr.arpa. instead of 0-28.66.136.193.in-addr.arpa. N.B. I've had some problems with the forward slash character "/" in domain names multiple times in the past. I'd stick with the hyphen "-" for compatibility. I've had problems with web browsers with "non-hostname" characters. I don't consider web browsers or their ilk the likely use case for resources under in-addr.arpa. There are some things I would avoid as a courtesy to others if I was so inclined: escape, completion and wildcard characters in shells and SQL implementations... -- Fred Morris -- 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: Reverse lookups not working when Internet connection failed.
Don't kid yourself. This is wishing for a security outcome which will never reach fruition because of asymmetric interests and capabilities. On Sun, 6 Nov 2022, Grant Taylor via bind-users wrote: [...] I find that $CLIENTNAME or some other stand in for the client is a potential for information lek. The PUBLIC DNS is not secure against eavesdropping or parallel construction and never will be. Just like the destruction of whois (never was a good tool) doesn't prevent reconstruction of people's networks. People like me get paid a lot of money to see that this is so, and at least in some cases I remain convinced it's a good enough idea I don't care what people think about it. I even offer software to accomplish this for free on the internet; I even leverage features of e.g. BIND to do this. I can make arguments for being generic, or provider centric, or customer centric; I can also make arguments for outright lying. Hey, choose your own adventure; other people will judge you accordingly. -- Fred Morris, internet plumber -- 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: Reverse lookups not working when Internet connection failed.
On 07.11.22 15:57, David Carvalho via bind-users wrote: Finally had the opportunity to get back to this. Having internet connection restored, everything seems to be working as supposed to. One simple query from my client and one response from my server. Output from wireshark: 1 0.0010.0.0.199 193.136.66.1DNS 85 Standard query 0x000b PTR 8.66.136.193.in-addr.arpa 2 0.016660193.136.66.110.0.0.199 DNS 204 Standard query response 0x000b PTR 8.66.136.193.in-addr.arpa CNAME 8.0-28.66.136.193.in-addr.arpa PTR meteo.di.ubi.pt NS dns.di.ubi.pt NS dns2.di.ubi.pt A 193.136.66.1 A 193.136.66.2 Just 2 packets. great, it works. But on the command line I get the following, and I'm confused why the "non-authoritive answer": Non-authoritative answer: ---here!??? 8.66.136.193.in-addr.arpa canonical name = 8.0-28.66.136.193.in-addr.arpa this happens your server is not authoritative for the 66.136.193.in-addr.arpa domain. I guess your servers don't fetch 66.136.193.in-addr.arpa from your ISP. I also wasn't able to reach your servers: 8.66.136.193.in-addr.arpa. 86400 IN CNAME 8.0-28.66.136.193.in-addr.arpa. 0-28.66.136.193.in-addr.arpa. 86400 IN NS dns2.di.ubi.pt. 0-28.66.136.193.in-addr.arpa. 86400 IN NS dns.di.ubi.pt. ;; Received 121 bytes from 193.136.2.228#53(ns02.fccn.pt) in 56 ms % dig -x 193.136.66.8 @dns.di.ubi.pt. dig: couldn't get address for 'dns.di.ubi.pt.': failure % dig -x 193.136.66.8 @dns2.di.ubi.pt. dig: couldn't get address for 'dns2.di.ubi.pt.': failure so there's another problem to solve. IN NS dns.di.ubi.pt. IN NS dns2.di.ubi.pt. looks like your servers dns.di.ubi.pt (193.136.66.1) and dns2.di.ubi.pt (193.136.66.2) aren't reachable from internet. -- 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. Linux IS user friendly, it's just selective who its friends are... -- 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: Reverse lookups not working when Internet connection failed.
Hello again. Finally had the opportunity to get back to this. Having internet connection restored, everything seems to be working as supposed to. One simple query from my client and one response from my server. Output from wireshark: 1 0.0010.0.0.199 193.136.66.1DNS 85 Standard query 0x000b PTR 8.66.136.193.in-addr.arpa 2 0.016660193.136.66.110.0.0.199 DNS 204 Standard query response 0x000b PTR 8.66.136.193.in-addr.arpa CNAME 8.0-28.66.136.193.in-addr.arpa PTR meteo.di.ubi.pt NS dns.di.ubi.pt NS dns2.di.ubi.pt A 193.136.66.1 A 193.136.66.2 Just 2 packets. But on the command line I get the following, and I'm confused why the "non-authoritive answer": Nslookup Set stype=ptr > 193.136.66.8 Server: dns.di.ubi.pt Address: 193.136.66.1 Aliases: 1.66.136.193.in-addr.arpa Non-authoritative answer: ---here!??? 8.66.136.193.in-addr.arpa canonical name = 8.0-28.66.136.193.in-addr.arpa 8.0-28.66.136.193.in-addr.arpa name = meteo.di.ubi.pt 0-28.66.136.193.in-addr.arpanameserver = dns.di.ubi.pt 0-28.66.136.193.in-addr.arpanameserver = dns2.di.ubi.pt dns.di.ubi.pt internet address = 193.136.66.1 dns2.di.ubi.pt internet address = 193.136.66.2 I believe my records are properly created, so I need to understand this before considering the steps bellow. Thanks and best regards David My reverse file again: $TTL 86400 @ IN SOA di.ubi.pt. postmaster.di.ubi.pt ( 2020040401 ; serial 28800 ; refresh 3h 7200; retry 1h 604800 ; expire 1w 86400 ) ; ttl 1d ; Servidores de nomes IN NS dns.di.ubi.pt. IN NS dns2.di.ubi.pt. 0.0-28.66.136.193.in-addr.arpa. IN A 193.136.66.0 1.0-28.66.136.193.in-addr.arpa. IN A 193.136.66.1 ... 14.0-28.66.136.193.in-addr.arpa.IN A 193.136.66.14 ; reverse mapping 1 IN PTR dns.di.ubi.pt. 2 IN PTR dns2.di.ubi.pt. ... 14 IN PTR gw.di.ubi.pt. -Original Message- From: bind-users On Behalf Of Matus UHLAR - fantomas Sent: 06 November 2022 13:39 To: bind-users@lists.isc.org Subject: Re: Reverse lookups not working when Internet connection failed. On 05.11.22 09:58, David Alexandre M. de Carvalho via bind-users wrote: >Thank you all for the replies. >For what I understand after reading your replies (I might be wrong :) >), reverse lookups fail when I have no outgoing connection because some >caching or or transfer is needed from 66.136.193.in-addr.arpa. , wich I don't >control. This is divided in several networks, 2 of them under my control. correct. Admin of that zone is supposed to: 1. create proper CNAME records: 0.66.136.193.in-addr.arpa. CNAME 0.0-28.66.136.193.in-addr.arpa. ... 15.66.136.193.in-addr.arpa. CNAME 15.0-28.66.136.193.in-addr.arpa. 2. delegate 0-28.66.136.193.in-addr.arpa. to your servers, make their servers secondary for this zone (optional) 3. allow your servers to to fetch 66.136.193.in-addr.arpa. step 1. creates proper aliases step 2. creates working delegation step 3. allows you to see reverse records when your connection is down. alternatively they can choose to 0/28.66.136.193.in-addr.arpa. or 0-15.66.136.193.in-addr.arpa. instead of 0-28.66.136.193.in-addr.arpa. >I'll have to read more carefully your suggestions to see if I find an >alternative way to achieve this only by modifying my zone files, >without messing up my current setup. I'll let you know how it goes. >> On 11/4/22 2:07 PM, Mark Andrews wrote: >>> 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. >> >> I've had enough trouble getting ISPs to support 2317 delegation period. >> I think that asking them to allow me to do a zone transfer would have >> been a hard no. >> >> I certainly don't think this would be allowed /by/ /default/. >> >> I just checked and § 5.1 of RFC 2317 mentioned having the parent do a >> secondary zone transfer of the child zone. But I don't see any >> mention of the child doing a secondary zone transfer of the parent zone. >> >> I think that would be a good idea. -- 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. Emacs is a complicated operating system without good text editor. -- Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with pa
Re: Reverse lookups not working when Internet connection failed.
On 11/6/22 11:12 AM, Carl Byington via bind-users wrote: or use $clientname.66.136.193.in-addr.arpa. as the intermediate zone which has a slight advantage when the same client has multiple disjoint parts of the same /24. On 06.11.22 20:08, Grant Taylor via bind-users wrote: I find that $CLIENTNAME or some other stand in for the client is a potential for information lek. I agree, the client may want to stay private. There is nothing inherent in the CNAME to non-identifying RNAMEs that leaks any client identifying information. Conversely the client is in charge of what information they put in the sub-zone, so it's not the ISP leaking client identifying information. -- 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. "Two words: Windows survives." - Craig Mundie, Microsoft senior strategist "So does syphillis. Good thing we have penicillin." - Matthew Alton -- 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: Reverse lookups not working when Internet connection failed.
On 11/6/22 6:39 AM, Matus UHLAR - fantomas wrote: 3. allow your servers to to fetch 66.136.193.in-addr.arpa. On 06.11.22 20:05, Grant Taylor via bind-users wrote: Is this 3rd step documented somewhere? I searched for it in RFC 2317 but didn't find it. Maybe I over looked it. This step is not necessary for classless reverse DNS delegation. This step is however necessary for OP's DNS server being able to reverse resolve its own IP range, when its connectivity is down (this the OP's question), because OP's clients will try to resolve names in 66.136.193.in-addr.arpa. alternatively they can choose to 0/28.66.136.193.in-addr.arpa. or 0-15.66.136.193.in-addr.arpa. instead of 0-28.66.136.193.in-addr.arpa. N.B. I've had some problems with the forward slash character "/" in domain names multiple times in the past. I'd stick with the hyphen "-" for compatibility. I've had no problem with that one in the past. TMTOWTDI -- 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? -- 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: Reverse lookups not working when Internet connection failed.
On 11/6/22 6:39 AM, Matus UHLAR - fantomas wrote: 3. allow your servers to to fetch 66.136.193.in-addr.arpa. Is this 3rd step documented somewhere? I searched for it in RFC 2317 but didn't find it. Maybe I over looked it. alternatively they can choose to 0/28.66.136.193.in-addr.arpa. or 0-15.66.136.193.in-addr.arpa. instead of 0-28.66.136.193.in-addr.arpa. N.B. I've had some problems with the forward slash character "/" in domain names multiple times in the past. I'd stick with the hyphen "-" for compatibility. -- Grant. . . . unix || die smime.p7s Description: S/MIME Cryptographic Signature -- 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: Reverse lookups not working when Internet connection failed.
On 11/6/22 11:12 AM, Carl Byington via bind-users wrote: or use $clientname.66.136.193.in-addr.arpa. as the intermediate zone which has a slight advantage when the same client has multiple disjoint parts of the same /24. I find that $CLIENTNAME or some other stand in for the client is a potential for information lek. There is nothing inherent in the CNAME to non-identifying RNAMEs that leaks any client identifying information. Conversely the client is in charge of what information they put in the sub-zone, so it's not the ISP leaking client identifying information. -- Grant. . . . unix || die smime.p7s Description: S/MIME Cryptographic Signature -- 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: Reverse lookups not working when Internet connection failed.
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On Sun, 2022-11-06 at 14:39 +0100, Matus UHLAR - fantomas wrote: > alternatively they can choose to 0/28.66.136.193.in-addr.arpa. or > 0-15.66.136.193.in-addr.arpa. > instead of 0-28.66.136.193.in-addr.arpa. or use $clientname.66.136.193.in-addr.arpa. as the intermediate zone which has a slight advantage when the same client has multiple disjoint parts of the same /24. -BEGIN PGP SIGNATURE- iHIEAREKADMWIQSuFMepaSkjWnTxQ5QvqPuaKVMWwQUCY2f41xUcY2FybEBmaXZl LXRlbi1zZy5jb20ACgkQL6j7milTFsHBXgCTByqT09Rrz54p7OjWMqOEmj3fnwCe LPnNvD9XwOCDCK94G4ui+uAd8Vc= =mnp9 -END PGP SIGNATURE- -- 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: Reverse lookups not working when Internet connection failed.
On 05.11.22 09:58, David Alexandre M. de Carvalho via bind-users wrote: Thank you all for the replies. For what I understand after reading your replies (I might be wrong :) ), reverse lookups fail when I have no outgoing connection because some caching or or transfer is needed from 66.136.193.in-addr.arpa. , wich I don't control. This is divided in several networks, 2 of them under my control. correct. Admin of that zone is supposed to: 1. create proper CNAME records: 0.66.136.193.in-addr.arpa. CNAME 0.0-28.66.136.193.in-addr.arpa. ... 15.66.136.193.in-addr.arpa. CNAME 15.0-28.66.136.193.in-addr.arpa. 2. delegate 0-28.66.136.193.in-addr.arpa. to your servers, make their servers secondary for this zone (optional) 3. allow your servers to to fetch 66.136.193.in-addr.arpa. step 1. creates proper aliases step 2. creates working delegation step 3. allows you to see reverse records when your connection is down. alternatively they can choose to 0/28.66.136.193.in-addr.arpa. or 0-15.66.136.193.in-addr.arpa. instead of 0-28.66.136.193.in-addr.arpa. I'll have to read more carefully your suggestions to see if I find an alternative way to achieve this only by modifying my zone files, without messing up my current setup. I'll let you know how it goes. On 11/4/22 2:07 PM, Mark Andrews wrote: 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. I've had enough trouble getting ISPs to support 2317 delegation period. I think that asking them to allow me to do a zone transfer would have been a hard no. I certainly don't think this would be allowed /by/ /default/. I just checked and § 5.1 of RFC 2317 mentioned having the parent do a secondary zone transfer of the child zone. But I don't see any mention of the child doing a secondary zone transfer of the parent zone. I think that would be a good idea. -- 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. Emacs is a complicated operating system without good text editor. -- 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: Reverse lookups not working when Internet connection failed.
On 11/5/22 4:32 AM, Ondřej Surý wrote: The IPv4 reverse zone is easy to scrape and stored for situations like this… just saying. Fair enough. Though if we're going to not officially sanctioned behavior, I'm inclined to create a local version of the 66.136.193.in-addr.arpa. zone that CNAMEs the (OP's) records of interest as necessary /and/ ""delegates the other records over to the real zone. -- It's a hack, but it works acceptably well in my experience. -- Grant. . . . unix || die smime.p7s Description: S/MIME Cryptographic Signature -- 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: Reverse lookups not working when Internet connection failed.
The IPv4 reverse zone is easy to scrape and stored for situations like this… just saying. Ondrej -- Ondřej Surý — ISC (He/Him) My working hours and your working hours may be different. Please do not feel obligated to reply outside your normal working hours. > On 5. 11. 2022, at 0:48, Grant Taylor via bind-users > wrote: > > On 11/4/22 2:07 PM, Mark Andrews wrote: >> 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. > > I've had enough trouble getting ISPs to support 2317 delegation period. I > think that asking them to allow me to do a zone transfer would have been a > hard no. > > I certainly don't think this would be allowed /by/ /default/. > > I just checked and § 5.1 of RFC 2317 mentioned having the parent do a > secondary zone transfer of the child zone. But I don't see any mention of > the child doing a secondary zone transfer of the parent zone. > > I think that would be a good idea. > > > > -- > 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 -- 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: Reverse lookups not working when Internet connection failed.
Thank you all for the replies. For what I understand after reading your replies (I might be wrong :) ), reverse lookups fail when I have no outgoing connection because some caching or or transfer is needed from 66.136.193.in-addr.arpa. , wich I don't control. This is divided in several networks, 2 of them under my control. I'll have to read more carefully your suggestions to see if I find an alternative way to achieve this only by modifying my zone files, without messing up my current setup. I'll let you know how it goes. Thanks once again. David > On 11/4/22 2:07 PM, Mark Andrews wrote: >> 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. > > I've had enough trouble getting ISPs to support 2317 delegation period. > I think that asking them to allow me to do a zone transfer would have > been a hard no. > > I certainly don't think this would be allowed /by/ /default/. > > I just checked and § 5.1 of RFC 2317 mentioned having the parent do a > secondary zone transfer of the child zone. But I don't see any mention > of the child doing a secondary zone transfer of the parent zone. > > I think that would be a good idea. > > > > -- > 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 > -- 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: Reverse lookups not working when Internet connection failed.
On 11/4/22 2:07 PM, Mark Andrews wrote: 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. I've had enough trouble getting ISPs to support 2317 delegation period. I think that asking them to allow me to do a zone transfer would have been a hard no. I certainly don't think this would be allowed /by/ /default/. I just checked and § 5.1 of RFC 2317 mentioned having the parent do a secondary zone transfer of the child zone. But I don't see any mention of the child doing a secondary zone transfer of the parent zone. I think that would be a good idea. -- Grant. . . . unix || die smime.p7s Description: S/MIME Cryptographic Signature -- 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: Reverse lookups not working when Internet connection failed.
On 11/4/22 12:09 PM, Cuttler, Brian R (HEALTH) via bind-users wrote: My pointer zones are more like Zone "28.66.136.193.in-addr.arpa.", I've never had that leading "0-" Is that typical? What does it do? I invite you to go skim RFC 2317 -- Classless IN-ADDR.ARPA Delegation. TL;DR: 2317 is a way to delegate /part/ /of/ a single class of IPs. N.B. "class" is akin to the dot boundary in dotted quad IPv4. This is important because DNS (sub)domains are delegated on the dot boundary. The idea is to turn 1.2.0.192.in-addr.arpa., which normally has the PTR record, into a CNAME to an RNAME that is in a /different/ /domain/. This is done explicitly so that the /different/ /domain/ can be delegated to someone so that they can manage their own reverse DNS PTR records. E.g.: $ORIGIN 2.0.192.in-addr.arpa. ;... ; 0-3 are directly in the 2.0.192.in-addr.arpa. zone file. 0 IN PTR test0.example.net. 1 IN PTR test1.example.net. 2 IN PTR test2.example.net. 3 IN PTR test3.example.net. ; 4-7 are aliased to records in the 4-30.2.0.192.in-addr.arpa. zone. 4 IN CNAME 4.4-30.2.0.192.in-addr.arpa. 5 IN CNAME 5.4-30.2.0.192.in-addr.arpa. 6 IN CNAME 6.4-30.2.0.192.in-addr.arpa. 7 IN CNAME 7.4-30.2.0.192.in-addr.arpa. ; 8-15 are aliased to records in the 8-29.2.0.192.in-addr.arpa. zone. 8 IN CNAME 8.8-29.2.0.192.in-addr.arpa. 9 IN CNAME 9.8-29.2.0.192.in-addr.arpa. ... 14 IN CNAME 14.8-29.2.0.192.in-addr.arpa. 15 IN CNAME 15.8-29.2.0.192.in-addr.arpa. ; delegate the 4-30.2.0.192.in-addr.arpa. zone to Customer1. 4-30IN NS ns1.customer1.example. IN NS ns2.customer1.example. ; delegate the 8-29.2.0.192.in-addr.arpa. zone to Customer2. 8-29IN NS nsA.customer2.example. IN NS nsB.customer2.example. Notice how the PTR records for 0-3 are found directly in the 2.0.192.in-addr.arpa. zone. Notice how the PTR records for 4-7 and 8-15 are aliased to records in a sub-domain. Notice how the 4-30 and 8-29 sub-domains of the 2.0.192.in-addr.arpa. zone are delegated to different entities. RFC 2317 delegates (NS records for (sub)domain) control over the PTR records to other DNS administrators via CNAME records in the parent zone. N.B. the 0-28 in the OP's examples and my 4-30 & 8-29, are using the RFC 2317 /convention/ of delegating to the - as the sub-domain to use. -- I maintain that this is a convention and is not required. -- RNAME records could just as easily have been delegated to 16.example.com and the example.com zone could have had the following record: 16 IN PTR test0x10.example.com -- Grant. . . . unix || die smime.p7s Description: S/MIME Cryptographic Signature -- 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: Reverse lookups not working when Internet connection failed.
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 > 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
RE: Reverse lookups not working when Internet connection failed.
Come to think of it I don't have the trailing dot either.
I thought the dot was to terminate domain name qualification for forwarder
records.
zone "174.50.10.in-addr.arpa" in {
type master;
file "db.10.50.174";
};
-Original Message-
From: bind-users On Behalf Of Cuttler, Brian
R (HEALTH) via bind-users
Sent: Friday, November 4, 2022 2:09 PM
To: Grant Taylor ; bind-users@lists.isc.org
Subject: RE: Reverse lookups not working when Internet connection failed.
ATTENTION: This email came from an external source. Do not open attachments or
click on links from unknown senders or unexpected emails.
My pointer zones are more like
Zone "28.66.136.193.in-addr.arpa.", I've never had that leading "0-"
Is that typical? What does it do?
-Original Message-
From: bind-users On Behalf Of Grant Taylor
via bind-users
Sent: Friday, November 4, 2022 1:07 PM
To: bind-users@lists.isc.org
Subject: Re: Reverse lookups not working when Internet connection failed.
ATTENTION: This email came from an external source. Do not open attachments or
click on links from unknown senders or unexpected emails.
On 11/4/22 10:54 AM, David Carvalho via bind-users wrote:
> Thanks for the replies.
You're welcome.
> My reverse zone in named.conf. My secondary dns gets it automatically
> daily, along with the "di.ubi.pt.".
ACK
> zone "0-28.66.136.193.in-addr.arpa." IN {
> allow-query { any; };
> type master;
> file "rev0.hosts";
> };
That confirms that the origin is in fact "0-28.66.136.193.in-addr.arpa."
(Save for any typo that I may have introduced.)
> I'll have to study more about some things you guys wrote. This is
> getting complicated
So when your system(s) try to do a reverse DNS (PTR) lookup for
193.136.66.1, it will actually do a PTR lookup for
1.66.136.193.in-addr.arpa. and fail because you don't have a copy of the
66.136.193.in-addr.arpa. zone file locally.
At least my understanding is that you have a copy of your forward zone,
and your 0-28.66.136.193.in-addr.arpa. zone. But you don't have a copy
of, nor access to, the intermediate 66.136.193.in-addr.arpa. zone that
references the 0-28.66.136.193.in-addr.arpa. zone.
Does that help?
Please feel free to ask additional questions.
--
Grant. . . .
unix || die
--
Visit
https://gcc02.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.isc.org%2Fmailman%2Flistinfo%2Fbind-usersdata=05%7C01%7Cbrian.cuttler%40health.ny.gov%7C7bd0df8a0d434f5450dd08dabe8fcfcc%7Cf46cb8ea79004d108ceb80e8c1c81ee7%7C0%7C0%7C638031822152040580%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7Csdata=OVa5%2FibLwJVyAEt5dTAQ3QBdXl%2FajqWQVLcgY2w%2FrTU%3Dreserved=0
to unsubscribe from this list
ISC funds the development of this software with paid support subscriptions.
Contact us at
https://gcc02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.isc.org%2Fcontact%2Fdata=05%7C01%7Cbrian.cuttler%40health.ny.gov%7C7bd0df8a0d434f5450dd08dabe8fcfcc%7Cf46cb8ea79004d108ceb80e8c1c81ee7%7C0%7C0%7C638031822152040580%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7Csdata=d6WQ5ypJsg8cRm6YIzLW0F%2BESiv%2Fj5MdxgEHKSDrSa0%3Dreserved=0
for more information.
bind-users mailing list
bind-users@lists.isc.org
https://gcc02.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.isc.org%2Fmailman%2Flistinfo%2Fbind-usersdata=05%7C01%7Cbrian.cuttler%40health.ny.gov%7C7bd0df8a0d434f5450dd08dabe8fcfcc%7Cf46cb8ea79004d108ceb80e8c1c81ee7%7C0%7C0%7C638031822152040580%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7Csdata=OVa5%2FibLwJVyAEt5dTAQ3QBdXl%2FajqWQVLcgY2w%2FrTU%3Dreserved=0
--
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: Reverse lookups not working when Internet connection failed.
My pointer zones are more like
Zone "28.66.136.193.in-addr.arpa.", I've never had that leading "0-"
Is that typical? What does it do?
-Original Message-
From: bind-users On Behalf Of Grant Taylor
via bind-users
Sent: Friday, November 4, 2022 1:07 PM
To: bind-users@lists.isc.org
Subject: Re: Reverse lookups not working when Internet connection failed.
ATTENTION: This email came from an external source. Do not open attachments or
click on links from unknown senders or unexpected emails.
On 11/4/22 10:54 AM, David Carvalho via bind-users wrote:
> Thanks for the replies.
You're welcome.
> My reverse zone in named.conf. My secondary dns gets it automatically
> daily, along with the "di.ubi.pt.".
ACK
> zone "0-28.66.136.193.in-addr.arpa." IN {
> allow-query { any; };
> type master;
> file "rev0.hosts";
> };
That confirms that the origin is in fact "0-28.66.136.193.in-addr.arpa."
(Save for any typo that I may have introduced.)
> I'll have to study more about some things you guys wrote. This is
> getting complicated
So when your system(s) try to do a reverse DNS (PTR) lookup for
193.136.66.1, it will actually do a PTR lookup for
1.66.136.193.in-addr.arpa. and fail because you don't have a copy of the
66.136.193.in-addr.arpa. zone file locally.
At least my understanding is that you have a copy of your forward zone,
and your 0-28.66.136.193.in-addr.arpa. zone. But you don't have a copy
of, nor access to, the intermediate 66.136.193.in-addr.arpa. zone that
references the 0-28.66.136.193.in-addr.arpa. zone.
Does that help?
Please feel free to ask additional questions.
--
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
Re: Reverse lookups not working when Internet connection failed.
On 11/4/22 11:19 AM, David Carvalho via bind-users wrote: Thanks again. You're welcome again. :-) Probably. Am I supposed to, I have just 2 segments in this network (and 2 others on another work) ? Normally no, you're not supposed to /need/ to have a copy of an intermediate zone. However, because you're using RFC 2317 Classless IN-ADDR.ARPA delegation, you have introduced additional complexity. As such, you have an additional dependency. I don't think that's a bad thing per se. But it definitely is something to keep in mind. Yes! But I never heard of intermediate zone before. As far as I know, my top domain forwards all "di.ubi.pt" requests to me and that works. The intermediate zone; 66.136.193.in-addr.arpa. is for /reverse/ /DNS/. Your "di.ubi.pt." zone is /forward/ /DNS/. There are actually multiple intermediate zones for both forward DNS; ubi.pt. and pt., and reverse DNS; 66.136.193.in-addr.arpa., 136.193.in-addr.arpa., 193.in-addr.arpa., in-addr.arpa., and arpa. It's just that the intermediate zones are hosted outside of your control. Both forward and reverse DNS chain down to zones that you do have control over hosting. The difference in behavior between forward and reverse DNS /while/ /offline/ has to do with how things work technically. Forward DNS simply looks for records of a given name in a given zone, both of which you have. Reverse DNS on the other hand translates an IP address to a FQDN to look up in the DNS system. E.g. a.b.c.d becomes d.c.b.a.in-addr.arpa Your use of RFC 2317 Classless IN-ADDR.ARPA delegation complicates things in that, d.c.b.a.in-addr.arpa. becomes d.x-y.c.b.a.in-addr.arpa. This 2317 delegation means that your client & server don't recognize that d.c.b.a.in-addr.arpa. maps to d.x-y.c.b.a.in-addr.arpa. /without/ the knowledge contained in the c.b.a.in-addr.arpa. zone. Does that help thin the mud at all? Or did I make things worse? -- Grant. . . . unix || die smime.p7s Description: S/MIME Cryptographic Signature -- 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: Reverse lookups not working when Internet connection failed.
Thanks again.
>So when your system(s) try to do a reverse DNS (PTR) lookup for 193.136.66.1,
>it will actually do a PTR lookup for 1.66.136.193.in-addr.arpa. and fail
>because you don't have a copy of the >66.136.193.in-addr.arpa. zone file
>locally.
Probably. Am I supposed to, I have just 2 segments in this network (and 2
others on another work) ?
>At least my understanding is that you have a copy of your forward zone, and
>your 0-28.66.136.193.in-addr.arpa. zone. But you don't have a copy of, nor
>access to, the intermediate >66.136.193.in-addr.arpa. zone that references the
>0-28.66.136.193.in-addr.arpa. zone.
Yes! But I never heard of intermediate zone before. As far as I know, my top
domain forwards all "di.ubi.pt" requests to me and that works.
Regards
David
-Original Message-
From: bind-users On Behalf Of Grant Taylor
via bind-users
Sent: 04 November 2022 17:07
To: bind-users@lists.isc.org
Subject: Re: Reverse lookups not working when Internet connection failed.
On 11/4/22 10:54 AM, David Carvalho via bind-users wrote:
> Thanks for the replies.
You're welcome.
> My reverse zone in named.conf. My secondary dns gets it automatically
> daily, along with the "di.ubi.pt.".
ACK
> zone "0-28.66.136.193.in-addr.arpa." IN {
> allow-query { any; };
> type master;
> file "rev0.hosts";
> };
That confirms that the origin is in fact "0-28.66.136.193.in-addr.arpa."
(Save for any typo that I may have introduced.)
> I'll have to study more about some things you guys wrote. This is
> getting complicated
So when your system(s) try to do a reverse DNS (PTR) lookup for 193.136.66.1,
it will actually do a PTR lookup for 1.66.136.193.in-addr.arpa. and fail
because you don't have a copy of the 66.136.193.in-addr.arpa. zone file locally.
At least my understanding is that you have a copy of your forward zone, and
your 0-28.66.136.193.in-addr.arpa. zone. But you don't have a copy of, nor
access to, the intermediate 66.136.193.in-addr.arpa. zone that references the
0-28.66.136.193.in-addr.arpa. zone.
Does that help?
Please feel free to ask additional questions.
--
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
Re: Reverse lookups not working when Internet connection failed.
On 11/4/22 10:54 AM, David Carvalho via bind-users wrote:
Thanks for the replies.
You're welcome.
My reverse zone in named.conf. My secondary dns gets it automatically
daily, along with the "di.ubi.pt.".
ACK
zone "0-28.66.136.193.in-addr.arpa." IN {
allow-query { any; };
type master;
file "rev0.hosts";
};
That confirms that the origin is in fact "0-28.66.136.193.in-addr.arpa."
(Save for any typo that I may have introduced.)
I'll have to study more about some things you guys wrote. This is
getting complicated
So when your system(s) try to do a reverse DNS (PTR) lookup for
193.136.66.1, it will actually do a PTR lookup for
1.66.136.193.in-addr.arpa. and fail because you don't have a copy of the
66.136.193.in-addr.arpa. zone file locally.
At least my understanding is that you have a copy of your forward zone,
and your 0-28.66.136.193.in-addr.arpa. zone. But you don't have a copy
of, nor access to, the intermediate 66.136.193.in-addr.arpa. zone that
references the 0-28.66.136.193.in-addr.arpa. zone.
Does that help?
Please feel free to ask additional questions.
--
Grant. . . .
unix || die
smime.p7s
Description: S/MIME Cryptographic Signature
--
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: Reverse lookups not working when Internet connection failed.
Hi. On Fri, 4 Nov 2022, Grant Taylor via bind-users wrote: 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. [...] 1 IN PTR dns.di.ubi.pt. This. It's really like that but within the response policy zone. It depends on how your RPZ is scoped. If you just take over the world it looks like this: $ORIGIN . $TTL 600; 10 minutes REARVIEW.M3047.NET IN SOA DEV.NULL. M3047.M3047.NET. ( 2114499; serial 30 ; refresh (30 seconds) 15 ; retry (15 seconds) 86400 ; expire (1 day) 600; minimum (10 minutes) ) NS LOCALHOST. $ORIGIN 1.0.10.in-addr.arpa.rearview.m3047.net. 207 PTR fire3-10-inch.m3047. TXT "depth=1,first=1665768627.2416348,last=1667531692.5136201,count=264,trend=3935.662293321998,update=1 667540875.2942646,score=6.057739570203342" $ORIGIN 21.100.in-addr.arpa.rearview.m3047.net. 103.0 PTR arcus-uswest.amazon.com. TXT "depth=1,first=1665810308.1564665,last=1667535958.6280398,count=152,trend=11758.670145495724,update= 1667540875.2953703,score=5.3302068902418895" $ORIGIN 24.100.in-addr.arpa.rearview.m3047.net. 64.188 PTR s2s.aniview.com. TXT "depth=2,first=1667458140.2700894,last=1667507046.0667324,count=12,trend=3481.8259883810015,update=1 That is a BIND generated zonefile. Takeaways: * The zone is rearview.m3047.net. * The zone is being used as a response policy zone. * The rewrites are fully specified WITHIN THAT ZONE: 103.0.21.100.in-addr.arpa.rearview.m3047.net. PTR arcus-uswest.amazon.com. * Note the trailing terminal dot on both the LHS and RHS. # dig -x 100.21.0.103 ;; QUESTION SECTION: ;103.0.21.100.in-addr.arpa. IN PTR ;; ANSWER SECTION: 103.0.21.100.in-addr.arpa. 300 IN PTR ec2-100-21-0-103.us-west-2.compute.amazonaws.com. ;; AUTHORITY SECTION: 0.21.100.in-addr.arpa. 300 IN NS ns2-24-us-west-2.ec2-rdns.amazonaws.com. 0.21.100.in-addr.arpa. 300 IN NS ns4-24-us-west-2.ec2-rdns.amazonaws.com. 0.21.100.in-addr.arpa. 300 IN NS ns1-24-us-west-2.ec2-rdns.amazonaws.com. 0.21.100.in-addr.arpa. 300 IN NS ns3-24-us-west-2.ec2-rdns.amazonaws.com. ;; ADDITIONAL SECTION: ns1-24-us-west-2.ec2-rdns.amazonaws.com. 300 IN A 205.251.197.77 ns4-24-us-west-2.ec2-rdns.amazonaws.com. 300 IN A 205.251.194.254 ;; SERVER: 10.0.0.220#53(10.0.0.220) # dig @10.0.0.230 -x 100.21.0.103 ;; QUESTION SECTION: ;103.0.21.100.in-addr.arpa. IN PTR ;; ANSWER SECTION: 103.0.21.100.in-addr.arpa. 5IN PTR arcus-uswest.amazon.com. ;; AUTHORITY SECTION: REARVIEW.M3047.NET. 600 IN NS LOCALHOST. ;; ADDITIONAL SECTION: REARVIEW.M3047.NET. 1 IN SOA DEV.NULL. M3047.M3047.NET. 2114509 30 15 86400 600 ;; SERVER: 10.0.0.230#53(10.0.0.230) # dig @10.0.0.220 103.0.21.100.in-addr.arpa.rearview.m3047.net. PTR ;; QUESTION SECTION: ;103.0.21.100.in-addr.arpa.rearview.m3047.net. IN PTR ;; ANSWER SECTION: 103.0.21.100.in-addr.arpa.rearview.m3047.net. 600 IN PTR arcus-uswest.amazon.com. ;; AUTHORITY SECTION: REARVIEW.M3047.NET. 600 IN NS LOCALHOST. ;; SERVER: 10.0.0.220#53(10.0.0.220) # dig @10.0.0.220 103.0.21.100.in-addr.arpa.rearview.m3047.net. TXT ;; QUESTION SECTION: ;103.0.21.100.in-addr.arpa.rearview.m3047.net. IN TXT ;; ANSWER SECTION: 103.0.21.100.in-addr.arpa.rearview.m3047.net. 600 IN TXT "depth=1,first=1665810308.1564665,last=1667535958.6280398,count=152,trend=11758.670145495724,update=1667540875.2953703,score=5.3302068902418895" ;; AUTHORITY SECTION: REARVIEW.M3047.NET. 600 IN NS LOCALHOST. ;; SERVER: 10.0.0.220#53(10.0.0.220) -- Fred Morris, internet plumber -- 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: Reverse lookups not working when Internet connection failed.
The queries should work if you query an authoritative dns server for that zone. If you are querying a recursive only server(when Internet connection is down), it won't be able to find the authoritative server and will answer only if it has valid cached answer. Once that cached answer expires or is not there, a recursive only server will fail to give you the answer you seek. That is very dependent on your internal dns setup and the type of dns server you are querying. Lyle Giese On 11/4/22 11:07, David Carvalho via bind-users wrote: Thanks for the replies. My reverse zone file $TTL 86400 @ IN SOA di.ubi.pt. postmaster.di.ubi.pt ( 2020040401 ; serial 28800 ; refresh 3h 7200; retry 1h 604800 ; expire 1w 86400 ) ; ttl 1d ; Servidores de nomes IN NS dns.di.ubi.pt. IN NS dns2.di.ubi.pt. 0.0-28.66.136.193.in-addr.arpa. IN A 193.136.66.0 1.0-28.66.136.193.in-addr.arpa. IN A 193.136.66.1 2.0-28.66.136.193.in-addr.arpa. IN A 193.136.66.2 3.0-28.66.136.193.in-addr.arpa. IN A 193.136.66.3 4.0-28.66.136.193.in-addr.arpa. IN A 193.136.66.4 5.0-28.66.136.193.in-addr.arpa. IN A 193.136.66.5 6.0-28.66.136.193.in-addr.arpa. IN A 193.136.66.6 7.0-28.66.136.193.in-addr.arpa. IN A 193.136.66.7 8.0-28.66.136.193.in-addr.arpa. IN A 193.136.66.8 9.0-28.66.136.193.in-addr.arpa. IN A 193.136.66.9 10.0-28.66.136.193.in-addr.arpa.IN A 193.136.66.10 11.0-28.66.136.193.in-addr.arpa.IN A 193.136.66.11 12.0-28.66.136.193.in-addr.arpa.IN A 193.136.66.12 13.0-28.66.136.193.in-addr.arpa.IN A 193.136.66.13 14.0-28.66.136.193.in-addr.arpa.IN A 193.136.66.14 ; Reverse mapping 1 IN PTR dns.di.ubi.pt. 2 IN PTR dns2.di.ubi.pt. 3 IN PTR geodac.di.ubi.pt. ... -Original Message- From: bind-users On Behalf Of Matus UHLAR - fantomas Sent: 04 November 2022 16:02 To: bind-users@lists.isc.org Subject: Re: Reverse lookups not working when Internet connection failed. On 04.11.22 15:41, David Carvalho via bind-users wrote: We've had an internet failure for a few days last week and as services got online I found the following: Dns queries about my.domain from my.domain worked as expected. Since there was no internet connection, I obviously couldn't query the outside world. Reverse (PTR) Dns queries about my.domain from my.domain didn't work. Now that the internet connection is restored, everything is ok. The reverse entries are in the format "z.y.x.in-addr.arpa."for IP x.y.z Aren't they supposed to work locally when no outside connection is available? if they are properly configured, yes. What could I be missing? can you provide an example of an IP and configured reverse zone, and the zone file? -- 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. Support bacteria - they're the only culture some people have. -- 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 -- 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: Reverse lookups not working when Internet connection failed.
Thanks for the replies.
My reverse zone in named.conf. My secondary dns gets it automatically daily,
along with the "di.ubi.pt.".
zone "0-28.66.136.193.in-addr.arpa." IN {
allow-query { any; };
type master;
file "rev0.hosts";
};
I'll have to study more about some things you guys wrote. This is getting
complicated
Regards
David
-Original Message-
From: bind-users On Behalf Of Grant Taylor
via bind-users
Sent: 04 November 2022 16:36
To: bind-users@lists.isc.org
Subject: Re: Reverse lookups not working when Internet connection failed.
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
Re: Reverse lookups not working when Internet connection failed.
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 smime.p7s Description: S/MIME Cryptographic Signature -- 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: Reverse lookups not working when Internet connection failed.
Ok. This is public address space. Delegation for reverse zones is separate from forward zones. Kind of depends on where the connectivity failure is, as to whether or not clients can walk the delegation tree (or need to). Then there's the effect of TTLs expiring. -- Fred Morris, internet plumber -- 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: Reverse lookups not working when Internet connection failed.
Thanks for the replies. My reverse zone file $TTL 86400 @ IN SOA di.ubi.pt. postmaster.di.ubi.pt ( 2020040401 ; serial 28800 ; refresh 3h 7200; retry 1h 604800 ; expire 1w 86400 ) ; ttl 1d ; Servidores de nomes IN NS dns.di.ubi.pt. IN NS dns2.di.ubi.pt. 0.0-28.66.136.193.in-addr.arpa. IN A 193.136.66.0 1.0-28.66.136.193.in-addr.arpa. IN A 193.136.66.1 2.0-28.66.136.193.in-addr.arpa. IN A 193.136.66.2 3.0-28.66.136.193.in-addr.arpa. IN A 193.136.66.3 4.0-28.66.136.193.in-addr.arpa. IN A 193.136.66.4 5.0-28.66.136.193.in-addr.arpa. IN A 193.136.66.5 6.0-28.66.136.193.in-addr.arpa. IN A 193.136.66.6 7.0-28.66.136.193.in-addr.arpa. IN A 193.136.66.7 8.0-28.66.136.193.in-addr.arpa. IN A 193.136.66.8 9.0-28.66.136.193.in-addr.arpa. IN A 193.136.66.9 10.0-28.66.136.193.in-addr.arpa.IN A 193.136.66.10 11.0-28.66.136.193.in-addr.arpa.IN A 193.136.66.11 12.0-28.66.136.193.in-addr.arpa.IN A 193.136.66.12 13.0-28.66.136.193.in-addr.arpa.IN A 193.136.66.13 14.0-28.66.136.193.in-addr.arpa.IN A 193.136.66.14 ; Reverse mapping 1 IN PTR dns.di.ubi.pt. 2 IN PTR dns2.di.ubi.pt. 3 IN PTR geodac.di.ubi.pt. ... -Original Message- From: bind-users On Behalf Of Matus UHLAR - fantomas Sent: 04 November 2022 16:02 To: bind-users@lists.isc.org Subject: Re: Reverse lookups not working when Internet connection failed. On 04.11.22 15:41, David Carvalho via bind-users wrote: >We've had an internet failure for a few days last week and as services >got online I found the following: > >Dns queries about my.domain from my.domain worked as expected. Since >there was no internet connection, I obviously couldn't query the outside world. > >Reverse (PTR) Dns queries about my.domain from my.domain didn't work. >Now that the internet connection is restored, everything is ok. > > > >The reverse entries are in the format "z.y.x.in-addr.arpa."for IP x.y.z > >Aren't they supposed to work locally when no outside connection is >available? if they are properly configured, yes. > What could I be missing? can you provide an example of an IP and configured reverse zone, and the zone file? -- 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. Support bacteria - they're the only culture some people have. -- 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 -- 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: Reverse lookups not working when Internet connection failed.
Not enough information is provided about how your PTR zone is configured to allow anyone to provide a definitive answer. (Is this nonroutable space? Where are the machines located? Are they talking directly to the auth servers or are there recursives in the resolution path?) On Fri, 4 Nov 2022, David Carvalho via bind-users wrote: Reverse (PTR) Dns queries about my.domain from my.domain didn't work. Now that the internet connection is restored, everything is ok. Overall I'm unsurprised. You can put PTR records in a Response Policy Zone as a mitigation or for more advanced purposes. -- Fred Morris, internet plumber -- 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: Reverse lookups not working when Internet connection failed.
On 04.11.22 15:41, David Carvalho via bind-users wrote: We've had an internet failure for a few days last week and as services got online I found the following: Dns queries about my.domain from my.domain worked as expected. Since there was no internet connection, I obviously couldn't query the outside world. Reverse (PTR) Dns queries about my.domain from my.domain didn't work. Now that the internet connection is restored, everything is ok. The reverse entries are in the format "z.y.x.in-addr.arpa."for IP x.y.z Aren't they supposed to work locally when no outside connection is available? if they are properly configured, yes. What could I be missing? can you provide an example of an IP and configured reverse zone, and the zone file? -- 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. Support bacteria - they're the only culture some people have. -- 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
