date:20201217

Re: Forwarded lookup failing on no valid RRSIG

2020-12-17 Thread Mark Andrews

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:~] marka% dig +dnssec ds com

; <<>> DiG 9.15.4 <<>> +dnssec ds com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 31284
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 4096
; COOKIE: 5cf268bbbafd31a901005fdc081a24542baf0ffea0bb (good)
;; QUESTION SECTION:
;com.   IN  DS

;; ANSWER SECTION:
com.40483   IN  DS  30909 8 2 
E2D3C916F6DEEAC73294E8268FB5885044A833FC5459588F4A9184CF C41A5766
com.40483   IN  RRSIG   DS 8 1 86400 2020122917 
2020121616 26116 . cgPgcSi6cq++komd2l+PzrCsawleAikedcwcGk5PbNr1onkXZGNypJoF 
7QQJ4GjMf4b7t+bO5f8szmo0cd2bz+DD0DMXoqUSFvEH4gOX9naoHcm0 
90MS5Wfdeg43gNDSot/U74RJS1CS50U3SreFd2ZFIik9MlCHrSFLf/9V 
7EqTJrs3xz9d/EG34O6qjaEqdw4GW40d3sA6kDGtSC+I9t4rttSEeasZ 
FnkZWLCOvzOLfYQlCVqaWpYCnvNdoQUPsbmDCEJf22tanPUft59hPRMu 
HmJAOKj77vy+kQWXaBcBo//NUX2asBLus8S7sJ9BDxpGUAsS9o+TdRlq YkIHBA==

;; Query time: 0 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Fri Dec 18 12:38:34 AEDT 2020
;; MSG SIZE  rcvd: 395

[beetle:~] marka% 


> On 18 Dec 2020, at 11:36, Nicolas Bock  wrote:
> 
> 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 dns-server named[843946]: delete_node(): 0x7fa7e331e010 
> www.canonical.com (bucket 15)
>   Dec 17 20:58:06 dns-server named[843946]: delete_node(): 0x7fa7e331b080 
> com (bucket 2)
>   Dec 17 20:58:06 dns-server named[843946]: no valid RRSIG resolving 
> 'com/DS/IN': 10.0.0.2#53
>   Dec 17 20:58:06 dns-server named[843946]: delete_node(): 0x7fa7e331b080 
> com (bucket 2)
>   Dec 17 20:58:06 dns-server named[843946]: no valid RRSIG resolving 
> 'com/DS/IN': 10.0.0.3#53
>   Dec 17 20:58:06 dns-server named[843946]: delete_node(): 0x7fa7e331b080 
> com (bucket 2)
>   Dec 17 20:58:06 dns-server named[843946]: no valid DS resolving 
> 'www.canonical.com/A/IN': 10.0.0.2#53
>   Dec 17 20:58:06 dns-server named[843946]: delete_node(): 0x7fa7e331e010 
> www.canonical.com (bucket 15)
>   Dec 17 20:58:06 dns-server named[843946]: validating 
> www.canonical.com/A: bad cache hit (com/DS)
>   Dec 17 20:58:06 dns-server named[843946]: delete_node(): 0x7fa7e331e010 
> www.canonical.com (bucket 15)
>   Dec 17 20:58:06 dns-server named[843946]: broken trust chain resolving 
> 'www.canonical.com/A/IN': 10.0.0.3#53
> 
> I don't quite understand why. Are 10.0.0.{2,3} incorrectly
> set up for DNSSEC? It looks like DNSSEC is already breaking
> for com. How can I trace what the root cause is?
> 
> Thanks!
> 
> Nick
> ___
> Please 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@lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742  INTERNET: ma...@isc.org

___
Please 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@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Forwarded lookup failing on no valid RRSIG

2020-12-17 Thread Nicolas Bock

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 dns-server named[843946]: delete_node(): 0x7fa7e331e010 
www.canonical.com (bucket 15)
   Dec 17 20:58:06 dns-server named[843946]: delete_node(): 0x7fa7e331b080 
com (bucket 2)
   Dec 17 20:58:06 dns-server named[843946]: no valid RRSIG resolving 
'com/DS/IN': 10.0.0.2#53
   Dec 17 20:58:06 dns-server named[843946]: delete_node(): 0x7fa7e331b080 
com (bucket 2)
   Dec 17 20:58:06 dns-server named[843946]: no valid RRSIG resolving 
'com/DS/IN': 10.0.0.3#53
   Dec 17 20:58:06 dns-server named[843946]: delete_node(): 0x7fa7e331b080 
com (bucket 2)
   Dec 17 20:58:06 dns-server named[843946]: no valid DS resolving 
'www.canonical.com/A/IN': 10.0.0.2#53
   Dec 17 20:58:06 dns-server named[843946]: delete_node(): 0x7fa7e331e010 
www.canonical.com (bucket 15)
   Dec 17 20:58:06 dns-server named[843946]: validating 
www.canonical.com/A: bad cache hit (com/DS)
   Dec 17 20:58:06 dns-server named[843946]: delete_node(): 0x7fa7e331e010 
www.canonical.com (bucket 15)
   Dec 17 20:58:06 dns-server named[843946]: broken trust chain resolving 
'www.canonical.com/A/IN': 10.0.0.3#53

I don't quite understand why. Are 10.0.0.{2,3} incorrectly
set up for DNSSEC? It looks like DNSSEC is already breaking
for com. How can I trace what the root cause is?

Thanks!

Nick
___
Please 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@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: Serial number question..

2020-12-17 Thread Mark Elkins


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 - 
so in an easily understandable human readable format (as long as there 
are no more than 99 updates in a day - or one change every 15 minute 
clock tick). Another option is the current seconds since Unix epoch - 
which is what I thought might be going on. That could work for very busy 
or dynamic zones.


It then allows for simple sanity checking of the SOA Serial number based 
on the current date (and time) - before telling your authoritative 
nameserver software a change has happened.


Years ago - I had to rotate an SOA Serial past 2^31, negative and down, 
past Zero to the format we wanted when an uncontrolled SOA update 
happened. Pain in the rear end.


Anyway - the Secondaries will only update again once the Primary SOA 
Serial number is "bigger" than they are.


On 12/17/20 8:56 PM, Bruce Johnson wrote:

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 elixir.pharmacy.arizona.edu. 
wunz.elixir.pharmacy.arizona.edu. 1297117089 3600 120 1209600 86400


Secondaries:

bruces-Mac-Mini:~ johnson$ dig @dhbns1.pharmacy.arizona.edu -t SOA +noall 
+answer pharmacy.arizona.edu
pharmacy.arizona.edu.   86404   IN  SOA elixir.pharmacy.arizona.edu. 
wunz.elixir.pharmacy.arizona.edu. 1762233707 3600 120 1209600 86400
bruces-Mac-Mini:~ johnson$ dig @ns-remote.arizona.edu -t SOA +noall +answer 
pharmacy.arizona.edu
pharmacy.arizona.edu.   86404   IN  SOA elixir.pharmacy.arizona.edu. 
wunz.elixir.pharmacy.arizona.edu. 1762233707 3600 120 1209600 86400

Is the fix here just setting the serial number on the primary to 1762233708 ?

The various things online I’ve found are all based on “you accidentally set the 
primary more than 2^32 ahead” so you have to do a bunch of modulo arithmetic...



--

Mark James ELKINS  -  Posix Systems - (South) Africa
m...@posix.co.za   Tel: +27.826010496 
For fast, reliable, low cost Internet in ZA: https://ftth.posix.co.za 



Posix SystemsVCARD for MJ Elkins

___
Please 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@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: Serial number question..

2020-12-17 Thread Bruce Johnson

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:
>> bruces-Mac-Mini:~ johnson$ dig @elixir.pharmacy.arizona.edu -t SOA +noall 
>> +answer pharmacy.arizona.edu
>> pharmacy.arizona.edu.86404   IN  SOA 
>> elixir.pharmacy.arizona.edu. wunz.elixir.pharmacy.arizona.edu. 1297117089 
>> 3600 120 1209600 86400
>> Secondaries:
>> bruces-Mac-Mini:~ johnson$ dig @dhbns1.pharmacy.arizona.edu -t SOA +noall 
>> +answer pharmacy.arizona.edu
>> pharmacy.arizona.edu.86404   IN  SOA 
>> elixir.pharmacy.arizona.edu. wunz.elixir.pharmacy.arizona.edu. 1762233707 
>> 3600 120 1209600 86400
>> bruces-Mac-Mini:~ johnson$ dig @ns-remote.arizona.edu -t SOA +noall +answer 
>> pharmacy.arizona.edu
>> pharmacy.arizona.edu.86404   IN  SOA 
>> elixir.pharmacy.arizona.edu. wunz.elixir.pharmacy.arizona.edu. 1762233707 
>> 3600 120 1209600 86400
>> Is the fix here just setting the serial number on the primary to 1762233708 ?
>> The various things online I’ve found are all based on “you accidentally set 
>> the primary more than 2^32 ahead” so you have to do a bunch of modulo 
>> arithmetic...
> 
> just set it *higher* on the master and you are done
> ___
> Please 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@lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users

-- 
Bruce Johnson
University of Arizona
College of Pharmacy
Information Technology Group

Institutions do not have opinions, merely customs


___
Please 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@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: Serial number question..

2020-12-17 Thread Ondřej Surý

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 steps (as you have found on the Internet).

Ondrej
--
Ondřej Surý — ISC (He/Him)

> On 17. 12. 2020, at 19:56, Bruce Johnson  wrote:
> 
> 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.86404INSOAelixir.pharmacy.arizona.edu. 
> wunz.elixir.pharmacy.arizona.edu. 1297117089 3600 120 1209600 86400
> 
> 
> Secondaries:
> 
> bruces-Mac-Mini:~ johnson$ dig @dhbns1.pharmacy.arizona.edu -t SOA +noall 
> +answer pharmacy.arizona.edu
> pharmacy.arizona.edu.86404INSOAelixir.pharmacy.arizona.edu. 
> wunz.elixir.pharmacy.arizona.edu. 1762233707 3600 120 1209600 86400
> bruces-Mac-Mini:~ johnson$ dig @ns-remote.arizona.edu -t SOA +noall +answer 
> pharmacy.arizona.edu
> pharmacy.arizona.edu.86404INSOAelixir.pharmacy.arizona.edu. 
> wunz.elixir.pharmacy.arizona.edu. 1762233707 3600 120 1209600 86400
> 
> Is the fix here just setting the serial number on the primary to 1762233708 ?
> 
> The various things online I’ve found are all based on “you accidentally set 
> the primary more than 2^32 ahead” so you have to do a bunch of modulo 
> arithmetic...
> 
> 
> -- 
> Bruce Johnson
> University of Arizona
> College of Pharmacy
> Information Technology Group
> 
> Institutions do not have opinions, merely customs
> 
> 
> ___
> Please 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@lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users

___
Please 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@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: Serial number question..

2020-12-17 Thread Sten Carlsen

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 killed in the making of this e-mail... however,
a large number of electrons were terribly inconvenienced."

> On 17 Dec 2020, at 20.02, 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:
>> bruces-Mac-Mini:~ johnson$ dig @elixir.pharmacy.arizona.edu -t SOA +noall 
>> +answer pharmacy.arizona.edu
>> pharmacy.arizona.edu.86404   IN  SOA 
>> elixir.pharmacy.arizona.edu. wunz.elixir.pharmacy.arizona.edu. 1297117089 
>> 3600 120 1209600 86400
>> Secondaries:
>> bruces-Mac-Mini:~ johnson$ dig @dhbns1.pharmacy.arizona.edu -t SOA +noall 
>> +answer pharmacy.arizona.edu
>> pharmacy.arizona.edu.86404   IN  SOA 
>> elixir.pharmacy.arizona.edu. wunz.elixir.pharmacy.arizona.edu. 1762233707 
>> 3600 120 1209600 86400
>> bruces-Mac-Mini:~ johnson$ dig @ns-remote.arizona.edu -t SOA +noall +answer 
>> pharmacy.arizona.edu
>> pharmacy.arizona.edu.86404   IN  SOA 
>> elixir.pharmacy.arizona.edu. wunz.elixir.pharmacy.arizona.edu. 1762233707 
>> 3600 120 1209600 86400
>> Is the fix here just setting the serial number on the primary to 1762233708 ?
>> The various things online I’ve found are all based on “you accidentally set 
>> the primary more than 2^32 ahead” so you have to do a bunch of modulo 
>> arithmetic...
> 
> just set it *higher* on the master and you are done
> ___
> Please 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@lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users

___
Please 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@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: Serial number question..

2020-12-17 Thread Ricardo Stella

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 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:
> >
> > bruces-Mac-Mini:~ johnson$ dig @elixir.pharmacy.arizona.edu -t SOA
> +noall +answer pharmacy.arizona.edu
> > pharmacy.arizona.edu. 86404   IN  SOA
> elixir.pharmacy.arizona.edu. wunz.elixir.pharmacy.arizona.edu. 1297117089
> 3600 120 1209600 86400
> >
> >
> > Secondaries:
> >
> > bruces-Mac-Mini:~ johnson$ dig @dhbns1.pharmacy.arizona.edu -t SOA
> +noall +answer pharmacy.arizona.edu
> > pharmacy.arizona.edu. 86404   IN  SOA
> elixir.pharmacy.arizona.edu. wunz.elixir.pharmacy.arizona.edu. 1762233707
> 3600 120 1209600 86400
> > bruces-Mac-Mini:~ johnson$ dig @ns-remote.arizona.edu -t SOA +noall
> +answer pharmacy.arizona.edu
> > pharmacy.arizona.edu. 86404   IN  SOA
> elixir.pharmacy.arizona.edu. wunz.elixir.pharmacy.arizona.edu. 1762233707
> 3600 120 1209600 86400
> >
> > Is the fix here just setting the serial number on the primary to
> 1762233708 ?
> >
> > The various things online I’ve found are all based on “you accidentally
> set the primary more than 2^32 ahead” so you have to do a bunch of modulo
> arithmetic...
>
> just set it *higher* on the master and you are done
> ___
> Please 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@lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users
>


-- 
°(((=((===°°°(((
___
Please 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@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: Serial number question..

2020-12-17 Thread Reindl Harald




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
pharmacy.arizona.edu.   86404   IN  SOA elixir.pharmacy.arizona.edu. 
wunz.elixir.pharmacy.arizona.edu. 1297117089 3600 120 1209600 86400


Secondaries:

bruces-Mac-Mini:~ johnson$ dig @dhbns1.pharmacy.arizona.edu -t SOA +noall 
+answer pharmacy.arizona.edu
pharmacy.arizona.edu.   86404   IN  SOA elixir.pharmacy.arizona.edu. 
wunz.elixir.pharmacy.arizona.edu. 1762233707 3600 120 1209600 86400
bruces-Mac-Mini:~ johnson$ dig @ns-remote.arizona.edu -t SOA +noall +answer 
pharmacy.arizona.edu
pharmacy.arizona.edu.   86404   IN  SOA elixir.pharmacy.arizona.edu. 
wunz.elixir.pharmacy.arizona.edu. 1762233707 3600 120 1209600 86400

Is the fix here just setting the serial number on the primary to 1762233708 ?

The various things online I’ve found are all based on “you accidentally set the 
primary more than 2^32 ahead” so you have to do a bunch of modulo arithmetic...


just set it *higher* on the master and you are done
___
Please 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@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Serial number question..

2020-12-17 Thread 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
pharmacy.arizona.edu.   86404   IN  SOA elixir.pharmacy.arizona.edu. 
wunz.elixir.pharmacy.arizona.edu. 1297117089 3600 120 1209600 86400


Secondaries:

bruces-Mac-Mini:~ johnson$ dig @dhbns1.pharmacy.arizona.edu -t SOA +noall 
+answer pharmacy.arizona.edu
pharmacy.arizona.edu.   86404   IN  SOA elixir.pharmacy.arizona.edu. 
wunz.elixir.pharmacy.arizona.edu. 1762233707 3600 120 1209600 86400
bruces-Mac-Mini:~ johnson$ dig @ns-remote.arizona.edu -t SOA +noall +answer 
pharmacy.arizona.edu
pharmacy.arizona.edu.   86404   IN  SOA elixir.pharmacy.arizona.edu. 
wunz.elixir.pharmacy.arizona.edu. 1762233707 3600 120 1209600 86400

Is the fix here just setting the serial number on the primary to 1762233708 ?

The various things online I’ve found are all based on “you accidentally set the 
primary more than 2^32 ahead” so you have to do a bunch of modulo arithmetic...


-- 
Bruce Johnson
University of Arizona
College of Pharmacy
Information Technology Group

Institutions do not have opinions, merely customs


___
Please 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@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

RHEL, Centos, Fedora rpm 9.16.10

2020-12-17 Thread Carl Byington via bind-users

-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
LXRlbi1zZy5jb20ACgkQL6j7milTFsFpFACcD0YoVAshJ4tYIyOsjw3F1pwfmfcA
nj9HeeYhGiwSy83yvWaPnrnqKn0g
=M9z3
-END PGP SIGNATURE-


___
Please 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@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

How does query denial actually work?

2020-12-17 Thread Andrew P .

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 designated servers at the DNS provider, 
and the zones don't actually list the primary in NS records (only in the SOA 
record). So I'm seeing large numbers of bursts of denied errors like this:

client @0x6e702710 73.61.186.10#21509 (.): query (cache) './ANY/IN' denied

I'll get maybe 20 in a row in under 2 seconds from one IP address, then a time 
gap, then a similar burst supposedly from a different IP address.

So, my questions are:

1. Are these attacks?

2. Does BIND actually send a reject message back, or is it silent in such 
denial cases (as in, not still attacking with smaller packets the victim of a 
DNS amplication attack)?

I can't figure it out from reading the source code; I haven't so far been able 
to trace back from where the messages are logged to where (if any) a response 
packet would be transmitted.

Andrew
___
Please 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@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: Forwarded lookup failing on no valid RRSIG

Forwarded lookup failing on no valid RRSIG

Re: Serial number question..

Re: Serial number question..

Re: Serial number question..

Re: Serial number question..

Re: Serial number question..

Re: Serial number question..

Serial number question..

RHEL, Centos, Fedora rpm 9.16.10

How does query denial actually work?

11 matches

Site Navigation

Mail list logo

Footer information