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 sa

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

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

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

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

RE: Testing KASP, CDS, and .ch

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

RE: Testing KASP, CDS, and .ch

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

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 2

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 Pop

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 chang

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 i

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

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?

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 uns

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 f

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 a

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 fol

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 r

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 re

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

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

Re: Testing

Polo On 6/24/16 6:29 PM, John W. Blue wrote: Marco Sent from Nine *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/listinf

Re: Testing

Marco Sent from Nine 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 m

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 wai

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

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

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 o

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:

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

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 administra

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

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

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 keyrol

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 t

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 know

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

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

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,

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

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

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 th

RE: testing validation

> Though I am still curious about this from the end of sigchase output: > Launch a query to find a RRset of type DS for zone: . > ;; NO ANSWERS: no more > ;; 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

Re: testing validation

On 4/18/12 11:48 AM, Spain, Dr. Jeffry A. wrote: >> Isn't the "DS for the zone: ." what the "managed-keys" clause provides? >> Though putting it back in didn't make the warning go away, so I must be >> missing something else here... > > Any difference with dnssec-validation auto and removing the

RE: testing validation

> Why would 149.20.64.20 return ad then? It's not authoritative either... As I understand it, you need a dnssec-enabled recursive resolver to get an AD flag returned. An authoritative-only server will never return an AD flag. Jeff. ___ Please visit htt

RE: testing validation

> Isn't the "DS for the zone: ." what the "managed-keys" clause provides? > Though putting it back in didn't make the warning go away, so I must be > missing something else here... Any difference with dnssec-validation auto and removing the managed-keys and root hint zone? Jeff.

Re: testing validation

On 4/18/12 11:14 AM, Spain, Dr. Jeffry A. wrote: > Alan: Comments on your configuration file: I also forgot to remove the nameserver entries from resolv.conf after installing bind. Sigh. Sorry to bother everyone... Though I am still curious about this from the end of sigchase output: Launch

RE: testing validation

Alan: Comments on your configuration file: I believe that managed-keys... and zone "." { type hint... are built into bind 9.9.0 recursive resolvers and therefore not needed. You can enable the built in root trust anchor by changing dnssec-validation from yes to auto. I think that listen-on { 12

Re: testing validation

Because this IP has dnssec enabled and raindrop.us is signed :-) Regards, - Carlos Eduardo Ribas 2012/4/18 Alan Batie > On 4/18/12 10:46 AM, Carlos Ribas wrote: > > > Is your recursive resolver also authoritative for raindrop.us? > > If so, you will not ge

Re: testing validation

On 4/18/12 10:46 AM, Carlos Ribas wrote: > Is your recursive resolver also authoritative for raindrop.us? > If so, you will not get the "ad" flag. You can > test with DNS-OARC resolver [1]: > > # dig +dnssec +multiline @149.20.64.20 raindrop.us Why would 149.20.64.20 return ad then? It's no

Re: testing validation

On 4/18/12 10:33 AM, Spain, Dr. Jeffry A. wrote: > Your post is somewhat unclear to me. Querying from my bind 9.9.0 recursive > resolver "dig @localhost raindrop.us +dnssec", I get an AD flag returned, > suggesting that dnssec is working for raindrop.us. In your query "dig +dnssec > +sigchase s

Re: testing validation

Hello, Is your recursive resolver also authoritative for raindrop.us? If so, you will not get the "ad" flag. You can test with DNS-OARC resolver [1]: # dig +dnssec +multiline @149.20.64.20 raindrop.us ; <<>> DiG 9.7.3 <<>> +dnssec +multiline @149.20.64.20 raindrop.us ; (1 server found) ;; gl

RE: testing validation

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

Re: testing bind9

Gera 123 wrote: [from dig...] > ;; ANSWER SECTION: > elimparcial.com. 3832 IN A 216.240.181.166 [from nslookup...] > *** No se puede econtrar el nombre de servidor para la direccion > 192.168.0.19 : non-existent domain > *** los servidores predeterminados no estan disponibles > Respuesta no aut

Re: Testing my configuration

On Wed, Dec 17, 2008 at 12:36:44PM +0100, Holger Honert wrote a message of 113 lines which said: > check out dig eith the zone-transfer option (man dig): He asked for information about a DOMAIN NAME, which may or may not be also a ZONE. If it is not a zone, zone transfer wont' work. Using:

Re: Testing my configuration

Hello Fred, try dig -t any domain.com @your-server dig -t any domain.com @your-server +vc and dig --help Regards Peter Fred Zinsli wrote: > Hello all > > Well I have a basic setup going and it seems to function. > > What I am wanting to know is, is there a way of getting all of the >

Re: Testing my configuration

dig @nameserver zone axfr For example: dig @10.10.10.10 my.domain.com axfr you need to allow zone transfer. On Wed, Dec 17, 2008 at 1:50 AM, Fred Zinsli wrote: > Hello all > > Well I have a basic setup going and it seems to function. > > What I am wanting to know is, is there a way of getting

Re: Testing my configuration

Hi Fred, check out dig with the zone-transfer option (man dig): The -t option sets the query type to type. It can be any valid query type which is supported in BIND 9. The default query type is "A", unless the -x option is supplied to indicate a reverse lookup. A zone transfer can

Re: Testing my configuration

Hi Fred, check out dig eith the zone-transfer option (man dig): The -t option sets the query type to type. It can be any valid query type which is supported in BIND 9. The default query type is "A", unless the -x option is supplied to indicate a reverse lookup. A zone transfer can