RPZ: is this config correct?

George Thessalonikefs george at nlnetlabs.nl
Wed Nov 18 10:36:16 UTC 2020


Hi RayG,

Indeed it works for me on linux.
It *seems* like an issue on windows.
It would be great if other windows users could try and verify the same 
behavior before I start debugging there.

To clarify this is not about writing the file but succeeding with the 
transfer to begin with.

-- George

On 16/11/2020 18:22, RayG wrote:
> Hi George,
> 
> I have tried many things over the weekend but despite everything I cannot see why this is not working.
> 
> All I see in the log is "Transfer failed"
> 
> rpz: # MyResponsePolicyZones.conf
>       name: "URLHaus"
>       zonefile: "C:\ProgramData\Unbound\Logs\urlhaus.zone"
>       url: https://urlhaus.abuse.ch/downloads/rpz/
>       rpz-log: yes
>       rpz-log-name: "URLHausRPZ"
>       rpz-action-override: nxdomain
> 
> There is no indication of why it failed or if indeed it did download the data and failed while processing it.
> 
> Until I can get a handle on what is going on I cannot see a way to resolve the situation.
> 
> I got the impression that the configuration worked for you but why not for me?
> 
> RayG
> 
> -----Original Message-----
> From: RayG <rgsub1 at btinternet.com>
> Sent: 11 November 2020 16:14
> To: 'Eduardo Schoedler' <listas at esds.com.br>; 'Unbound-users' <unbound-users at lists.nlnetlabs.nl>; 'George Thessalonikefs' <george at nlnetlabs.nl>
> Subject: RE: RPZ: is this config correct?
> 
> Hi Eduardo,
> 
> Thanks for the suggestion, that is certainly an easier way to get the debugging output.
> 
> Looking through the logs and in greater detail I wonder if I have seen the issue.
> 
> See these two commands:
> 
> C:\Program Files\Unbound>I:\wget64.exe https://151.101.130.49/downloads/rpz
> --2020-11-11 16:01:48--  https://151.101.130.49/downloads/rpz
> Connecting to 151.101.130.49:443... connected.
>      ERROR: certificate common name 'c.sni.fastly.net' doesn't match requested host name '151.101.130.49'.
> To connect to 151.101.130.49 insecurely, use `--no-check-certificate'.
> 
> C:\Program Files\Unbound>I:\wget64.exe https://urlhaus.abuse.ch/downloads/rpz
> --2020-11-11 16:02:54--  https://urlhaus.abuse.ch/downloads/rpz
> Resolving urlhaus.abuse.ch (urlhaus.abuse.ch)... 151.101.66.49, 151.101.2.49, 151.101.194.49, ...
> Connecting to urlhaus.abuse.ch (urlhaus.abuse.ch)|151.101.66.49|:443... connected.
> HTTP request sent, awaiting response... 200 OK
> Length: 130762 (128K) [text/plain]
> Saving to: 'rpz'
> 
> rpz                           100%[=================================================>] 127.70K  --.-KB/s    in 0.04s
> 
> 2020-11-11 16:02:54 (3.15 MB/s) - 'rpz' saved [130762/130762]
> 
> And the data is there in the "rpz" file.
> 
> I see in the unbound log file:
> 
> 10/11/2020 15:05:14 C:\Program Files\Unbound\unbound.exe[15932:0] debug: auth zone rpz.urlhaus.abuse.ch. transfer next HTTP fetch from 151.101.122.49 started ...
> 10/11/2020 15:05:24 C:\Program Files\Unbound\unbound.exe[15932:0] debug: xfr stopped, connection timeout to urlhaus.abuse.ch ...
> 10/11/2020 15:05:24 C:\Program Files\Unbound\unbound.exe[15932:0] debug: auth zone rpz.urlhaus.abuse.ch. transfer failed, wait
> 
> Which suggests the transfer is being done using the IP address rather than the DNS name and as we can see from above with wget we get a certificate error.
> 
> Is this what is causing things to go wrong?
> 
> Is unbound using the DNS name or the IP address?
> 
> RayG
> 


More information about the Unbound-users mailing list