Re: can I provide invalid HTTPS values for testing?

[Stephen Farrell]

Hiya,

On 20/06/2024 14:34, Ondřej Surý wrote:

Stephen,

you actually gave me an idea - you should use BIND version without HTTPS record
support and just convert the records to TYPExxx form. That way, there will be no
parser standing in your way and you can put all kind of rubbish to the zone.


Yep, there are likely some tests where I'll want to do that,
or similar, but I'm good for a while at least with cases
where the badness is mostly within the base64 encoding of
the ECHConfigList, which bind seems ok with.


P.S.: Why am I even helping you when the eduroam at TCD didn’t work for me last
week ;))).


I can only apologise for our eduroam setup (again, I've had
to do it before;-), but happy to supply an apologetic beverage
next time we meet.

Cheers,
S.


OpenPGP_0xE4D8E9F997A833DD.asc
Description: OpenPGP public key


OpenPGP_signature.asc
Description: OpenPGP digital signature
-- 
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: can I provide invalid HTTPS values for testing?

[Ondřej Surý]

Stephen,

you actually gave me an idea - you should use BIND version without HTTPS record 
support and just convert the records to TYPExxx form. That way, there will be 
no parser standing in your way and you can put all kind of rubbish to the zone.

P.S.: Why am I even helping you when the eduroam at TCD didn’t work for me last 
week ;))).

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 20. 6. 2024, at 15:29, Stephen Farrell  wrote:
> 
> 
> Hi again,
> 
> Actually, it may well be that bind allows me sufficient
> leeway to do most of the tests I want, so this is just
> to check that there's no imminent plan to have bind
> disallow the kind of rubbish HTTPS RRs below. If that's
> not likely to change in the next few months, then I'd
> say I'm fine. (With apologies for the noise;-)
> 
> Thanks,
> S.
> 
> $ dig +short https dodgy.test.defo.ie
> 1 . alpn="\"" ipv4hint=10.0.0.1 ech=Cg==
> 1 . ech=AAA=
> 1 . 
> ech=ADn+DQA128zMACBZkH1hkFTJB6Hyls62Pd4dV/cvFdsXJgGi9rVeZufNDwAEAAEAAQAGYmFyLmllAAA=
> 1 . alpn="\"" ipv4hint=10.0.0.1 ech
> 1 . alpn="\"" ipv4hint=10.0.0.0 ech=Cg==


OpenPGP_0xE4D8E9F997A833DD.asc
Description: Binary data
> --
> 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
-- 
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: can I provide invalid HTTPS values for testing?

[Stephen Farrell]

Hi again,

Actually, it may well be that bind allows me sufficient
leeway to do most of the tests I want, so this is just
to check that there's no imminent plan to have bind
disallow the kind of rubbish HTTPS RRs below. If that's
not likely to change in the next few months, then I'd
say I'm fine. (With apologies for the noise;-)

Thanks,
S.

$ dig +short https dodgy.test.defo.ie
1 . alpn="\"" ipv4hint=10.0.0.1 ech=Cg==
1 . ech=AAA=
1 . 
ech=ADn+DQA128zMACBZkH1hkFTJB6Hyls62Pd4dV/cvFdsXJgGi9rVeZufNDwAEAAEAAQAGYmFyLmllAAA=

1 . alpn="\"" ipv4hint=10.0.0.1 ech
1 . alpn="\"" ipv4hint=10.0.0.0 ech=Cg==


OpenPGP_0xE4D8E9F997A833DD.asc
Description: OpenPGP public key


OpenPGP_signature.asc
Description: OpenPGP digital signature
-- 
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: can I provide invalid HTTPS values for testing?

[Stephen Farrell]

Hiya,

Thanks all for the info/suggestions. I guess I'll have
to try what Ondřej suggests or something similar, and
that's ok.

Cheers,
S.


OpenPGP_0xE4D8E9F997A833DD.asc
Description: OpenPGP public key


OpenPGP_signature.asc
Description: OpenPGP digital signature
-- 
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: can I provide invalid HTTPS values for testing?

[Mark Andrews]

> On 20 Jun 2024, at 15:29, Michael Richardson  wrote:
> 
> 
> Mark Andrews  wrote:
>> Named and nsupdate validate input for types they know about (both text
>> and wire). You would have to use versions that are not HTTPS aware and
>> use unknown type format.
> 
> So, he could code it in Perl or Python or something which had a dynamic DNS
> library.  Bind itself wouldn't validate the "ascii-hex" part when it receives
> it.

Named will reject HTTPS records that it can determine are invalid.  This 
includes
in UPDATE requests.  The server will return FORMERR to the dynamic update 
client.

See lib/dns/rdata/in_1/svcb_64.c for all the checks performed.

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

-- 
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: can I provide invalid HTTPS values for testing?

[Michael Richardson]

Mark Andrews  wrote:
> Named and nsupdate validate input for types they know about (both text
> and wire). You would have to use versions that are not HTTPS aware and
> use unknown type format.

So, he could code it in Perl or Python or something which had a dynamic DNS
library.  Bind itself wouldn't validate the "ascii-hex" part when it receives
it.



signature.asc
Description: PGP signature
-- 
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: can I provide invalid HTTPS values for testing?

[Ondřej Surý]

Stephen,

I would suggest to write a specialized DNS server using dnspython rather than 
trying to cram the crap into existing DNS servers.

Then it should be possible to use something like this: 
https://hypothesis.readthedocs.io/en/latest/ to generate the test cases 
automatically.

Cheers,
--
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 20. 6. 2024, at 3:40, Stephen Farrell  wrote:
> 
> 
> Hiya,
> 
> Apologies if this is a repeat, I spent a bit of time looking
> but didn't find stuff...
> 
> I'd like to publish various HTTPS RRs with dodgy encodings
> in order to test which clients handle things well or badly.
> 
> Were it possible to use nsupdate for that, that'd make my
> life simpler, but I've not found a way to do that so far.
> 
> What I'd like to be able to do in nsupdate would be like:
> 
>  update add example.com 300 HTTPS 
> 
> Where the ascii-hex value is some (broken) variant of what
> I'd get from:
> 
>  dig +unknownformat https example.com
> 
> Is there a way to do that?
> 
> Thanks in advance,
> Stephen.
> 
> 
> --
> 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
-- 
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: can I provide invalid HTTPS values for testing?

[Mark Andrews]

Named and nsupdate validate input for types they know about (both text
and wire). You would have to use versions that are not HTTPS aware and
use unknown type format.

Mark

> On 20 Jun 2024, at 11:39, Stephen Farrell  wrote:
> 
> 
> Hiya,
> 
> Apologies if this is a repeat, I spent a bit of time looking
> but didn't find stuff...
> 
> I'd like to publish various HTTPS RRs with dodgy encodings
> in order to test which clients handle things well or badly.
> 
> Were it possible to use nsupdate for that, that'd make my
> life simpler, but I've not found a way to do that so far.
> 
> What I'd like to be able to do in nsupdate would be like:
> 
>  update add example.com 300 HTTPS 
> 
> Where the ascii-hex value is some (broken) variant of what
> I'd get from:
> 
>  dig +unknownformat https example.com
> 
> Is there a way to do that?
> 
> Thanks in advance,
> Stephen.
> 
> -- 
> 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

-- 
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

can I provide invalid HTTPS values for testing?

[Stephen Farrell]

Hiya,

Apologies if this is a repeat, I spent a bit of time looking
but didn't find stuff...

I'd like to publish various HTTPS RRs with dodgy encodings
in order to test which clients handle things well or badly.

Were it possible to use nsupdate for that, that'd make my
life simpler, but I've not found a way to do that so far.

What I'd like to be able to do in nsupdate would be like:

  update add example.com 300 HTTPS 

Where the ascii-hex value is some (broken) variant of what
I'd get from:

  dig +unknownformat https example.com

Is there a way to do that?

Thanks in advance,
Stephen.



OpenPGP_0xE4D8E9F997A833DD.asc
Description: OpenPGP public key


OpenPGP_signature.asc
Description: OpenPGP digital signature
-- 
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: [DNSSEC] testing KASP

[Petr Špaček]

On 29. 05. 24 11:31, adrien sipasseuth wrote:

Only if KSK has DSState: rumoured. If the DSState is hidden it means
that it is not expected to be in the parent (for example because the
DNSKEY has not yet been fully propagated).


 > Do you need to withdraw the old key too immediatly ? anything else to 
do ?


 >>> Do you mean withdraw the old DS?

Yes, the old DS should be not yet withdraw because some RRSIG could be 
still valid ? or can i withdraw the old DS / KSK immediatly ?


In my logic :
For each file en .state
     If is KSK with "DSState: rumoured" or "DSState: hidden"
         If not in my registar (dig ds  +dnssec +multiline)
             Publish on my Registar(api register)
             Notify Bind(bind rndc dnssec -checkds -key  
published )
             Notify Bind(bind rndc dnssec -checkds -key  
withdraw )


In my understanding, i shouldn't do "Notify Bind(bind rndc dnssec 
-checkds -key  withdraw )" and wait until all RRSIG 
sign (with the old KSK) expire. In that case, how can i check this ? 
(some dig command ? or check state file for "DSState: unretentive" ?)


I think the best approach is to enable "checkds" feature and leave it up 
to BIND to decide when it's safe to do next state transition. There 
should not be a need to do the rndc magic.


See
https://bind9.readthedocs.io/en/latest/reference.html#automated-ksk-rollovers

and also

https://bind9.readthedocs.io/en/latest/reference.html#namedconf-statement-parental-agents

I hope it helps.

--
Petr Špaček
Internet Systems Consortium
--
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: [DNSSEC] testing KASP

[adrien sipasseuth]

Only if KSK has DSState: rumoured. If the DSState is hidden it means
that it is not expected to be in the parent (for example because the
DNSKEY has not yet been fully propagated).


> Do you need to withdraw the old key too immediatly ? anything else to do ?

>>> Do you mean withdraw the old DS?

Yes, the old DS should be not yet withdraw because some RRSIG could be
still valid ? or can i withdraw the old DS / KSK immediatly ?

In my logic :
For each file en .state
If is KSK with "DSState: rumoured" or "DSState: hidden"
If not in my registar (dig ds  +dnssec +multiline)
Publish on my Registar(api register)
Notify Bind(bind rndc dnssec -checkds -key 
published )
Notify Bind(bind rndc dnssec -checkds -key 
withdraw )

In my understanding, i shouldn't do "Notify Bind(bind rndc dnssec -checkds
-key  withdraw )" and wait until all RRSIG sign (with
the old KSK) expire. In that case, how can i check this ? (some dig command
? or check state file for "DSState: unretentive" ?)

regards,

Adrien


Le ven. 17 mai 2024 à 15:13, Matthijs Mekking  a écrit :

> Hi,
>
> On 5/16/24 14:02, adrien sipasseuth wrote:
> > Hello,
> >
> > I try to set up a testing environment in order to create some scripts
> > for automated the roll over KSK.
> >
> > # question 1 #
> > this is my policy :
> >
> > dnssec-policy "test" {
> >  keys {
> >  ksk lifetime P3D algorithm ecdsa256 2048;
> >  zsk lifetime P1D algorithm ecdsa256 2048;
> >  };
> >
> >  // Key timings
> >  purge-keys P4D;
> >
> >  // Signature timings
> >  signatures-refresh  PT50M;
> >  signatures-validity PT1H;
> >  signatures-validity-dnskey PT1H;
> >
> >  // Zone parameters
> >  max-zone-ttl PT1H;
> >  parent-ds-ttl PT1H;
> >
> > };
> >
> > I would like automaticly update new DS to my registar, to do it this my
> > logic :
> >
> > For each file en .state
> >  If is KSK with "DSState: rumoured" or "DSState: hidden"
> >  If not in my registar (dig ds  +dnssec +multiline)
> >  Publish on my Registar(api register)
> >  Notify Bind(bind rndc dnssec -checkds -key  published
> > )
>
> Only if KSK has DSState: rumoured. If the DSState is hidden it means
> that it is not expected to be in the parent (for example because the
> DNSKEY has not yet been fully propagated).
>
>
> > Do y need to withdraw the old key too immediatly ? anything else to do ?
>
> Do you mean withdraw the old DS?
>
> I would use similar logic but then use "unretentive" instead of
> "rumoured". Following the example above:
>
> For each file en .state
>If is KSK with "DSState: unretentive"
>If in my registar (dig ds  +dnssec +multiline)
>Withdraw on my Registar(api register)
>Notify Bind(bind rndc dnssec -checkds -key  withdrawn
>
>
> > # question 2 #
> > If i want to unsigned a zone, i change my policy to "insecure" which is
> > default but file like .signed still exist, Bind doesn't remove
> it ?
>
> Correct. If all DNSSEC records have been removed, it is safe to remove
> the "dnssec-policy" configuration from your named.conf and then remove
> the .signed file.
>
> Unsigning your zone also takes time.
>
>
> > # question 3 #
> >
> > In state file, when the remove date issue, can i just remove the key,
> > anything else to do ?
>
> When all states are "hidden" it is safe to remove the key.
>
> Best regards,
>
> Matthijs
>
>
> > Regards,
> > Adrien SIPASSEUTH
> >
> >
> >
> --
> 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
>
-- 
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: [DNSSEC] testing KASP

[Matthijs Mekking]

Hi,

On 5/16/24 14:02, adrien sipasseuth wrote:

Hello,

I try to set up a testing environment in order to create some scripts 
for automated the roll over KSK.


# question 1 #
this is my policy :

dnssec-policy "test" {
     keys {
     ksk lifetime P3D algorithm ecdsa256 2048;
     zsk lifetime P1D algorithm ecdsa256 2048;
     };

     // Key timings
     purge-keys P4D;

     // Signature timings
     signatures-refresh  PT50M;
     signatures-validity PT1H;
     signatures-validity-dnskey PT1H;

     // Zone parameters
     max-zone-ttl PT1H;
     parent-ds-ttl PT1H;

};

I would like automaticly update new DS to my registar, to do it this my 
logic :


For each file en .state
     If is KSK with "DSState: rumoured" or "DSState: hidden"
         If not in my registar (dig ds  +dnssec +multiline)
             Publish on my Registar(api register)
             Notify Bind(bind rndc dnssec -checkds -key  published 
)


Only if KSK has DSState: rumoured. If the DSState is hidden it means 
that it is not expected to be in the parent (for example because the 
DNSKEY has not yet been fully propagated).




Do y need to withdraw the old key too immediatly ? anything else to do ?


Do you mean withdraw the old DS?

I would use similar logic but then use "unretentive" instead of 
"rumoured". Following the example above:


For each file en .state
  If is KSK with "DSState: unretentive"
  If in my registar (dig ds  +dnssec +multiline)
  Withdraw on my Registar(api register)
  Notify Bind(bind rndc dnssec -checkds -key  withdrawn



# question 2 #
If i want to unsigned a zone, i change my policy to "insecure" which is 
default but file like .signed still exist, Bind doesn't remove it ?


Correct. If all DNSSEC records have been removed, it is safe to remove 
the "dnssec-policy" configuration from your named.conf and then remove 
the .signed file.


Unsigning your zone also takes time.



# question 3 #

In state file, when the remove date issue, can i just remove the key, 
anything else to do ?


When all states are "hidden" it is safe to remove the key.

Best regards,

Matthijs



Regards,
Adrien SIPASSEUTH




--
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

[DNSSEC] testing KASP

[adrien sipasseuth]

Hello,

I try to set up a testing environment in order to create some scripts for
automated the roll over KSK.

# question 1 #
this is my policy :

dnssec-policy "test" {
keys {
ksk lifetime P3D algorithm ecdsa256 2048;
zsk lifetime P1D algorithm ecdsa256 2048;
};

// Key timings
purge-keys P4D;

// Signature timings
signatures-refresh  PT50M;
signatures-validity PT1H;
signatures-validity-dnskey PT1H;

// Zone parameters
max-zone-ttl PT1H;
parent-ds-ttl PT1H;

};

I would like automaticly update new DS to my registar, to do it this my
logic :
For each file en .state
If is KSK with "DSState: rumoured" or "DSState: hidden"
If not in my registar (dig ds  +dnssec +multiline)
Publish on my Registar(api register)
Notify Bind(bind rndc dnssec -checkds -key  published
)

Do y need to withdraw the old key too immediatly ? anything else to do ?

# question 2 #
If i want to unsigned a zone, i change my policy to "insecure" which is
default but file like .signed still exist, Bind doesn't remove it ?

# question 3 #

In state file, when the remove date issue, can i just remove the key,
anything else to do ?

Regards,
Adrien SIPASSEUTH
-- 
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: rpz testing -> shut down hung fetch while resolving

[Havard Eidnes via bind-users]

>> I recently made an upgrade of BIND to version 9.18.11 on our
>> resolver cluster, following the recent announcement.  Shortly
>> thereafter I received reports that the validation that lookups of
>> "known entries" in our quite small RPZ feed (it's around 1MB
>> on-disk) no longer succeeds as expected, but instead take a long
>> time, finally gives SRVFAIL to the client, and associated with
>> this we get this log message:
>>
>> Jan 26 18:41:27 xxx-res named[6179]: shut down hung fetch while resolving 
>> 'known-rpz-entry.no/A'
>
> This usually means there's a circular dependency somewhere in the
> resolution or validation process. For example, we can't resolve a name
> without looking up the address of a name server, but that lookup can't
> succeed until the original name is resolved. The two lookups will wait on
> each other for ten seconds, and then the whole query times out and issues
> that log message.
>
> The log message is new in 9.18, but the 10-second delay and SERVFAIL
> response would probably have happened in earlier releases as well.

This turned out to be related to the fact that we had configured
query forwarding from two of our nodes to two of the others with
the intention to build a larger central cache, and improve query
response time for the resolvers which did that forwarding.

Once I commented out the query forwarding, this problem no longer
occurred. Our forwarding config was of this form:

  forwarders {
  128.39.x.y;
  158.38.z.r;
  };
  // But if both are dead (unlikely), do resolution ourselves
  forward first;

This part is now commented out and I've done "rndc reconfig", and
the SERVFAIL responses to the "known rpz-blocked entries" no
longer occur.  But ... the two resolvers will now have to build a
cache of their own, and do not benefit from the cache built on
the two more "central" nodes.

Regards,

- Håvard
-- 
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: rpz testing -> shut down hung fetch while resolving

[Evan Hunt]

On Thu, Jan 26, 2023 at 07:03:37PM +0100, Havard Eidnes via bind-users wrote:
> Hi,
> 
> I recently made an upgrade of BIND to version 9.18.11 on our
> resolver cluster, following the recent announcement.  Shortly
> thereafter I received reports that the validation that lookups of
> "known entries" in our quite small RPZ feed (it's around 1MB
> on-disk) no longer succeeds as expected, but instead take a long
> time, finally gives SRVFAIL to the client, and associated with
> this we get this log message:
> 
> Jan 26 18:41:27 xxx-res named[6179]: shut down hung fetch while resolving 
> 'known-rpz-entry.no/A'

This usually means there's a circular dependency somewhere in the
resolution or validation process. For example, we can't resolve a name
without looking up the address of a name server, but that lookup can't
succeed until the original name is resolved. The two lookups will wait on
each other for ten seconds, and then the whole query times out and issues
that log message.

The log message is new in 9.18, but the 10-second delay and SERVFAIL
response would probably have happened in earlier releases as well.

-- 
Evan Hunt -- e...@isc.org
Internet Systems Consortium, Inc.
-- 
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

rpz testing -> shut down hung fetch while resolving

[Havard Eidnes via bind-users]

Hi,

I recently made an upgrade of BIND to version 9.18.11 on our
resolver cluster, following the recent announcement.  Shortly
thereafter I received reports that the validation that lookups of
"known entries" in our quite small RPZ feed (it's around 1MB
on-disk) no longer succeeds as expected, but instead take a long
time, finally gives SRVFAIL to the client, and associated with
this we get this log message:

Jan 26 18:41:27 xxx-res named[6179]: shut down hung fetch while resolving 
'known-rpz-entry.no/A'

Initially I thought that this was new behaviour between BIND
9.18.10 and 9.18.11, but after downgrading to 9.18.10 on one of
the affected nodes, this problem is still observable there.
Also, only a subset of our 4 nodes exhibit this behaviour,
despite the unaffected ones running 9.18.11, which is quite
strange.  None of the name servers are under severe strain by any
measure -- one affected sees around 200qps, another around 50qps
at the time of writing.

I want to ask if this sort of issue is already known (I briefly
searched the issues on ISC's gitlab and came up empty), and also
to ask if there is any particular sort of information I should
collect to narrow this down if it is a new issue.

Regards,

- Håvard
-- 
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

Testing, please ignore

[Dan Mahoney (Gushi)]

Testing, please ignore.

-Dan

--


--
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

testing, please ignore

[Dan Mahoney (Gushi)]

Sorry for the noise

--

--
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

Testing, please ignore

[Dan Mahoney]

testing, please ignore
___
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: where are the testing docs ?

[Ondřej Surý]

And I am saying all of this is a definition of off-topic, so please be nice to 
each other and stay on topic.

Dennis, we are going to accept a MR that would fix your case and not break 
anything else. You can either submit patch inline in the issue or you can ask 
and I can permit forking the project in ISC GitLab.

Ondřej
--
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 10. 5. 2021, at 20:19, Paul Kosinski via bind-users 
>  wrote:
> 
> Actually, it's in keeping with the *original* definition of hacking!
> 
> 
>> On Sun, 9 May 2021 23:55:13 -0600
>> @lbutlr  wrote:
>> 
>>> On 06 May 2021, at 09:57, Dennis Clarke via bind-users 
>>>  wrote:
>>> I do NOT trust a build result where I had to go hacking into all the
>>> Makefiles just to get it to build. You install without doing testing?  
>> 
>> That's a very strange definition of "hacking". Setting makefile [preferences 
>> and options is not in and way "hacking".
>> 
> ___
> 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: where are the testing docs ?

[Paul Kosinski via bind-users]

Actually, it's in keeping with the *original* definition of hacking!


On Sun, 9 May 2021 23:55:13 -0600
@lbutlr  wrote:

> On 06 May 2021, at 09:57, Dennis Clarke via bind-users 
>  wrote:
> > I do NOT trust a build result where I had to go hacking into all the
> > Makefiles just to get it to build. You install without doing testing?  
> 
> That's a very strange definition of "hacking". Setting makefile [preferences 
> and options is not in and way "hacking".
> 
___
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: where are the testing docs ?

[Dennis Clarke via bind-users]

On 5/10/21 01:55, @lbutlr wrote:
> On 06 May 2021, at 09:57, Dennis Clarke via bind-users 
>  wrote:
>> I do NOT trust a build result where I had to go hacking into all the
>> Makefiles just to get it to build. You install without doing testing?
> 
> That's a very strange definition of "hacking". Setting makefile [preferences 
> and options is not in and way "hacking".
> 

I realize you are being a jerk on purpose but regardless :

1) 9.11.26 builds perfectly out of the box with no issues

2) 9.11.27 fails to build with a bucket of undefined symbols

3) 9.11.28 fails to build in the same manner

4) 9.11.29 why waste my time looking here ?

5) 9.11.30 does not even exist ... please play again

6) 9.11.31 fails to build with a bucket of undefined symbols

7) dig around madly into 9.11.26 to see if *something* has gone
   wonky thereafter ... rebuild it and watch everything "just work"

8) change some compiler flags, look at the CPPFLAGS and begin
   digging into the Makefiles to see where things have gone bork

9) find that the Makefile in bin/tools is in fact bork bork bork

   10) compare the Makefile in bin/tools with the results from 9.11.26

   11) find possible bork botk bork and begin to hack in some silly
   edits to get past the bin/tools portion of this mess

   12) that works and now other things break, so begin a pile of sed
   and grep and awk and such over ALL the Makefiles everywhere and
   determine that in fact yes they are all borked slightly

I call all of those four days of work a pile of hack. On an old legacy
platform that no one wants to keep running anymore, and it just keeps
running and running. I don't know what you call it. I just say that
releases after 9.11.26 are borked. However only slightly and in places
no one would look at anyways.


-- 
Dennis Clarke
RISC-V/SPARC/PPC/ARM/CISC
UNIX and Linux spoken
GreyBeard and suspenders optional


___
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: where are the testing docs ?

On 06 May 2021, at 09:57, Dennis Clarke via bind-users 
 wrote:
> I do NOT trust a build result where I had to go hacking into all the
> Makefiles just to get it to build. You install without doing testing?

That's a very strange definition of "hacking". Setting makefile [preferences 
and options is not in and way "hacking".

-- 
I started playing Myst at 4:30 in the afternoon and looked up
suddenly and realized it was February.

___
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: where are the testing docs ?

[Dennis Clarke via bind-users]

On 5/8/21 14:13, Evan Hunt wrote:
> On Thu, May 06, 2021 at 11:57:58AM -0400, Dennis Clarke via bind-users wrote:
>> I do NOT trust a build result where I had to go hacking into all the
>> Makefiles just to get it to build. You install without doing testing?
> 
> I think Ondrej just meant that we haven't put much emphasis on making the
> tests user-friendly, since most of the time you *don't* have to hack
> makefiles. We generally use the tests to make sure we haven't broken
> something while making changes, but we're not expecting everybody to
> do so when installing a published release.  That said, I'm *delighted*
> to see people running them.
> 
> We seem to have inadvertently removed a nice feature when the tests were
> revamped a while back - it used to print a helpful message if you ran
> "make check" without setting up the environment first, and told you what
> you needed to do (specifically, "sudo sh bin/tests/system/ifconfig.sh up").
> I think the message got lost when we switched to automake.
> 
> Some tests will be skipped if there are missing dependencies, so you may
> also wish to install the Net::DNS, Net::DNS::Nameserver and XML::Simple
> modules for perl, and dnspython for python.
> 

Well to be fair the build result seems to be just fine. At least fine
enough on this legacy system. The idea is to rip this machine out of
existence in the next year regardless and that will be the last time I
ever look at Solaris or SPARC. End of an era and I think LawnMower Larry
wants things that way.  So 9.11.31 will be running as a service on some
Fujitsu SPARC64 boxen until Jan next year and that is he end of that.

For that matter, even Fujitsu tossed the platform out a window and they
built their latest supercomputer with arm64.  Lets hope that RISC-V will
get some traction but risc on big endian anything is an endangered
species rarely ever seen in the wild anymore.


-- 
Dennis Clarke
RISC-V/SPARC/PPC/ARM/CISC
UNIX and Linux spoken
GreyBeard and suspenders optional
___
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: where are the testing docs ?

[Evan Hunt]

On Thu, May 06, 2021 at 11:57:58AM -0400, Dennis Clarke via bind-users wrote:
> I do NOT trust a build result where I had to go hacking into all the
> Makefiles just to get it to build. You install without doing testing?

I think Ondrej just meant that we haven't put much emphasis on making the
tests user-friendly, since most of the time you *don't* have to hack
makefiles. We generally use the tests to make sure we haven't broken
something while making changes, but we're not expecting everybody to
do so when installing a published release.  That said, I'm *delighted*
to see people running them.

We seem to have inadvertently removed a nice feature when the tests were
revamped a while back - it used to print a helpful message if you ran
"make check" without setting up the environment first, and told you what
you needed to do (specifically, "sudo sh bin/tests/system/ifconfig.sh up").
I think the message got lost when we switched to automake.

Some tests will be skipped if there are missing dependencies, so you may
also wish to install the Net::DNS, Net::DNS::Nameserver and XML::Simple
modules for perl, and dnspython for python.

-- 
Evan Hunt -- e...@isc.org
Internet Systems Consortium, Inc.
___
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: where are the testing docs ?

[Dennis Clarke via bind-users]

On 5/6/21 11:24, Ondřej Surý wrote:
> FTR the test suite is meant to be used by developers. There’s little value to 
> use it for validating the production systems.
> 
> Generally speaking, having the dependencies and test interfaces (`sudo 
> bin/tests/system/ifconfig.sh up`) and running `make check` is enough.
> 

I do NOT trust a build result where I had to go hacking into all the
Makefiles just to get it to build. You install without doing testing?

Dennis
___
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: where are the testing docs ?

[Ondřej Surý]

FTR the test suite is meant to be used by developers. There’s little value to 
use it for validating the production systems.

Generally speaking, having the dependencies and test interfaces (`sudo 
bin/tests/system/ifconfig.sh up`) and running `make check` is enough.

Ondřej 
--
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 6. 5. 2021, at 17:03, Dennis Clarke via bind-users 
>  wrote:
> 
> On 5/6/21 10:50, Tony Finch wrote:
>> Dennis Clarke via bind-users  wrote:
>>> 
>>> Hey there. I looked in the README and I dont see an INSTALL file at all
>>> so I have to assume that the testing docs exist somewhere.
>> 
>> Have a look at
>> 
>> https://gitlab.isc.org/isc-projects/bind9/-/tree/main/bin/tests/system
> 
> Good stuff, thank you. I was searching high and low and I did see :
> 
>https://kb.isc.org/docs/aa-00768
> 
> However that says nothing at all about running the testsuite after a
> nice clean build. Which is non-trivial now that Makefiles are slightly
> borked but that is another issue.
> 
> Perhaps the docs at https://kb.isc.org/docs/aa-00768 can be updated to
> at least point to the gutlab link above?
> 
>> 
>> There are some more notes in:
>> 
>> https://gitlab.isc.org/isc-projects/bind9/-/blob/main/doc/dev
>> 
> 
> I will glance there but for now I think the testsuite should be able to
> at least run.
> 
> Dennis
> 
> ___
> 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: where are the testing docs ?

[Dennis Clarke via bind-users]

On 5/6/21 10:50, Tony Finch wrote:
> Dennis Clarke via bind-users  wrote:
>>
>> Hey there. I looked in the README and I dont see an INSTALL file at all
>>  so I have to assume that the testing docs exist somewhere.
> 
> Have a look at
> 
> https://gitlab.isc.org/isc-projects/bind9/-/tree/main/bin/tests/system

Good stuff, thank you. I was searching high and low and I did see :

https://kb.isc.org/docs/aa-00768

However that says nothing at all about running the testsuite after a
nice clean build. Which is non-trivial now that Makefiles are slightly
borked but that is another issue.

Perhaps the docs at https://kb.isc.org/docs/aa-00768 can be updated to
at least point to the gutlab link above?

> 
> There are some more notes in:
> 
> https://gitlab.isc.org/isc-projects/bind9/-/blob/main/doc/dev
> 

I will glance there but for now I think the testsuite should be able to
at least run.

Dennis

___
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: where are the testing docs ?

[Tony Finch]

Dennis Clarke via bind-users  wrote:
>
> Hey there. I looked in the README and I dont see an INSTALL file at all
>  so I have to assume that the testing docs exist somewhere.

Have a look at

https://gitlab.isc.org/isc-projects/bind9/-/tree/main/bin/tests/system

There are some more notes in:

https://gitlab.isc.org/isc-projects/bind9/-/blob/main/doc/dev

Tony.
-- 
f.anthony.n.finchhttps://dotat.at/
disperse power, foster diversity, and nurture creativity

___
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

where are the testing docs ?

[Dennis Clarke via bind-users]

Hey there. I looked in the README and I dont see an INSTALL file at all
 so I have to assume that the testing docs exist somewhere.

I build 9.11.31 after wrangling the Makefile(s) everywhere and now I
have built a separate machine to run the tests.  I needed that because
there are a bucket of interfaces needed and I can not do that on any
large production hardware easily. So anyways ... where are the testing
docs ?


-- 
Dennis Clarke
RISC-V/SPARC/PPC/ARM/CISC
UNIX and Linux spoken
GreyBeard and suspenders optional
___
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: Testing KASP, CDS, and .ch

[Jim Popovitch via bind-users]

On Sat, 2021-04-10 at 13:18 +0200, Oli Schacher wrote:
> Hi Jim
> let me give you a bit more info
> 
> > On April 9, 2021 8:23:48 PM UTC, Hugo Salgado  wrote:
> > > Switch has a website to test the CDS processing for .ch:
> > >   https://www.nic.ch/security/cds/
> > > 
> > > for domainmail.ch it says "The CDS configuration of the domain name
> > > domainmail.ch will not be processed.
> > > [ ... ]
> > > The DNS query returned: "Server failed to complete the DNS request".
> > > "
> 
> It looks like until last night (when the last check ran), the domain was 
> BOGUS ( https://dnsviz.net/d/domainmail.ch/YHDacA/dnssec/ ) - so we 
> couldn't even fetch the CDS RRSET. RFC 8078 / 7344 can not be used to 
> fix a bogus domain, this needs to be fixed by updating the DS  through 
> the registrar (which it seems you have done by now)

To be clear, although this is the first time I've reached out to this
list, I have had the DNSSEC correct on and off since it was registered
on 2021-Jan-04.

> The error message on our website in this case is indeed not very clear. 
> Eventually I hope to improve this once our resolvers support RFC8914 
> extended dns errors which we could pass on to the frontend.

+1 Thanks!!


> On 4/9/21 9:11 PM, Jim Popovitch via bind-users wrote:
> > > > What I can't figure out is how/when does .ch query the CDS/CDNSKEY data.
> > > > 
> This process happens in two stages, once every 24 hours.
> 
> In stage 1 (during the night), we scan all .CH and .LI domains for their 
> CDS RRSETS.
> Domains which already have DS in parent are scanned through a validating 
> resolver. This is where domainmail.ch failed up until last night.
> Domains which are currently insecure (=no DS in parent) are scanned over 
> TCP from multiple locations on every IP address of all nameservers 
> registered at the registry.
> 
> In stage 2 (during the day) we process the domains with CDS records 
> found in stage1 and perform additional checks. If all checks pass, we 
> apply the requested change, i.e. the DS RRSET is changed to match the 
> published CDS RRSET.
> Some restrictions are different if the domain already has a valid DS in 
> parent. For example, INSECURE domains need to provide a consistent CDS 
> RRSET on all their nameserver IPs for at least three consecutive days 
> before the DS RRSET is activated.  Key Rollovers or going unsigned 
> happens immediately if the current CDS RRSET validates ok. The 3 day 
> delay initially also applied to Rollovers and Deletes, but we have 
> meanwhile lifted this restriction  as it did not provide a security 
> benefit and caused operational issues(for example, changing Nameserver 
> operators)
> Some other restrictions however apply in all cases, for example, the CDS 
> RRSET will not be processed if the resulting DS RRSET would break the 
> chain of trust.

Thank you for that info.  

Something that most certainly contributed to my problems is that when I
did my first rounds of testing, months ago, I had a dnssec-policy of 24
hours.  At that time I didn't know about the 3-day rule, so I have
definitely learned something, Thank you.

-Jim P.

___
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: Testing KASP, CDS, and .ch

[Oli Schacher]

Hi Jim
let me give you a bit more info


On April 9, 2021 8:23:48 PM UTC, Hugo Salgado  wrote:

Switch has a website to test the CDS processing for .ch:
  https://www.nic.ch/security/cds/

for domainmail.ch it says "The CDS configuration of the domain name
domainmail.ch will not be processed.
[ ... ]
The DNS query returned: "Server failed to complete the DNS request".
"


It looks like until last night (when the last check ran), the domain was 
BOGUS ( https://dnsviz.net/d/domainmail.ch/YHDacA/dnssec/ ) - so we 
couldn't even fetch the CDS RRSET. RFC 8078 / 7344 can not be used to 
fix a bogus domain, this needs to be fixed by updating the DS  through 
the registrar (which it seems you have done by now)


The error message on our website in this case is indeed not very clear. 
Eventually I hope to improve this once our resolvers support RFC8914 
extended dns errors which we could pass on to the frontend.



On 4/9/21 9:11 PM, Jim Popovitch via bind-users wrote:

What I can't figure out is how/when does .ch query the CDS/CDNSKEY data.


This process happens in two stages, once every 24 hours.

In stage 1 (during the night), we scan all .CH and .LI domains for their 
CDS RRSETS.
Domains which already have DS in parent are scanned through a validating 
resolver. This is where domainmail.ch failed up until last night.
Domains which are currently insecure (=no DS in parent) are scanned over 
TCP from multiple locations on every IP address of all nameservers 
registered at the registry.


In stage 2 (during the day) we process the domains with CDS records 
found in stage1 and perform additional checks. If all checks pass, we 
apply the requested change, i.e. the DS RRSET is changed to match the 
published CDS RRSET.
Some restrictions are different if the domain already has a valid DS in 
parent. For example, INSECURE domains need to provide a consistent CDS 
RRSET on all their nameserver IPs for at least three consecutive days 
before the DS RRSET is activated.  Key Rollovers or going unsigned 
happens immediately if the current CDS RRSET validates ok. The 3 day 
delay initially also applied to Rollovers and Deletes, but we have 
meanwhile lifted this restriction  as it did not provide a security 
benefit and caused operational issues(for example, changing Nameserver 
operators)
Some other restrictions however apply in all cases, for example, the CDS 
RRSET will not be processed if the resulting DS RRSET would break the 
chain of trust.


Best regards
Oli
___
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: Testing KASP, CDS, and .ch

[Jim Popovitch via bind-users]

On April 9, 2021 8:21:33 PM UTC, "John W. Blue via bind-users" 
 wrote:
>Sorry .. clicked send too soon.
>
>Found this via google:
>
>https://docs.gandi.net/en/domain_names/advanced_users/dnssec.html
>
>"You can not add DS keys as we compute it for you with the KSK or ZSK, then we 
>send it to the registry."
>
>So it looks like the owner of domainmail.ch must get the DS from Gandi???  I 
>wouldn't know how that would work exactly but clearly a conversation is needed 
>with Gandi.
>
>Good hunting.

Thanks for trying but i think you're missing the point of this thread.  I'm not 
asking about how to configure DNSSEC the traditional way.   

Btw, one *can* manually setup a DS RR at Gandi, but they take and decode the 
actual key data not the DS.


-Jim P 
___
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: Testing KASP, CDS, and .ch

[Jim Popovitch via bind-users]

On April 9, 2021 8:23:48 PM UTC, Hugo Salgado  wrote:
>Switch has a website to test the CDS processing for .ch:
>  https://www.nic.ch/security/cds/
>
>for domainmail.ch it says "The CDS configuration of the domain name
>domainmail.ch will not be processed.
>[ ... ]
>The DNS query returned: "Server failed to complete the DNS request".
>"
>
>You should check the requirements. You'd need to answer for three
>consecutive days, be consistent in all NS IP addresses, etc.
>
>Hugo
>
>On 15:11 09/04, Jim Popovitch via bind-users wrote:
>> On Fri, 2021-04-09 at 19:05 +, John W. Blue via bind-users wrote:
>> > So the issue here is that the DS record that sit in .ch has an ID of 22048 
>> > but the domainmail.ch servers are telling the world that the correct ID is 
>> > 17870.
>> > 
>> > Thus the DNSSEC breakage.
>> 
>> Of course, however there is no 22048 id in Gandi (the Registrar), yet it
>> appears in .ch, and 17870 is still Active (as of this moment in time).  
>> 
>> What I can't figure out is how/when does .ch query the CDS/CDNSKEY data.
>> 
>> I know that I can make the domain validate by manually putting a
>> keyid+data in Gandi, but the whole purpose of CDS/CDNSKEY is to not have
>> to do that, no?
>> 
>> -Jim P.
>> 
>> 
>> 
>> ___
>> 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
>> 

Thanks Hugo!  That helps.

-Jim P.
___
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: Testing KASP, CDS, and .ch

[Hugo Salgado]

Switch has a website to test the CDS processing for .ch:
  https://www.nic.ch/security/cds/

for domainmail.ch it says "The CDS configuration of the domain name
domainmail.ch will not be processed.
[ ... ]
The DNS query returned: "Server failed to complete the DNS request".
"

You should check the requirements. You'd need to answer for three
consecutive days, be consistent in all NS IP addresses, etc.

Hugo

On 15:11 09/04, Jim Popovitch via bind-users wrote:
> On Fri, 2021-04-09 at 19:05 +, John W. Blue via bind-users wrote:
> > So the issue here is that the DS record that sit in .ch has an ID of 22048 
> > but the domainmail.ch servers are telling the world that the correct ID is 
> > 17870.
> > 
> > Thus the DNSSEC breakage.
> 
> Of course, however there is no 22048 id in Gandi (the Registrar), yet it
> appears in .ch, and 17870 is still Active (as of this moment in time).  
> 
> What I can't figure out is how/when does .ch query the CDS/CDNSKEY data.
> 
> I know that I can make the domain validate by manually putting a
> keyid+data in Gandi, but the whole purpose of CDS/CDNSKEY is to not have
> to do that, no?
> 
> -Jim P.
> 
> 
> 
> ___
> 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
> 


signature.asc
Description: 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

RE: Testing KASP, CDS, and .ch

[John W. Blue via bind-users]

Sorry .. clicked send too soon.

Found this via google:

https://docs.gandi.net/en/domain_names/advanced_users/dnssec.html

"You can not add DS keys as we compute it for you with the KSK or ZSK, then we 
send it to the registry."

So it looks like the owner of domainmail.ch must get the DS from Gandi???  I 
wouldn't know how that would work exactly but clearly a conversation is needed 
with Gandi.

Good hunting.

John

-Original Message-
From: bind-users [mailto:bind-users-boun...@lists.isc.org] On Behalf Of Jim 
Popovitch via bind-users
Sent: Friday, April 09, 2021 2:12 PM
To: bind-users@lists.isc.org
Subject: Re: Testing KASP, CDS, and .ch

On Fri, 2021-04-09 at 19:05 +, John W. Blue via bind-users wrote:
> So the issue here is that the DS record that sit in .ch has an ID of 22048 
> but the domainmail.ch servers are telling the world that the correct ID is 
> 17870.
> 
> Thus the DNSSEC breakage.

Of course, however there is no 22048 id in Gandi (the Registrar), yet it 
appears in .ch, and 17870 is still Active (as of this moment in time).  

What I can't figure out is how/when does .ch query the CDS/CDNSKEY data.

I know that I can make the domain validate by manually putting a
keyid+data in Gandi, but the whole purpose of CDS/CDNSKEY is to not have
to do that, no?

-Jim P.



___
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: Testing KASP, CDS, and .ch

[John W. Blue via bind-users]

The owner of domainmail.ch will need to give .ch an updated copy of the DS 
record that contains 17870.

Once that has been accomplished .ch will start telling the open internet to 
expect 17870 when talking to domainmail.ch.  When the open internet matches 
what it expects with what it gets then DNSSEC will be validated.

John

-Original Message-
From: bind-users [mailto:bind-users-boun...@lists.isc.org] On Behalf Of Jim 
Popovitch via bind-users
Sent: Friday, April 09, 2021 2:12 PM
To: bind-users@lists.isc.org
Subject: Re: Testing KASP, CDS, and .ch

On Fri, 2021-04-09 at 19:05 +, John W. Blue via bind-users wrote:
> So the issue here is that the DS record that sit in .ch has an ID of 22048 
> but the domainmail.ch servers are telling the world that the correct ID is 
> 17870.
> 
> Thus the DNSSEC breakage.

Of course, however there is no 22048 id in Gandi (the Registrar), yet it 
appears in .ch, and 17870 is still Active (as of this moment in time).  

What I can't figure out is how/when does .ch query the CDS/CDNSKEY data.

I know that I can make the domain validate by manually putting a
keyid+data in Gandi, but the whole purpose of CDS/CDNSKEY is to not have
to do that, no?

-Jim P.



___
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: Testing KASP, CDS, and .ch

[Jim Popovitch via bind-users]

On Fri, 2021-04-09 at 19:05 +, John W. Blue via bind-users wrote:
> So the issue here is that the DS record that sit in .ch has an ID of 22048 
> but the domainmail.ch servers are telling the world that the correct ID is 
> 17870.
> 
> Thus the DNSSEC breakage.

Of course, however there is no 22048 id in Gandi (the Registrar), yet it
appears in .ch, and 17870 is still Active (as of this moment in time).  

What I can't figure out is how/when does .ch query the CDS/CDNSKEY data.

I know that I can make the domain validate by manually putting a
keyid+data in Gandi, but the whole purpose of CDS/CDNSKEY is to not have
to do that, no?

-Jim P.



___
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: Testing KASP, CDS, and .ch

[John W. Blue via bind-users]

So the issue here is that the DS record that sit in .ch has an ID of 22048 but 
the domainmail.ch servers are telling the world that the correct ID is 17870.

Thus the DNSSEC breakage.

John

-Original Message-
From: bind-users [mailto:bind-users-boun...@lists.isc.org] On Behalf Of Jim 
Popovitch via bind-users
Sent: Friday, April 09, 2021 1:58 PM
To: bind-users@lists.isc.org
Subject: Testing KASP, CDS, and .ch

Hello!

I've read the "Schacher 20200622 Support for and adoption of CDS in .ch and 
.li", and studied https://kb.isc.org/docs/dnssec-key-and-signing-policy, 
however I've hita brick wall: 

https://dnsviz.net/d/domainmail.ch/dnssec/

What am I missing?

I'm using the following policy and zone config: 

dnssec-policy "test" {
keys { csk lifetime P30D algorithm ECDSAP256SHA256; }; };

zone "domainmail.ch" {
type master;
file "/etc/bind/zone/domainmail.ch";
dnssec-policy "test";
};

Here are the info of the active keys:

/etc/bind/keys/Kdomainmail.ch.+013+22048.key
; This is a key-signing key, keyid 22048, for domainmail.ch.
; Created: 20210208192710 (Mon Feb  8 19:27:10 2021) ; Publish: 20210208192710 
(Mon Feb  8 19:27:10 2021) ; Activate: 20210208222710 (Mon Feb  8 22:27:10 
2021) ; Inactive: 20210310222710 (Wed Mar 10 22:27:10 2021) ; Delete: 
20210320233210 (Sat Mar 20 23:32:10 2021) ; SyncPublish: 20210208222710 (Mon 
Feb  8 22:27:10 2021)

/etc/bind/keys/Kdomainmail.ch.+013+17870.key
; This is a key-signing key, keyid 17870, for domainmail.ch.
; Created: 20210310202210 (Wed Mar 10 20:22:10 2021) ; Publish: 20210310202210 
(Wed Mar 10 20:22:10 2021) ; Activate: 20210310222710 (Wed Mar 10 22:27:10 
2021) ; Inactive: 20210409222710 (Fri Apr  9 22:27:10 2021) ; Delete: 
20210419233210 (Mon Apr 19 23:32:10 2021) ; SyncPublish: 20210310222710 (Wed 
Mar 10 22:27:10 2021)

/etc/bind/keys/Kdomainmail.ch.+013+04319.key
; This is a key-signing key, keyid 4319, for domainmail.ch.
; Created: 20210220012755 (Sat Feb 20 01:27:55 2021) ; Publish: 20210220012755 
(Sat Feb 20 01:27:55 2021) ; Activate: 20210220012755 (Sat Feb 20 01:27:55 
2021) ; Inactive: 20210221040633 (Sun Feb 21 04:06:33 2021) ; Delete: 
20210303051133 (Wed Mar  3 05:11:33 2021) ; SyncPublish: 20210221023255 (Sun 
Feb 21 02:32:55 2021)


-Jim P.

___
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

Testing KASP, CDS, and .ch

[Jim Popovitch via bind-users]

Hello!

I've read the "Schacher 20200622 Support for and adoption of CDS in .ch
and .li", and studied 
https://kb.isc.org/docs/dnssec-key-and-signing-policy, however I've hita brick 
wall: 

https://dnsviz.net/d/domainmail.ch/dnssec/

What am I missing?

I'm using the following policy and zone config: 

dnssec-policy "test" {
keys { csk lifetime P30D algorithm ECDSAP256SHA256; };
};

zone "domainmail.ch" {
type master;
file "/etc/bind/zone/domainmail.ch";
dnssec-policy "test";
};

Here are the info of the active keys:

/etc/bind/keys/Kdomainmail.ch.+013+22048.key
; This is a key-signing key, keyid 22048, for domainmail.ch.
; Created: 20210208192710 (Mon Feb  8 19:27:10 2021)
; Publish: 20210208192710 (Mon Feb  8 19:27:10 2021)
; Activate: 20210208222710 (Mon Feb  8 22:27:10 2021)
; Inactive: 20210310222710 (Wed Mar 10 22:27:10 2021)
; Delete: 20210320233210 (Sat Mar 20 23:32:10 2021)
; SyncPublish: 20210208222710 (Mon Feb  8 22:27:10 2021)

/etc/bind/keys/Kdomainmail.ch.+013+17870.key
; This is a key-signing key, keyid 17870, for domainmail.ch.
; Created: 20210310202210 (Wed Mar 10 20:22:10 2021)
; Publish: 20210310202210 (Wed Mar 10 20:22:10 2021)
; Activate: 20210310222710 (Wed Mar 10 22:27:10 2021)
; Inactive: 20210409222710 (Fri Apr  9 22:27:10 2021)
; Delete: 20210419233210 (Mon Apr 19 23:32:10 2021)
; SyncPublish: 20210310222710 (Wed Mar 10 22:27:10 2021)

/etc/bind/keys/Kdomainmail.ch.+013+04319.key
; This is a key-signing key, keyid 4319, for domainmail.ch.
; Created: 20210220012755 (Sat Feb 20 01:27:55 2021)
; Publish: 20210220012755 (Sat Feb 20 01:27:55 2021)
; Activate: 20210220012755 (Sat Feb 20 01:27:55 2021)
; Inactive: 20210221040633 (Sun Feb 21 04:06:33 2021)
; Delete: 20210303051133 (Wed Mar  3 05:11:33 2021)
; SyncPublish: 20210221023255 (Sun Feb 21 02:32:55 2021)


-Jim P.

___
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: Testing a new master server...

[Bruce Johnson]

On Nov 18, 2020, at 11:26 PM, John W. Blue via bind-users 
mailto:bind-users@lists.isc.org>> wrote:

Hello Bruce!

For opening comments .. I have nothing but empathy for you and the firefight 
you are in.  "Intuitional inertia" is never enjoyable especially when you are 
the one tasked with change.

So you indicated "upstream network management" is sending DNS/DHCP traffic but 
then you say that it is from your vLAN's.  That does not make sense.

It feels like what you meant to say is that you have a bunch of zones and there 
is a ton of traffic (DNS/DHCP) being sent from your vLAN's *and* you need to 
coordinate and changes with "upstream network management".  The reason why I 
bring this up is because (without extra data points) it feels like you are 
attempting to replace an old bandaid with a new one hoping that will resolve 
user angst.


I am probably explaining this poorly. Our college has units in 5 different 
buildings on two campuses in different cities. The University network has set 
up Vlans in those buildings on the larger network that they control, and we 
provide DNS/DHCP/Windows Domain service on those VLANS, so when a dhcp request 
comes from one of them it is directed to this server.

The server itself resides on a vlan that is tied to one port from the switch, 
and if it is moved to a different port (which it now has to be, since it’s now 
going to be virtualized) and that is not under our control, but the main campus 
network management, so that needs to be coordinated.


Some things to think about as a sanity check:
If the current configuration is so easy to break, do you really want to keep 
administrating a design that is doing that?

It isn't ‘easy to break’, it’s that I am a neophyte at setting this up. We’ve 
really had zero issues with DNS/DHCP with the current setup, but I wasn’t the 
one doing the configuring. As I said, I’m probably overthinking what can go 
wrong. The previous person who did this told me “Just copy all the 
configuration files over to the new box, give it the right IP address and 
you’re good”.

What change management processes are in place when OS patches need to be 
applied or there DNS/DHCP maintenance to be done?
Does this server face the open Internet or is it exclusively an RFC1918 box?

It faces the open internet. We have a mix of public and private zones.

If one server is responsible for both DNS/DHCP for everything would it make 
more sense to split the roles out?

That’s probably a very good idea, that it hasn’t been done before now is that 
this setup has worked reliably for decades, and we pretty much proceeded on the 
“it ain’t broke, so lets not fix it” …then the people who had done this retired 
or moved to other jobs, I’m now the “*nix ‘Expert’"…and now it’s old enough 
that we have to deal with replacing it in an orderly fashion rather than on an 
emergency one.


Assuming there is currently one RFC1918 server for everything, my thoughts (at 
a very high level) would be to redesign the environment to start using a hidden 
primary.  Next, stand up two DNS servers as secondaries (configured with ' 
allow-update-forwarding ') each running DHCP to take advantage of "auto partner 
down".  With a hidden primary there is now a single source of truth on the 
network that is being dynamically update by the secondaries.

When it comes time for maintenance, rebooting or taking one of the secondary 
servers offline will not kill off the services for the users.  When it is time 
to apply patches to the hidden primary, do that after hours.  " 
allow-update-forwarding" is real-time forwarding not store and forward.

To address your question about "allow-transfer" and "allow-update" I don’t 
think those are as important as disabling "also-notify".

Thanks for these tips, this makes me feel a lot more confident that I'm on the 
right track.


Regardless, I do hope your migration goes smooth!

John

-Original Message-
From: bind-users [mailto:bind-users-boun...@lists.isc.org] On Behalf Of Bruce 
Johnson
Sent: Wednesday, November 18, 2020 11:35 AM
To: bind-users@lists.isc.org<mailto:bind-users@lists.isc.org>
Subject: Testing a new master server...

I’m in the process of migrating our master DNS server from an ancient system 
(it’s running RHEL4.0) to a modern system. This kind of fell in my lap; I’m 
familiar with adding host assignments and such but managing the server itself 
in the past is pretty much relegated  to ’service named reload’ and finding the 
newly introduced typo in the hosts or zone file if it fails...

It's a mildly complicated setup with a bunch of zones (including a big one that 
is dynamically updated) and more pressingly I will need to coordinate with 
upstream network management that sends DNS and dhcp requests from our VLAN's to 
the specific switch port it is on when we do the cutover, then change the IP 
address on the new s

RE: Testing a new master server...

[John W. Blue via bind-users]

Hello Bruce!

For opening comments .. I have nothing but empathy for you and the firefight 
you are in.  "Intuitional inertia" is never enjoyable especially when you are 
the one tasked with change.

So you indicated "upstream network management" is sending DNS/DHCP traffic but 
then you say that it is from your vLAN's.  That does not make sense.

It feels like what you meant to say is that you have a bunch of zones and there 
is a ton of traffic (DNS/DHCP) being sent from your vLAN's *and* you need to 
coordinate and changes with "upstream network management".  The reason why I 
bring this up is because (without extra data points) it feels like you are 
attempting to replace an old bandaid with a new one hoping that will resolve 
user angst.

Some things to think about as a sanity check:
If the current configuration is so easy to break, do you really want to keep 
administrating a design that is doing that?
What change management processes are in place when OS patches need to be 
applied or there DNS/DHCP maintenance to be done?
Does this server face the open Internet or is it exclusively an RFC1918 box?
If one server is responsible for both DNS/DHCP for everything would it make 
more sense to split the roles out?

Assuming there is currently one RFC1918 server for everything, my thoughts (at 
a very high level) would be to redesign the environment to start using a hidden 
primary.  Next, stand up two DNS servers as secondaries (configured with ' 
allow-update-forwarding ') each running DHCP to take advantage of "auto partner 
down".  With a hidden primary there is now a single source of truth on the 
network that is being dynamically update by the secondaries.

When it comes time for maintenance, rebooting or taking one of the secondary 
servers offline will not kill off the services for the users.  When it is time 
to apply patches to the hidden primary, do that after hours.  " 
allow-update-forwarding" is real-time forwarding not store and forward.

To address your question about "allow-transfer" and "allow-update" I don’t 
think those are as important as disabling "also-notify".

Regardless, I do hope your migration goes smooth!

John

-Original Message-
From: bind-users [mailto:bind-users-boun...@lists.isc.org] On Behalf Of Bruce 
Johnson
Sent: Wednesday, November 18, 2020 11:35 AM
To: bind-users@lists.isc.org
Subject: Testing a new master server...

I’m in the process of migrating our master DNS server from an ancient system 
(it’s running RHEL4.0) to a modern system. This kind of fell in my lap; I’m 
familiar with adding host assignments and such but managing the server itself 
in the past is pretty much relegated  to ’service named reload’ and finding the 
newly introduced typo in the hosts or zone file if it fails...

It's a mildly complicated setup with a bunch of zones (including a big one that 
is dynamically updated) and more pressingly I will need to coordinate with 
upstream network management that sends DNS and dhcp requests from our VLAN's to 
the specific switch port it is on when we do the cutover, then change the IP 
address on the new server so that it repsonds as the old master, so if I can be 
sure it’ll work I’ll have fewer main campus network mnanagers annoyed with me 
and many fewer end users with torches and pitchforks at my door for breaking 
everything...  

I've made some changes to the configuration (mostly removing zones and address 
assignments that are no longer valid) and I'd like to bring it up for testing 
so I know it’s working before we do the cutover to production.

If I comment out the the allow-transfer directive so it does not divert 
requests to our ‘real' secondary servers and the allow-update for the 
dynamically updated zone, I think I should be able to bring it up in a master 
server role (on a different IP address) without it interfering with our real 
one, as the only clients that would actually talk to it would be ones that 
specify that IP address for resolution.

Am I missing something or overcomplicating things?

-- 
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

Testing a new master server...

[Bruce Johnson]

I’m in the process of migrating our master DNS server from an ancient system 
(it’s running RHEL4.0) to a modern system. This kind of fell in my lap; I’m 
familiar with adding host assignments and such but managing the server itself 
in the past is pretty much relegated  to ’service named reload’ and finding the 
newly introduced typo in the hosts or zone file if it fails...

It's a mildly complicated setup with a bunch of zones (including a big one that 
is dynamically updated) and more pressingly I will need to coordinate with 
upstream network management that sends DNS and dhcp requests from our VLAN's to 
the specific switch port it is on when we do the cutover, then change the IP 
address on the new server so that it repsonds as the old master, so if I can be 
sure it’ll work I’ll have fewer main campus network mnanagers annoyed with me 
and many fewer end users with torches and pitchforks at my door for breaking 
everything...  

I've made some changes to the configuration (mostly removing zones and address 
assignments that are no longer valid) and I'd like to bring it up for testing 
so I know it’s working before we do the cutover to production.

If I comment out the the allow-transfer directive so it does not divert 
requests to our ‘real' secondary servers and the allow-update for the 
dynamically updated zone, I think I should be able to bring it up in a master 
server role (on a different IP address) without it interfering with our real 
one, as the only clients that would actually talk to it would be ones that 
specify that IP address for resolution.

Am I missing something or overcomplicating things?

-- 
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: Testing

[Nuno]

Working

Nuno

Sent from my Verizon 4G LTE Droid
On Feb 14, 2018 1:48 AM, Dan Mahoney <dmaho...@isc.org> wrote:
>
> Please ignore -- just testing post mailman upgrade. 
>
> Best, 
>
> -Dan Mahoney 
> ISC Operations Group 
> ___ 
> Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
> from this list 
>
> 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

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Testing

[Dan Mahoney]

Please ignore -- just testing post mailman upgrade.

Best,

-Dan Mahoney
ISC Operations Group
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: Testing...

[Hika van den Hoven]

Hoi Tony,

Wednesday, August 30, 2017, 6:44:32 PM, you wrote:

> Grant Taylor  wrote:
>>
>> There is additional footer content (as well as headers) in messages from the
>> mailing list.
>>
>> Does Gmail detect that and ignore it?  Or is the message simply folded into
>> the conversation in Gmail?

> No, I believe deduplication is based purely on the message-ID, but as far
> as I can see it isn't documented by Google. If you have more questions
> about Gmail you should take them elsewhere. There are reasons I am no
> longer a postmaster...

> Tony.

As far as I know If you pop from a gmail account, it will never
include any message containing itself as the sender. However if you go
to web-mail it will be there. Gmail takes part of the tasks of your
mail program by keeping track of what has been downloaded and it seems
to mark those messages as already downloaded.
So in that case you have to use your mailprogram filtering to copy
your send messages to the list folder.

Tot mails,
  bind userlistmailto:hika...@gmail.com

"Zonder hoop kun je niet leven
Zonder leven is er geen hoop
Het eeuwige dilemma
Zeker als je hoop moet vernietigen om te kunnen overleven!"

De lerende Mens
--

___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: Testing...

[Alan Clegg]

On 8/30/17 12:44 PM, Tony Finch wrote:

> There are reasons I am no longer a postmaster...

And they all said Ramen...

AlanC



signature.asc
Description: OpenPGP digital signature
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: Testing...

[Tony Finch]

Grant Taylor  wrote:
>
> There is additional footer content (as well as headers) in messages from the
> mailing list.
>
> Does Gmail detect that and ignore it?  Or is the message simply folded into
> the conversation in Gmail?

No, I believe deduplication is based purely on the message-ID, but as far
as I can see it isn't documented by Google. If you have more questions
about Gmail you should take them elsewhere. There are reasons I am no
longer a postmaster...

Tony.
-- 
f.anthony.n.finch    http://dotat.at/  -  I xn--zr8h punycode
Trafalgar: North or northwest 4 or 5, occasionally 6 later. Moderate,
occasionally rough later in northwest. Showers. Good.
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: Testing...

[Grant Taylor]

On 08/30/2017 09:49 AM, Tony Finch wrote:

You seem to be using Gmail which does de-duplication across all messages
in your account, so your messages received from the list are deleted since
they are duplicates of the copies in your sent-mail folder.


There is additional footer content (as well as headers) in messages from 
the mailing list.


Does Gmail detect that and ignore it?  Or is the message simply folded 
into the conversation in Gmail?


Also, there is a Mailman setting to enable receiving your own posts to 
the mailing list.  I believe it is disabled by default.




--
Grant. . . .
unix || die



smime.p7s
Description: S/MIME Cryptographic Signature
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: Testing...

[Tony Finch]

Alan Clegg  wrote:
>
> It appears that I just don't see my own posts for whatever reason.  8-)

You seem to be using Gmail which does de-duplication across all messages
in your account, so your messages received from the list are deleted since
they are duplicates of the copies in your sent-mail folder.

Tony.
-- 
f.anthony.n.finch    http://dotat.at/  -  I xn--zr8h punycode
South Utsire: Westerly or northwesterly 3 or 4, decreasing 2 for a time.
Slight or moderate. Showers. Good.
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: Testing...

[Alan Clegg]

On 8/30/17 11:25 AM, Adamiec, Lawrence wrote:
> I see your email on the list.

Thanks to those that have responded both on- and off-list.

It appears that I just don't see my own posts for whatever reason.  8-)

[You know how long it's been since I debugged a mailing list issue??!]

No additional responses needed at this time.

AlanC



signature.asc
Description: OpenPGP digital signature
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: Testing...

[Warren Kumari]

... yes, yes you are.

I'm explicitly responding in case you have the mailman "Don't send me
my own posts" (not metoo) option.

W

On Wed, Aug 30, 2017 at 11:20 AM, Alan Clegg  wrote:
> I don't think I can post to this list for some reason.
>
> I'd like to be able to respond to questions, but my responses never seem
> to show up...
>
> this is just a test to see if I am visible on the list.
>
> Thanks!
> AlanC
>
>
> ___
> Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
> from this list
>
> bind-users mailing list
> bind-users@lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users



-- 
I don't think the execution is relevant when it was obviously a bad
idea in the first place.
This is like putting rabid weasels in your pants, and later expressing
regret at having chosen those particular rabid weasels and that pair
of pants.
   ---maf
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: Testing...

[Adamiec, Lawrence]

I see your email on the list.



Thank you.
Larry

__
Lawrence Adamiec
Web Developer/UNIX Admin
Information Technology Services (ITS)
Chicago-Kent College of Law
Illinois Institute of Technology
565 W. Adams St.
Chicago, IL
60661

On Wed, Aug 30, 2017 at 10:20 AM, Alan Clegg  wrote:

> I don't think I can post to this list for some reason.
>
> I'd like to be able to respond to questions, but my responses never seem
> to show up...
>
> this is just a test to see if I am visible on the list.
>
> Thanks!
> AlanC
>
>
> ___
> Please visit https://lists.isc.org/mailman/listinfo/bind-users to
> unsubscribe from this list
>
> 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

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Testing...

[Alan Clegg]

I don't think I can post to this list for some reason.

I'd like to be able to respond to questions, but my responses never seem
to show up...

this is just a test to see if I am visible on the list.

Thanks!
AlanC



signature.asc
Description: OpenPGP digital signature
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: Testing DNS security

[Emil Natan]

There is a difference between security policy check and performance check.
If you want to check policies, you can do it manually issuing different sorts 
of queries from different locations making sure what should be answered is 
answered and what should not be answered is not.
If you want to test performance, there are multiple tools that could 
generate/replay queries at high volume, just search the list, the topic was 
discussed multiple times.

Emil






 Original Message 
Subject: Testing DNS security
Local Time: February 21, 2017 2:05 PM
UTC Time: February 21, 2017 12:05 PM
From: kaoutharcheti...@gmail.com
To: bind-users <bind-users@lists.isc.org>



Hi,


I have created a DNS server by using BIND and I have established security 
policies

Now I want to test its performance before hosting it

Can you recommend me network simulators that allow to check its security ??


Thank you in advance.

--___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Testing DNS security

[Kaouthar Chetioui]

Hi,

I have created a DNS server by using BIND and I have established  security
policies

Now I want to test its performance before hosting it

Can you recommend me network simulators that allow to check its security ??


Thank you in advance.

--
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: Can anyone tell me a good DNS server testing program

[King, Harold Clyde (Hal)]

Thanks everyone for your suggestions. I’ll go forward with dnsperf.


-- 
Hal King  - h...@utk.edu
Systems Administrator
Office of Information Technology
Shared Systems Services

The University of Tennessee
103C5 Kingston Pike Building
2309 Kingston Pk. Knoxville, TN 37996
Phone : 974-1599
Helpdesk 24/7 : 974-9900

On 6/22/16, 08:58, "Warren Kumari" <war...@kumari.net> wrote:

Kinda depends on what you are testing, but there is also Nominum's
dnsperf: http://nominum.com/measurement-tools/

This is easy to install, simple to use, and comes with a sample query file.
W

On Wed, Jun 22, 2016 at 8:48 AM, Emil Natan <shly...@gmail.com> wrote:
> queryperf, supplied with BIND, found under contrib.
> What we usually do is "record" some real traffic, then run queryperf on
> multiple machines against a server. If I'm not mistaken similar topic was
> discussed here recently so you can search the archives.
>
> Emil
>
> On Wed, Jun 22, 2016 at 3:34 PM, King, Harold Clyde (Hal) <h...@utk.edu>
> wrote:
>>
>> I have a new DNS BIND setup that I need to stress test. There are many
>> test for hitting a web server to simulate traffic, but I can’t find a one
>> for doing the same thing to a DNS server. Does anyone have any
>> recommendations?
>>
>>
>> --
>> Hal King  - h...@utk.edu
>> Systems Administrator
>> Office of Information Technology
>> Shared Systems Services
>>
>> The University of Tennessee
>> 103C5 Kingston Pike Building
>> 2309 Kingston Pk. Knoxville, TN 37996
>> Phone : 974-1599
>> Helpdesk 24/7 : 974-9900
>>
>> ___
>> Please visit https://lists.isc.org/mailman/listinfo/bind-users to
>> unsubscribe from this list
>>
>> 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
>
> bind-users mailing list
> bind-users@lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users



-- 
I don't think the execution is relevant when it was obviously a bad
idea in the first place.
This is like putting rabid weasels in your pants, and later expressing
regret at having chosen those particular rabid weasels and that pair
of pants.
   ---maf


___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: Testing

[Bill Christensen]

Polo

On 6/24/16 6:29 PM, John W. Blue wrote:

Marco

Sent from Nine <http://www.9folders.com/>

*From:* Dan Mahoney <dmaho...@isc.org>
*Sent:* Jun 24, 2016 6:28 PM
*To:* bind-us...@isc.org
*Subject:* Testing

testing
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to 
unsubscribe from this list


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

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users



--
Bill Christensen
http://SustainableSources.com
http://LinkedIn.com/in/billc108

___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Testing SMTP

[Dan Mahoney]

Sorry for the noise, please ignore.

-Dan Mahoney
ISC Ops team
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Testing

[Dan Mahoney]

testing
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: Can anyone tell me a good DNS server testing program

[Warren Kumari]

Kinda depends on what you are testing, but there is also Nominum's
dnsperf: http://nominum.com/measurement-tools/

This is easy to install, simple to use, and comes with a sample query file.
W

On Wed, Jun 22, 2016 at 8:48 AM, Emil Natan <shly...@gmail.com> wrote:
> queryperf, supplied with BIND, found under contrib.
> What we usually do is "record" some real traffic, then run queryperf on
> multiple machines against a server. If I'm not mistaken similar topic was
> discussed here recently so you can search the archives.
>
> Emil
>
> On Wed, Jun 22, 2016 at 3:34 PM, King, Harold Clyde (Hal) <h...@utk.edu>
> wrote:
>>
>> I have a new DNS BIND setup that I need to stress test. There are many
>> test for hitting a web server to simulate traffic, but I can’t find a one
>> for doing the same thing to a DNS server. Does anyone have any
>> recommendations?
>>
>>
>> --
>> Hal King  - h...@utk.edu
>> Systems Administrator
>> Office of Information Technology
>> Shared Systems Services
>>
>> The University of Tennessee
>> 103C5 Kingston Pike Building
>> 2309 Kingston Pk. Knoxville, TN 37996
>> Phone : 974-1599
>> Helpdesk 24/7 : 974-9900
>>
>> ___
>> Please visit https://lists.isc.org/mailman/listinfo/bind-users to
>> unsubscribe from this list
>>
>> 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
>
> bind-users mailing list
> bind-users@lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users



-- 
I don't think the execution is relevant when it was obviously a bad
idea in the first place.
This is like putting rabid weasels in your pants, and later expressing
regret at having chosen those particular rabid weasels and that pair
of pants.
   ---maf
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: Can anyone tell me a good DNS server testing program

[Emil Natan]

queryperf, supplied with BIND, found under contrib.
What we usually do is "record" some real traffic, then run queryperf on
multiple machines against a server. If I'm not mistaken similar topic was
discussed here recently so you can search the archives.

Emil

On Wed, Jun 22, 2016 at 3:34 PM, King, Harold Clyde (Hal) 
wrote:

> I have a new DNS BIND setup that I need to stress test. There are many
> test for hitting a web server to simulate traffic, but I can’t find a one
> for doing the same thing to a DNS server. Does anyone have any
> recommendations?
>
>
> --
> Hal King  - h...@utk.edu
> Systems Administrator
> Office of Information Technology
> Shared Systems Services
>
> The University of Tennessee
> 103C5 Kingston Pike Building
> 2309 Kingston Pk. Knoxville, TN 37996
> Phone : 974-1599
> Helpdesk 24/7 : 974-9900
>
> ___
> Please visit https://lists.isc.org/mailman/listinfo/bind-users to
> unsubscribe from this list
>
> 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

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Can anyone tell me a good DNS server testing program

[King, Harold Clyde (Hal)]

I have a new DNS BIND setup that I need to stress test. There are many test for 
hitting a web server to simulate traffic, but I can’t find a one for doing the 
same thing to a DNS server. Does anyone have any recommendations?


-- 
Hal King  - h...@utk.edu
Systems Administrator
Office of Information Technology
Shared Systems Services

The University of Tennessee
103C5 Kingston Pike Building
2309 Kingston Pk. Knoxville, TN 37996
Phone : 974-1599
Helpdesk 24/7 : 974-9900

___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Testing DNS delegation using 2 Linux devices

[Harshith Mulky]

Hello,


Is it possible to test DNS delegation using 2 Linux devices running RHEL 
Version 6.1 and bind-9.8.2


What changes would be required in named.conf or Zone Files in order to test this


P.S: This is just for my learning purpose, as I am unable to understand how the 
Tiered architecture works


Thanks

Harshith
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: Testing RFC 5011 key roll

[Edward Lewis]

Evan/et.al.,

I've updated to 9.10.2, adjusted the timers, etc., and have managed to
follow the keyroll.systems test over night (a handful of key changes) plus
still get the desired AD bit.

With the timing in mind, I looked at my unbound (I realize this is BIND
users ;)) which wasn't keeping up with the rolls - I had neglected to
speed up it's clock.  Once I did that, it worked.

My lesson is - besides just working out the configuration - testing
RFC5011 takes more patience than just about any other feature of
DNS/DNSSEC.  RFC5011 is the most wall-clock driven mechanism we have.
(Yes, signatures expire and TTL's lapse, but these can be set low in lab
environments.)

I have a suggestion - is there a way to query a BIND server for it's trust
anchor key set?  Perhaps it is unnecessary and perhaps it should only be
allowed by authorized users.  I say perhaps unnecessary because the
information may be available on disk (which an administrator could get to
via ssh, perhaps).

Ed

On 4/20/15, 15:12, Evan Hunt e...@isc.org wrote:

On Mon, Apr 20, 2015 at 06:42:42PM +, Edward Lewis wrote:
 Being that I'm working on a laptop (hence on on over the weekend) I've
had
 to recreate the environment today.  I'm a bit more puzzled now.

There's a separate file that named creates to keep the current
managed keys state information -- it's based on the view name,
so in your case it'll be recursive.mkeys (and possibly
recursive.mkeys.jnl).  I suspect it still has the key from
Friday in it, and that's messing things up.  Delete that file and
reinitialize, then leave the server up and running (not forgetting
to use -T mkeytimers=H/D/M, where M is no more than 3600 seconds,
because keyroll.systems rolls its keys every hour and normal RFC
5011 processing can't handle that), and you should be in good shape.

-- 
Evan Hunt -- e...@isc.org
Internet Systems Consortium, Inc.


smime.p7s
Description: S/MIME cryptographic signature
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: Testing RFC 5011 key roll

[Evan Hunt]

 By default it dumps its output to a file; you can use `rndc secroots -`
 to get output on stdout.

Using - to get it to dump the secroots output to stdout is a new
feature added for 9.11.  That hasn't been published yet, but if you build
from the source tree at source.isc.org (like Tony does), you can it.

If you're doing that, then you can *also* use rndc managed-keys, which
lets you check key status and force keys to be refreshed ahead of schedule.

-- 
Evan Hunt -- e...@isc.org
Internet Systems Consortium, Inc.
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: Testing RFC 5011 key roll

[Edward Lewis]

On 4/21/15, 10:15, Warren Kumari war...@kumari.net wrote:


From the ARM:

Sigh, RTFM...(My, BIND's gotten a lot more complicated/feature-rich since
I last read the docs.)

Hey, it's there.


smime.p7s
Description: S/MIME cryptographic signature
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: Testing RFC 5011 key roll

[Tony Finch]

Edward Lewis edward.le...@icann.org wrote:

 I have a suggestion - is there a way to query a BIND server for it's trust
 anchor key set?

rndc secroots

(though this only provides the key tags not the public key data)

 I say perhaps unnecessary because the information may be available on
 disk (which an administrator could get to via ssh, perhaps).

You can also look in the .mkeys file.

Tony.
-- 
f.anthony.n.finch  d...@dotat.at  http://dotat.at/
Trafalgar: In southeast, cyclonic 5 to 7, but easterly 6 to gale 8 in far
southeast. In northwest, variable 4, becoming southwesterly 4 or 5 in west
later. In southeast, moderate or rough. in northwest, mainly moderate. In
southeast, occasional rain. In northwest, showers. In southeast, moderate or
good. In northwest, good.
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: Testing RFC 5011 key roll

[Tony Finch]

Edward Lewis edward.le...@icann.org wrote:

 I tried secroots with my set up, I got nothing despite the mkeys file.
 (Kind of asking - does that work?):

By default it dumps its output to a file; you can use `rndc secroots -`
to get output on stdout.

Tony.
-- 
f.anthony.n.finch  d...@dotat.at  http://dotat.at/
Hebrides, Bailey: Southwesterly 4 or 5, increasing 6 or 7 in north Bailey.
Moderate, becoming rough in north Bailey. Occasional drizzle, fog patches.
Moderate or good, occasionally very poor.
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: Testing RFC 5011 key roll

[Warren Kumari]

On Tue, Apr 21, 2015 at 9:55 AM, Edward Lewis edward.le...@icann.org wrote:
 On 4/21/15, 9:45, Tony Finch d...@dotat.at wrote:
rndc secroots

You can also look in the .mkeys file.

 I tried secroots with my set up, I got nothing despite the mkeys file.
 (Kind of asking - does that work?):

 (I had my rndc port bumped out of sudo-land, so it's overridden:)

 $ rndc -p 1953 -c rndc.conf secroots


From the ARM:
secroots-file:
The pathname of the file the server dumps security roots to when
instructed to do so with rndc secroots. If not specified, the default
is named.secroots.

root@eric:/var/named# rndc secroots
root@eric:/var/named# more named.secroots
21-Apr-2015 10:07:02.278

 Start view external

./RSASHA256/19036 ; managed
dlv.isc.org/RSASHA1/19297 ; trusted

W





 $

 $ cat
 21ce078705d04ca6324c1d0313fc08ea99f3cef6389a6744d40bd2d9d0cd7816.mkeys
 $ORIGIN .
 $TTL 0  ; 0 seconds
 @   IN SOA  . . (
 879; serial
 0  ; refresh (0 seconds)
 0  ; retry (0 seconds)
 0  ; expire (0 seconds)
 0  ; minimum (0 seconds)
 )
 KEYDATA 20150421135415 20150421125042 1970010100 
 257 3 8 (
 AwEAAb7pfymUZ3LzR7ldtJ5fvgxxu/Y4I7QtBmlqlhJS
 Je6Ugw+/72eYAnLYh7xHaNkAzjP6oi1rxOL0s9wj7TVU
 +r9bK+KuzOvZfKzNS+ywTdZ0QXSJSJNTLJfgaMMvnyp/
 K2LajQ4wNV1UblSqPPs9FdCXqVbxKF7i4j6h6QO61xkf
 s2LSkiPu+TCK05fizdfuDIit8KlQr6sgV1jiBrXm4kmY
 5o9txePRz8oy/C4+6IDVtA1zSlDTvsbwYk1KjHa9CXcA
 7BkuYaBlxB4zgBF/koaX55IdhbKKkwsN8qJhPanu72zq
 2933IF96RtikjvX/ugC7VBvNlGgy5dQrvKu/G7M=
 ) ; KSK; alg = RSASHA256; key id = 26512
 ; next refresh: Tue, 21 Apr 2015 13:54:15 GMT
 ; trusted since: Tue, 21 Apr 2015 12:50:42 GMT
 KEYDATA 20150421135415 20150421135145 1970010100 
 257 3 8 (
 AwEAAeHrxs5uJwldPTjAplgBzGRptPYrFgNFoPZDyrEa
 CAuNckUuHkQIMr5Pkv/XONS2CLcLmq5HtvLPzevkAjWv
 wIMhYn0nE4fTTl8diTnOFKLEcPBs/jAqKU5n/ZV5ZXiP
 NCUgg3qvXetntojb+JesE9fdYgUlWrgIUjx9y17Fhb+J
 lP56kqhxER2L0AUEFTH+x/Jxkzea6E8FFkYGUJ+tzEt0
 S+ESRaDTNmdKgqe9GAi6ID3GRYgsn9cgNIOmBYHrzhQv
 R5XaTK37nUlVMKjyQxu2Lq+lhIu9348aSt+g42QJxJ1s
 VTRPVPEVQt1s71SHuWTd/OBCz5f8fZqQrG0mA9E=
 ) ; KSK; alg = RSASHA256; key id = 8869
 ; next refresh: Tue, 21 Apr 2015 13:54:15 GMT
 ; trusted since: Tue, 21 Apr 2015 13:51:45 GMT

 ___
 Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
 from this list

 bind-users mailing list
 bind-users@lists.isc.org
 https://lists.isc.org/mailman/listinfo/bind-users



-- 
I don't think the execution is relevant when it was obviously a bad
idea in the first place.
This is like putting rabid weasels in your pants, and later expressing
regret at having chosen those particular rabid weasels and that pair
of pants.
   ---maf
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: Testing RFC 5011 key roll

[Edward Lewis]

On 4/21/15, 9:45, Tony Finch d...@dotat.at wrote:
rndc secroots

You can also look in the .mkeys file.

I tried secroots with my set up, I got nothing despite the mkeys file.
(Kind of asking - does that work?):

(I had my rndc port bumped out of sudo-land, so it's overridden:)

$ rndc -p 1953 -c rndc.conf secroots

$ 

$ cat 
21ce078705d04ca6324c1d0313fc08ea99f3cef6389a6744d40bd2d9d0cd7816.mkeys
$ORIGIN .
$TTL 0  ; 0 seconds
@   IN SOA  . . (
879; serial
0  ; refresh (0 seconds)
0  ; retry (0 seconds)
0  ; expire (0 seconds)
0  ; minimum (0 seconds)
)
KEYDATA 20150421135415 20150421125042 1970010100 
257 3 8 (
AwEAAb7pfymUZ3LzR7ldtJ5fvgxxu/Y4I7QtBmlqlhJS
Je6Ugw+/72eYAnLYh7xHaNkAzjP6oi1rxOL0s9wj7TVU
+r9bK+KuzOvZfKzNS+ywTdZ0QXSJSJNTLJfgaMMvnyp/
K2LajQ4wNV1UblSqPPs9FdCXqVbxKF7i4j6h6QO61xkf
s2LSkiPu+TCK05fizdfuDIit8KlQr6sgV1jiBrXm4kmY
5o9txePRz8oy/C4+6IDVtA1zSlDTvsbwYk1KjHa9CXcA
7BkuYaBlxB4zgBF/koaX55IdhbKKkwsN8qJhPanu72zq
2933IF96RtikjvX/ugC7VBvNlGgy5dQrvKu/G7M=
) ; KSK; alg = RSASHA256; key id = 26512
; next refresh: Tue, 21 Apr 2015 13:54:15 GMT
; trusted since: Tue, 21 Apr 2015 12:50:42 GMT
KEYDATA 20150421135415 20150421135145 1970010100 
257 3 8 (
AwEAAeHrxs5uJwldPTjAplgBzGRptPYrFgNFoPZDyrEa
CAuNckUuHkQIMr5Pkv/XONS2CLcLmq5HtvLPzevkAjWv
wIMhYn0nE4fTTl8diTnOFKLEcPBs/jAqKU5n/ZV5ZXiP
NCUgg3qvXetntojb+JesE9fdYgUlWrgIUjx9y17Fhb+J
lP56kqhxER2L0AUEFTH+x/Jxkzea6E8FFkYGUJ+tzEt0
S+ESRaDTNmdKgqe9GAi6ID3GRYgsn9cgNIOmBYHrzhQv
R5XaTK37nUlVMKjyQxu2Lq+lhIu9348aSt+g42QJxJ1s
VTRPVPEVQt1s71SHuWTd/OBCz5f8fZqQrG0mA9E=
) ; KSK; alg = RSASHA256; key id = 8869
; next refresh: Tue, 21 Apr 2015 13:54:15 GMT
; trusted since: Tue, 21 Apr 2015 13:51:45 GMT


smime.p7s
Description: S/MIME cryptographic signature
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: Testing RFC 5011 key roll

[Jan-Piet Mens]

 My lesson is - besides just working out the configuration - testing
 RFC5011 takes more patience than just about any other feature of
 DNS/DNSSEC.  RFC5011 is the most wall-clock driven mechanism we have.

Yup. I learned that as well.

As a side note: can you imagine my surprise when, after waiting all that
time BIND then crashed on me after being fed OpenDNSSEC keys? Had to
start all over and explain excessive hair loss to the missus ...

It's thanks to Warren's keyroll.systems that I actually persisted
testing, and only then did I report the crash to ISC, whereupon I was
forced to wait a full rollover period until I was allowed to talk about
it. ;-)

-JP

___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: Testing RFC 5011 key roll

[Warren Kumari]

On Mon, Apr 20, 2015 at 4:33 PM, Evan Hunt e...@isc.org wrote:
 On Mon, Apr 20, 2015 at 04:17:57PM -0400, Warren Kumari wrote:
 That page says (for BIND):
 Note: When using this config file you will probably need to delete
 /var/named/21ce078705d04ca6324c1d0313fc08ea99f3cef6389a6744d40bd2d9d0cd7816.mkeys*
 every time you restart BIND after missing a keyroll. (I'm not quite
 sure how that filename was derived...)

 The misguided idea was to make a filename that would be unique for
 each view, but not to use the view name because those can contain
 characters that are illegal in file names (e.g., '/').  So it's a
 sha256 hash of the view name,

Cool! It looked like a hash of something, I was just too lazy to
go figure out what the something was. I was hoping it was a hash of
something funny...

 which is guaranteed to be a legal file
 name because it's all hexadecimal.  It's also guaranteed to be maximally
 confusing.

 As of BIND 9.10, it doesn't name files that way anymore.

Awww... Now that I know the secret you've gone and changed it.

W

 It'll still
 read an existing file using that naming format if it finds one, though.

 --
 Evan Hunt -- e...@isc.org
 Internet Systems Consortium, Inc.



-- 
I don't think the execution is relevant when it was obviously a bad
idea in the first place.
This is like putting rabid weasels in your pants, and later expressing
regret at having chosen those particular rabid weasels and that pair
of pants.
   ---maf
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: Testing RFC 5011 key roll

[Evan Hunt]

On Mon, Apr 20, 2015 at 04:17:57PM -0400, Warren Kumari wrote:
 That page says (for BIND):
 Note: When using this config file you will probably need to delete
 /var/named/21ce078705d04ca6324c1d0313fc08ea99f3cef6389a6744d40bd2d9d0cd7816.mkeys*
 every time you restart BIND after missing a keyroll. (I'm not quite
 sure how that filename was derived...)

The misguided idea was to make a filename that would be unique for
each view, but not to use the view name because those can contain
characters that are illegal in file names (e.g., '/').  So it's a
sha256 hash of the view name, which is guaranteed to be a legal file
name because it's all hexadecimal.  It's also guaranteed to be maximally
confusing.

As of BIND 9.10, it doesn't name files that way anymore.  It'll still
read an existing file using that naming format if it finds one, though.

-- 
Evan Hunt -- e...@isc.org
Internet Systems Consortium, Inc.
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: Testing RFC 5011 key roll

[Warren Kumari]

On Mon, Apr 20, 2015 at 3:41 PM, Edward Lewis edward.le...@icann.org wrote:
 Thanks.  rm'd the file and added the timers.  (I did that also after
 sending, so it is the deleting the old file that did the trick.)  The
 start-up lines look good.

 Got an AD bit again too.

 (I may have a few more issues as I move this off a laptop on to a regular
 machine.  Right now it helps knowing where the loose bits are stored.)

Just FYI, the current key should always be at:
http://keyroll.systems/current , along with pre-built named.conf and
unbound.conf, suitable for cutting and pasting into config files.

That page says (for BIND):
Note: When using this config file you will probably need to delete
/var/named/21ce078705d04ca6324c1d0313fc08ea99f3cef6389a6744d40bd2d9d0cd7816.mkeys*
every time you restart BIND after missing a keyroll. (I'm not quite
sure how that filename was derived...)


Jakob Schlyter created a nifty toolset at
https://github.com/jschlyter/keyroll/ to download the key, put it in
the right format, etc. It comes with config files for Unbound and
BIND, and makes using this simpler and easier!


 On 4/20/15, 15:12, Evan Hunt e...@isc.org wrote:

On Mon, Apr 20, 2015 at 06:42:42PM +, Edward Lewis wrote:
 Being that I'm working on a laptop (hence on on over the weekend) I've
had
 to recreate the environment today.  I'm a bit more puzzled now.

There's a separate file that named creates to keep the current
managed keys state information -- it's based on the view name,
so in your case it'll be recursive.mkeys (and possibly
recursive.mkeys.jnl).  I suspect it still has the key from
Friday in it, and that's messing things up.  Delete that file and
reinitialize, then leave the server up and running (not forgetting
to use -T mkeytimers=H/D/M, where M is no more than 3600 seconds,
because keyroll.systems rolls its keys every hour and normal RFC
5011 processing can't handle that), and you should be in good shape.

Actually it seems to be every 90 minutes at the moment.

keyroll.systems is very much a kludge
W



--
Evan Hunt -- e...@isc.org
Internet Systems Consortium, Inc.

 ___
 Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
 from this list

 bind-users mailing list
 bind-users@lists.isc.org
 https://lists.isc.org/mailman/listinfo/bind-users



-- 
I don't think the execution is relevant when it was obviously a bad
idea in the first place.
This is like putting rabid weasels in your pants, and later expressing
regret at having chosen those particular rabid weasels and that pair
of pants.
   ---maf
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: Testing RFC 5011 key roll

[Evan Hunt]

On Mon, Apr 20, 2015 at 06:42:42PM +, Edward Lewis wrote:
 Being that I'm working on a laptop (hence on on over the weekend) I've had
 to recreate the environment today.  I'm a bit more puzzled now.

There's a separate file that named creates to keep the current
managed keys state information -- it's based on the view name,
so in your case it'll be recursive.mkeys (and possibly
recursive.mkeys.jnl).  I suspect it still has the key from
Friday in it, and that's messing things up.  Delete that file and
reinitialize, then leave the server up and running (not forgetting
to use -T mkeytimers=H/D/M, where M is no more than 3600 seconds,
because keyroll.systems rolls its keys every hour and normal RFC
5011 processing can't handle that), and you should be in good shape.

-- 
Evan Hunt -- e...@isc.org
Internet Systems Consortium, Inc.
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: Testing RFC 5011 key roll

[Edward Lewis]

Thanks to Evan for the last look and thanks to Jan-Piet for the suggestion
to go to 9.10.2.

Being that I'm working on a laptop (hence on on over the weekend) I've had
to recreate the environment today.  I'm a bit more puzzled now.

I've built and installed BIND 9.10.2.  Using http://keyroll.systems,
there's a page showing the BIND config and it seems to have the current
key there.  (I thought the page was static.)  I guess I'm just a bit
surprised, anyway, I have that key in place.

And - I've also updated by unbound, I do get an 'ad' bit for ./IN/SOA.
(I need to figure out why I needed to update unbound - perhaps it is that
I'm on a laptop and not a 24x7 machine, but I can get it to validate.)

Ugly details below:

This time I do see an error upon startup:

$ named -g -c rfc5011.conf
20-Apr-2015 14:34:18.432 starting BIND 9.10.2 -g -c rfc5011.conf
20-Apr-2015 14:34:18.432 built with '--with-openssl=/usr/local/ssl'
'STD_CDEFINES=-DDIG_SIGCHASE=1'
20-Apr-2015 14:34:18.432

20-Apr-2015 14:34:18.432 BIND 9 is maintained by Internet Systems
Consortium,
20-Apr-2015 14:34:18.432 Inc. (ISC), a non-profit 501(c)(3) public-benefit
20-Apr-2015 14:34:18.432 corporation.  Support and training for BIND 9 are
20-Apr-2015 14:34:18.432 available at https://www.isc.org/support
20-Apr-2015 14:34:18.432

20-Apr-2015 14:34:18.432 found 4 CPUs, using 4 worker threads
20-Apr-2015 14:34:18.432 using 2 UDP listeners per interface
20-Apr-2015 14:34:18.433 using up to 4096 sockets
20-Apr-2015 14:34:18.439 loading configuration from
'/Users/edwardlewis/Documents/DNS/secure_BIND_resolver/rfc5011.conf'
20-Apr-2015 14:34:18.439 reading built-in trusted keys from file
'/etc/bind.keys'
20-Apr-2015 14:34:18.439 using default UDP/IPv4 port range: [49152, 65535]
20-Apr-2015 14:34:18.440 using default UDP/IPv6 port range: [49152, 65535]
20-Apr-2015 14:34:18.440 listening on IPv6 interface lo0, ::1#1053
20-Apr-2015 14:34:18.442 listening on IPv4 interface lo0, 127.0.0.1#1053
20-Apr-2015 14:34:18.442 generating session key for dynamic DNS
20-Apr-2015 14:34:18.443 sizing zone task pool based on 1 zones
20-Apr-2015 14:34:18.445 set up managed keys zone for view recursive, file
'21ce078705d04ca6324c1d0313fc08ea99f3cef6389a6744d40bd2d9d0cd7816.mkeys'
20-Apr-2015 14:34:18.445 automatic empty zone: view recursive:
10.IN-ADDR.ARPA...yadda...yadda...yadda...
20-Apr-2015 14:34:18.449 command channel listening on 127.0.0.1#1953
20-Apr-2015 14:34:18.449 not using config file logging statement for
logging due to -g option
20-Apr-2015 14:34:18.449 managed-keys-zone/recursive: loaded serial 3
20-Apr-2015 14:34:18.460 all zones loaded
20-Apr-2015 14:34:18.460 running
20-Apr-2015 14:34:18.554 validating ./DNSKEY: unable to find a DNSKEY
which verifies the DNSKEY RRset and also matches a trusted key for '.'
20-Apr-2015 14:34:18.554 no valid KEY resolving './DNSKEY/IN':
204.42.252.20#53
20-Apr-2015 14:34:18.554 broken trust chain resolving './NS/IN':
204.42.252.20#53

My rfc5011.conf file is:

$ cat rfc5011.conf 
options
{
dnssec-enable yes;
dnssec-validation yes;
pid-file none;
session-keyfile session.key;
notify no;
listen-on port 1053 { 127.0.0.1; };
listen-on-v6 port 1053 { ::1; };
};

key rndc-key
{
  algorithm hmac-md5;
  secret cuxAvCYntho2ia6jhDM4yw==;
};

controls
{
  inet 127.0.0.1 port 1953
  allow { 127.0.0.1; } keys { rndc-key; };
};

managed-keys {
  . initial-key 257 3 8
AwEAAaTCfs92ag0oZpg/uzN7NcN2aIXZxR7Q1XOin8eEei+QPR0dXrI7
DskSUNVBsHMS6piMCTQRqFHq1TwY19tWiJJf0meZWRMWTOrzyFd/Tioa
KwWTga0bNN09dciQmNxJyfnHDNfqJ8k3LeQz8WHQzc9QC0x8cOmT1IG7
yn+0S6QFl4/G6uwBxJ3ejxdiygJQKa8i3YAv3EEKP066YuRki5h1yz93
P9UEyU2E2MOByqMJtgpaBPbOX5riTdaTu5gXKnoJyag//545+Z43+Y6u
+wQzfnFFhWHzQiH8Yl3y4qNuBVXSvlmg9XU4LhT7EqTA+v5v/O2Humkm
KqetoGkEbJ0=;
};

view recursive IN {
match-clients { any; };
allow-query   { any; };
recursion yes;

allow-recursion { any; };

// prime the server with the RFC5011 Key roll server.
zone . {
   type hint;
   file keyroller-db.root;
};

};  // End of recursive view.


The current dig fake-. dnskey is:


$ dig @204.42.252.20 . dnskey

;  DiG 9.10.2  @204.42.252.20 . dnskey
; (1 server found)
;; global options: +cmd
;; Got answer:
;; -HEADER- opcode: QUERY, status: NOERROR, id: 16270
;; flags: qr aa rd; QUERY: 1, ANSWER: 4, AUTHORITY: 0, ADDITIONAL: 1
;; WARNING: recursion requested but not available

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;.  IN  DNSKEY

;; ANSWER SECTION:
.   3600IN  DNSKEY  385 3 8
AwEAAb1tBF4Fbnx8Wx4dDpoMbeKpId70bZyWRzz07uORb5ZrbgQfy8u1
sFH9k3kNsisc09CoG/aSGIsrEz0OueGHFDbwSWdaIwVFIpNRBwGQjbvf
pzod0HTfSo2Ka7oFBuc7Sm5CSjbxcXJ28FW9BCn/SboI1bw08R322rEy

Re: Testing RFC 5011 key roll

[Edward Lewis]

Thanks.  rm'd the file and added the timers.  (I did that also after
sending, so it is the deleting the old file that did the trick.)  The
start-up lines look good.

Got an AD bit again too.

(I may have a few more issues as I move this off a laptop on to a regular
machine.  Right now it helps knowing where the loose bits are stored.)

On 4/20/15, 15:12, Evan Hunt e...@isc.org wrote:

On Mon, Apr 20, 2015 at 06:42:42PM +, Edward Lewis wrote:
 Being that I'm working on a laptop (hence on on over the weekend) I've
had
 to recreate the environment today.  I'm a bit more puzzled now.

There's a separate file that named creates to keep the current
managed keys state information -- it's based on the view name,
so in your case it'll be recursive.mkeys (and possibly
recursive.mkeys.jnl).  I suspect it still has the key from
Friday in it, and that's messing things up.  Delete that file and
reinitialize, then leave the server up and running (not forgetting
to use -T mkeytimers=H/D/M, where M is no more than 3600 seconds,
because keyroll.systems rolls its keys every hour and normal RFC
5011 processing can't handle that), and you should be in good shape.

-- 
Evan Hunt -- e...@isc.org
Internet Systems Consortium, Inc.


smime.p7s
Description: S/MIME cryptographic signature
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: Testing RFC 5011 key roll

[Jan-Piet Mens]

Edward,

the subject of this message piqued my interest ;-)

 17-Apr-2015 10:17:02.083 starting BIND 9.10.0 -g -c rfc5011.conf

Very ouch. Much pain. Lots frustration. Many hairpulls. Mucho crash. ;)

Upgrade to 9.10.2 [1] in which Evan fixes the CVE we discovered on
RFC5011 rolls and, thankfully, adds comments to BIND's managed-keys.db
in which BIND then tells us nice things, e.g. whether key is trusted,
revoked, etc.

-JP


[1] https://kb.isc.org/article/AA-01257/0/BIND-9.10.2-Release-Notes.html
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Testing RFC 5011 key roll

[Edward Lewis]

I am building named and unbound recursive servers to follow a test of RFC
5011 trust anchor updates, the experiment is documented at
http://keyroll.systems.  One reason why I'm asking here is in
http://jpmens.net/2015/01/21/opendnssec-rfc-5011-bind-and-unbound/
which mentions some issues with RFC 5011 rolls in BIND.

But I bet my problem is that I haven't included yet-another configuration
statement.

I have unbound working, but can't get bind to give me an 'ad' bit, so I'm
certain that the authoritative server side is set up right.

What is puzzling is that I don't see any (relevant) errors when starting
up my named instance.

I'm running named in user space, off port 1053.  So the permission
denied parts are acceptable.

$ named -g -c rfc5011.conf
17-Apr-2015 10:17:02.083 starting BIND 9.10.0 -g -c rfc5011.conf
17-Apr-2015 10:17:02.083 built with '--with-openssl=/usr/local/ssl'
'STD_CDEFINES=-DDIG_SIGCHASE=1'
17-Apr-2015 10:17:02.083

17-Apr-2015 10:17:02.083 BIND 9 is maintained by Internet Systems
Consortium,
17-Apr-2015 10:17:02.083 Inc. (ISC), a non-profit 501(c)(3) public-benefit
17-Apr-2015 10:17:02.083 corporation.  Support and training for BIND 9 are
17-Apr-2015 10:17:02.083 available at https://www.isc.org/support
17-Apr-2015 10:17:02.083

17-Apr-2015 10:17:02.083 found 4 CPUs, using 4 worker threads
17-Apr-2015 10:17:02.083 using 2 UDP listeners per interface
17-Apr-2015 10:17:02.084 using up to 4096 sockets
17-Apr-2015 10:17:02.091 loading configuration from
'/Users/edwardlewis/Documents/DNS/secure_BIND_resolver/rfc5011.conf'
17-Apr-2015 10:17:02.092 reading built-in trusted keys from file
'/Users/edwardlewis/Documents/DNS/secure_BIND_resolver/test.key'
17-Apr-2015 10:17:02.092 using default UDP/IPv4 port range: [49152, 65535]
17-Apr-2015 10:17:02.092 using default UDP/IPv6 port range: [49152, 65535]
17-Apr-2015 10:17:02.093 listening on IPv6 interfaces, port 53
17-Apr-2015 10:17:02.093 could not listen on UDP socket: permission denied
17-Apr-2015 10:17:02.093 listening on all IPv6 interfaces failed
17-Apr-2015 10:17:02.093 listening on IPv4 interface lo0, 127.0.0.1#1053
17-Apr-2015 10:17:02.094 generating session key for dynamic DNS
17-Apr-2015 10:17:02.094 couldn't mkdir '/var/run/named': Permission denied
17-Apr-2015 10:17:02.094 could not create /var/run/named/session.key
17-Apr-2015 10:17:02.094 failed to generate session key for dynamic DNS:
permission denied
17-Apr-2015 10:17:02.094 sizing zone task pool based on 1 zones
17-Apr-2015 10:17:02.096 using built-in root key for view recursive
17-Apr-2015 10:17:02.097 set up managed keys zone for view recursive, file
'21ce078705d04ca6324c1d0313fc08ea99f3cef6389a6744d40bd2d9d0cd7816.mkeys'
17-Apr-2015 10:17:02.097 automatic empty zone: ...yadda...yadda...yadda...
17-Apr-2015 10:17:02.101 command channel listening on 127.0.0.1#1953
17-Apr-2015 10:17:02.101 not using config file logging statement for
logging due to -g option
17-Apr-2015 10:17:02.101 listening on IPv6 interfaces, port 53
17-Apr-2015 10:17:02.101 could not listen on UDP socket: permission denied
17-Apr-2015 10:17:02.101 listening on all IPv6 interfaces failed
17-Apr-2015 10:17:02.101 managed-keys-zone/recursive: loaded serial 5
17-Apr-2015 10:17:02.112 all zones loaded
17-Apr-2015 10:17:02.112 running

$ cat /Users/edwardlewis/Documents/DNS/secure_BIND_resolver/rfc5011.conf

options
{
dnssec-enable yes;
dnssec-validation auto;
bindkeys-file 
/Users/edwardlewis/Documents/DNS/secure_BIND_resolver/test.key;
pid-file none;
dump-file 5011logs/cache_dump.db;
statistics-file 5011logs/named_stats.txt;
memstatistics-file 5011logs/named.memstats;
zone-statistics yes;
hostname foobar;
recursion yes;
notify no;
auth-nxdomain no;
listen-on port 1053 { 127.0.0.1; };
};

managed-keys {
.initial-key 257 3 8
AwEAAchoK9nG+mBjR/NZKqez+XYcqoWPL5e0VTreHS3Wi1KmU0Qgsr1N3O9u+McnsUwF/dsSW8
F/h3yXSMAEhS731eFvqxNDkhL8rQUfGBtALB3onTthYM38fk16vki5UsCecbt3uI46lb5cz5Dts
9drW/55OckwnSw4GTwiq2zebO5fo/UZlftpZTsupqgojL1Y3QlqL0LpP+vPIAgBe+OfhVpFPLxT
P6aeKoNviWC0O2CJiVqVZxp9cumjwOnKUvSfHcsl8tcH3cQjmIhQDDw+Z109J9ly+QcL6RUdHo9
m/TyKL04dQulKBAmgWanAQ0CF7zwhIiUxkxTsUtMTRMuXWcM=;
};

view recursive IN {
match-clients { any; };
allow-query   { any; };
recursion yes;

allow-recursion { any; };

// prime the server with the RFC5011 Key roll server.
zone . {
   type hint;
   file keyroller-db.root;
};

};  // End of recursive view.

$ cat /Users/edwardlewis/Documents/DNS/secure_BIND_resolver/test.key

managed-keys {
. initial-key 257 3 8
AwEAAchoK9nG+mBjR/NZKqez+XYcqoWPL5e0VTreHS3Wi1KmU0Qgsr1N3O9u+McnsUwF/dsSW8
F/h3yXSMAEhS731eFvqxNDkhL8rQUfGBtALB3onTthYM38fk16vki5UsCecbt3uI46lb5cz5Dts
9drW/55OckwnSw4GTwiq2zebO5fo/UZlftpZTsupqgojL1Y3QlqL0LpP+vPIAgBe+OfhVpFPLxT

Re: Testing RFC 5011 key roll

[Edward Lewis]

Thanks.  Now have 'ad' bits via both BIND and unbound.

Will let you know when I've shot myself in the foot.

On 4/17/15, 12:45, Evan Hunt e...@isc.org wrote:
...

instead of waiting a full 30 days.  (This is, I hope obviously, *not*
something you want to run in production. :) )



smime.p7s
Description: S/MIME cryptographic signature
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: Testing RFC 5011 key roll

[Evan Hunt]

On Fri, Apr 17, 2015 at 02:46:16PM +, Edward Lewis wrote:
 I am building named and unbound recursive servers to follow a test of RFC
 5011 trust anchor updates, the experiment is documented at
 http://keyroll.systems.  One reason why I'm asking here is in
 http://jpmens.net/2015/01/21/opendnssec-rfc-5011-bind-and-unbound/
 which mentions some issues with RFC 5011 rolls in BIND.

I believe all of the issues Jan-Piet discovered have been fixed in
the latest versions.

 But I bet my problem is that I haven't included yet-another configuration
 statement.

A minor nit: You have both a bindkeys-file (which is loaded when you use
dnssec-validation auto) and a managed-keys statement in your named.conf.
It's harmless, but there's no need to have both.  You can lose the bindkeys
file and set dnssec-validation yes, or lose the managed-keys statement.

The key at keyroll.systems rolls every 90 minutes if I recall correctly,
so when you start the process you'll need to be sure you're using the
latest key; if you leave your file alone for a few hours it'll stop
working.  dig @204.42.252.20 dnskey . will show you the current key
set.

I tried your configuration, and after updating the key to the most recent
one, I am getting responses that validate.

By the way, if you want to ensure that named smoothly rolls over to the
next key, you'll need to adjust its timers.  RFC 5011 says that you can't
trust a new key until it's been in the DNSKEY rrset for at least a month.
To enable testing in a reasonable time, there's an undocumented
option to named that redefines time units for RFC 5011 purposes:

$ named -T mkeytimers=2/5/60

The numbers between the slashes are the number of seconds to use for
an hour, a day, and a month, respectively.  If you run with the
above option, named will trust a new key 60 seconds after it's seen it,
instead of waiting a full 30 days.  (This is, I hope obviously, *not*
something you want to run in production. :) )

-- 
Evan Hunt -- e...@isc.org
Internet Systems Consortium, Inc.
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: How reliable is RPZ in production? I'm seeing flakiness in testing.

[Phil Mayers]

On 06/01/15 22:52, Anne Bennett wrote:


I don't know what to make of this; it looks as though the
technology is several years old, and my experience with ISC
bind is usually excellent.  Has anyone else encountered this
type of flakiness?


No, but we're not using client-ip RPZ, just qname-based blacklists.

I've had a couple of occurrences of runaway CPU use triggered by a large 
RPZ AXFR, but no-one seems to believe me when I bring it up here, so 
I've stopped bothering :o/


But we certainly haven't see the kind of sporadic issue you describe. It 
might be that the client-ip stuff is newer?


Not sure how you'd debug it.
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: How reliable is RPZ in production? I'm seeing flakiness in testing.

[Anne Bennett]

John, thanks for helping.

 You might start things out by giving us your bind version

9.10.1-P1

 and your response-policy {} config.

  response-policy {
zone rpz-whitelist   policy given;
zone rpz-quarantine  policy given;
zone rpz-phish   policy given;
zone rpz-malware policy given;
zone rpz-isc-suspicious  policy given;
zone rpz-mwdoms-doms policy given;
zone rpz-mwdoms-hostspolicy given;
  };

At the moment, only the first four contain any records
aside from SOA and NS.

 Also print out the exact rules (one or two
 examples should suffice) you're using for client quarantining --
 that'll help narrow things down.

rpz-whitelist has QNAME/passthru entries for names in
my domain and for patch sites.  It also has rpz-ip/passthru
entries for IP addresses of the same.  To show a few examples,
first for our University's public network:

  concordia.caCNAME rpz-passthru.
  *.concordia.ca  CNAME rpz-passthru.

  205.132.in-addr.arpaCNAME rpz-passthru.
  *.205.132.in-addr.arpa  CNAME rpz-passthru.

  16.0.0.205.132.rpz-ip   CNAME rpz-passthru.

... and for a patch site:

  12.0.0.0.23.rpz-ip  CNAME rpz-passthru. ; Akamai

(Note that I added the in-addr.arpa lines just lately, and
haven't re-run the tests with those in place, but those weren't
the names I was testing for; I was testing with nslookup.)

rpz-quarantine had, when I was testing, my workstation's address:

  32.192.47.205.132.rpz-client-ip CNAME serv-quarantine.encs.concordia.ca.

rpz-phish and rpz-malware have a few test entries, for example:

  nonexistent.porcupine.caCNAME serv-fishnet.encs.concordia.ca.
  *.nonexistent.porcupine.ca  CNAME serv-fishnet.encs.concordia.ca.

  emaillimitedequota.yolasite.com CNAME serv-fishnet.encs.concordia.ca.
  *.emaillimitedequota.yolasite.com   CNAME serv-fishnet.encs.concordia.ca.



 Also, how are you publishing to your
 client quarantine zones?  Presumably you're using some sort of DDNS
 publishing that gets triggered when a client does something
 suspicious.

No, actually, so far it's all manual (edit the zone file and
issue a reload), and the first four will remain that way.
The last three will contain data we obtain automatically from
offsite, but my download-parse-update-reload script will do
essentially the same as my manual operation.  We don't use
DDNS at all.


I'm going to re-run my tests with a fresh mind (I last tested
before I took a vacation in December, and I needed that
vacation!), though I find it hard to see what I could possibly
have done wrong that would have the nameserver changing its
responses to me without the data having been touched.

I'll report back with my new test results.



Anne.
-- 
Ms. Anne Bennett, Senior Sysadmin, ENCS, Concordia University, Montreal H3G 1M8
a...@encs.concordia.ca+1 514 848-2424 x2285
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: How reliable is RPZ in production? I'm seeing flakiness in testing.

[John Miller]

Hi Anne,

We've been using RPZ in production for over six months, and haven't
had any serious issues.  We haven't encountered this specific type of
flakiness, but then again, it's likely our configs and bind versions
aren't the same either: we do our quarantining at layer 2.

You might start things out by giving us your bind version and your
response-policy {} config.  Also print out the exact rules (one or two
examples should suffice) you're using for client quarantining --
that'll help narrow things down.  Also, how are you publishing to your
client quarantine zones?  Presumably you're using some sort of DDNS
publishing that gets triggered when a client does something
suspicious.

John
-- 
John Miller
Systems Engineer
Brandeis University
johnm...@brandeis.edu


On Tue, Jan 6, 2015 at 5:52 PM, Anne Bennett a...@encs.concordia.ca wrote:
 I'm playing with RPZ with a view to both quarantining internal
 compromised or vulnerable hosts, and capturing attempts at
 communication with known external bad hosts.  I start with a
 fairly extensive whitelist, to avoid lying about any of my own
 hosts, and to give truthful answers for patch sites, so that my
 users can patch their systems even when otherwise quarantined.

 The masters for my RPZs do not themselves use the zones
 for policy (nor do they recurse on queries).  However the
 nameservers that do recursive resolution for my network are
 slaves for those RPZs, and *do* use them for policy.

 My set-up works, but sporadically - it's as though the RPZs wink
 in and out of use for no apparent reason, even when I'm not
 changing the data.  At one point while testing last December,
 my by-client-IP test quarantine rule just stopped matching
 (based on no logged hits, and no redirection of my queries
 from the quarantined host).  Only a restart of named on the
 resolver brought the quarantine back, but then the whitelist
 worked only partially.

 I don't know what to make of this; it looks as though the
 technology is several years old, and my experience with ISC
 bind is usually excellent.  Has anyone else encountered this
 type of flakiness?

 If not, any advice about how to debug this?
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

How reliable is RPZ in production? I'm seeing flakiness in testing.

[Anne Bennett]

Happy New Year, folks.

I posted last December to dnsfirewalls, but I'm told that RPZ
is no longer particularly new, and I'd be more likely to get
feedback here.  So here goes...

I'm playing with RPZ with a view to both quarantining internal
compromised or vulnerable hosts, and capturing attempts at
communication with known external bad hosts.  I start with a
fairly extensive whitelist, to avoid lying about any of my own
hosts, and to give truthful answers for patch sites, so that my
users can patch their systems even when otherwise quarantined.

The masters for my RPZs do not themselves use the zones
for policy (nor do they recurse on queries).  However the
nameservers that do recursive resolution for my network are
slaves for those RPZs, and *do* use them for policy.

My set-up works, but sporadically - it's as though the RPZs wink
in and out of use for no apparent reason, even when I'm not
changing the data.  At one point while testing last December,
my by-client-IP test quarantine rule just stopped matching
(based on no logged hits, and no redirection of my queries
from the quarantined host).  Only a restart of named on the
resolver brought the quarantine back, but then the whitelist
worked only partially.

I don't know what to make of this; it looks as though the
technology is several years old, and my experience with ISC
bind is usually excellent.  Has anyone else encountered this
type of flakiness?

If not, any advice about how to debug this?


Anne.
-- 
Ms. Anne Bennett, Senior Sysadmin, ENCS, Concordia University, Montreal H3G 1M8
a...@encs.concordia.ca+1 514 848-2424 x2285
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Testing, please ignore

[Dan Mahoney]

Sorry for the noise.

-Dan Mahoney
ISC
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Testing, please ignore

[Dan Mahoney]

Sorry for the noise.

-Dan
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

bsa: A testing toolkit for bind configurations.

[John-John Tedro]

Hi,

First post here!

At my current occupation we rely heavily on our internal DNS operating
correctly.
And I got involved on how we would do change management, or specifically
unit test our existing configuration.

I got interested and started a personal project of mine, currently named
bsa for bind static analyzer.
It allows you to digest a complete bind configuration and run standalone or
integrate it into your existing test-suites.

Some project goals;

* Flexible and extensible. The project is built in a way that clearly
separates it's component. Adding custom RRs shouldn't be a problem.
* Read-only (with except for caching), no destruction or modifications on
the existing configuration should be necessary.
* Macro and/or third party sources support. A lot of people generate
configuration from a DSL, I want bsa to consume these directly and for it
to have the desired effect in the database.
* Completely off-line.
* Fast.
* This is not a bind emulator, just some tools for accessing it's database
in a convenient manner.

At it's current state it builds an in-memory database that it exposes
through some simple query functions.
There are also a few library tools useful when writing test suites.

If the tool is invoked with '-i' it starts up an ipython embedded shell
which gives you full and live access to the internals of the toolkit, for
you pythonistas out there this is a lot of fun to play with.

I am looking for people willing to try it out, but mainly just sharing and
caring.

Source available at http://github.com/udoprog/bsa
Licensed under GPLv3.

-- John-John Tedro
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

RE: Compiling and testing on Fedora

[Lightner, Jeff]

Turning off SELinux also requires a reboot after changing mode.





From: bind-users-bounces+jlightner=water@lists.isc.org 
[mailto:bind-users-bounces+jlightner=water@lists.isc.org] On Behalf Of 
Shawn Bakhtiar
Sent: Thursday, June 21, 2012 1:19 AM
To: bind-us...@isc.org
Subject: RE: Compiling and testing on Fedora



Did you turn OFF SELinux?

promptsetenforce 0

Then run the test,
 From: dan.lut...@level3.commailto:dan.lut...@level3.com
 To: bind-us...@isc.orgmailto:bind-us...@isc.org
 Subject: Compiling and testing on Fedora
 Date: Wed, 20 Jun 2012 23:33:08 +

 Hi all,

 I've had a major problem with using Fedora Core (10 through 15), when 
 compiling and running make test:

 A:System test acl
 I:Couldn't start server ns2 (pid=17344)
 R:FAIL
 S:allow_query:Wed Jun 20 23:21:47 GMT 2012
 T:allow_query:1:A
 A:System test allow_query
 I:Couldn't start server ns2 (pid=17368)
 R:FAIL
 S:addzone:Wed Jun 20 23:22:01 GMT 2012
 T:addzone:1:A
 A:System test addzone
 I:Couldn't start server ns2 (pid=17393)
 R:FAIL
 S:autosign:Wed Jun 20 23:22:15 GMT 2012
 T:autosign:1:A
 A:System test autosign
 I:generating keys and preparing zones
 I:Couldn't start server ns1 (pid=17734)
 R:FAIL
 S:builtin:Wed Jun 20 23:22:35 GMT 2012
 T:builtin:1:A
 A:System test builtin
 I:Couldn't start server ns1 (pid=17755)
 R:FAIL
 S:cacheclean:Wed Jun 20 23:22:49 GMT 2012
 T:cacheclean:1:A
 A:System test cacheclean
 I:Couldn't start server ns1 (pid=17776)
 R:FAIL

 I'm running the bin/tests/system/ifconfig.sh up script, and see the lo:1 
 through lo:7 interfaces come up. I don't have this problem on any of my 
 Solaris systems, just the Fedora servers. I do have several lo: interfaces 
 already defined, and they cannot be removed

 Has anyone seen such an issue, and if so, how did you fix it?

 Dan Luther
 Operations Engineer
 Systems Operation Engineering
 Level 3 Communications
 One Technology Center, Tulsa OK 74103
 p: 918-547-4370
 e: dan.lut...@level3.commailto:dan.lut...@level3.com


 ___
 Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
 from this list

 bind-users mailing list
 bind-users@lists.isc.orgmailto:bind-users@lists.isc.org
 https://lists.isc.org/mailman/listinfo/bind-users





Athena®, Created for the Cause™

Making a Difference in the Fight Against Breast Cancer





How and Why I Should Support Bottled Water!
Do not relinquish your right to choose bottled water as a healthy alternative 
to beverages that contain sugar, calories, etc. Your support of bottled water 
will make a difference! Your signatures count! Go to 
http://www.bottledwatermatters.org/luv-bottledwater-iframe/dswaters and sign a 
petition to support your right to always choose bottled water. Help fight 
federal and state issues, such as bottle deposits (or taxes) and organizations 
that want to ban the sale of bottled water. Support community curbside 
recycling programs. Support bottled water as a healthy way to maintain proper 
hydration. Our goal is 50,000 signatures. Share this petition with your friends 
and family today!



-
CONFIDENTIALITY NOTICE: This e-mail may contain privileged or confidential 
information and is for the sole use of the intended recipient(s). If you are 
not the intended recipient, any disclosure, copying, distribution, or use of 
the contents of this information is prohibited and may be unlawful. If you have 
received this electronic transmission in error, please reply immediately to the 
sender that you have received the message in error, and delete it. Thank you.
--


___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: Compiling and testing on Fedora

[Phil Mayers]

On 21/06/12 15:21, Lightner, Jeff wrote:

Turning off SELinux also requires a reboot after changing mode.


setenforce 0 does not require a reboot.
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

RE: Compiling and testing on Fedora

[Paul Wouters]

On Thu, 21 Jun 2012, Shawn Bakhtiar wrote:


Did you turn OFF SELinux?


That is not neccessary.

I ran the tests with selinux enabled:

E:zonechecks:Thu Jun 21 17:23:31 EDT 2012
I:System test result summary:
I: 2 FAIL
I:45 PASS
I: 2 SKIPPED

Looking at the failed test and interesting output

tests.sh: line 130: 31718 Aborted (core dumped)
$NSUPDATE -l -p 5300 -k ns1/session.key  nsupdate.out 21  END
update add other.nil. 600 in ns ns6.other.nil.
update add ns6.other.nil 600 in a 10.53.0.1
send
END

S:dlz:Thu Jun 21 17:13:57 EDT 2012
T:dlz:1:A
A:System test dlz
I:no response from ns1
R:FAIL
I:ns1 died before a SIGTERM was sent

I:testing that rndc stop updates the master file
I:check that 'nsupdate -l' with a missing keyfile reports the missing
file
I:check that changes to the DNSKEY RRset TTL do not have side effects
(11)
I:check notify with TSIG worked (12)
I:exit status: 1
R:FAIL

Other that then, the tests ran fine for me? This is on Fedora 17

Paul



 From: dan.lut...@level3.com
 To: bind-us...@isc.org
 Subject: Compiling and testing on Fedora
 Date: Wed, 20 Jun 2012 23:33:08 +

 Hi all,

 I've had a major problem with using Fedora Core (10 through 15), when compiling 
and running make
test:

 A:System test acl
 I:Couldn't start server ns2 (pid=17344)
 R:FAIL
 S:allow_query:Wed Jun 20 23:21:47 GMT 2012
 T:allow_query:1:A
 A:System test allow_query
 I:Couldn't start server ns2 (pid=17368)
 R:FAIL
 S:addzone:Wed Jun 20 23:22:01 GMT 2012
 T:addzone:1:A
 A:System test addzone
 I:Couldn't start server ns2 (pid=17393)
 R:FAIL
 S:autosign:Wed Jun 20 23:22:15 GMT 2012
 T:autosign:1:A
 A:System test autosign
 I:generating keys and preparing zones
 I:Couldn't start server ns1 (pid=17734)
 R:FAIL
 S:builtin:Wed Jun 20 23:22:35 GMT 2012
 T:builtin:1:A
 A:System test builtin
 I:Couldn't start server ns1 (pid=17755)
 R:FAIL
 S:cacheclean:Wed Jun 20 23:22:49 GMT 2012
 T:cacheclean:1:A
 A:System test cacheclean
 I:Couldn't start server ns1 (pid=17776)
 R:FAIL

 I'm running the bin/tests/system/ifconfig.sh up script, and see the lo:1 through 
lo:7
interfaces come up. I don't have this problem on any of my Solaris systems, 
just the Fedora servers. I
do have several lo: interfaces already defined, and they cannot be removed

 Has anyone seen such an issue, and if so, how did you fix it?

 Dan Luther
 Operations Engineer
 Systems Operation Engineering
 Level 3 Communications
 One Technology Center, Tulsa OK 74103
 p: 918-547-4370
 e: dan.lut...@level3.com


 ___
 Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

 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

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Compiling and testing on Fedora

[Luther, Dan]

Hi all, 

I've had a major problem with using Fedora Core (10 through 15), when compiling 
and running make test:

A:System test acl
I:Couldn't start server ns2 (pid=17344)
R:FAIL
S:allow_query:Wed Jun 20 23:21:47 GMT 2012
T:allow_query:1:A
A:System test allow_query
I:Couldn't start server ns2 (pid=17368)
R:FAIL
S:addzone:Wed Jun 20 23:22:01 GMT 2012
T:addzone:1:A
A:System test addzone
I:Couldn't start server ns2 (pid=17393)
R:FAIL
S:autosign:Wed Jun 20 23:22:15 GMT 2012
T:autosign:1:A
A:System test autosign
I:generating keys and preparing zones
I:Couldn't start server ns1 (pid=17734)
R:FAIL
S:builtin:Wed Jun 20 23:22:35 GMT 2012
T:builtin:1:A
A:System test builtin
I:Couldn't start server ns1 (pid=17755)
R:FAIL
S:cacheclean:Wed Jun 20 23:22:49 GMT 2012
T:cacheclean:1:A
A:System test cacheclean
I:Couldn't start server ns1 (pid=17776)
R:FAIL

I'm running the bin/tests/system/ifconfig.sh up script, and see the lo:1 
through lo:7 interfaces come up. I don't have this problem on any of my 
Solaris systems, just the Fedora servers. I do have several lo: interfaces 
already defined, and they cannot be removed

Has anyone seen such an issue, and if so, how did you fix it?

Dan Luther
Operations Engineer
Systems Operation Engineering 
Level 3 Communications
One Technology Center, Tulsa OK 74103
p: 918-547-4370
e: dan.lut...@level3.com


___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

RE: Compiling and testing on Fedora

[Shawn Bakhtiar]

Did you turn OFF SELinux? 

promptsetenforce 0

Then run the test, 

 From: dan.lut...@level3.com
 To: bind-us...@isc.org
 Subject: Compiling and testing on Fedora 
 Date: Wed, 20 Jun 2012 23:33:08 +
 
 Hi all, 
 
 I've had a major problem with using Fedora Core (10 through 15), when 
 compiling and running make test:
 
 A:System test acl
 I:Couldn't start server ns2 (pid=17344)
 R:FAIL
 S:allow_query:Wed Jun 20 23:21:47 GMT 2012
 T:allow_query:1:A
 A:System test allow_query
 I:Couldn't start server ns2 (pid=17368)
 R:FAIL
 S:addzone:Wed Jun 20 23:22:01 GMT 2012
 T:addzone:1:A
 A:System test addzone
 I:Couldn't start server ns2 (pid=17393)
 R:FAIL
 S:autosign:Wed Jun 20 23:22:15 GMT 2012
 T:autosign:1:A
 A:System test autosign
 I:generating keys and preparing zones
 I:Couldn't start server ns1 (pid=17734)
 R:FAIL
 S:builtin:Wed Jun 20 23:22:35 GMT 2012
 T:builtin:1:A
 A:System test builtin
 I:Couldn't start server ns1 (pid=17755)
 R:FAIL
 S:cacheclean:Wed Jun 20 23:22:49 GMT 2012
 T:cacheclean:1:A
 A:System test cacheclean
 I:Couldn't start server ns1 (pid=17776)
 R:FAIL
 
 I'm running the bin/tests/system/ifconfig.sh up script, and see the lo:1 
 through lo:7 interfaces come up. I don't have this problem on any of my 
 Solaris systems, just the Fedora servers. I do have several lo: interfaces 
 already defined, and they cannot be removed
 
 Has anyone seen such an issue, and if so, how did you fix it?
 
 Dan Luther
 Operations Engineer
 Systems Operation Engineering 
 Level 3 Communications
 One Technology Center, Tulsa OK 74103
 p: 918-547-4370
 e: dan.lut...@level3.com
 
 
 ___
 Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
 from this list
 
 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

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Announcing DSKM DNSsec key management tool ready for beta testing

[Axel Rau]

This is a DNSsec key management add-on to ISC bind 9.9.x for zones with
   auto-dnssec maintain;
   inline-signing yes;
It creates and deletes keys, submits DS or DNSKEY RRs to parent,
validates chain of trust and does alarming per email if something goes wrong.

Zones may be local, public or reverse (IP4 or IP6).
Initial implemented registrar is joker.com and ip registry ripe.net.

Local means internal zones with local trust anchor.

Intention is to have DNSsec automated completely.

Design is state-table driven with transitions triggered by DNS query results
or point in time reached, written in Python3.

License is GPLv3, may be downloaded from here
https://sourceforge.net/projects/dskm/files/

Source at GitHub:
https://github.com/rabaxabel/DSKM
Who implements the next registrar?
I will implement manual registrar handover notification per email soon.

I'm still improving my knowledge about DNSsec (Thanks list!) but DSKM
is running with 3 test domains and shortend key life times for 2 months now
with only minor problems.

Axel
---
PGP-Key:29E99DD6  ☀ +49 151 2300 9283  ☀ computing @ chaos claudius

___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Invitation to help ISC out with BIND10 command line tool testing

[Larissa Shapiro]

Dear BIND User Community,

The BIND 10 engineering team and are looking for BIND 9 users or other
DNS users who would be interested in helping us do some requirements
gathering and prototype testing. We're asking a select group of
customers to apply to be in a user test project for the command line tool.

_What you would need to commit to_:
Several 1/2 hr to 1 hr sessions with Shane and Larissa where we walk
through command line tool scenarios, later test out the actual tool and
provide feedback.

_Benefits to you_:
Opportunity to make sure their requirements get into the next generation
of BIND. Hopefully make their lives easier in the long run. Love,
admiration, and probably a free t-shirt.

_Benefits to ISC_:
Making sure the tool actually meets our users requirements. Hopefully
reducing support overhead in the future as a result. Developing and
strengthening relationships with our users.

If you cannot help out but someone within your group/team is interested,
please let me know as soon as possible! We're finalizing participants
Wednesday, May 9th.

Thank you for your consideration.

Larissa

Larissa Shapiro
BIND and DHCP Product Manager
Internet Systems Consortium
+1650 423 1335
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

testing validation

[Alan Batie]

I'm testing out dnssec with bind 9.9.0's auto signing and a test domain;
this appears to be working (see below, RRSIG records returned from the
actual nameserver), however and attempt to validate fails with:

# dig +dnssec +sigchase soa raindrop.us
;; RRset to chase:
raindrop.us.987 IN  SOA ns1.raindrop.us. 
hostmaster.rdrop.com.
2012030815 3600 3600 86400 3600



Launch a query to find a RRset of type RRSIG for zone: raindrop.us.

;; RRSIG is missing for continue validation: FAILED


I have this included in the resolver's named.conf:

managed-keys {
   . initial-key 257 3 8
AwEAAagAIKlVZrpC6Ia7gEzahOR+9W29euxhJhVVLOyQbSEW0O8gcCjF
FVQUTf6v58fLjwBd0YI0EzrAcQqBGCzh/RStIoO8g0NfnfL2MTJRkxoX
bfDaUeVPQuYEhg37NZWAJQ9VnMVDxP/VHL496M/QZxkjf5/Efucp2gaD
X6RS6CXpoY68LsvPVjR0ZSwzz1apAzvN9dlzEheX7ICJBBtuA6G3LQpz
W5hOA2hzCTMjJPJ8LbqF6dsV6DoBQzgul0sGIcGOYl7OyQdXfZ57relS
Qageu+ipAdTTJ25AsRTAoub8ONGcLmqrAmRLKBP1dfwhYB4N7knNnulq QxA+Uk1ihz0= ;
};

per https://calomel.org/dns_bind.html

When I simply try to validate the root:

# dig +dnssec +sigchase .
;; NO ANSWERS: no more
We want to prove the non-existence of a type of rdata 1 or of the zone:
there is no NSEC for this zone: validating that the zone doesn't exist

;; Impossible to verify the Non-existence, the NSEC RRset can't be
validated: FAILED

I'm not sure what to look for now...



# dig +dnssec @ns6.peak.org raindrop.us

;  DiG 9.9.0  +dnssec @ns6.peak.org raindrop.us
; (1 server found)
;; global options: +cmd
;; Got answer:
;; -HEADER- opcode: QUERY, status: NOERROR, id: 15953
;; flags: qr aa rd; QUERY: 1, ANSWER: 2, AUTHORITY: 2, ADDITIONAL: 3
;; WARNING: recursion requested but not available

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 4096
;; QUESTION SECTION:
;raindrop.us.   IN  A

;; ANSWER SECTION:
raindrop.us.3600IN  A   199.26.172.34
raindrop.us.3600IN  RRSIG   A 5 2 3600 20120512011136 
20120412010327
41190 raindrop.us.
kH5rKfIHghbsiKLTMkO6GjDtXI0Afkgl2x74K0o0AKtDlTDfsk+2pPZ/
XwKj1k2jIYButqXximUjHOHQHK1bSru7V8DkkN7JF/wozTOiGCs777sO
s90jKmaHIIMSTbNcQgtDySqzPsd4Sn9Qp86Iykj0nvXyUeMib2bzPJ5S VBY=

;; AUTHORITY SECTION:
raindrop.us.3600IN  NS  ns1.raindrop.us.
raindrop.us.3600IN  RRSIG   NS 5 2 3600 20120512011136 
20120412010327
41190 raindrop.us.
UQxIRpKV+b4opfCJx/j4oIFht8nqxpn1g0siOLI2XkxfVrnXHh17/ChT
X6PH5YOrF7D3v7AUMbVo+o8glSUfk1uML8i3C8H5lD/NmujPPrIqFaO/
6zCJen1q34FVunCoqfrYvYlaKHenFGsrpOl61H75ns0IjLMXSs+TRpIY GTs=

;; ADDITIONAL SECTION:
ns1.raindrop.us.3600IN  2607:f678::56
ns1.raindrop.us.3600IN  RRSIG    5 3 3600 20120512011136
20120412010327 41190 raindrop.us.
MhaOIt7D7kT8k4USk9Mpocw+tSx8WBSO/Yi+4F/YFV1ZVSXLKgYj4K4S
hTjVTBD3tCQYMJY+SkArlkoQRyTk4QYrLV8CP2TvvdrUPjZUZNAEMsuk
0NWsd2tLgStZ34yN0Pe1xa9P2SZjvsXJj1D1N5JNFxfS/OFCwMa9Hvcr atM=

;; Query time: 253 msec
;; SERVER: 2607:f678:10::53#53(2607:f678:10::53)
;; WHEN: Tue Apr 17 23:29:08 2012
;; MSG SIZE  rcvd: 615




___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

RE: testing validation

[Spain, Dr. Jeffry A.]

 I'm testing out dnssec with bind 9.9.0's auto signing and a test domain; this 
 appears to be working (see below, RRSIG records returned from the actual 
 nameserver), however and attempt to validate fails with:
 # dig +dnssec +sigchase soa raindrop.us
 When I simply try to validate the root:

 # dig +dnssec +sigchase .
 ;; NO ANSWERS: no more

 # dig +dnssec @ns6.peak.org raindrop.us
 ;; WARNING: recursion requested but not available

Your post is somewhat unclear to me. Querying from my bind 9.9.0 recursive 
resolver dig @localhost raindrop.us +dnssec, I get an AD flag returned, 
suggesting that dnssec is working for raindrop.us. In your query dig +dnssec 
+sigchase soa raindrop.us, is the resolver dnssec-enabled? I assume this would 
be one of the resolvers listed in your resolv.conf file. It appears that 
ns6.peak.org is not a recursive resolver. Does it have a zone file for 
raindrop.us?

Jeffry A. Spain
Network Administrator
Cincinnati Country Day School
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: testing validation

[Carlos Ribas]

Hello,

Is your recursive resolver also authoritative for raindrop.us? If so,
you will not get the ad flag. You can test with DNS-OARC resolver [1]:

# dig +dnssec +multiline @149.20.64.20 raindrop.us

;  DiG 9.7.3  +dnssec +multiline @149.20.64.20 raindrop.us
; (1 server found)
;; global options: +cmd
;; Got answer:
;; -HEADER- opcode: QUERY, status: NOERROR, id: 28120
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 4096
;; QUESTION SECTION:
;raindrop.us.   IN A

;; ANSWER SECTION:
raindrop.us.3600 IN A 199.26.172.34
raindrop.us.3600 IN RRSIG A 5 2 3600 20120512011136 (
20120412010327 41190 raindrop.us.
kH5rKfIHghbsiKLTMkO6GjDtXI0Afkgl2x74K0o0AKtD
lTDfsk+2pPZ/XwKj1k2jIYButqXximUjHOHQHK1bSru7
V8DkkN7JF/wozTOiGCs777sOs90jKmaHIIMSTbNcQgtD
ySqzPsd4Sn9Qp86Iykj0nvXyUeMib2bzPJ5SVBY= )

;; Query time: 787 msec
;; SERVER: 149.20.64.20#53(149.20.64.20)
;; WHEN: Wed Apr 18 14:39:45 2012
;; MSG SIZE  rcvd: 227

It's working fine.

[1] - https://www.dns-oarc.net/oarc/services/odvr


Best regards,

-
Carlos Eduardo Ribas



2012/4/18 Alan Batie a...@peak.org

 I'm testing out dnssec with bind 9.9.0's auto signing and a test domain;
 this appears to be working (see below, RRSIG records returned from the
 actual nameserver), however and attempt to validate fails with:

 # dig +dnssec +sigchase soa raindrop.us
 ;; RRset to chase:
 raindrop.us.987 IN  SOA ns1.raindrop.us.
 hostmaster.rdrop.com.
 2012030815 3600 3600 86400 3600



 Launch a query to find a RRset of type RRSIG for zone: raindrop.us.

 ;; RRSIG is missing for continue validation: FAILED


 I have this included in the resolver's named.conf:

 managed-keys {
   . initial-key 257 3 8
 AwEAAagAIKlVZrpC6Ia7gEzahOR+9W29euxhJhVVLOyQbSEW0O8gcCjF
 FVQUTf6v58fLjwBd0YI0EzrAcQqBGCzh/RStIoO8g0NfnfL2MTJRkxoX
 bfDaUeVPQuYEhg37NZWAJQ9VnMVDxP/VHL496M/QZxkjf5/Efucp2gaD
 X6RS6CXpoY68LsvPVjR0ZSwzz1apAzvN9dlzEheX7ICJBBtuA6G3LQpz
 W5hOA2hzCTMjJPJ8LbqF6dsV6DoBQzgul0sGIcGOYl7OyQdXfZ57relS
 Qageu+ipAdTTJ25AsRTAoub8ONGcLmqrAmRLKBP1dfwhYB4N7knNnulq QxA+Uk1ihz0= ;
 };

 per https://calomel.org/dns_bind.html

 When I simply try to validate the root:

 # dig +dnssec +sigchase .
 ;; NO ANSWERS: no more
 We want to prove the non-existence of a type of rdata 1 or of the zone:
 there is no NSEC for this zone: validating that the zone doesn't exist

 ;; Impossible to verify the Non-existence, the NSEC RRset can't be
 validated: FAILED

 I'm not sure what to look for now...



 # dig +dnssec @ns6.peak.org raindrop.us

 ;  DiG 9.9.0  +dnssec @ns6.peak.org raindrop.us
 ; (1 server found)
 ;; global options: +cmd
 ;; Got answer:
 ;; -HEADER- opcode: QUERY, status: NOERROR, id: 15953
 ;; flags: qr aa rd; QUERY: 1, ANSWER: 2, AUTHORITY: 2, ADDITIONAL: 3
 ;; WARNING: recursion requested but not available

 ;; OPT PSEUDOSECTION:
 ; EDNS: version: 0, flags: do; udp: 4096
 ;; QUESTION SECTION:
 ;raindrop.us.   IN  A

 ;; ANSWER SECTION:
 raindrop.us.3600IN  A   199.26.172.34
 raindrop.us.3600IN  RRSIG   A 5 2 3600 20120512011136
 20120412010327
 41190 raindrop.us.
 kH5rKfIHghbsiKLTMkO6GjDtXI0Afkgl2x74K0o0AKtDlTDfsk+2pPZ/
 XwKj1k2jIYButqXximUjHOHQHK1bSru7V8DkkN7JF/wozTOiGCs777sO
 s90jKmaHIIMSTbNcQgtDySqzPsd4Sn9Qp86Iykj0nvXyUeMib2bzPJ5S VBY=

 ;; AUTHORITY SECTION:
 raindrop.us.3600IN  NS  ns1.raindrop.us.
 raindrop.us.3600IN  RRSIG   NS 5 2 3600
 20120512011136 20120412010327
 41190 raindrop.us.
 UQxIRpKV+b4opfCJx/j4oIFht8nqxpn1g0siOLI2XkxfVrnXHh17/ChT
 X6PH5YOrF7D3v7AUMbVo+o8glSUfk1uML8i3C8H5lD/NmujPPrIqFaO/
 6zCJen1q34FVunCoqfrYvYlaKHenFGsrpOl61H75ns0IjLMXSs+TRpIY GTs=

 ;; ADDITIONAL SECTION:
 ns1.raindrop.us.3600IN  2607:f678::56
 ns1.raindrop.us.3600IN  RRSIG    5 3 3600
 20120512011136
 20120412010327 41190 raindrop.us.
 MhaOIt7D7kT8k4USk9Mpocw+tSx8WBSO/Yi+4F/YFV1ZVSXLKgYj4K4S
 hTjVTBD3tCQYMJY+SkArlkoQRyTk4QYrLV8CP2TvvdrUPjZUZNAEMsuk
 0NWsd2tLgStZ34yN0Pe1xa9P2SZjvsXJj1D1N5JNFxfS/OFCwMa9Hvcr atM=

 ;; Query time: 253 msec
 ;; SERVER: 2607:f678:10::53#53(2607:f678:10::53)
 ;; WHEN: Tue Apr 17 23:29:08 2012
 ;; MSG SIZE  rcvd: 615




 ___
 Please visit https://lists.isc.org/mailman/listinfo/bind-users to
 unsubscribe from this list

 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

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: testing validation

[Alan Batie]

On 4/18/12 10:33 AM, Spain, Dr. Jeffry A. wrote:

 Your post is somewhat unclear to me. Querying from my bind 9.9.0 recursive 
 resolver dig @localhost raindrop.us +dnssec, I get an AD flag returned, 
 suggesting that dnssec is working for raindrop.us. In your query dig +dnssec 
 +sigchase soa raindrop.us, is the resolver dnssec-enabled? I assume this 
 would be one of the resolvers listed in your resolv.conf file. It appears 
 that ns6.peak.org is not a recursive resolver. Does it have a zone file for 
 raindrop.us?

That's somewhat reassuring in that at least the authoritative server
seems to be working, meaning it's my resolver that isn't.

Sorry about the clarity - I am working with two machines, each running
bind 9.9.0: ns6.peak.org is the test authoritative server which is
serving the test domain, raindrop.us.  I'm using another machine as a
dnssec enabled resolver to do the testing from with this named.conf:


include /var/named/rdrop.blocks;
include /var/named/peak.blocks;

options {
directory /var/named;
pid-file /var/run/named/pid;

listen-on { 127.0.0.1; };
listen-on-v6 { ::1; };

allow-query {
127.0.0.1;
::1;
rdrop_blocks;
peak_blocks;
};
allow-recursion {
127.0.0.1;
::1;
rdrop_blocks;
peak_blocks;
};
allow-transfer { none; };

dnssec-enable yes;
dnssec-validation yes;
masterfile-format text;

query-source address 127.0.0.1 port *;
version named;
};

managed-keys {
   . initial-key 257 3 8
AwEAAagAIKlVZrpC6Ia7gEzahOR+9W29euxhJhVVLOyQbSEW0O8gcCjF
FVQUTf6v58fLjwBd0YI0EzrAcQqBGCzh/RStIoO8g0NfnfL2MTJRkxoX
bfDaUeVPQuYEhg37NZWAJQ9VnMVDxP/VHL496M/QZxkjf5/Efucp2gaD
X6RS6CXpoY68LsvPVjR0ZSwzz1apAzvN9dlzEheX7ICJBBtuA6G3LQpz
W5hOA2hzCTMjJPJ8LbqF6dsV6DoBQzgul0sGIcGOYl7OyQdXfZ57relS
Qageu+ipAdTTJ25AsRTAoub8ONGcLmqrAmRLKBP1dfwhYB4N7knNnulq QxA+Uk1ihz0= ;
};

zone . {
  type hint;
  file named.root;
};

zone 0.0.127.in-addr.arpa {
  type master;
  file master/localhost-reverse.db;
};

___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users