Re: ntpd.conf.5 duplicate word

2021-01-06 Thread Jason McIntyre
On Wed, Jan 06, 2021 at 08:53:04PM +0800, Sean Davies wrote:
> Index: ntpd.conf.5
> ===
> RCS file: /cvs/src/usr.sbin/ntpd/ntpd.conf.5,v
> retrieving revision 1.46
> diff -u -p -u -r1.46 ntpd.conf.5
> --- ntpd.conf.5   16 May 2020 16:58:12 -0000  1.46
> +++ ntpd.conf.5   6 Jan 2021 12:41:49 -
> @@ -119,7 +119,7 @@ sensor udcf0 correction 7
>  A
>  .Ic refid
>  .Ar ID-string
> -of up up to 4 ASCII characters can be
> +of up to 4 ASCII characters can be
>  given to publish the sensor type to clients.
>  RFC 2030 suggests some common reference identifiers, but new identifiers
>  "can be contrived as appropriate."
> 
> -- 
> Sean
> 

fixed, thanks.
jmc



ntpd.conf.5 duplicate word

2021-01-06 Thread Sean Davies
Index: ntpd.conf.5
===
RCS file: /cvs/src/usr.sbin/ntpd/ntpd.conf.5,v
retrieving revision 1.46
diff -u -p -u -r1.46 ntpd.conf.5
--- ntpd.conf.5 16 May 2020 16:58:12 -  1.46
+++ ntpd.conf.5 6 Jan 2021 12:41:49 -
@@ -119,7 +119,7 @@ sensor udcf0 correction 7
 A
 .Ic refid
 .Ar ID-string
-of up up to 4 ASCII characters can be
+of up to 4 ASCII characters can be
 given to publish the sensor type to clients.
 RFC 2030 suggests some common reference identifiers, but new identifiers
 "can be contrived as appropriate."

-- 
Sean



Re: [PATCH] correcting in-sane ntpd.conf

2019-12-09 Thread Theo de Raadt
Tim Kuijsten  wrote:

> > Nor do you bring up the traffic to the IP addresses offered by
> > pool.ntp.org.  That traffic has a pattern easily distinguished as
> > "system startup".
> > 
> > What's the difference?  There isn't.  Yet you brought up only google.
> 
> I can understand why someone would be ok with sending some packets
> to small players like pool.ntp.org and not be ok with sending packets
> to extremely big and powerful companies that are in the business
> of surveillance capitalism. Divide and conquer!

So you have no justification at all.



Re: [PATCH] correcting in-sane ntpd.conf

2019-12-09 Thread Stuart Henderson
On 2019/12/09 13:16, Tim Kuijsten wrote:
> > Nor do you bring up the traffic to the IP addresses offered by
> > pool.ntp.org.  That traffic has a pattern easily distinguished as
> > "system startup".
> > 
> > What's the difference?  There isn't.  Yet you brought up only google.
> 
> I can understand why someone would be ok with sending some packets
> to small players like pool.ntp.org and not be ok with sending packets
> to extremely big and powerful companies that are in the business
> of surveillance capitalism. Divide and conquer!
> 

I don't see how pool.ntp.org can be described as a small player when it
comes to public NTP servers? 3 of the 4 hosts I currently get from them
are large transit ISPs (NTT, TATA, Interoute). Plus of course you have no
idea in advance who you are getting.

If you are concerned about people using this information to evaluate
things like how many machines you have running OpenBSD or how often they
reboot, run your own NTP server with an internet upstream and point
clients there. Or if you don't want people on the network path between
you and public NTP servers to figure out that you're running OpenBSD at
all from your time queries, GNSS modules are pretty cheap nowadays so
you can run your own stratum 1 easily enough.



Re: [PATCH] correcting in-sane ntpd.conf

2019-12-09 Thread Tim Kuijsten
> Nor do you bring up the traffic to the IP addresses offered by
> pool.ntp.org.  That traffic has a pattern easily distinguished as
> "system startup".
> 
> What's the difference?  There isn't.  Yet you brought up only google.

I can understand why someone would be ok with sending some packets
to small players like pool.ntp.org and not be ok with sending packets
to extremely big and powerful companies that are in the business
of surveillance capitalism. Divide and conquer!



Re: [PATCH] correcting in-sane ntpd.conf

2019-12-08 Thread Theo de Raadt
>I meant that as a privacy concern that some users might not be aware of.

What privacy concern?

You don't bring up privacy concerns with DNS lookup of pool.ntp.org.

Nor do you bring up the traffic to the IP addresses offered by
pool.ntp.org.  That traffic has a pattern easily distinguished as
"system startup".

What's the difference?  There isn't.  Yet you brought up only google.

If you don't want people to know you are running a ntp server, then
don't run a ntp server.

>As a way of solving that problem one could suggest and point a finger
>explicitly on the default ntpd.conf. 

Unless there are great reasons to do otherwise, we ship turn-key
systems.

>Reasons ? A privacy concern that most users won't be aware of. 

>I might have understood you wrong, otto. Please correct me. 

I think you are tilting at windmills.



Re: [PATCH] correcting in-sane ntpd.conf

2019-12-08 Thread List
I meant that as a privacy concern that some users might not be aware of.
As a way of solving that problem one could suggest and point a finger
explicitly on the default ntpd.conf. 

Reasons ? A privacy concern that most users won't be aware of. 

I might have understood you wrong, otto. Please correct me. 

g Stephan

On Sun, Dec 08, 2019 at 10:36:18AM +0100, Otto Moerbeek wrote:
> On Sun, Dec 08, 2019 at 11:15:55AM +0100, List wrote:
> 
> > Please excuse that I wasted your time. You're absolutely right.
> > 
> > The only thing that comes to my mind is that one could add something
> > like a small notice that tells the new user to maybe alter his ntpd
> > constraints to a "TLS-Provider" that resides in his time zone. 
> > A good place for that could be the welcoming mail, which already
> > describes some first steps. 
> 
> Why? You can travel the internet many times around and still be withing
> the bounds the constraint checking allows. As for response time, google
> anycast is pretty good at that.
> 
>   -Otto
> 
> > 
> > 
> > On Sat, Dec 07, 2019 at 11:25:48AM -0700, Theo de Raadt wrote:
> > > >That might be the case. 
> > > >The man page creates the impression that my ntpd will carry out a TLS
> > > >Handshake with "https://www.google.com;. Out of that handshake (because
> > > >it is anycast) you get your approximate local time. Which serves as
> > > >vague measuring point for answers by the ntp servers that you are
> > > >querying. But the suggestion I made is absolutely 100 % wrong.
> > > >
> > > >Would it be an option to choose another Anycast resolving address ?
> > > >For example akami.net ? 
> > > 
> > > akami.net has no https.
> > > maybe you mean akamai.net?  again, no https.
> > > 
> > > many akamai services come out of less capable caches, not making the
> > > same effective certificate promises as the google front-end.  would
> > > you notice if an akamai service did a certificate downgrade? not
> > > really.  i don't think the proposal is serious.
> > > 
> > > as a result we use quad9 and google https because their global
> > > adjacency is excellent, and then we are avoiding cloudflare https
> > > because we added their ticker in the mix (though their anycast ticker
> > > is a very weird thing)
> > > 
> > > >g Stephan
> > > >
> > > >On Thu, Dec 05, 2019 at 03:03:43PM -0700, Theo de Raadt wrote:
> > > >> I guess you don't understand what is going on there.
> > > >> 
> > > >> List  wrote:
> > > >> 
> > > >> > Hello, 
> > > >> > 
> > > >> > here a diff replacing www.google.com as a default time constraint by
> > > >> > www.openbsd.org.
> > > >> > It is claimed that OpenBSD would have sane and secure defaults. While
> > > >> > www.google.com might be secure it ain't sane from a privacy concerned
> > > >> > perspective. Therefore the diff. 
> > > >> > 
> > > >> > Regards,
> > > >> > Stephan
> > > >> > 
> > > >> > Index: etc/ntpd.conf
> > > >> > ===
> > > >> > RCS file: /cvs/src/etc/ntpd.conf,v
> > > >> > retrieving revision 1.16
> > > >> > diff -u -p -r1.16 ntpd.conf
> > > >> > --- etc/ntpd.conf   6 Nov 2019 19:04:12 -   1.16
> > > >> > +++ etc/ntpd.conf   5 Dec 2019 21:36:57 -
> > > >> > @@ -8,4 +8,4 @@ sensor *
> > > >> >  
> > > >> >   constraint from "9.9.9.9"  # quad9 v4 without DNS
> > > >> >constraint from "2620:fe::fe"  # quad9 v6 without DNS
> > > >> >-constraints from "www.google.com"  # intentionally not 
> > > >> > 8.8.8.8
> > > >> >+constraints from "www.openbsd.org"  # intentionally not 
> > > >> > Google
> > > >> > 
> > > >> 
> > > >
> > 
> 



Re: [PATCH] correcting in-sane ntpd.conf

2019-12-08 Thread Otto Moerbeek
On Sun, Dec 08, 2019 at 11:15:55AM +0100, List wrote:

> Please excuse that I wasted your time. You're absolutely right.
> 
> The only thing that comes to my mind is that one could add something
> like a small notice that tells the new user to maybe alter his ntpd
> constraints to a "TLS-Provider" that resides in his time zone. 
> A good place for that could be the welcoming mail, which already
> describes some first steps. 

Why? You can travel the internet many times around and still be withing
the bounds the constraint checking allows. As for response time, google
anycast is pretty good at that.

-Otto

> 
> 
> On Sat, Dec 07, 2019 at 11:25:48AM -0700, Theo de Raadt wrote:
> > >That might be the case. 
> > >The man page creates the impression that my ntpd will carry out a TLS
> > >Handshake with "https://www.google.com;. Out of that handshake (because
> > >it is anycast) you get your approximate local time. Which serves as
> > >vague measuring point for answers by the ntp servers that you are
> > >querying. But the suggestion I made is absolutely 100 % wrong.
> > >
> > >Would it be an option to choose another Anycast resolving address ?
> > >For example akami.net ? 
> > 
> > akami.net has no https.
> > maybe you mean akamai.net?  again, no https.
> > 
> > many akamai services come out of less capable caches, not making the
> > same effective certificate promises as the google front-end.  would
> > you notice if an akamai service did a certificate downgrade? not
> > really.  i don't think the proposal is serious.
> > 
> > as a result we use quad9 and google https because their global
> > adjacency is excellent, and then we are avoiding cloudflare https
> > because we added their ticker in the mix (though their anycast ticker
> > is a very weird thing)
> > 
> > >g Stephan
> > >
> > >On Thu, Dec 05, 2019 at 03:03:43PM -0700, Theo de Raadt wrote:
> > >> I guess you don't understand what is going on there.
> > >> 
> > >> List  wrote:
> > >> 
> > >> > Hello, 
> > >> > 
> > >> > here a diff replacing www.google.com as a default time constraint by
> > >> > www.openbsd.org.
> > >> > It is claimed that OpenBSD would have sane and secure defaults. While
> > >> > www.google.com might be secure it ain't sane from a privacy concerned
> > >> > perspective. Therefore the diff. 
> > >> > 
> > >> > Regards,
> > >> > Stephan
> > >> > 
> > >> > Index: etc/ntpd.conf
> > >> > ===
> > >> > RCS file: /cvs/src/etc/ntpd.conf,v
> > >> > retrieving revision 1.16
> > >> > diff -u -p -r1.16 ntpd.conf
> > >> > --- etc/ntpd.conf   6 Nov 2019 19:04:12 -   1.16
> > >> > +++ etc/ntpd.conf   5 Dec 2019 21:36:57 -
> > >> > @@ -8,4 +8,4 @@ sensor *
> > >> >  
> > >> >   constraint from "9.9.9.9"  # quad9 v4 without DNS
> > >> >constraint from "2620:fe::fe"  # quad9 v6 without DNS
> > >> >-constraints from "www.google.com"  # intentionally not 8.8.8.8
> > >> >+constraints from "www.openbsd.org"  # intentionally not Google
> > >> > 
> > >> 
> > >
> 



Re: [PATCH] correcting in-sane ntpd.conf

2019-12-08 Thread List
Please excuse that I wasted your time. You're absolutely right.

The only thing that comes to my mind is that one could add something
like a small notice that tells the new user to maybe alter his ntpd
constraints to a "TLS-Provider" that resides in his time zone. 
A good place for that could be the welcoming mail, which already
describes some first steps. 


On Sat, Dec 07, 2019 at 11:25:48AM -0700, Theo de Raadt wrote:
> >That might be the case. 
> >The man page creates the impression that my ntpd will carry out a TLS
> >Handshake with "https://www.google.com;. Out of that handshake (because
> >it is anycast) you get your approximate local time. Which serves as
> >vague measuring point for answers by the ntp servers that you are
> >querying. But the suggestion I made is absolutely 100 % wrong.
> >
> >Would it be an option to choose another Anycast resolving address ?
> >For example akami.net ? 
> 
> akami.net has no https.
> maybe you mean akamai.net?  again, no https.
> 
> many akamai services come out of less capable caches, not making the
> same effective certificate promises as the google front-end.  would
> you notice if an akamai service did a certificate downgrade? not
> really.  i don't think the proposal is serious.
> 
> as a result we use quad9 and google https because their global
> adjacency is excellent, and then we are avoiding cloudflare https
> because we added their ticker in the mix (though their anycast ticker
> is a very weird thing)
> 
> >g Stephan
> >
> >On Thu, Dec 05, 2019 at 03:03:43PM -0700, Theo de Raadt wrote:
> >> I guess you don't understand what is going on there.
> >> 
> >> List  wrote:
> >> 
> >> > Hello, 
> >> > 
> >> > here a diff replacing www.google.com as a default time constraint by
> >> > www.openbsd.org.
> >> > It is claimed that OpenBSD would have sane and secure defaults. While
> >> > www.google.com might be secure it ain't sane from a privacy concerned
> >> > perspective. Therefore the diff. 
> >> > 
> >> > Regards,
> >> > Stephan
> >> > 
> >> > Index: etc/ntpd.conf
> >> > ===
> >> > RCS file: /cvs/src/etc/ntpd.conf,v
> >> > retrieving revision 1.16
> >> > diff -u -p -r1.16 ntpd.conf
> >> > --- etc/ntpd.conf   6 Nov 2019 19:04:12 -   1.16
> >> > +++ etc/ntpd.conf   5 Dec 2019 21:36:57 -
> >> > @@ -8,4 +8,4 @@ sensor *
> >> >  
> >> >   constraint from "9.9.9.9"  # quad9 v4 without DNS
> >> >constraint from "2620:fe::fe"  # quad9 v6 without DNS
> >> >-constraints from "www.google.com"  # intentionally not 8.8.8.8
> >> >+constraints from "www.openbsd.org"  # intentionally not Google
> >> > 
> >> 
> >



Re: [PATCH] correcting in-sane ntpd.conf

2019-12-05 Thread Theo de Raadt
I guess you don't understand what is going on there.

List  wrote:

> Hello, 
> 
> here a diff replacing www.google.com as a default time constraint by
> www.openbsd.org.
> It is claimed that OpenBSD would have sane and secure defaults. While
> www.google.com might be secure it ain't sane from a privacy concerned
> perspective. Therefore the diff. 
> 
> Regards,
> Stephan
> 
> Index: etc/ntpd.conf
> ===
> RCS file: /cvs/src/etc/ntpd.conf,v
> retrieving revision 1.16
> diff -u -p -r1.16 ntpd.conf
> --- etc/ntpd.conf   6 Nov 2019 19:04:12 -   1.16
> +++ etc/ntpd.conf   5 Dec 2019 21:36:57 -
> @@ -8,4 +8,4 @@ sensor *
>  
>   constraint from "9.9.9.9"  # quad9 v4 without DNS
>constraint from "2620:fe::fe"  # quad9 v6 without DNS
>-constraints from "www.google.com"  # intentionally not 8.8.8.8
>+constraints from "www.openbsd.org"  # intentionally not Google
> 



[PATCH] correcting in-sane ntpd.conf

2019-12-05 Thread List
Hello, 

here a diff replacing www.google.com as a default time constraint by
www.openbsd.org.
It is claimed that OpenBSD would have sane and secure defaults. While
www.google.com might be secure it ain't sane from a privacy concerned
perspective. Therefore the diff. 

Regards,
Stephan

Index: etc/ntpd.conf
===
RCS file: /cvs/src/etc/ntpd.conf,v
retrieving revision 1.16
diff -u -p -r1.16 ntpd.conf
--- etc/ntpd.conf   6 Nov 2019 19:04:12 -   1.16
+++ etc/ntpd.conf   5 Dec 2019 21:36:57 -
@@ -8,4 +8,4 @@ sensor *
 
  constraint from "9.9.9.9"  # quad9 v4 without DNS
   constraint from "2620:fe::fe"  # quad9 v6 without DNS
   -constraints from "www.google.com"  # intentionally not 8.8.8.8
   +constraints from "www.openbsd.org"  # intentionally not Google



Re: ntpd.conf

2016-12-30 Thread Jason McIntyre
On Wed, Dec 28, 2016 at 09:59:06PM +0100, Jan Stary wrote:
> Markup a forgotten keyword.
> 
>   Jan
> 

fixed, thanks.
jmc

> Index: ntpd.conf.5
> ===
> RCS file: /cvs/src/usr.sbin/ntpd/ntpd.conf.5,v
> retrieving revision 1.33
> diff -u -p -r1.33 ntpd.conf.5
> --- ntpd.conf.5   23 Oct 2015 14:52:20 -  1.33
> +++ ntpd.conf.5   28 Dec 2016 20:58:06 -
> @@ -127,7 +127,9 @@ sensor nmea0 refid GPS
>  .Ed
>  .Pp
>  A stratum value other than the default of 1 can be assigned using
> -the stratum keyword.
> +the
> +.Ic stratum
> +keyword.
>  .It Xo Ic server Ar address
>  .Op Ic weight Ar weight-value
>  .Xc
> 



ntpd.conf

2016-12-29 Thread Jan Stary
Markup a forgotten keyword.

Jan

Index: ntpd.conf.5
===
RCS file: /cvs/src/usr.sbin/ntpd/ntpd.conf.5,v
retrieving revision 1.33
diff -u -p -r1.33 ntpd.conf.5
--- ntpd.conf.5 23 Oct 2015 14:52:20 -  1.33
+++ ntpd.conf.5 28 Dec 2016 20:58:06 -
@@ -127,7 +127,9 @@ sensor nmea0 refid GPS
 .Ed
 .Pp
 A stratum value other than the default of 1 can be assigned using
-the stratum keyword.
+the
+.Ic stratum
+keyword.
 .It Xo Ic server Ar address
 .Op Ic weight Ar weight-value
 .Xc



Re: ntpd.conf and Google

2016-01-13 Thread Renaud Allard

On 01/13/2016 06:10 AM, Theo de Raadt wrote:

$ fgrep constraint /etc/ntpd.conf
constraints from "https://www.google.com;
$

www.google.com and other Google services are not accessible from
countries like China or Vietnam.  It's easy enough for people to
change their ntpd.conf if necessary but how about using a default
value that is more likely to work for everyone?  Something like
https://www.un.org/ for example.


That looks like a centralized service operated on a single provider
network without global load balancing "features", the DNS TTL alone
hints this would be unsuitable.

Probably not built to the same scale, does not feel right to me.

There are are a lot of variables involved in making a selection, and
the result is certainly imperfect.  I get where you are coming from,
but you can probably see why we currently choose what we do.




What about using https://www.akamai.com?



smime.p7s
Description: S/MIME Cryptographic Signature


Re: ntpd.conf and Google

2016-01-12 Thread Theo de Raadt
> $ fgrep constraint /etc/ntpd.conf
> constraints from "https://www.google.com;
> $
> 
> www.google.com and other Google services are not accessible from
> countries like China or Vietnam.  It's easy enough for people to
> change their ntpd.conf if necessary but how about using a default
> value that is more likely to work for everyone?  Something like
> https://www.un.org/ for example.

That looks like a centralized service operated on a single provider
network without global load balancing "features", the DNS TTL alone
hints this would be unsuitable.

Probably not built to the same scale, does not feel right to me.

There are are a lot of variables involved in making a selection, and
the result is certainly imperfect.  I get where you are coming from,
but you can probably see why we currently choose what we do.



ntpd.conf and Google

2016-01-12 Thread Philippe Meunier
Hello,

$ fgrep constraint /etc/ntpd.conf
constraints from "https://www.google.com;
$

www.google.com and other Google services are not accessible from
countries like China or Vietnam.  It's easy enough for people to
change their ntpd.conf if necessary but how about using a default
value that is more likely to work for everyone?  Something like
https://www.un.org/ for example.

Cheers,

Philippe




reference ntpctl in ntpd.conf.5

2015-08-27 Thread Rob Pierce
This is similar to what is done for relayd and snmpd, etc.

Index: ntpd.conf.5
===
RCS file: /cvs/src/usr.sbin/ntpd/ntpd.conf.5,v
retrieving revision 1.31
diff -u -p -r1.31 ntpd.conf.5
--- ntpd.conf.5 18 May 2015 11:10:03 -  1.31
+++ ntpd.conf.5 28 Aug 2015 02:44:59 -
@@ -223,6 +223,7 @@ default
 configuration file
 .El
 .Sh SEE ALSO
+.Xr ntpctl 8 ,
 .Xr ntpd 8 ,
 .Xr sysctl 8
 .Sh HISTORY



Re: man ntpd.conf: small errors in constraints section

2015-02-16 Thread Jason McIntyre
On Sat, Feb 14, 2015 at 05:16:49PM +0100, Max Fillinger wrote:
 Some small issues in the new section:
 
 - 'NTP servers' means actual servers, not the keyword, so remove the .Ic
 
 - 'constraint' is used instead of 'constraint from' in some places; that
   might be ok as an abbreviation, but at least the example should use
   the full keyword. In the diff below, I used 'constraint from'
   everywhere.
 

fixed, thanks.
jmc

 Index: usr.sbin/ntpd/ntpd.conf.5
 ===
 RCS file: /cvs/src/usr.sbin/ntpd/ntpd.conf.5,v
 retrieving revision 1.27
 diff -u -p -r1.27 ntpd.conf.5
 --- usr.sbin/ntpd/ntpd.conf.5 10 Feb 2015 19:21:16 -  1.27
 +++ usr.sbin/ntpd/ntpd.conf.5 14 Feb 2015 15:55:54 -
 @@ -188,24 +188,23 @@ thereby reducing the impact of unauthent
  attacks.
  Received NTP packets with time information falling outside of a range
  near the constraint will be discarded and such NTP
 -.Ic servers
 -will be marked as invalid.
 +servers will be marked as invalid.
  .Bl -tag -width Ds
  .It Ic constraint from Ar url
  Specify the URL, IP address or the hostname of an HTTPS server to
  provide a constraint.
  If multiple
 -.Ic constraint
 +.Ic constraint from
  keywords are used,
  .Xr ntpd 8
  will calculate a median constraint from all the servers specified.
  .Bd -literal -offset indent
  server ntp.example.org
 -constraint www.example.com
 +constraint from www.example.com
  .Ed
  .It Ic constraints from Ar url
  As with
 -.Ic constraint ,
 +.Ic constraint from ,
  specify the URL, IP address or the hostname of an HTTPS server to
  provide a constraint.
  Should the hostname resolve to multiple IP addresses,
 



man ntpd.conf: small errors in constraints section

2015-02-14 Thread Max Fillinger
Some small issues in the new section:

- 'NTP servers' means actual servers, not the keyword, so remove the .Ic

- 'constraint' is used instead of 'constraint from' in some places; that
  might be ok as an abbreviation, but at least the example should use
  the full keyword. In the diff below, I used 'constraint from'
  everywhere.

Index: usr.sbin/ntpd/ntpd.conf.5
===
RCS file: /cvs/src/usr.sbin/ntpd/ntpd.conf.5,v
retrieving revision 1.27
diff -u -p -r1.27 ntpd.conf.5
--- usr.sbin/ntpd/ntpd.conf.5   10 Feb 2015 19:21:16 -  1.27
+++ usr.sbin/ntpd/ntpd.conf.5   14 Feb 2015 15:55:54 -
@@ -188,24 +188,23 @@ thereby reducing the impact of unauthent
 attacks.
 Received NTP packets with time information falling outside of a range
 near the constraint will be discarded and such NTP
-.Ic servers
-will be marked as invalid.
+servers will be marked as invalid.
 .Bl -tag -width Ds
 .It Ic constraint from Ar url
 Specify the URL, IP address or the hostname of an HTTPS server to
 provide a constraint.
 If multiple
-.Ic constraint
+.Ic constraint from
 keywords are used,
 .Xr ntpd 8
 will calculate a median constraint from all the servers specified.
 .Bd -literal -offset indent
 server ntp.example.org
-constraint www.example.com
+constraint from www.example.com
 .Ed
 .It Ic constraints from Ar url
 As with
-.Ic constraint ,
+.Ic constraint from ,
 specify the URL, IP address or the hostname of an HTTPS server to
 provide a constraint.
 Should the hostname resolve to multiple IP addresses,