DNSSEC requires that forwarders support DNSSEC. Check that the forwarders
return
DNSSEC records when they are queried. The forwarders should also be validating
to
filter spoofed responses from the internet. You should be getting a answer like
this if the forwarders are validating.
[beetle:~]
Hi,
When I configure my named to forward to our corporate DNS
servers (10.0.0.2 and 10.0.0.3), I end up getting error
messages such as
Dec 17 20:58:06 dns-server named[843946]: fetch: www.canonical.com/A
Dec 17 20:58:06 dns-server named[843946]: fetch: com/DS
Dec 17 20:58:06
I was wondering if there was any significance in the SOA serial value
$ date --date='@1297117089'
Tue Feb 8 00:18:09 SAST 2011
$ date --date='@1762233707'
Tue Nov 4 07:21:47 SAST 2025
...so nope (but sort of close?)
Personally - I try and use a MMDDxx format in my SOA Serial number -
Thanks, that worked perfectly!
> On Dec 17, 2020, at 12:02 PM, Reindl Harald wrote:
>
>
>
> Am 17.12.20 um 19:56 schrieb Bruce Johnson:
>> Someone updated out name server and messed up the serial number on the
>> primary; as a result our secondaries are not updating properly.
>> Primary:
>>
Bruce,
you should start by picking a policy for your serial number. Both unixtime and
datetime are viable, but you should pick one.
Then rotate to your desired policy by doing the serial number arithmetic. For
datetime, you would just bump it, but for unixtime you will need to do that in
more
The modulo arithmetic comes if you need it to be lower than in the slaves since
they will consider a lower numbered transfer to be out of date and refuse to
update. Meaning you will need to go to the top and round back to where you need
to be.
--
Best regards
Sten Carlsen
"No trees were
Suggestion I learned ages ago...
Set the serial number to match the date the change is made such as
MMDDvv (Year, month, date, version). For example: 2020121701
Of course, if you do more than 99 changes in a single day, you probably
have other problems..
On Thu, Dec 17, 2020 at 2:02 PM
Am 17.12.20 um 19:56 schrieb Bruce Johnson:
Someone updated out name server and messed up the serial number on the primary;
as a result our secondaries are not updating properly.
Primary:
bruces-Mac-Mini:~ johnson$ dig @elixir.pharmacy.arizona.edu -t SOA +noall
+answer pharmacy.arizona.edu
Someone updated out name server and messed up the serial number on the primary;
as a result our secondaries are not updating properly.
Primary:
bruces-Mac-Mini:~ johnson$ dig @elixir.pharmacy.arizona.edu -t SOA +noall
+answer pharmacy.arizona.edu
pharmacy.arizona.edu. 86404 IN SOA
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
https://www.five-ten-sg.com/mapper/bind contains links to the source
rpms, and build instructions.
-BEGIN PGP SIGNATURE-
iHMEAREKADMWIQSuFMepaSkjWnTxQ5QvqPuaKVMWwQUCX9uRhRUcY2FybEBmaXZl
Greetings, all.
I was curious about one of the features in BIND. Per the Best Practices, my
on-site primary nameserver for my public domains (the secondaries being with a
large public DNS provider) is configured to only allow queries from within my
LAN and transfers in the LAN and to the
11 matches
Mail list logo
