3

Service down?

Is there a problem with the service?

40replies Oldest first
  • Oldest first
  • Newest first
  • Active threads
  • Popular
  • I've been running into the same issues lately as well, not sure going crazy or what? Same exact thing..... You'll be asked to run the collection tool when it happens to upload a diag. Maybe you can make more progress? What kind of setup are you using?

     

    Here's my thread: https://help.nextdns.io/t/60hzvs5/anycast-dns1-nextdns-io-error-anycast1

    Like
  • I’m suddenly getting this on my iOS devices:

    This network is blocking encrypted DNS traffic.
    
    The names of websites and other servers your devices accesses on this network may be monitored and recorded by other devices on this network.

    If I disable NextDNS the warning disappears and DNS does work...

    Like
  • As paying customers we could use (semi) real-time support now!

    Do we really need to wait until a NextDNS employee checks this forum?

    (not good enough if the service is really down right now)

    Like 1
  • I noticed that Ultralow was on the fritz earlier, the CLI also failed over to Dallas (normally IAD or XPS). Seems to be running better now, but not sure what was happening.

    Like
  • We had a bad push that affected ultralow steering in some regions. This has been rolled back a few minutes later. Sorry for the inconvenience.

    Like 2
      • Gaurav
      • iamtheanon
      • 2 yrs ago
      • Reported - view

      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. 

      Like
    • Gaurav which browser is that? What version?

      Like
      • Gaurav
      • iamtheanon
      • 2 yrs ago
      • Reported - view

      Olivier Poitrey Using Brave Browser, the latest stable version. 

      Like
    • Gaurav with DoH setup in Brave?

      Like
      • Gaurav
      • iamtheanon
      • 2 yrs ago
      • Reported - view

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

      Like
    • 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?

      Like
      • Gaurav
      • iamtheanon
      • 2 yrs ago
      • Reported - view

      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. 

      Like
  • Thanks!

    Like
  • Looks like the problem is back again. DOH is down for me. IP works fine.

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

      Like
  • nslookup dns.nextdns.io
    Server:         192.168.2.3
    Address:        192.168.2.3#53
    ** server can't find dns.nextdns.io: SERVFAIL
    
    nslookup https://test.nextdns.io
    Server:         192.168.2.3
    Address:        192.168.2.3#53
    ** server can't find https://test.nextdns.io: SERVFAIL

     

    if i disable dnssec

    nslookup dns.nextdns.io
    Server:         192.168.2.3
    Address:        192.168.2.3#53
    Non-authoritative answer:
    dns.nextdns.io  canonical name = steering.nextdns.io.
    Name:   steering.nextdns.io
    Address: 188.172.221.9
    Name:   steering.nextdns.io
    Address: 155.138.130.135
    Name:   steering.nextdns.io
    Address: 2001:19f0:5:663d:5400:2ff:fece:2f14
    Name:   steering.nextdns.io
    Address: 2a00:11c0:46:4::5
    
    nslookup https://test.nextdns.io
    Server:         192.168.2.3
    Address:        192.168.2.3#53
    ** server can't find https://test.nextdns.io: SERVFAIL
    
    Like
  • an hour ago my nextdns service went down too which is still not working.

    Like
  • A fix is being deployed.

    Like
      • thor
      • thor
      • 2 yrs ago
      • Reported - view

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

      Like
  • It is still happening. You have still, at least on CH, downtime every minutes or every x queries.

    Plus your mirror for linux installation of your client is unreachable. It is happening on every devices I have so it's still the case i guess for the other customers too. 

    Like
    • thor please show the error.

      Like
      • thor
      • thor
      • 2 yrs ago
      • Reported - view

      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....

      Like
    • 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).

      Like
      • thor
      • thor
      • 2 yrs ago
      • Reported - view

      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
      
      Like
      • thor
      • thor
      • 2 yrs ago
      • Reported - view

      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 

      Like
    • 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"

      Like
      • thor
      • thor
      • 2 yrs ago
      • Reported - view

      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

      Like
    • thor please paste the whole curl output.

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

      Like
      • thor
      • thor
      • 2 yrs ago
      • Reported - view

      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  -
      Like
      • thor
      • thor
      • 2 yrs ago
      • Reported - view

      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? 

      Like
    • 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.

      Like
      • thor
      • thor
      • 2 yrs ago
      • Reported - view
      • thor
      • thor
      • 2 yrs ago
      • Reported - view

      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 

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

      Like
      • thor
      • thor
      • 2 yrs ago
      • Reported - view

      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 

      Like
      • thor
      • thor
      • 2 yrs ago
      • Reported - view

      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. 

      Like
    • thor let's open another thread.

      Like
  • Since 2 hours NextDNS is down for me as well. Internet works fine, as long as I'm not using NextDNS. Adding insult to injury is the remark that I should contact support (Bitte sprechen Sie mit uns...). How should I speak to you people? 🙄

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

      Like
Like3 Follow
  • 3 Likes
  • 2 yrs agoLast active
  • 40Replies
  • 651Views
  • 11 Following