Re: Testing KASP, CDS, and .ch

[Jim Popovitch via bind-users]

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

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

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

+1 Thanks!!


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

Thank you for that info.  

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

-Jim P.

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

ISC funds the development of this software with paid support subscriptions. 
Contact us at https://www.isc.org/contact/ for more information.


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

Re: Testing KASP, CDS, and .ch

[Oli Schacher]

Hi Jim
let me give you a bit more info


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

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

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


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


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



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

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


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

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


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


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

ISC funds the development of this software with paid support subscriptions. 
Contact us at https://www.isc.org/contact/ for more information.


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

RE: Testing KASP, CDS, and .ch

[Jim Popovitch via bind-users]

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

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

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


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

ISC funds the development of this software with paid support subscriptions. 
Contact us at https://www.isc.org/contact/ for more information.


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

Re: Testing KASP, CDS, and .ch

[Jim Popovitch via bind-users]

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

Thanks Hugo!  That helps.

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

ISC funds the development of this software with paid support subscriptions. 
Contact us at https://www.isc.org/contact/ for more information.


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

Re: Testing KASP, CDS, and .ch

[Hugo Salgado]

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

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

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

Hugo

On 15:11 09/04, Jim Popovitch via bind-users wrote:
> On Fri, 2021-04-09 at 19:05 +, John W. Blue via bind-users wrote:
> > So the issue here is that the DS record that sit in .ch has an ID of 22048 
> > but the domainmail.ch servers are telling the world that the correct ID is 
> > 17870.
> > 
> > Thus the DNSSEC breakage.
> 
> Of course, however there is no 22048 id in Gandi (the Registrar), yet it
> appears in .ch, and 17870 is still Active (as of this moment in time).  
> 
> What I can't figure out is how/when does .ch query the CDS/CDNSKEY data.
> 
> I know that I can make the domain validate by manually putting a
> keyid+data in Gandi, but the whole purpose of CDS/CDNSKEY is to not have
> to do that, no?
> 
> -Jim P.
> 
> 
> 
> ___
> Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
> from this list
> 
> ISC funds the development of this software with paid support subscriptions. 
> Contact us at https://www.isc.org/contact/ for more information.
> 
> 
> bind-users mailing list
> bind-users@lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users
> 


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

ISC funds the development of this software with paid support subscriptions. 
Contact us at https://www.isc.org/contact/ for more information.


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

RE: Testing KASP, CDS, and .ch

[John W. Blue via bind-users]

Sorry .. clicked send too soon.

Found this via google:

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

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

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

Good hunting.

John

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

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

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

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

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

-Jim P.



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

ISC funds the development of this software with paid support subscriptions. 
Contact us at https://www.isc.org/contact/ for more information.


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

ISC funds the development of this software with paid support subscriptions. 
Contact us at https://www.isc.org/contact/ for more information.


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

RE: Testing KASP, CDS, and .ch

[John W. Blue via bind-users]

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

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

John

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

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

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

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

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

-Jim P.



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

ISC funds the development of this software with paid support subscriptions. 
Contact us at https://www.isc.org/contact/ for more information.


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

ISC funds the development of this software with paid support subscriptions. 
Contact us at https://www.isc.org/contact/ for more information.


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

Re: Testing KASP, CDS, and .ch

[Jim Popovitch via bind-users]

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

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

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

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

-Jim P.



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

ISC funds the development of this software with paid support subscriptions. 
Contact us at https://www.isc.org/contact/ for more information.


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

RE: Testing KASP, CDS, and .ch

[John W. Blue via bind-users]

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

Thus the DNSSEC breakage.

John

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

Hello!

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

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

What am I missing?

I'm using the following policy and zone config: 

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

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

Here are the info of the active keys:

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

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

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


-Jim P.

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

ISC funds the development of this software with paid support subscriptions. 
Contact us at https://www.isc.org/contact/ for more information.


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

ISC funds the development of this software with paid support subscriptions. 
Contact us at https://www.isc.org/contact/ for more information.


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

Re: Testing a new master server...

[Bruce Johnson]

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

Hello Bruce!

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

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

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


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

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


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

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

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

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

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

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


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

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

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

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


Regardless, I do hope your migration goes smooth!

John

-Original Message-
From: bind-users [mailto:bind-users-boun...@lists.isc.org] On Behalf Of Bruce 
Johnson
Sent: Wednesday, November 18, 2020 11:35 AM
To: bind-users@lists.isc.org
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 cam

RE: Testing a new master server...

[John W. Blue via bind-users]

Hello Bruce!

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

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

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

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

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

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

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

Regardless, I do hope your migration goes smooth!

John

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

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

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

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

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

Am I missing something or overcomplicating things?

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

Institutions do not have opinions, merely customs


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

ISC funds the development of this software with paid support subscriptions. 
Contact us at https://www.isc.org/contact/ for more information.


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

ISC funds the development of this software with paid support subscriptions. 
Contact us at https://www.isc.org/contact/ for more information.


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

Re: Testing

[Nuno]

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

Re: Testing...

[Hika van den Hoven]

Hoi Tony,

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

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

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

> Tony.

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

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

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

De lerende Mens
--

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

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

Re: Testing...

[Alan Clegg]

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

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

And they all said Ramen...

AlanC



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

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

Re: Testing...

[Tony Finch]

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

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

Tony.
-- 
f.anthony.n.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...

[Grant Taylor]

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

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


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


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


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




--
Grant. . . .
unix || die



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

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

Re: Testing...

[Tony Finch]

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

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

Tony.
-- 
f.anthony.n.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...

[Alan Clegg]

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

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

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

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

No additional responses needed at this time.

AlanC



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

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

Re: Testing...

[Warren Kumari]

... yes, yes you are.

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

W

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



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

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

Re: Testing...

[Adamiec, Lawrence]

I see your email on the list.



Thank you.
Larry

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

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

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

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

Re: Testing DNS security

[Emil Natan]

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

Emil






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



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

[Bill Christensen]

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

Re: Testing

[John W. Blue]

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 mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

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

Re: Testing RFC 5011 key roll

[Jan-Piet Mens]

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

Yup. I learned that as well.

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

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

-JP

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

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

Re: Testing RFC 5011 key roll

[Evan Hunt]

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

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

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

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

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

Re: Testing RFC 5011 key roll

[Edward Lewis]

On 4/21/15, 10:15, "Warren Kumari"  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

[Warren Kumari]

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

[Tony Finch]

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

[Edward Lewis]

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

[Tony Finch]

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

[Edward Lewis]

Evan/et.al.,

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

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

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

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

Ed

On 4/20/15, 15:12, "Evan Hunt"  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

[Warren Kumari]

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

[Evan Hunt]

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

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

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

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

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

Re: Testing RFC 5011 key roll

[Warren Kumari]

On Mon, Apr 20, 2015 at 3:41 PM, Edward Lewis  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

[Edward Lewis]

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

Got an AD bit again too.

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

On 4/20/15, 15:12, "Evan Hunt"  wrote:

>On Mon, Apr 20, 2015 at 06:42:42PM +, Edward Lewis wrote:
>> Being that I'm working on a laptop (hence on on over the weekend) I've
>>had
>> to recreate the environment today.  I'm a bit more puzzled now.
>
>There's a separate file that named creates to keep the current
>managed keys state information -- it's based on the view name,
>so in your case it'll be "recursive.mkeys" (and possibly
>"recursive.mkeys.jnl").  I suspect it still has the key from
>Friday in it, and that's messing things up.  Delete that file and
>reinitialize, then leave the server up and running (not forgetting
>to use -T mkeytimers=H/D/M, where M is no more than 3600 seconds,
>because keyroll.systems rolls its keys every hour and normal RFC
>5011 processing can't handle that), and you should be in good shape.
>
>-- 
>Evan Hunt -- e...@isc.org
>Internet Systems Consortium, Inc.


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

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

Re: Testing RFC 5011 key roll

[Evan Hunt]

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

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

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

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

Re: Testing RFC 5011 key roll

[Edward Lewis]

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

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

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

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

Ugly details below:

This time I do see an error upon startup:

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

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

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

My rfc5011.conf file is:

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

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

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

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

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

allow-recursion { any; };

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

};  // End of recursive view.


The current dig "fake-. dnskey" is:


$ dig @204.42.252.20 . dnskey

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

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

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

Re: Testing RFC 5011 key roll

[Jan-Piet Mens]

Edward,

the subject of this message piqued my interest ;-)

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

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

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

-JP


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

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

Re: Testing RFC 5011 key roll

[Edward Lewis]

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

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

On 4/17/15, 12:45, "Evan Hunt"  wrote:
...

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



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

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

Re: Testing RFC 5011 key roll

[Evan Hunt]

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

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

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

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

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

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

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

$ named -T mkeytimers=2/5/60

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

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

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

Re: testing validation

[Alan Batie]

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

RE: testing validation

[Spain, Dr. Jeffry A.]

> 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 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.
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

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

Re: testing validation

[Alan Batie]

On 4/18/12 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 managed-keys and 
> root hint zone? Jeff.

No; I did turn on auto and removed the managed-keys and hint, noticed
the warning and tried turning validation back to yes with the
managed-keys, but that didn't change the warning.  dig still reports
successful validation even with the warning though...

# dig @localhost +dnssec raindrop.us

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

...

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

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

RE: testing validation

[Spain, Dr. Jeffry A.]

> 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 https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

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

RE: testing validation

[Spain, Dr. Jeffry A.]

> 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.
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

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

Re: testing validation

[Alan Batie]

On 4/18/12 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 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?
 Though putting it back in didn't make the warning go away, so I must be
missing something else here...

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

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

RE: testing validation

[Spain, Dr. Jeffry A.]

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 { 127.0.0.1; }; will prevent your resolver from 
accepting queries from network sources, and so is inconsistent with your 
allow-query statement. Consider omitting listen-on and changing listen-on-v6 to 
{any;}.

Consider adding zones for 
1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.ip6.arpa and 
localhost.

Jeff.


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

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

Re: testing validation

[Carlos Ribas]

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 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 not authoritative either...
>
>
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

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

Re: testing validation

[Alan Batie]

On 4/18/12 10: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 not authoritative either...

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

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

Re: testing validation

[Alan Batie]

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

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

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

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


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

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

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

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

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

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

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

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

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

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

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

Re: testing validation

[Carlos Ribas]

Hello,

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

# dig +dnssec +multiline @149.20.64.20 raindrop.us

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

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

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

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

It's working fine.

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


Best regards,

-
Carlos Eduardo Ribas



2012/4/18 Alan Batie 

> I'm testing out dnssec with bind 9.9.0's auto signing and a test domain;
> this appears to be working (see below, RRSIG records returned from the
> actual nameserver), however and attempt to validate fails with:
>
> # dig +dnssec +sigchase soa raindrop.us
> ;; RRset to chase:
> raindrop.us.987 IN  SOA ns1.raindrop.us.
> hostmaster.rdrop.com.
> 2012030815 3600 3600 86400 3600
>
>
>
> Launch a query to find a RRset of type RRSIG for zone: raindrop.us.
>
> ;; RRSIG is missing for continue validation: FAILED
>
>
> I have this included in the resolver's named.conf:
>
> managed-keys {
>   "." initial-key 257 3 8
> "AwEAAagAIKlVZrpC6Ia7gEzahOR+9W29euxhJhVVLOyQbSEW0O8gcCjF
> FVQUTf6v58fLjwBd0YI0EzrAcQqBGCzh/RStIoO8g0NfnfL2MTJRkxoX
> bfDaUeVPQuYEhg37NZWAJQ9VnMVDxP/VHL496M/QZxkjf5/Efucp2gaD
> X6RS6CXpoY68LsvPVjR0ZSwzz1apAzvN9dlzEheX7ICJBBtuA6G3LQpz
> W5hOA2hzCTMjJPJ8LbqF6dsV6DoBQzgul0sGIcGOYl7OyQdXfZ57relS
> Qageu+ipAdTTJ25AsRTAoub8ONGcLmqrAmRLKBP1dfwhYB4N7knNnulq QxA+Uk1ihz0= ";
> };
>
> per https://calomel.org/dns_bind.html
>
> When I simply try to validate the root:
>
> # dig +dnssec +sigchase .
> ;; NO ANSWERS: no more
> We want to prove the non-existence of a type of rdata 1 or of the zone:
> there is no NSEC for this zone: validating that the zone doesn't exist
>
> ;; Impossible to verify the Non-existence, the NSEC RRset can't be
> validated: FAILED
>
> I'm not sure what to look for now...
>
>
>
> # dig +dnssec @ns6.peak.org raindrop.us
>
> ; <<>> DiG 9.9.0 <<>> +dnssec @ns6.peak.org raindrop.us
> ; (1 server found)
> ;; global options: +cmd
> ;; Got answer:
> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 15953
> ;; flags: qr aa rd; QUERY: 1, ANSWER: 2, AUTHORITY: 2, ADDITIONAL: 3
> ;; WARNING: recursion requested but not available
>
> ;; OPT PSEUDOSECTION:
> ; EDNS: version: 0, flags: do; udp: 4096
> ;; QUESTION SECTION:
> ;raindrop.us.   IN  A
>
> ;; ANSWER SECTION:
> raindrop.us.3600IN  A   199.26.172.34
> raindrop.us.3600IN  RRSIG   A 5 2 3600 20120512011136
> 20120412010327
> 41190 raindrop.us.
> kH5rKfIHghbsiKLTMkO6GjDtXI0Afkgl2x74K0o0AKtDlTDfsk+2pPZ/
> XwKj1k2jIYButqXximUjHOHQHK1bSru7V8DkkN7JF/wozTOiGCs777sO
> s90jKmaHIIMSTbNcQgtDySqzPsd4Sn9Qp86Iykj0nvXyUeMib2bzPJ5S VBY=
>
> ;; AUTHORITY SECTION:
> raindrop.us.3600IN  NS  ns1.raindrop.us.
> raindrop.us.3600IN  RRSIG   NS 5 2 3600
> 20120512011136 20120412010327
> 41190 raindrop.us.
> UQxIRpKV+b4opfCJx/j4oIFht8nqxpn1g0siOLI2XkxfVrnXHh17/ChT
> X6PH5YOrF7D3v7AUMbVo+o8glSUfk1uML8i3C8H5lD/NmujPPrIqFaO/
> 6zCJen1q34FVunCoqfrYvYlaKHenFGsrpOl61H75ns0IjLMXSs+TRpIY GTs=
>
> ;; ADDITIONAL SECTION:
> ns1.raindrop.us.3600IN  2607:f678::56
> ns1.raindrop.us.3600IN  RRSIG    5 3 3600
> 20120512011136
> 20120412010327 41190 raindrop.us.
> MhaOIt7D7kT8k4USk9Mpocw+tSx8WBSO/Yi+4F/YFV1ZVSXLKgYj4K4S
> hTjVTBD3tCQYMJY+SkArlkoQRyTk4QYrLV8CP2TvvdrUPjZUZNAEMsuk
> 0NWsd2tLgStZ34yN0Pe1xa9P2SZjvsXJj1D1N5JNFxfS/OFCwMa9Hvcr atM=
>
> ;; Query time: 253 msec
> ;; SERVER: 2607:f678:10::53#53(2607:f678:10::53)
> ;; WHEN: Tue Apr 17 23:29:08 2012
> ;; MSG SIZE  rcvd: 615
>
>
>
>
> ___
> Please visit https://lists.isc.org/mailman/listinfo/bind-users to
> unsubscribe from this list
>
> bind-users mailing list
> bind-users@lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users
>
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 

RE: testing validation

[Spain, Dr. Jeffry A.]

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

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

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

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

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

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

Re: testing bind9

[Eivind Olsen]

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 autoritativa
> Servidor: UnKnown
> Address: 192.168.0.19
>
> Nombre: elimparcial.com
> Address: 216.240.181.166

You got the same answer back, in the end. The error message you got about
192.168.0.19 non-existent domain is probably because you don't have a
reverse lookup zone for your internal subnet. It really isn't important,
even though nslookup tends to think it is.

In general, I'd recommend debugging/testing DNS lookups with a proper tool
like dig, and not nslookup which has a couple of snags which can easily
confuse more than it helps.

Regards
Eivind Olsen


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

Re: Testing my configuration

[Stephane Bortzmeyer]

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:

dig @your.name.server ANY dom.ain.name.example

would be more sensible.
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: Testing my configuration

[Peter Dambier]

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
> information pertaining to a specific domain name.
> 
> Currently I am using nslookup and dig, but I only seem to get basic
> information.
> 
> IE, dig domain.com only produces ns and A record information.
> I have done things like dig txt chaos domain.com
> 
> I am wanting to be able to see all entries, A,MX,PTR,CNAME,TXT,etc
> 
> Any comments would be most helpful.
> 
> Regards
> 
> Fred
> 
> 
> ___
> bind-users mailing list
> bind-users@lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users

-- 
Peter and Karin Dambier
Cesidian Root - Radice Cesidiana
Rimbacher Strasse 16
D-69509 Moerlenbach-Bonsweiher
+49(6209)795-816 (Telekom)
+49(6252)750-308 (VoIP: sipgate.de)
mail: pe...@peter-dambier.de
http://www.peter-dambier.de/
http://iason.site.voila.fr/
https://sourceforge.net/projects/iason/
ULA= fd80:4ce1:c66a::/48
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: Testing my configuration

[Josh Kuo]

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 all of the
> information pertaining to a specific domain name.
>
> Currently I am using nslookup and dig, but I only seem to get basic
> information.
>
> IE, dig domain.com only produces ns and A record information.
> I have done things like dig txt chaos domain.com
>
> I am wanting to be able to see all entries, A,MX,PTR,CNAME,TXT,etc
>
> Any comments would be most helpful.
>
> Regards
>
> Fred
>
>
> ___
> bind-users mailing list
> bind-users@lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users
>
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: Testing my configuration

[Holger Honert]

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 be requested
  by specifying a type of AXFR. When an incremental zone transfer 
(IXFR) is required, type is set to ixfr=N. The
  incremental zone transfer will contain the changes made to the 
zone since the serial number in the zone's SOA

  record was N.

HtH

Holger


Fred Zinsli schrieb:

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
information pertaining to a specific domain name.

Currently I am using nslookup and dig, but I only seem to get basic
information.

IE, dig domain.com only produces ns and A record information.
I have done things like dig txt chaos domain.com

I am wanting to be able to see all entries, A,MX,PTR,CNAME,TXT,etc

Any comments would be most helpful.

Regards

Fred


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


  




SIGNAL Krankenversicherung a. G.
Sitz: Dortmund, HR B 2405 AG Dortmund, Ust-IdNr. DE 124906350
IDUNA Vereinigte Lebensversicherung aG fur Handwerk, Handel und Gewerbe
Sitz: Hamburg, HR B 2740 AG Hamburg, Ust-IdNr. DE 118617622
SIGNAL Unfallversicherung a. G.
Sitz: Dortmund, HR B 2220, AG Dortmund, Ust-IdNr. DE 124906341
SIGNAL IDUNA Allgemeine Versicherung AG
Sitz: Dortmund, HR B 19108, AG Dortmund, Ust-IdNr. DE 118617622

Vorstande:
Reinhold Schulte (Vorsitzender), Dr. Karl-Josef Bierth, Michael Johnigk,
Ulrich Leitermann, Michael Petmecky, Dr. Klaus Sticker, Vorsitzender der
Aufsichtsrate: Gunter Kutz

SIGNAL IDUNA Gruppe Hauptverwaltungen, Internet: www.signal-iduna.de,
E-Mail: i...@signal-iduna.de

44121 Dortmund, Hausanschrift: Joseph-Scherer-Str. 3, 44139 Dortmund,
Telefon: (02 31) 1 35-0, Telefax: (02 31) 1 35-46 38

20351 Hamburg, Hausanschrift: Neue Rabenstra?e 15-19, 20354 Hamburg,
Telefon: (0 40) 41 24-0, Telefax: (0 40) 41 24-29 58
begin:vcard
fn:Holger Honert
n:Honert;Holger
org:SIGNAL IDUNA Gruppe;koms-97850
adr;dom:;;Joseph-Scherer-Str. 3;Dortmund;NRW;44139
email;internet:holger.hon...@signal-iduna.org
title:Dipl.-Ing. (FH)
tel;work:0231/135-4043
tel;fax:0231/135-2959
x-mozilla-html:FALSE
url:http://signal-iduna.de
version:2.1
end:vcard

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

Re: Testing my configuration

[Holger Honert]

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 be requested
  by specifying a type of AXFR. When an incremental zone transfer 
(IXFR) is required, type is set to ixfr=N. The
  incremental zone transfer will contain the changes made to the 
zone since the serial number in the zone's SOA

  record was N.

HtH

Holger


Fred Zinsli schrieb:

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
information pertaining to a specific domain name.

Currently I am using nslookup and dig, but I only seem to get basic
information.

IE, dig domain.com only produces ns and A record information.
I have done things like dig txt chaos domain.com

I am wanting to be able to see all entries, A,MX,PTR,CNAME,TXT,etc

Any comments would be most helpful.

Regards

Fred


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


  




SIGNAL Krankenversicherung a. G.
Sitz: Dortmund, HR B 2405 AG Dortmund, Ust-IdNr. DE 124906350
IDUNA Vereinigte Lebensversicherung aG fur Handwerk, Handel und Gewerbe
Sitz: Hamburg, HR B 2740 AG Hamburg, Ust-IdNr. DE 118617622
SIGNAL Unfallversicherung a. G.
Sitz: Dortmund, HR B 2220, AG Dortmund, Ust-IdNr. DE 124906341
SIGNAL IDUNA Allgemeine Versicherung AG
Sitz: Dortmund, HR B 19108, AG Dortmund, Ust-IdNr. DE 118617622

Vorstande:
Reinhold Schulte (Vorsitzender), Dr. Karl-Josef Bierth, Michael Johnigk,
Ulrich Leitermann, Michael Petmecky, Dr. Klaus Sticker, Vorsitzender der
Aufsichtsrate: Gunter Kutz

SIGNAL IDUNA Gruppe Hauptverwaltungen, Internet: www.signal-iduna.de,
E-Mail: i...@signal-iduna.de

44121 Dortmund, Hausanschrift: Joseph-Scherer-Str. 3, 44139 Dortmund,
Telefon: (02 31) 1 35-0, Telefax: (02 31) 1 35-46 38

20351 Hamburg, Hausanschrift: Neue Rabenstra?e 15-19, 20354 Hamburg,
Telefon: (0 40) 41 24-0, Telefax: (0 40) 41 24-29 58
begin:vcard
fn:Holger Honert
n:Honert;Holger
org:SIGNAL IDUNA Gruppe;koms-97850
adr;dom:;;Joseph-Scherer-Str. 3;Dortmund;NRW;44139
email;internet:holger.hon...@signal-iduna.org
title:Dipl.-Ing. (FH)
tel;work:0231/135-4043
tel;fax:0231/135-2959
x-mozilla-html:FALSE
url:http://signal-iduna.de
version:2.1
end:vcard

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