Unbound(8) caching resolver no workie on fresh install :-(

classic Classic list List threaded Threaded
14 messages Options
Reply | Threaded
Open this post in threaded view
|

Unbound(8) caching resolver no workie on fresh install :-(

Ronald F. Guilmette-2

I just installed a fresh 11.1-RELEASE system onto a pristine drive.
(Be patient with me please.  I haven't done this in a long while.)

All seems to be working well, however I noticed the new install option
to enable a local caching resolver, and I said to myself "Yea!  Sounds
great to me!"  So I enabled that.

After the install finished and I booted the new system, I immediately
got some console errors indicating that the various default NTP servers
(I also enabled NTP) were not resolving. :-(

So, um, what gives?  This particular machine is, for the moment, NAT'd/DHCP'd
behind my trusty Linksys E4200.  Do I need to poke a hole in that so that the
UDP DNS query replies can actually make it all the way back to this box?
Or is there something I need to diddle under /etc/unbound that isn't just
ready to go, out of the box?
_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: Unbound(8) caching resolver no workie on fresh install :-(

Matthew Seaman-5
On 12/10/2017 05:57, Ronald F. Guilmette wrote:

>
> I just installed a fresh 11.1-RELEASE system onto a pristine drive.
> (Be patient with me please.  I haven't done this in a long while.)
>
> All seems to be working well, however I noticed the new install option
> to enable a local caching resolver, and I said to myself "Yea!  Sounds
> great to me!"  So I enabled that.
>
> After the install finished and I booted the new system, I immediately
> got some console errors indicating that the various default NTP servers
> (I also enabled NTP) were not resolving. :-(
>
> So, um, what gives?  This particular machine is, for the moment, NAT'd/DHCP'd
> behind my trusty Linksys E4200.  Do I need to poke a hole in that so that the
> UDP DNS query replies can actually make it all the way back to this box?
> Or is there something I need to diddle under /etc/unbound that isn't just
> ready to go, out of the box?

This is something I've observed too -- it's an ordering or timing
problem with the startup scripts -- ie. ntpd(8) gets started before
local_unbound is properly ready to answer queries.

However, the effect is largely cosmetic.  ntpd will complain about
resolving server names on startup, but as soon as unbound gets going,
ntpd should connect and sync up.

I suspect you were being misled by the other problem you posted about
where ntpd was dying shortly after startup because the clock was way off
-- these error messages are not related to why ntpd is failing.

As for local_unbound, if you can resolve hostnames into IP numbers 'host
www.freebsd.org'  from the command line, then you can be pretty sure
that local_unbound is working OK.  local_unbound defaults to using any
resolvers found in /etc/resolv.conf as forwarders -- so if your local
DHCP server says to use a specific resolver, it will -- but you can
override that by setting local_unbound_forwarders in /etc/rc.conf to a
list of IP numbers for the DNS resolvers you'ld like to use.
local_unbound will in fact work perfectly happily without any
forwarders, but there isn't a flag to force that behaviour.

        Cheers,

        Matthew
_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: Unbound(8) caching resolver no workie on fresh install :-(

Ernie Luzar
Matthew Seaman wrote:

> On 12/10/2017 05:57, Ronald F. Guilmette wrote:
>> I just installed a fresh 11.1-RELEASE system onto a pristine drive.
>> (Be patient with me please.  I haven't done this in a long while.)
>>
>> All seems to be working well, however I noticed the new install option
>> to enable a local caching resolver, and I said to myself "Yea!  Sounds
>> great to me!"  So I enabled that.
>>
>> After the install finished and I booted the new system, I immediately
>> got some console errors indicating that the various default NTP servers
>> (I also enabled NTP) were not resolving. :-(
>>
>> So, um, what gives?  This particular machine is, for the moment, NAT'd/DHCP'd
>> behind my trusty Linksys E4200.  Do I need to poke a hole in that so that the
>> UDP DNS query replies can actually make it all the way back to this box?
>> Or is there something I need to diddle under /etc/unbound that isn't just
>> ready to go, out of the box?
>
> This is something I've observed too -- it's an ordering or timing
> problem with the startup scripts -- ie. ntpd(8) gets started before
> local_unbound is properly ready to answer queries.
>
> However, the effect is largely cosmetic.  ntpd will complain about
> resolving server names on startup, but as soon as unbound gets going,
> ntpd should connect and sync up.
>
> I suspect you were being misled by the other problem you posted about
> where ntpd was dying shortly after startup because the clock was way off
> -- these error messages are not related to why ntpd is failing.
>
> As for local_unbound, if you can resolve hostnames into IP numbers 'host
> www.freebsd.org'  from the command line, then you can be pretty sure
> that local_unbound is working OK.  local_unbound defaults to using any
> resolvers found in /etc/resolv.conf as forwarders -- so if your local
> DHCP server says to use a specific resolver, it will -- but you can
> override that by setting local_unbound_forwarders in /etc/rc.conf to a
> list of IP numbers for the DNS resolvers you'ld like to use.
> local_unbound will in fact work perfectly happily without any
> forwarders, but there isn't a flag to force that behavior.
>
> Cheers,
>
> Matthew

unbound has a built-in "root-zone" function which negates the need for a
forward-zone: section at all. Is there a rc.conf parameter to enable
that function for local_unbound?

_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: Unbound(8) caching resolver no workie on fresh install :-(

Erwan Legrand
In reply to this post by Ronald F. Guilmette-2
On Thu, Oct 12, 2017 at 6:57 AM, Ronald F. Guilmette
<[hidden email]> wrote:
> After the install finished and I booted the new system, I immediately
> got some console errors indicating that the various default NTP servers
> (I also enabled NTP) were not resolving. :-(

This could happen if you forward queries to servers which strip DNSSEC
signatures. If that is the case, you have two options: either you stop
forwarding to these servers or your disable the DNSSEC support in
Unbound.
_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: Unbound(8) caching resolver no workie on fresh install :-(

Ronald F. Guilmette-2

In message <CA+4G5KY727cJ=[hidden email]>
Erwan Legrand <[hidden email]> wrote:

>On Thu, Oct 12, 2017 at 6:57 AM, Ronald F. Guilmette
><[hidden email]> wrote:
>> After the install finished and I booted the new system, I immediately
>> got some console errors indicating that the various default NTP servers
>> (I also enabled NTP) were not resolving. :-(
>
>This could happen if you forward queries to servers which strip DNSSEC
>signatures. If that is the case, you have two options: either you stop
>forwarding to these servers or your disable the DNSSEC support in
>Unbound.

OK, this is a little bit confusing to me, so please bear with me...

My *router* (Linksys E4200) has been configured to tell DHCP clients
to use the two public name servers of OpenDNS, i.e. 208.67.222.222
and 208.67.220.220.

However I'm unclear on what, if anything, this ha to do with the Unbound(8)
caching resolver.

During this (fresh) install, I -never- explicitly selected any option that
would obcviously hav the effect of telling unbound to forward/route all
of its DNS queries through any other specific name servers).  So why on
earth would it be doing so?

I mean I -thought- that this was (mostly) the whole point of running a
local caching resolver, i.e. that *it* would do all of the DNS lookups
itself, traversing/descending its way, as necessary, down from the root
zone servers until it found what it was looking for.

I don't know if the OpenDNS server strip DNSSEC stuff or not, but again,
I don't see why Unbound(8) should even be using those servers anyway.
Just because my router is giving those two specific IPv4 addresses to
each of its DHCP clients, that doesn't mean that any of those clients
are in any way forced to use them.  And I don't see why Unbound(8) would
be doing so.

If it isn't, and if unbound is, as I believed, traversing the DNS tree itself,
starting from the root each time, then there is nobody and nothing between
it and the authoritative servers for whatever it happens to be looking
for -- thus, no filtering of DNSSEC, and thus, the resolutions failures
I described are still mysterious... to me anyway.

What am I missing?
_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: Unbound(8) caching resolver no workie on fresh install :-(

Baho Utot


On 10/12/2017 12:58 PM, Ronald F. Guilmette wrote:

> In message <CA+4G5KY727cJ=[hidden email]>
> Erwan Legrand <[hidden email]> wrote:
>
>> On Thu, Oct 12, 2017 at 6:57 AM, Ronald F. Guilmette
>> <[hidden email]> wrote:
>>> After the install finished and I booted the new system, I immediately
>>> got some console errors indicating that the various default NTP servers
>>> (I also enabled NTP) were not resolving. :-(
>> This could happen if you forward queries to servers which strip DNSSEC
>> signatures. If that is the case, you have two options: either you stop
>> forwarding to these servers or your disable the DNSSEC support in
>> Unbound.
> OK, this is a little bit confusing to me, so please bear with me...
>
> My *router* (Linksys E4200) has been configured to tell DHCP clients
> to use the two public name servers of OpenDNS, i.e. 208.67.222.222
> and 208.67.220.220.
>
> However I'm unclear on what, if anything, this ha to do with the Unbound(8)
> caching resolver.
>
> During this (fresh) install, I -never- explicitly selected any option that
> would obcviously hav the effect of telling unbound to forward/route all
> of its DNS queries through any other specific name servers).  So why on
> earth would it be doing so?

Because the base system uses unbound as the resolver.

>
> I mean I -thought- that this was (mostly) the whole point of running a
> local caching resolver, i.e. that *it* would do all of the DNS lookups
> itself, traversing/descending its way, as necessary, down from the root
> zone servers until it found what it was looking for.
>
> I don't know if the OpenDNS server strip DNSSEC stuff or not, but again,
> I don't see why Unbound(8) should even be using those servers anyway.
> Just because my router is giving those two specific IPv4 addresses to
> each of its DHCP clients, that doesn't mean that any of those clients
> are in any way forced to use them.  And I don't see why Unbound(8) would
> be doing so.
>
> If it isn't, and if unbound is, as I believed, traversing the DNS tree itself,
> starting from the root each time, then there is nobody and nothing between
> it and the authoritative servers for whatever it happens to be looking
> for -- thus, no filtering of DNSSEC, and thus, the resolutions failures
> I described are still mysterious... to me anyway.
>
> What am I missing?
> _______________________________________________
> [hidden email] mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-questions
> To unsubscribe, send any mail to "[hidden email]"

_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: Unbound(8) caching resolver no workie on fresh install :-(

freebsd-questions mailing list
On Thu, 12 Oct 2017 17:31:32 -0400
Baho Utot wrote:

> On 10/12/2017 12:58 PM, Ronald F. Guilmette wrote:

> > During this (fresh) install, I -never- explicitly selected any
> > option that would obcviously hav the effect of telling unbound to
> > forward/route all of its DNS queries through any other specific
> > name servers).  So why on earth would it be doing so?  
>
> Because the base system uses unbound as the resolver.

That doesn't explain why it forwards by default.

Is ISP cache poisoning entirely a thing of the past? IIRC there are
also attacks where a DSL router is hacked and reconfigured to give bogus
DNS servers via DHCP.

There's also the issue that mail servers should avoid using shared
caches because of per IP address limits on blocklists. Linux resolver
packages that set-up forwarding without making it clear have been a
problem for a while now.



 
_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: Unbound(8) caching resolver no workie on fresh install :-(

CyberLeo Kitsana
On 10/14/2017 04:43 PM, RW via freebsd-questions wrote:

> On Thu, 12 Oct 2017 17:31:32 -0400
> Baho Utot wrote:
>
>> On 10/12/2017 12:58 PM, Ronald F. Guilmette wrote:
>
>>> During this (fresh) install, I -never- explicitly selected any
>>> option that would obcviously hav the effect of telling unbound to
>>> forward/route all of its DNS queries through any other specific
>>> name servers).  So why on earth would it be doing so?  
>>
>> Because the base system uses unbound as the resolver.
>
> That doesn't explain why it forwards by default.

FreeBSD's local_unbound setup will, by default, forward to the
nameservers provided by DHCP or hardcoded in the config files, rather
than doing full lookups by itself. See below for why this is safe.

> Is ISP cache poisoning entirely a thing of the past? IIRC there are
> also attacks where a DSL router is hacked and reconfigured to give bogus
> DNS servers via DHCP.

Properly implemented DNSSEC mitigates cache-poisoning or DNS redirection
attacks, as any answers not properly signed by the authority for the
name you're looking up (and every parent up to the root zone) will be
rejected. The name will simply fail to resolve, rather than returning
corrupt, forged, or tampered results.

FreeBSD implemented local_unbound specifically to add DNSSEC validation
to machines that rely on external recursing nameservers, like those
provided by your ISP. DNSSEC is slow, as any given validation requires
many lookups and cryptographic operations to chain the signature to a
trusted root, so any local caching is beneficial. Offloading the
validation to a single local caching daemon is much easier and less
error-prone than dealing with the complexities of adding validation and
cache management to a library that is loaded into pretty much every
process on your machine.

> There's also the issue that mail servers should avoid using shared
> caches because of per IP address limits on blocklists. Linux resolver
> packages that set-up forwarding without making it clear have been a
> problem for a while now.
--
Fuzzy love,
-CyberLeo

<[hidden email]>
Technical Administrator

CyberLeo.Net Webhosting
http://www.CyberLeo.Net

Element9 Communications
http://www.Element9.net


Furry Peace! - http://www.fur.com/peace/
_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: Unbound(8) caching resolver no workie on fresh install :-(

freebsd-questions mailing list
On Sat, 14 Oct 2017 18:08:27 -0500
CyberLeo Kitsana wrote:

> On 10/14/2017 04:43 PM, RW via freebsd-questions wrote:

> FreeBSD's local_unbound setup will, by default, forward to the
> nameservers provided by DHCP or hardcoded in the config files, rather
> than doing full lookups by itself.

But is it possible to force recursion (for the reason below).
Matthew Seaman implied that it wasn't.  

The reason I ask is that I'm still using DJB dnscache, and should
probably be using something more modern; and something in base would be
preferable.


> > There's also the issue that mail servers should avoid using shared
> > caches because of per IP address limits on blocklists.
_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: Unbound(8) caching resolver no workie on fresh install :-(

Matthew Seaman-5
On 15/10/2017 01:10, RW via freebsd-questions wrote:

> On Sat, 14 Oct 2017 18:08:27 -0500
> CyberLeo Kitsana wrote:
>
>> On 10/14/2017 04:43 PM, RW via freebsd-questions wrote:
>
>> FreeBSD's local_unbound setup will, by default, forward to the
>> nameservers provided by DHCP or hardcoded in the config files, rather
>> than doing full lookups by itself.
>
> But is it possible to force recursion (for the reason below).
> Matthew Seaman implied that it wasn't.  
I didn't say it was impossible.  I said that there wasn't a simple flag
you could set to enforce that behaviour.

The way you prevent local_unbound from using forwarders is to not have
any forwarders configured anywhere local_unbound can find them.
Basically that means:

   * no local_unbound_forwarders setting in /etc/rc.conf
   * no nameserver lines in /etc/resolv.conf
   * if you need to use DHCP, then you'ld need to add settings to
     /etc/dhclient.conf to supersede the supplied DNS servers with
     an empty list.

> The reason I ask is that I'm still using DJB dnscache, and should
> probably be using something more modern; and something in base would be
> preferable.

Something that supports DNSSEC would be preferable, although that does
presuppose that the rest of the internet gets off its collective
backside and implements DNSSEC routinely.  How short memories are --
remember the fuss over the Kaminsky attack?  That was never actually
"solved" by the work-arounds given in the security advisories at the
time, just made significantly less likely to succeed.  The real fix was
always enabling DNSSEC everywhere.  Does _your_ bank use DNSSEC?

Hey, at least you could be assured that no-one is spoofing freebsd.org...

>>> There's also the issue that mail servers should avoid using shared
>>> caches because of per IP address limits on blocklists.

Anyone operating a mail server at reasonable scale has no excuse for not
paying for the service that blocklist providers provide, in which case,
the same per-IP limits will not apply.

        Cheers,

        Matthew


signature.asc (949 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Unbound(8) caching resolver no workie on fresh install :-(

Frank Shute-3
In reply to this post by Ronald F. Guilmette-2
On Thu, Oct 12, 2017 at 09:58:25AM -0700, Ronald F. Guilmette wrote:

>
>
> In message <CA+4G5KY727cJ=[hidden email]>
> Erwan Legrand <[hidden email]> wrote:
>
> >On Thu, Oct 12, 2017 at 6:57 AM, Ronald F. Guilmette
> ><[hidden email]> wrote:
> >> After the install finished and I booted the new system, I immediately
> >> got some console errors indicating that the various default NTP servers
> >> (I also enabled NTP) were not resolving. :-(
> >
> >This could happen if you forward queries to servers which strip DNSSEC
> >signatures. If that is the case, you have two options: either you stop
> >forwarding to these servers or your disable the DNSSEC support in
> >Unbound.
>
> OK, this is a little bit confusing to me, so please bear with me...
>
> My *router* (Linksys E4200) has been configured to tell DHCP clients
> to use the two public name servers of OpenDNS, i.e. 208.67.222.222
> and 208.67.220.220.
>
> However I'm unclear on what, if anything, this ha to do with the Unbound(8)
> caching resolver.
If you're going to run unbound(8) then you want to tell your DHCP clients
to use the local IP of the box unbound is running on. ie. a local (what
used to be known as a 'Class C') address: 192.168.*.* or 10.*.*.* or
176...etc.

ATM, all your clients are going out on the 'net to the OpenDNS servers for
name resolution.

What you need to do on the box running unbound, is configure
your dhclient.conf(5) on that machine to have the following in it:

interface "re0"{
prepend domain-name-servers 127.0.0.1;
}

Obviously, you may need to change "re0" to whatever NIC you use.

For other clients on the LAN, I'd suggest you configure the dhcp server on
your router to give them the local address of your unbound machine as the
nameserver followed by something out on the 'net in-case your unbound
machine goes down.

In unbound.conf(5) you need:

forward-zone:
      name: "."
      forward-addr: 208.67.222.222  # OpenDNS
      forward-addr: 208.67.220.220  # OpenDNS

Personally, I prefer to use my ISP's nameservers. They're closer and no
shenanigans.

It's also worth grabbing root.hints:

# fetch https://www.internic.net/domain/named.root -o /var/unbound/named.root
# chown unbound:wheel /var/unbound/named.root

(maybe make it a monthly cron job)

and in unbound.conf you need:

server:
        root-hints: "/var/unbound/named.root"


>
> During this (fresh) install, I -never- explicitly selected any option that
> would obcviously hav the effect of telling unbound to forward/route all
> of its DNS queries through any other specific name servers).  So why on
> earth would it be doing so?
>
> I mean I -thought- that this was (mostly) the whole point of running a
> local caching resolver, i.e. that *it* would do all of the DNS lookups
> itself, traversing/descending its way, as necessary, down from the root
> zone servers until it found what it was looking for.
>
> I don't know if the OpenDNS server strip DNSSEC stuff or not, but again,
> I don't see why Unbound(8) should even be using those servers anyway.
> Just because my router is giving those two specific IPv4 addresses to
> each of its DHCP clients, that doesn't mean that any of those clients
> are in any way forced to use them.  And I don't see why Unbound(8) would
> be doing so.
My understanding is that if you negotiate a lease from a dhcp server and
it's configured to tell you which nameserver(s) to use, then by default
your resolv.conf will be overwritten with the IPs of those nameserver(s)
and the client's resolver will use them. Have a look at resolvconf(8) &
the manpages referenced in the 'SEE ALSO:' of that manpage.

Of course, you can change that behaviour.

>
> If it isn't, and if unbound is, as I believed, traversing the DNS tree itself,
> starting from the root each time, then there is nobody and nothing between
> it and the authoritative servers for whatever it happens to be looking
> for -- thus, no filtering of DNSSEC, and thus, the resolutions failures
> I described are still mysterious... to me anyway.
>
> What am I missing?

I can't tell you about DNSSEC because I don't use it.


Regards,

--

Frank



signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Unbound(8) caching resolver no workie on fresh install :-(

Jon Radel
On 10/15/17 13:26, Frank Shute wrote:
> the local IP of the box unbound is running on. ie. a local (what
> used to be known as a 'Class C') address: 192.168.*.* or 10.*.*.* or
> 176...etc.
No, still known as a private or RFC 1918 address.  Class C is something
quite different.  As a matter of fact,

192.168.0.0/16 is 256 Class Cs
172.16.0.0/12 is 16 Class Bs
10.0.0.0/8 is 1 Class A

You are completely correct, however, that this is mainly of historical
interest and has no immediate impact.  Even when RFC 1918 was published,
referring to the addresses classes was referred to as an essentially
obsolete "pre-CIDR notation."

To bring some substance to this comment:  changing 172.16.0.0/12 to
"176...etc" is just asking for trouble, being wrong.

--
--Jon Radel
[hidden email]



smime.p7s (5K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Unbound(8) caching resolver no workie on fresh install :-(

Frank Shute-3
On Sun, Oct 15, 2017 at 04:30:25PM -0400, Jon Radel wrote:

>
> On 10/15/17 13:26, Frank Shute wrote:
> > the local IP of the box unbound is running on. ie. a local (what
> > used to be known as a 'Class C') address: 192.168.*.* or 10.*.*.* or
> > 176...etc.
>
> No, still known as a private or RFC 1918 address.  Class C is something
> quite different.  As a matter of fact,
>
> 192.168.0.0/16 is 256 Class Cs
> 172.16.0.0/12 is 16 Class Bs
> 10.0.0.0/8 is 1 Class A
Thanks for putting me straight Jon. From now on I'll use the correct
nomenclature. I can remember the number of that RFC.

>
> You are completely correct, however, that this is mainly of historical
> interest and has no immediate impact.  Even when RFC 1918 was published,
> referring to the addresses classes was referred to as an essentially
> obsolete "pre-CIDR notation."
>
> To bring some substance to this comment:  changing 172.16.0.0/12 to
> "176...etc" is just asking for trouble, being wrong.

Quite right. My memory is not as good as I thought and in future I will
check my 'facts'.

We shouldn't have to know all this stuff nowadays as we're all meant to
have moved to IPv6 aren't we? ;)


>
> --
> --Jon Radel
> [hidden email]
>
>


Regards,

--

Frank



signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Unbound(8) caching resolver no workie on fresh install :-(

Jon Radel
On 10/15/17 19:57, Frank Shute wrote:
> We shouldn't have to know all this stuff nowadays as we're all meant to
> have moved to IPv6 aren't we? ;)
>
Bwaaahahaha.

I started a new job in charge of a production network about a month
ago.  Early on I asked, "So are there any plans for ipv6 roll-out yet?" 
The answer, as I expected, was basically, "Not so much."

--
--Jon Radel
[hidden email]



smime.p7s (5K) Download Attachment