Niall,
Thanks for reporting back. This is an omission in our KB article that I
will fix.
- Matthijs
On 07-11-2022 18:24, Niall O'Reilly wrote:
On 7 Nov 2022, at 11:40, Niall O'Reilly wrote:
Preparation:
- Set up minimal stand-alone instance of BIND9 named,
configured with a **dnssec-po
On 7 Nov 2022, at 11:40, Niall O'Reilly wrote:
> Preparation:
>
> - Set up minimal stand-alone instance of BIND9 named,
> configured with a **dnssec-policy** for each algorithm,
> matching properties of existing DNSSEC keys, and with
> `lifetime unlimited`;
> - Deliver current key files and
"Garbage" records...
On Mon, 7 Nov 2022, Matus UHLAR - fantomas wrote:
On 07.11.22 15:42, Petr Špaček wrote:
That's part of normal resolver operation: Garbage in - garbage out -
garbage eventually cleaned out from cache. There is nothing special about
PTR records in that regard.
sooner or la
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 res
On 11/7/22 9:08 AM, Matus UHLAR - fantomas wrote:
I'm afraid that this problem can become really huge when someone creates
huge amount of generated records, e.g. using proposed module.
Even if BIND's cache is simply FIFO -- which I'm fairly certain that
it's smarter than that -- and flushes a
"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 t
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
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
On 7. 11. 2022, at 16:19, Matus UHLAR - fantomas wrote:
while it's doable, and with using BIND plugin at generating server it
won't need much of memory, any server that will be repeatedly asked to
resolve IPs from that range will fill its cache with generated records.
On 07.11.22 16:28, Ondře
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
> On 7. 11. 2022, at 16:19, Matus UHLAR - fantomas wrote:
>
> while it's doable, and with using BIND plugin at generating server it won't
> need much of memory, any server that will be repeatedly asked to resolve IPs
> from that range will fill its cache with generated records.
That's not any
On 7. 11. 2022, at 15:50, Matus UHLAR - fantomas wrote:
sooner or later, but filling up cache with garbage could result in other
non-garbage records being flushed out.
Are there any mechanisms that would wipe this garbage before other records,
used more often even if not very recently?
On 07
> On 7. 11. 2022, at 15:50, Matus UHLAR - fantomas wrote:
>
>
> sooner or later, but filling up cache with garbage could result in other
> non-garbage records being flushed out.
> Are there any mechanisms that would wipe this garbage before other records,
> used more often even if not very r
Thank you for your speedy response, Matthijs.
On 7 Nov 2022, at 13:10, Matthijs Mekking wrote:
Ignore that, I saw too late there were attachments.
Perhaps I ought to have mentioned them explicitly.
Are you able to share the public key and key state files with me so I
can investigate why BIN
On 28.10.22 08:26, Ondřej Surý wrote:
BIND 9 have support for writing plugins, and we would accept a
well written plugin that would allow generating the forward/reverse plugins on the fly.
There’s already a feature request for it here:
https://gitlab.isc.org/isc-projects/bind9/-/issues/1586
On 07. 11. 22 15:23, Matus UHLAR - fantomas wrote:
On 28.10.22 08:26, Ondřej Surý wrote:
BIND 9 have support for writing plugins, and we would accept a well
written
plugin that would allow generating the forward/reverse plugins on the fly.
There’s already a feature request for it here:
https
On 28.10.22 08:26, Ondřej Surý wrote:
BIND 9 have support for writing plugins, and we would accept a
well written plugin that would allow generating the forward/reverse plugins on the fly.
There’s already a feature request for it here:
https://gitlab.isc.org/isc-projects/bind9/-/issues/1586
On 28. 10. 22 9:29, Matus UHLAR - fantomas wrote:
On 28.10.22 08:26, Ondřej Surý wrote:
BIND 9 have support for writing plugins, and we would accept a well
written
plugin that would allow generating the forward/reverse plugins on the fly.
There’s already a feature request for it here:
https:
On 07-11-2022 14:04, Matthijs Mekking wrote:
Hi Niall,
You need to share the dnssec-policy for no8.be in order to investigate
why it doesn't show the expected behavior, but I suspect that the policy
did not match the properties for the existing DNSSEC keys completely.
Ignore that, I saw too
Hi Niall,
You need to share the dnssec-policy for no8.be in order to investigate
why it doesn't show the expected behavior, but I suspect that the policy
did not match the properties for the existing DNSSEC keys completely.
Best regards,
Matthijs
On 07-11-2022 12:40, Niall O'Reilly wrote:
I have a couple of zones which I want to migrate from CLI-driven
signing to BIND9 automatic signing, while avoiding any change to
the respective parent-zone DS RR.
Status quo ante:
- https://dnsviz.net/d/no8.be/dnssec/
separate KSK, ZSK; both using alg 13
- https://dnsviz.net/d/jamm.ie/dnssec/
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 $CLIENT
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 no
Thanks for replying so promptly, Ondřej.
On 6 Nov 2022, at 15:34, Ondřej Surý wrote:
Nope, that’s local to your system. Hard to tell what’s wrong from
just a single message, but either there’s cruft somewhere in the
path with more priority
That was it. Rebuilding the cache cleared the proble
24 matches
Mail list logo
