TL;DR Don't do this. It is not going to work as the origin of the RRSIG would
different.
gitlab.isc.org. 7200 IN A 52.201.58.154
gitlab.isc.org. 7200 IN RRSIG A 13 3 7200 (
20241222045850 20241208044609 27566 isc.org.
Just an idea, but what if you copy the current ZSK key files from the
example.com zone and rename the files (i.e. add “bar” into the filenames) so it
will be picked up by the bar.example.com zone? In theory that should populate
bar.example.com with the correct RRSIG records prior to removing the
Good idea, Brian. People should test more.
Hope it goes well. Packet captures and Wireshark are your friends.
Cheers, Greg
On Tue, 10 Dec 2024 at 15:25, Cuttler, Brian R (HEALTH) <
brian.cutt...@health.ny.gov> wrote:
> Greg,
>
>
>
> I have a test server I will enable the changes on before I roll
Greg,
I have a test server I will enable the changes on before I roll them out to my
primary and secondary servers.
The test server is where we make all tests and updates to zone files.
As I configure the forwarders stanza, I will remove the zone for db.cache and
test it out.
Thanks,
Brian
Fr
And my point is that you just don't need that hint zone definition at
all, especially using custom NS in an environment such as this. Maybe try
commenting it out and see if it makes any difference.
Greg
On Tue, 10 Dec 2024 at 14:48, Cuttler, Brian R (HEALTH) <
brian.cutt...@health.ny.gov> wrote:
Greg,
Yes, I do have that but it looks like this
(/etc/dns-root is a link to /etc/bind/zones carry over from an older platform)
These are the servers I want to use as the forwards for all queries that aren't
either local zones or more specific zones in the internal corp network.
brian@cedar:/e
Hi Brian.
So in your config you still have a section like this?
zone ".: {
type hint;
file ;
};
You don't need it a) at all anyway, for the reason I gave and b) because
you are forwarding everything non-local and if you specify "forward only;"
for both global forwarding (last resort, simila
Nick, Greg,
Thank you both, don't deal with that level of detail very often but I love
having a clue as to the underpinnings of things.
The root priming process is exactly the sort of thing you'd hope a service like
this did, and it does!
Thanks,
Brian
From: bind-users On Behalf Of Greg Chou
Greg,
Thank you.
Replacing the db.cache file seems to work for replacing the root servers, I saw
traffic shift to an internal router were I had expected/previously seen traffic
through the FW.
Manager noticed that secondary queries to domain servers were still going
through the FW.
The forwar
>From what Ondřej says, if you can temporarily move the bar.example.com zone
to a different set of nameservers, that would be much safer. Then you add
the new records and remove the NS delegation of bar from the example.com
zone, and wait for TTL's to expire. I would also turn down the TTL's
ever
Hello!
Sometimes (serial quirks) it is necessary to force an AXFR. The "rndc retrieve"
only queues the request, so I have to "tail -f" the log file to see if the AXFR
was performed, which requires manual inspection.
I would like to have a possibility, to trigger the AXFR, and wait until the
AX
Hi Ondřej!
We run Ubuntu 24.04. Can you please update the dev-ppa too?
Thanks
Klaus
--
Klaus Darilion, Head of Operations
nic.at GmbH, Jakob-Haringer-Straße 8/V
5020 Salzburg, Austria
From: Ondřej Surý
Sent: Monday, December 9, 2024 2:54 PM
To: Klaus Darilion
Cc: Klaus Darilion via bind-users
Hello Chris.
My take is that the *will* be some sort of breakage even if you do
everything right with shortest possible TTLs - because this is the DNS,
eventually consistent by design, and wildly misimplemented in practice.
So don't feel bad when some breakage occurs :-) It will very much depe
13 matches
Mail list logo
