Olivier Poitrey I am currently still getting the following:

  vultr-mia                 error
  anexia-mia                error
  atlantic-orl              error
  premiumrdp-jax            error
  smarthost-jax             error
  vultr-atl                 error
  anexia-atl                error
  tier-clt                  error
  hydron-clt                error
  anexia-mnz                error
  anycast.dns1.nextdns.io   error  (anycast1)
  anycast.dns2.nextdns.io   error  (anycast2)
  dns1.nextdns.io           error  (ultralow1)
  dns2.nextdns.io           error  (ultralow2)

I use DoH using the secure DNS feature on my browser only at this moment. While I am am able to browse the latency has increased a lot since the past few hours. 

Gaurav which browser is that? What version?

Olivier Poitrey Using Brave Browser, the latest stable version. 

Gaurav with DoH setup in Brave?

Olivier Poitrey Yes, the secure DNS setting in the browser itself with my configuration. Right now, however, it's resolving properly. 

Gaurav this is due to our rollout of HTTP/3. It created some problems with chrome based browsers. We disabled it for now. Do you have IPv6?

Olivier Poitrey Oh. Hopefully the next time you try out the HTTP/3 release you are better prepared and successful. 

As for ipv6 my ISP currently doesn't support it fully yet. Though, they plan to next month onwards. 

gc what do you get for "nslookup dns.nextdns.io" and "https://test.nextdns.io"

thor Olivier Poitrey or your linux client on raspberry and other distros does need an update but for that your mirror should be accessible.

thor please show the error.

Olivier Poitrey which one ? Sorry to ask but you could see for yourself first

if you are talking about your mirror:

 Ign :1 https://dl.bintray.com/nextdns/deb stable InRelease 

     this is because of I had errors earlier today and for several days now so => mirror down

where is the log for your client in house? or do I need to activate a setting for that ? 

I have plenty of 

ERR_NAME_NOT_RESOLVED

and my dns server are pihole and no my setup is working perfectly

the raspberries pi having this setup has 2 subresolvers for pihole which is nextdns and unbound and every x queries because I have a lot of BOGUS in direction to your dns resolver client so....

thor I can’t reproduce the bintray issue. Are you sure it is not blocked? What do you get for “dig dl.bintray.com”.

You setup sound very complex. Can you reproduce the issue with a simpler setup directly on your host for instance (or cli alone on your rpi).

Olivier Poitrey hardly doubtful 

; <<>> DiG 9.11.5-P4-5.1+deb10u3-Raspbian <<>> dl.bintray.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 50703
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1472
;; QUESTION SECTION:
;dl.bintray.com.                        IN      A
;; ANSWER SECTION:
dl.bintray.com.         3600    IN      A       3.121.249.232
dl.bintray.com.         3600    IN      A       52.29.138.222

so not a  dns problem apparently... so yeah a problem for the mirror itself

Olivier Poitrey it's not complex at all.

pihole is the resolver for my LAN and filter at the same time. Pihole is asking for dnsresolver wether it's official ones like quad9 or personal one.

unbound take much more time in general unless it's in cache so the forwarder(as you pretty well know because of the mechanics of dns) which is chosen is yours since it's normally under less than 40 ms.  

So its not complex at all and sorry but for this case I pretty much have much confidence in a implementation like pihole than yours than doesn't offer a log system internally and since you are not telling me : put that in your config nextdns.conf I guess there is no log option.... 

The only thing that should be done to be sure it's to analyze your technical logs of your server to see how much request doesn't end up as resolved... But I can't do that for you 

thor with the CLI, use "nextdns log" to read the logs. With multiple layer of filtering and forwarder like you have, you have more chance of getting issues, and it becomes harder to troubleshot.

For bintray, what is the output of "curl -vLo- 'https://bintray.com/nextdns/deb/download_file?file_path=pool%2Fmain%2Fm%2Fnextdns_1.11.0_amd64.deb' | md5sum"

Olivier Poitrey it's not a problem of filter I have already check it and it's not hard to verify since in pihole it's pretty clear and straightforward. And it's not coming from the filtering of your servers either since I can clearly identify the timestamp and I can see there are requests not being processed by your server and still being sent. 

is there any doc about the syntax you are using and the meaning of your log? 

I guess this is that king of problem you are looking for: 

mars 13 21:41:25 pi4data nextdns[735]: Query 127.0.0.1 UDP AAAA firefoxusercontent.com. (qry=51/res=12) cached HTTP/2.0: doh resolve: context deadline exceeded
mars 13 21:41:25 pi4data nextdns[735]: Query 127.0.0.1 UDP A contacts.skype.com. (qry=47/res=12) cached HTTP/2.0: doh resolve: context deadline exceeded
mars 13 21:41:25 pi4data nextdns[735]: Query 127.0.0.1 UDP PTR 207.247.44.108.in-addr.arpa. (qry=56/res=12) 421128ms : doh resolve: context deadline exceeded
mars 13 21:41:25 pi4data nextdns[735]: Query 127.0.0.1 UDP A firefoxusercontent.com. (qry=51/res=12) cached HTTP/2.0: doh resolve: context deadline exceeded
mars 13 21:41:25 pi4data nextdns[735]: Query 127.0.0.1 UDP A api.ghostery.net. (qry=45/res=12) cached HTTP/2.0: doh resolve: context deadline exceeded
mars 13 21:41:25 pi4data nextdns[735]: Query 127.0.0.1 UDP AAAA profile.accounts.firefox.com. (qry=57/res=12) cached HTTP/2.0: doh resolve: context deadline exceeded
mars 13 21:41:25 pi4data nextdns[735]: Query 127.0.0.1 UDP PTR 207.247.44.108.in-addr.arpa. (qry=56/res=12) 419130ms : doh resolve: context deadline exceeded
mars 13 21:41:25 pi4data nextdns[735]: Query 127.0.0.1 UDP AAAA api.ghostery.net. (qry=45/res=12) cached HTTP/2.0: doh resolve: context deadline exceeded
mars 13 21:41:25 pi4data nextdns[735]: Query 127.0.0.1 UDP PTR 74.155.218.92.in-addr.arpa. (qry=55/res=12) 416440ms : doh resolve: context deadline exceeded
mars 13 21:41:25 pi4data nextdns[735]: Query 127.0.0.1 UDP AAAA firefoxusercontent.com. (qry=51/res=12) cached HTTP/2.0: doh resolve: context deadline exceeded
mars 13 21:41:25 pi4data nextdns[735]: Query 127.0.0.1 UDP A crl3.digicert.com. (qry=46/res=12) cached HTTP/2.0: doh resolve: context deadline exceeded
mars 13 21:41:25 pi4data nextdns[735]: Query 127.0.0.1 UDP A api.ghostery.net. (qry=45/res=12) cached HTTP/2.0: doh resolve: context deadline exceeded

there is a swtiching endpoint line later today where it seems to go a bit better after that.

connected means the query has been resolved?

md5sum: ab31fe8e0b4fc6707d88eab5d70e734d

thor please paste the whole curl output.

Olivier Poitrey next time it fails, please submit a https://nextdns.io/diag

Olivier Poitrey 

* Expire in 0 ms for 6 (transfer 0x1a28b0)
* Expire in 1 ms for 1 (transfer 0x1a28b0)
* Expire in 4 ms for 1 (transfer 0x1a28b0)
* Expire in 8 ms for 1 (transfer 0x1a28b0)
* Expire in 8 ms for 1 (transfer 0x1a28b0)
* Expire in 11 ms for 1 (transfer 0x1a28b0)
* Expire in 11 ms for 1 (transfer 0x1a28b0)
* Expire in 16 ms for 1 (transfer 0x1a28b0)
* Expire in 14 ms for 1 (transfer 0x1a28b0)
* Expire in 14 ms for 1 (transfer 0x1a28b0)
*   Trying 108.168.194.93...
* TCP_NODELAY set
* Expire in 200 ms for 4 (transfer 0x1a28b0)
* Connected to bintray.com (108.168.194.93) port 443 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
* successfully set certificate verify locations:
*   CAfile: none
  CApath: /etc/ssl/certs
} [5 bytes data]
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
} [512 bytes data]
* TLSv1.3 (IN), TLS handshake, Server hello (2):
{ [106 bytes data]
* NPN, negotiated HTTP1.1
{ [5 bytes data]
* TLSv1.2 (IN), TLS handshake, Certificate (11):
{ [2765 bytes data]
* TLSv1.2 (IN), TLS handshake, Server key exchange (12):
{ [333 bytes data]
* TLSv1.2 (IN), TLS handshake, Server finished (14):
{ [4 bytes data]
* TLSv1.2 (OUT), TLS handshake, Client key exchange (16):
} [70 bytes data]
* TLSv1.2 (OUT), TLS change cipher, Change cipher spec (1):
} [1 bytes data]
* TLSv1.2 (OUT), TLS handshake, Next protocol (67):
} [36 bytes data]
* TLSv1.2 (OUT), TLS handshake, Finished (20):
} [16 bytes data]
* TLSv1.2 (IN), TLS handshake, Finished (20):
*  issuer: C=US; O=DigiCert Inc; OU=www.digicert.com; CN=GeoTrust RSA CA 2018
*  SSL certificate verify ok.
} [5 bytes data]
> GET /nextdns/deb/download_file?file_path=pool%2Fmain%2Fm%2Fnextdns_1.11.0_amd64.deb HTTP/1.1
< Server: nginx
* Expire in 0 ms for 1 (transfer 0x1a28b0)
* NPN, negotiated HTTP1.1
} [16 bytes data]
* SSL connection using TLSv1.2 / ECDHE-RSA-AES128-GCM-SHA256
*  subject: CN=*.bintray.com
*  start date: Sep 26 00:00:00 2019 GMT
*  issuer: C=US; O=DigiCert Inc; OU=www.digicert.com; CN=GeoTrust RSA CA 2018
> GET /nextdns/deb/pool/main/m/nextdns_1.11.0_amd64.deb HTTP/1.1
< Date: Sun, 14 Mar 2021 22:14:51 GMT
< Content-Length: 0e%3D%22nextdns_1.11.0_amd64.deb%22&Policy=eyJTdGF0ZW1lbnQiOiBbeyJSZXNvdXJjZSI6Imh0dHAqOi8vZDI5dnprNG93MDd3aTcuY2xvdWRmcm9udC5uZXQvOTI3NDNmNGE4NjFkNWQ4YjYyNWEzYjA4NWMS4xMS4wX2FtZDY0LmRlYiUyMiIsIkNvbmRpdGlvbiI6eyJEYXRlTGVzc1RoYW4iOnsiQVdTOkVwb2NoVGltZSI6MTYxNTc2MDgxMX0sIklwQWRkcmVzcyI6eyJBV1M6U291cmNlSXAiOiIwLjAuMC4wLzAifX19XX0_
* Expire in 2 ms for 1 (transfer 0x1a28b0)
* Expire in 1 ms for 1 (transfer 0x1a28b0)
* Expire in 1 ms for 1 (transfer 0x1a28b0)
* Expire in 2 ms for 1 (transfer 0x1a28b0)
* Expire in 2 ms for 1 (transfer 0x1a28b0)
* Expire in 4 ms for 1 (transfer 0x1a28b0)
* Expire in 3 ms for 1 (transfer 0x1a28b0)
* Expire in 4 ms for 1 (transfer 0x1a28b0)
* Expire in 3 ms for 1 (transfer 0x1a28b0)
* Expire in 4 ms for 1 (transfer 0x1a28b0)
* Expire in 4 ms for 1 (transfer 0x1a28b0)
* Expire in 7 ms for 1 (transfer 0x1a28b0)
* Expire in 16 ms for 1 (transfer 0x1a28b0)
* ALPN, offering http/1.1
  CApath: /etc/ssl/certs
} [5 bytes data]
> GET /92743f4a861d5d8b625a3b085cb3a0eeb836291cd2b620f875160932a9521c74?response-content-disposition=attachment%3Bfilename%3D%22nextdns_1.11.0_amd64.deb%22&Policy=eyJTdGF0ZW1lbnQiOiBbeyJSZXNvdXJjZSI6Imh0dHAqOi8vZDI5dnprNG93MDd3aTcuY2xvdWRmcm9udC5uZXQvOTI3NDNmNGE4NjFkNWQ4YjYyNWEzYjA4NWNiM2EwZWViODM2MjkxY2QyYjYyMGY4NzUxNjA5MzJhOTUyMWM3ND9yZXNwb25zZS1jb250ZW50LWRpc3Bvc2l0aW9uPWF0dGFjaG1lbnQlM0JmaWxlbmFtZSUzRCUyMm5leHRkbnNfMS4xMS4wX2FtZDY0LmRlYiUyMiIsIkNvbmRpdGlvbiI6eyJEYXRlTGVzc1RoYW4iOnsiQVdTOkVwb2NoVGltZSI6MTYxNTc2MDgxMX0sIklwQWRkcmVzcyI6eyJBV1M6U291cmNlSXAiOiIwLjAuMC4wLzAifX19XX0_&Signature=p1R-b7GQ8QYDq47I482GjBJb4JEUV~cU3TDIZ49QUWZ~GYkZWVMyYdTU4HA0jNT4V31tIXYmf2dxffX2pg7RCMzm84HAWww31EUL2rzUoJzqJiRL0XuItQTJq7f5W0zouGstItQaDkscN4SmYXV1DeK~GB0EsS5gu-66Go8GpjWd9jpB8iNICFRywxcZ8~3b4hG0JkJuun9cfacICtVZX2Fod6LKaU-0tjen9L2-QAmK8OlsBxe~Ektd4uI5-Yig~YWhpwreF0hECKf2ovU0EeAnNkfBpWbANuzizuprq2NC-3NQeVvmVfpBQ8fRQHVgT43aYZfI98Mze5ngKbGdww__&Key-Pair-Id=APKAIFKFWOMXM2UMTSFA HTTP/1.1> Host: d29vzk4ow07wi7.cloudfront.net
> User-Agent: curl/7.64.0
> Accept: */*
>
{ [5 bytes data]
< HTTP/1.1 200 OK
< Content-Type: application/x-debian-package
< Content-Length: 2876406
< Connection: keep-alive
< Date: Sun, 14 Mar 2021 22:14:53 GMT
< Last-Modified: Mon, 08 Mar 2021 23:54:48 GMT
< ETag: "ab31fe8e0b4fc6707d88eab5d70e734d"
< Content-Disposition: attachment;filename="nextdns_1.11.0_amd64.deb"
< Accept-Ranges: bytes
< Server: AmazonS3
< X-Cache: Miss from cloudfront
< Via: 1.1 bb45d9db269295920003af6514d7e7eb.cloudfront.net (CloudFront)
< X-Amz-Cf-Pop: DUS51-C1
< X-Amz-Cf-Id: JoBF8HaklHQcYw8mGokOr4_LUVGM8opa0DAc9TJVfmWDqRjjBz9pSQ==
<
  0 2808k    0     0    0     0      0      0 --:--:--  0:00:02 --:--:--     0{ [5 bytes data]
100 2808k  100 2808k    0     0   886k      0  0:00:03  0:00:03 --:--:-- 2562k
* Connection #2 to host d29vzk4ow07wi7.cloudfront.net left intact
ab31fe8e0b4fc6707d88eab5d70e734d  -

Olivier Poitrey if you want to, but it still would be nice to have an actual piece of doc to explain the syntax so the user can identify itself the problem and win some time over the problem resolution process... Or maybe I did miss this piece of doc? 

thor the bintray mirror is fine, the problem is elsewhere.

From your logs you seem to get timeouts talking to our servers. Diag would help understand the issue.

Olivier Poitrey https://nextdns.io/diag/a676b980-8518-11eb-b436-f1a41f11c9f5

Olivier Poitrey I don't see in all that a latency big enough to provoke an abandon of a dns query nor any tls handshake or anything but take your time to analyze it and we'll see and thanks anyway for your help 

thor it looks good. Please run it again next time you experience issue.

Olivier Poitrey no problem will do. 

will do the same also for the bintray repo and see if I get anything more. 

Thanks for your help anyway 

Olivier Poitrey I've succeeded to reproduce the problem on a test setup I'm using from time to time. 

Should I open a new thread? or Should I make you DM (if that's a possible).

disclaimer: it's about DNSSEC signature which are not correct apparently. 

thor let's open another thread.

Markus Schneider After roughly 3 hours everything worked fine again. Of course, without any information from NextDNS.