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
"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
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
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.00
s 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
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
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
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
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
-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
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
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 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
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
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
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
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
ind-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
-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:
>
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.
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. M
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; };
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
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
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 con
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
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
@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.do
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
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
Hello, good afternoon.
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)
31 matches
Mail list logo
