Re: can I provide invalid HTTPS values for testing?
On Thu, Jun 20, 2024 at 02:29:13PM +0100, Stephen Farrell wrote a message of 100 lines which said: > 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. A related issue: does anyone know a software / service which tests HTTPS records and actually connects to the HTTPS server to see if it indeed supports what it claims to support. (Testing all ALPNs, all IP hints, etc.) "Error, HTTP record says alpn=h3 but HTTP/3 setup failed" Bonus if I can integrate it in Nagios/Icinga/Zabbix/etc. -- 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?
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?
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?
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?
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?
> 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?
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?
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?
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?
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
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
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
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
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
>> 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
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
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
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
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
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 ?
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 ?
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 ?
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 ?
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 ?
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 ?
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 ?
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 ?
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 ?
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 ?
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
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
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
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
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
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
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
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
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
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
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...
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,
RE: Testing a new master server...
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...
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
Working Nuno Sent from my Verizon 4G LTE Droid On Feb 14, 2018 1:48 AM, Dan Mahoney 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
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...
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...
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...
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.finchhttp://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...
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...
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.finchhttp://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...
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...
... 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...
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...
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
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 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
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
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" 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 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) > 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
Polo On 6/24/16 6:29 PM, John W. Blue wrote: Marco Sent from Nine <http://www.9folders.com/> *From:* Dan Mahoney *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
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
Re: Testing
Marco Sent from Nine<http://www.9folders.com/> From: Dan Mahoney 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
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
Re: Can anyone tell me a good DNS server testing program
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 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) > 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
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
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
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
> 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
> 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
On 4/21/15, 10:15, "Warren Kumari" 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
On Tue, Apr 21, 2015 at 9:55 AM, Edward Lewis wrote: > On 4/21/15, 9:45, "Tony Finch" 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 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.finchhttp://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
On 4/21/15, 9:45, "Tony Finch" 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
Edward Lewis 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.finchhttp://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
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" 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
On Mon, Apr 20, 2015 at 4:33 PM, Evan Hunt 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 , I was just too lazy to go figure out what the 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
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
On Mon, Apr 20, 2015 at 3:41 PM, Edward Lewis 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" 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
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" 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
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
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 oA1rwc8tDpyApUXP57fuf
Re: Testing RFC 5011 key roll
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
Re: Testing RFC 5011 key roll
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" 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
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
Testing RFC 5011 key roll
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+vPIA
Re: How reliable is RPZ in production? I'm seeing flakiness in testing.
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-hosts"policy 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.
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.
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 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.
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
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
Testing, please ignore
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
bsa: A testing toolkit for bind configurations.
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
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 2>&1 < > 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
Re: Compiling and testing on Fedora
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
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? prompt>setenforce 0 Then run the test, > From: dan.lut...@level3.com<mailto:dan.lut...@level3.com> > To: bind-us...@isc.org<mailto: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<mailto: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<mailto: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
Did you turn OFF SELinux? prompt>setenforce 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
Re: Compiling and testing on Fedora
I don't immediately recognize the issue. But hopefully the detailed named debugging output is saved. Look for the "*.run" (maybe named.run) files. ___ 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
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
Announcing DSKM DNSsec key management tool ready for beta testing
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
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
Re: testing validation
On 4/18/12 12:18 PM, Spain, Dr. Jeffry A. wrote: >> ;; WARNING There is no DS for the zone: . >> Isn't the "DS for the zone: ." what the "managed-keys" clause provides? > > Now I think I see what you mean. It is my understanding that DS records exist > in parent zones and refer to child zones that are to be trusted. Thus there > is no DS record referring to the root zone, as it by definition has no > parent. The root trust anchor provided by managed-keys or dnssec-validation > serves the same purpose as this non-existent DS record. The warning above > makes sense in this context. Jeff. Right - although the trust anchor is provided, it's not actually a DS record, so you still get the warning... Now on to research key rotation management... ___ 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