Re: Is there any "try catch" functionality in VCL? If not, how to handle runtime errors in vcl_init?

[Batanun B]

Just to explain my concern a bit. The worst case scenario in production, that I 
very much would like to avoid, could look something like this:

1. Something happens with our public key, so that Varnish won't be able to 
start after getting the new faulty key. Already running servers will continue 
to run, but no new servers can be initiated.
2. Before we have been able to fix the problem with the public key, some other 
problem happens in Varnish, and all running Varnish servers dies.
3. We end up with no working Varnish servers running, and not being able to 
start any new ones.
4. All our websites are down.
___
varnish-misc mailing list
varnish-misc@varnish-cache.org
https://www.varnish-cache.org/lists/mailman/listinfo/varnish-misc

Re: Varnish won't start because backend host resolves to too many addresses, but they are all identical IPs

[Batanun B]

> https://github.com/nigoroll/libvmod-dynamic/blob/master/src/vmod_dynamic.vcc#L538-L583
> maybe?
>

> I'm sure Nils will pipe up here if you need help, and if you want more
> synchronous assistance, there's always the discord channel
> .

Thanks! :)

___
varnish-misc mailing list
varnish-misc@varnish-cache.org
https://www.varnish-cache.org/lists/mailman/listinfo/varnish-misc

Re: Is there any "try catch" functionality in VCL? If not, how to handle runtime errors in vcl_init?

[Batanun B]

> It's the VMOD author you should ask to have an option to ignore public
> key errors.

Well, I'm usually of the mindset that if a problem can be handled in a generic 
way by the language/platform/framework, then one should avoid requiring each 
and every custom vmod/plugin/library to handle it individually. And I'm also of 
the mindset that pretty much any non-trivial code can fail, and the calling 
code should be able to catch that if needed. :)

> This is a constructor, and even if we had a try-catch kind of
> construct in the language, I don't think we would make this one
> recoverable.

In my mind, with a try-catch I could handle it like this:

try {
  new cryptoVerifier = crypto.verifier(sha256, 
std.fileread("/path/to/public.key"));
} catch (error) {
  // log error...
  // then try with with a hard coded known safe key, but that will fail when 
checking the signature
  new cryptoVerifier = crypto.verifier(sha256, (sha256, {"
-BEGIN PUBLIC KEY-
...
-END PUBLIC KEY-
"});
}

With this approach, Varnish will start like normal. And the only requests 
failing will be the ones using the cryptoVerifier.
___
varnish-misc mailing list
varnish-misc@varnish-cache.org
https://www.varnish-cache.org/lists/mailman/listinfo/varnish-misc

Re: Possible to disable/inactivate a backend using VCL?

[Batanun B]

> It was back-ported to 6.0, which is not an LTS branch limited to bug fixes ;)
>
> https://varnish-cache.org/docs/6.0/users-guide/vcl-backends.html

Thanks! Wow, I can't believe that I could miss that. I thought I read that 
specific page, as well as searched on Google, but I guess I was too focused on 
looking for terms like "disabled" or "inactivated".

___
varnish-misc mailing list
varnish-misc@varnish-cache.org
https://www.varnish-cache.org/lists/mailman/listinfo/varnish-misc

Re: Varnish won't start because backend host resolves to too many addresses, but they are all identical IPs

[Guillaume Quintard]

> The documentation seems a bit lacking (no full VCL example), but I guess
I could use their test cases as examples.

https://github.com/nigoroll/libvmod-dynamic/blob/master/src/vmod_dynamic.vcc#L538-L583
maybe?
I'm sure Nils will pipe up here if you need help, and if you want more
synchronous assistance, there's always the discord channel
.

> The dynamic one seems like the only one that supports community edition
LTS 6.0.

Yes, of the three, that's the only one that will support that one (VS is
focused on the Enterprise version, and I lack the time to port vmods on 6.0
(but I'll welcome the help)).

Cheers,

-- 
Guillaume Quintard


On Wed, Apr 19, 2023 at 9:02 AM Batanun B  wrote:

> > Shouldn't your DNS entries be clean? ;-)
>
> Preferably, but I blame Microsoft here 🙂
>
> The problem went away by itself when I tried starting again like half an
> hour later or so, so I guess it was a temporary glitch in the matrix.
>
> As far as I understand it, the IPs of these machines only change if they
> are deleted and created again. We do it occasionally in test/staging, and
> there we can live with Varnish needing to be restarted. In production we
> don't really delete them once they are properly setup, unless there is some
> major problem and then a restart of the load balanced varnish servers
> should not be a concern.
>
> Thanks for your vmod suggestions! I will check them out. The dynamic one
> seems like the only one that supports community edition LTS 6.0. The
> documentation seems a bit lacking (no full VCL example), but I guess I
> could use their test cases as examples.
>
> --
> *From:* Guillaume Quintard 
> *Sent:* Wednesday, April 19, 2023 4:42 PM
> *To:* Batanun B 
> *Cc:* varnish-misc@varnish-cache.org 
> *Subject:* Re: Varnish won't start because backend host resolves to too
> many addresses, but they are all identical IPs
>
> The fact the IPs are identical is weird, but I wouldn't be surprised if
> the dns entry actually contained 3 identical IPs.
>
> > Shouldn't Varnish be able to figure out that in that case it can just
> choose any one and it will work as expected?
>
> Shouldn't your DNS entries be clean? ;-)
>
> Honestly, if the IP(s) behind the service name is liable to change, you
> shouldn't use a dynamic backend because Varnish resolves the IP when the
> VCL is loaded, so if the IP changes behind your back, Varnish won't follow
> it, and you'll be screwed.
> Instead, you should use dynamic backends, of which there are a handful:
> - dynamic , by UPLEX: it's
> been around for ages, it's battle-tested, and it's included in the oficial
> Varnish Docker image 
> - udo+activedns
> ,
> by Varnish Software: the design is slightly different and allows you to
> specify pretty much any load-balancing policy you might need. You'll need a
> subscription but you'll get excellent support (disclaimer, I'm an ex
> employee)
> - reqwest
> ,
> by yours truly: the interface focuses on providing a simple experience and
> a few bells and whistles (HTTPS, HTTP2, brotli, following redirects)
>
> As you can see, the static backend's reluctance to fully handle DNS has
> been a fertile ground for vmods :-)
>
> --
> Guillaume Quintard
>
>
> On Wed, Apr 19, 2023 at 1:49 AM Batanun B  wrote:
>
> All of the sudden Varnish fails to start in my development environment,
> and gives me the following error message:
>
> Message from VCC-compiler:
> Backend host "redacted-hostname": resolves to too many addresses.
> Only one IPv4 and one IPv6 are allowed.
> Please specify which exact address you want to use, we found all of these:
>  555.123.123.3:80
>  555.123.123.3:80
>  555.123.123.3:80
>
> I have changed the hostname and the IP above to not expose our server, but
> all three IP numbers are 100% identical. Shouldn't Varnish be able to
> figure out that in that case it can just choose any one and it will work as
> expected? It really should remove duplicates, and only if there are more
> than one non-duplicate IP then it should fail.
>
> The problem is that the backend host is a so called "app service" in
> Microsoft Azure, which is basically a platform as a service (PaaS), where
> Microsoft handles the networking including the domain name (no user access
> it directly). I have no idea why it suddenly resolves to multiple duplicate
> IPs.
> ___
> varnish-misc mailing list
> varnish-misc@varnish-cache.org
> https://www.varnish-cache.org/lists/mailman/listinfo/varnish-misc
>
>
___
varnish-misc mailing list
varnish-misc@varnish-cache.org
https://www.varnish-cache.org/lists/mailman/listinfo/varnish

Re: Is there any "try catch" functionality in VCL? If not, how to handle runtime errors in vcl_init?

[Dridi Boukelmoune]

On Wed, Apr 19, 2023 at 4:25 PM Batanun B  wrote:
>
> Hi,
>
> We use the vmod crypto to verify cryptographic signatures for some of our 
> traffic. When testing, the public key was hard coded in the VCL, but before 
> we start using this feature in production we will switch to reading the 
> public key from a file on disk. This file is generated on server startup, by 
> fetching it from an Azure keyvault.
>
> Now, the problem I'm picturing here is that this fetching of the public key 
> can fail, or the key can be corrupt or empty, maybe by user error. Or the key 
> could be valid, but the format of the key happens to be unsupported by the 
> vmod crypto. So, even if we do our best to validate the key, in theory it 
> could pass all our tests but still fail when we give it to the vmod crypto. 
> And if that happens, Varnish won't start because the vmod crypto is initiated 
> with the public key in vcl_init, like this:
>
> sub vcl_init {
>   new cryptoVerifier = crypto.verifier(sha256, 
> std.fileread("/path/to/public.key"));
> }
>
> What I would prefer to happen if the key is rejected, is that vcl_init goes 
> through without failure, and then the requests that use the cryptoVerifier 
> will fail, but all other traffic (like 99%) still works. Can we achieve this 
> somehow? Like some try-catch functionallity? If not, is there some other way 
> to handle this that doesn't cause Varnish to die on startup?

It's the VMOD author you should ask to have an option to ignore public
key errors.

This is a constructor, and even if we had a try-catch kind of
construct in the language, I don't think we would make this one
recoverable.

Dridi
___
varnish-misc mailing list
varnish-misc@varnish-cache.org
https://www.varnish-cache.org/lists/mailman/listinfo/varnish-misc

Re: Possible to disable/inactivate a backend using VCL?

[Dridi Boukelmoune]

On Wed, Apr 19, 2023 at 3:45 PM Batanun B  wrote:
>
> > backend theBackend none;
> > Here's the relevant documentation: 
> > https://varnish-cache.org/docs/trunk/users-guide/vcl-backends.html#the-none-backend
> > It was added in 6.4.
>
> Look like exactly what we need! Sadly we are "stuck" on 6.0 until the next 
> LTS version comes. So I think that until then I will use our poor man version 
> of the "none" backend, ie pointing to localhost with an port number that 
> won't give a response.

It was back-ported to 6.0, which is not an LTS branch limited to bug fixes ;)

https://varnish-cache.org/docs/6.0/users-guide/vcl-backends.html

Dridi
___
varnish-misc mailing list
varnish-misc@varnish-cache.org
https://www.varnish-cache.org/lists/mailman/listinfo/varnish-misc

Is there any "try catch" functionality in VCL? If not, how to handle runtime errors in vcl_init?

[Batanun B]

Hi,

We use the vmod crypto to verify cryptographic signatures for some of our 
traffic. When testing, the public key was hard coded in the VCL, but before we 
start using this feature in production we will switch to reading the public key 
from a file on disk. This file is generated on server startup, by fetching it 
from an Azure keyvault.

Now, the problem I'm picturing here is that this fetching of the public key can 
fail, or the key can be corrupt or empty, maybe by user error. Or the key could 
be valid, but the format of the key happens to be unsupported by the vmod 
crypto. So, even if we do our best to validate the key, in theory it could pass 
all our tests but still fail when we give it to the vmod crypto. And if that 
happens, Varnish won't start because the vmod crypto is initiated with the 
public key in vcl_init, like this:

sub vcl_init {
  new cryptoVerifier = crypto.verifier(sha256, 
std.fileread("/path/to/public.key"));
}

What I would prefer to happen if the key is rejected, is that vcl_init goes 
through without failure, and then the requests that use the cryptoVerifier will 
fail, but all other traffic (like 99%) still works. Can we achieve this 
somehow? Like some try-catch functionallity? If not, is there some other way to 
handle this that doesn't cause Varnish to die on startup?
___
varnish-misc mailing list
varnish-misc@varnish-cache.org
https://www.varnish-cache.org/lists/mailman/listinfo/varnish-misc

Re: Varnish won't start because backend host resolves to too many addresses, but they are all identical IPs

[Batanun B]

> Shouldn't your DNS entries be clean? ;-)

Preferably, but I blame Microsoft here 🙂

The problem went away by itself when I tried starting again like half an hour 
later or so, so I guess it was a temporary glitch in the matrix.

As far as I understand it, the IPs of these machines only change if they are 
deleted and created again. We do it occasionally in test/staging, and there we 
can live with Varnish needing to be restarted. In production we don't really 
delete them once they are properly setup, unless there is some major problem 
and then a restart of the load balanced varnish servers should not be a concern.

Thanks for your vmod suggestions! I will check them out. The dynamic one seems 
like the only one that supports community edition LTS 6.0. The documentation 
seems a bit lacking (no full VCL example), but I guess I could use their test 
cases as examples.


From: Guillaume Quintard 
Sent: Wednesday, April 19, 2023 4:42 PM
To: Batanun B 
Cc: varnish-misc@varnish-cache.org 
Subject: Re: Varnish won't start because backend host resolves to too many 
addresses, but they are all identical IPs

The fact the IPs are identical is weird, but I wouldn't be surprised if the dns 
entry actually contained 3 identical IPs.

> Shouldn't Varnish be able to figure out that in that case it can just choose 
> any one and it will work as expected?

Shouldn't your DNS entries be clean? ;-)

Honestly, if the IP(s) behind the service name is liable to change, you 
shouldn't use a dynamic backend because Varnish resolves the IP when the VCL is 
loaded, so if the IP changes behind your back, Varnish won't follow it, and 
you'll be screwed.
Instead, you should use dynamic backends, of which there are a handful:
- dynamic, by UPLEX: it's been 
around for ages, it's battle-tested, and it's included in the oficial Varnish 
Docker image
- 
udo+activedns,
 by Varnish Software: the design is slightly different and allows you to 
specify pretty much any load-balancing policy you might need. You'll need a 
subscription but you'll get excellent support (disclaimer, I'm an ex employee)
- 
reqwest,
 by yours truly: the interface focuses on providing a simple experience and a 
few bells and whistles (HTTPS, HTTP2, brotli, following redirects)

As you can see, the static backend's reluctance to fully handle DNS has been a 
fertile ground for vmods :-)

--
Guillaume Quintard


On Wed, Apr 19, 2023 at 1:49 AM Batanun B 
mailto:bata...@hotmail.com>> wrote:
All of the sudden Varnish fails to start in my development environment, and 
gives me the following error message:

Message from VCC-compiler:
Backend host "redacted-hostname": resolves to too many addresses.
Only one IPv4 and one IPv6 are allowed.
Please specify which exact address you want to use, we found all of these:
 555.123.123.3:80
 555.123.123.3:80
 555.123.123.3:80

I have changed the hostname and the IP above to not expose our server, but all 
three IP numbers are 100% identical. Shouldn't Varnish be able to figure out 
that in that case it can just choose any one and it will work as expected? It 
really should remove duplicates, and only if there are more than one 
non-duplicate IP then it should fail.

The problem is that the backend host is a so called "app service" in Microsoft 
Azure, which is basically a platform as a service (PaaS), where Microsoft 
handles the networking including the domain name (no user access it directly). 
I have no idea why it suddenly resolves to multiple duplicate IPs.
___
varnish-misc mailing list
varnish-misc@varnish-cache.org
https://www.varnish-cache.org/lists/mailman/listinfo/varnish-misc
___
varnish-misc mailing list
varnish-misc@varnish-cache.org
https://www.varnish-cache.org/lists/mailman/listinfo/varnish-misc

Re: Possible to disable/inactivate a backend using VCL?

[Batanun B]

> backend theBackend none;
> Here's the relevant documentation: 
> https://varnish-cache.org/docs/trunk/users-guide/vcl-backends.html#the-none-backend
> It was added in 6.4.

Look like exactly what we need! Sadly we are "stuck" on 6.0 until the next LTS 
version comes. So I think that until then I will use our poor man version of 
the "none" backend, ie pointing to localhost with an port number that won't 
give a response.
___
varnish-misc mailing list
varnish-misc@varnish-cache.org
https://www.varnish-cache.org/lists/mailman/listinfo/varnish-misc

Re: Varnish won't start because backend host resolves to too many addresses, but they are all identical IPs

[Dridi Boukelmoune]

On Wed, Apr 19, 2023 at 2:44 PM Guillaume Quintard
 wrote:
>
> The fact the IPs are identical is weird, but I wouldn't be surprised if the 
> dns entry actually contained 3 identical IPs.
>
> > Shouldn't Varnish be able to figure out that in that case it can just 
> > choose any one and it will work as expected?
>
> Shouldn't your DNS entries be clean? ;-)

It should, but Varnish could probably make an effort here.
___
varnish-misc mailing list
varnish-misc@varnish-cache.org
https://www.varnish-cache.org/lists/mailman/listinfo/varnish-misc

Re: Varnish won't start because backend host resolves to too many addresses, but they are all identical IPs

[Guillaume Quintard]

The fact the IPs are identical is weird, but I wouldn't be surprised if the
dns entry actually contained 3 identical IPs.

> Shouldn't Varnish be able to figure out that in that case it can just
choose any one and it will work as expected?

Shouldn't your DNS entries be clean? ;-)

Honestly, if the IP(s) behind the service name is liable to change, you
shouldn't use a dynamic backend because Varnish resolves the IP when the
VCL is loaded, so if the IP changes behind your back, Varnish won't follow
it, and you'll be screwed.
Instead, you should use dynamic backends, of which there are a handful:
- dynamic , by UPLEX: it's
been around for ages, it's battle-tested, and it's included in the oficial
Varnish Docker image 
- udo+activedns
,
by Varnish Software: the design is slightly different and allows you to
specify pretty much any load-balancing policy you might need. You'll need a
subscription but you'll get excellent support (disclaimer, I'm an ex
employee)
- reqwest
,
by yours truly: the interface focuses on providing a simple experience and
a few bells and whistles (HTTPS, HTTP2, brotli, following redirects)

As you can see, the static backend's reluctance to fully handle DNS has
been a fertile ground for vmods :-)

-- 
Guillaume Quintard


On Wed, Apr 19, 2023 at 1:49 AM Batanun B  wrote:

> All of the sudden Varnish fails to start in my development environment,
> and gives me the following error message:
>
> Message from VCC-compiler:
> Backend host "redacted-hostname": resolves to too many addresses.
> Only one IPv4 and one IPv6 are allowed.
> Please specify which exact address you want to use, we found all of these:
>  555.123.123.3:80
>  555.123.123.3:80
>  555.123.123.3:80
>
> I have changed the hostname and the IP above to not expose our server, but
> all three IP numbers are 100% identical. Shouldn't Varnish be able to
> figure out that in that case it can just choose any one and it will work as
> expected? It really should remove duplicates, and only if there are more
> than one non-duplicate IP then it should fail.
>
> The problem is that the backend host is a so called "app service" in
> Microsoft Azure, which is basically a platform as a service (PaaS), where
> Microsoft handles the networking including the domain name (no user access
> it directly). I have no idea why it suddenly resolves to multiple duplicate
> IPs.
> ___
> varnish-misc mailing list
> varnish-misc@varnish-cache.org
> https://www.varnish-cache.org/lists/mailman/listinfo/varnish-misc
>
___
varnish-misc mailing list
varnish-misc@varnish-cache.org
https://www.varnish-cache.org/lists/mailman/listinfo/varnish-misc

Re: Possible to disable/inactivate a backend using VCL?

[Guillaume Quintard]

Thank, I think I get it now. How about:

backend theBackend none;

Here's the relevant documentation:
https://varnish-cache.org/docs/trunk/users-guide/vcl-backends.html#the-none-backend
It was added in 6.4.

Hope that helps.

-- 
Guillaume Quintard


On Wed, Apr 19, 2023 at 1:36 AM Batanun B  wrote:

> Hi Guillaume,
>
> > I'm curious, if it's completely deactivated what's the benefit of having
> it in the vcl?
>
> It is only intended to be deactivated in production (until we go live).
> Our test and staging environments have the backend active.
>
> > if (false) {
> > set req.backend_hint = you_deactivated_backend;
> > }
>
> Thanks, I will test this.
> My current prod-specific setup for this backend looks like this:
>
> backend theBackend {
> .host = "localhost";
> .port = "";
> .probe = {
> .interval = 1h;
> }
> }
>
> This seems to be working when testing it locally. It also solves the
> problem of having to assign some arbitrary ip or hostname (the actual
> backend host for this service hasn't been created in production yet, since
> we are several months away from go live), which actually was our main
> problem. What do you think about this approach instead? Preferably this
> would be a built in feature in Varnish, with a setting "disabled = true" or
> similar in the backend definition, and then it would not require any host
> or ip to be configured.
>
> ___
> varnish-misc mailing list
> varnish-misc@varnish-cache.org
> https://www.varnish-cache.org/lists/mailman/listinfo/varnish-misc
>
___
varnish-misc mailing list
varnish-misc@varnish-cache.org
https://www.varnish-cache.org/lists/mailman/listinfo/varnish-misc

Re: Strange Broken Pipe error from Varnish health checks

[Batanun B]

Couldn't a HEAD request solve this? Then nginx wouldn't bother with the body at 
all, right?

This is what we do with our health checks. For example:

backend someBackend {
.host = "[redacted]";
.port = "80";
.probe = {
.interval = 9s;
.request =
"HEAD /healthcheck HTTP/1.1"
"Host: [redacted]"
"User-Agent: varnish-health-probe"
"Connection: Close"
"Accept: */*";
}
}

From: varnish-misc  
on behalf of George 
Sent: Monday, April 17, 2023 10:21 AM
To: varnish-misc@varnish-cache.org 
Subject: Strange Broken Pipe error from Varnish health checks

Hi,

I have a Varnish/nginx cluster running with varnish-7.1.2-1.el7.x86_64 on 
CentOS 7.

The issue I am having comes from the varnish health checks. I am getting a 
"broken pipe" error in the nginx error log at random times like below:
Apr 10 17:32:46 VARNISH-MASTER nginx_varnish_error: 2023/04/10 17:32:46 [info] 
17808#17808: *67626636 writev() failed (32: Broken pipe), client: unix:, 
server: _, request: "GET /varnish_check HTTP/1.1", host: "0.0.0.0"

The strange thing is that this error appears only when Varnish performs the 
health checks. I have other scripts doing it(nagios, curl, wget, AWS ELB) but 
those do not show any errors. In addition to this Varnish and nginx where the 
health checks occur are on the same server and it makes no difference if I use 
a TCP connection or socket based one.

Below are the varnish vcl and nginx locations for the health checks:
backend nginx_varnish {
   .path = "/run/nginx/nginx.sock";
   .first_byte_timeout = 600s;
   .probe = health;
}

location = /varnish_check {
keepalive_timeout 305;
return 200 'Varnish Check';
access_log /var/log/nginx/varnish_check.log main;
error_log /var/log/nginx/varnish_check_errors.log debug;
error_log 
syslog:server=unix:/run/nginx_log.in.sock,facility=local1,tag=nginx_varnish_error,nohostname
 info;
}

Are there any docs I can read about how exactly varnish performs the health 
checks and what internal processes are involved?
Did anyone happen to have similar issues? This is not causing any operational 
problems for the cluster but it is just something that I want to determine why 
it is happening because it just should not be happening.

Please help
THanks in advance.

___
varnish-misc mailing list
varnish-misc@varnish-cache.org
https://www.varnish-cache.org/lists/mailman/listinfo/varnish-misc

Varnish won't start because backend host resolves to too many addresses, but they are all identical IPs

[Batanun B]

All of the sudden Varnish fails to start in my development environment, and 
gives me the following error message:

Message from VCC-compiler:
Backend host "redacted-hostname": resolves to too many addresses.
Only one IPv4 and one IPv6 are allowed.
Please specify which exact address you want to use, we found all of these:
 555.123.123.3:80
 555.123.123.3:80
 555.123.123.3:80

I have changed the hostname and the IP above to not expose our server, but all 
three IP numbers are 100% identical. Shouldn't Varnish be able to figure out 
that in that case it can just choose any one and it will work as expected? It 
really should remove duplicates, and only if there are more than one 
non-duplicate IP then it should fail.

The problem is that the backend host is a so called "app service" in Microsoft 
Azure, which is basically a platform as a service (PaaS), where Microsoft 
handles the networking including the domain name (no user access it directly). 
I have no idea why it suddenly resolves to multiple duplicate IPs.
___
varnish-misc mailing list
varnish-misc@varnish-cache.org
https://www.varnish-cache.org/lists/mailman/listinfo/varnish-misc

Re: Possible to disable/inactivate a backend using VCL?

[Batanun B]

Hi Guillaume,

> I'm curious, if it's completely deactivated what's the benefit of having it 
> in the vcl?

It is only intended to be deactivated in production (until we go live). Our 
test and staging environments have the backend active.

> if (false) {
>   set req.backend_hint = you_deactivated_backend;
> }

Thanks, I will test this.
My current prod-specific setup for this backend looks like this:

backend theBackend {
.host = "localhost";
.port = "";
.probe = {
.interval = 1h;
}
}

This seems to be working when testing it locally. It also solves the problem of 
having to assign some arbitrary ip or hostname (the actual backend host for 
this service hasn't been created in production yet, since we are several months 
away from go live), which actually was our main problem. What do you think 
about this approach instead? Preferably this would be a built in feature in 
Varnish, with a setting "disabled = true" or similar in the backend definition, 
and then it would not require any host or ip to be configured.

___
varnish-misc mailing list
varnish-misc@varnish-cache.org
https://www.varnish-cache.org/lists/mailman/listinfo/varnish-misc