Reverse lookups not working when Internet connection failed.

David Carvalho david at di.ubi.pt
Mon Nov 7 15:57:27 UTC 2022


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.000000	10.0.0.199	193.136.66.1	DNS	85	Standard query 0x000b PTR 8.66.136.193.in-addr.arpa
2	0.016660	193.136.66.1	10.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.arpa    nameserver = dns.di.ubi.pt
0-28.66.136.193.in-addr.arpa    nameserver = 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 <bind-users-bounces at lists.isc.org> On Behalf Of Matus UHLAR - fantomas
Sent: 06 November 2022 13:39
To: bind-users at 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, uhlar at 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 at lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users



More information about the bind-users mailing list