https://www.ncbi.nlm.nih.gov doesn’t resolve using 1.1.1.1
Can someone confirm?
Switched to google public dns, and https://www.ncbi.nlm.nih.gov resolves. 1.1.1.1 is too buggy for me.
I suspect nlm.nih.gov servers to require responses that exceed 4096 bytes (!), which is the reasonable maximum response size many servers and libraries tolerate.
Just tested with ncbi.nlm.nih.gov @ns3.nih.gov: a simple A query without any options returns no less than 3976 bytes.
Adding some options or switching to a query such as ANY likely requires more than 4096 bytes, but instead of returning a truncated response, it just… doesn’t return any response at all.
But worse… With a shorter advertised payload size, it returns a truncated response without the truncated bit set.
I think most of their IPv6 nameservers drop large responses. And most of their responses are large.
http://dnsviz.net/d/www.ncbi.nlm.nih.gov/WsVB0g/dnssec/
So if a resolver is unlucky, or prefers IPv6, it might retry over IPv6 for a few seconds before trying IPv4. Or perhaps retrying with a smaller EDNS size.
And retrying with a smaller EDNS size is unreliable due to the TC bit not being set in their responses.
Wondering what a decent workaround would be. Retry directly over TCP instead of reducing the advertised payload size? This is not great.
I don’t know. I can say that Unbound seems to resolve it reliably – even with QNAME minimisation and 0x20 randomisation – though it takes 1-2 seconds from a cold cache.
I’m not sure if it’s luck, or different fallback logic, or different retry logic, or what.
Is it just me, or does kresd strongly prefer IPv6? Unbound (by default) picks IPv4 or IPv6 servers randomly. Maybe kresd tries 2 or 3 of the IPv6 servers before hitting an internal timeout and giving up, or something like that.
Whereas Unbound will probably try one of the IPv4 servers quickly, and it’s incredibly persistent anyway.
(I have no idea how kresd works. For that matter, I have almost no idea how Unbound works…)
Edit: PowerDNS and Google seem to have no problem resolving it either.
Edit: Though Google considers the zone insecure.
kresd has about 20% bias towards IPv6, the problem is with the oversize DNSKEY response from the v6. We’ll add an override to remove the bias for their nameservers in the next upgrade.
1 Like
I forgot to update this. It should be resolving now, let me know if you’re still seeing issues.
1 Like
This has been a while, but it seems that no NIH services are resolving again.
https://chem.nlm.nih.gov/chemidplus/
Etc.
Apologies for grave-digging and old thread but this still seems to be an issue.
Verified using multiple computers/browsers/dns servers i’m not able to get any connection from static.pubmed.gov which seems to be hosting most of the style sheets for Home - PMC - NCBI there are hundreds of thousands of sub articles under this domain for various scientific literature all with broken layouts.
Everyone else having this same issue i imagine?
Already tried the purge cache page on 1.1.1.1 no change.
static.pubmed.gov does not resolve at all when using 1.1.1.1 on my desktop computer OR when using the 1.1.1.1 app on my phone.
Chrome web console shows:
Failed to load resource: net::ERR_NAME_RESOLUTION_FAILED
After ipconfig /flushdns
a ping shows
C:\Users\User>ping static.pubmed.gov
Ping request could not find host static.pubmed.gov. Please check the name and try again.
Here is my connection info:
C:\Users\User>nslookup static.pubmed.gov
Server: one.one.one.one
Address: 1.1.1.1
DNS request timed out.
timeout was 2 seconds.
DNS request timed out.
timeout was 2 seconds.
DNS request timed out.
timeout was 2 seconds.
*** one.one.one.one can’t find static.pubmed.gov: Server failed
Not having issues when using any other DNS
I got successful responses from both 1.1.1.1 and 1.0.0.1:
~$ dig +short static.pubmed.gov @1.1.1.1
pubmedgov.wip.ncbi.nlm.nih.gov.
130.14.29.109
~$ dig +short static.pubmed.gov @1.0.0.1
pubmedgov.wip.ncbi.nlm.nih.gov.
130.14.29.109
The only one that didn’t respond was the 1.0.0.2, but it’s experimental and shouldn’t be used in production - anyway, I hadn’t observed this situation for any other domain until now.
PS: www.ncbi.nlm.nih.gov resolves from all three.
Yeah as far as i know i’ve not had issues with any other domains.
No problems with the others
C:\Users\User>nslookup pubmed.gov
Server: one.one.one.one
Address: 1.1.1.1
Non-authoritative answer:
Name: pubmed.gov
Addresses: 2607:f220:41e:4290::109
130.14.29.109
C:\Users\User>nslookup ncbi.nlm.nih.gov
Server: one.one.one.one
Address: 1.1.1.1
Non-authoritative answer:
Name: ncbi.nlm.nih.gov
Addresses: 2607:f220:41e:4290::110
130.14.29.110
with el goog
C:\Users\User>nslookup static.pubmed.gov
Server: dns.google
Address: 8.8.8.8
Non-authoritative answer:
Name: pubmedgov.wip.ncbi.nlm.nih.gov
Addresses: 2607:f220:41e:4290::109
130.14.29.109
Aliases: static.pubmed.gov
Thanks for reporting this issue. Our team will be investigating it.
1 Like
I’m unable to reach NIH from the UK at the moment. Is there a bad server address in there and some kind of DNS based load balancing going on? I’ve not had this problem before and I use PUBMED all the time.
Cloudflare:
Lookup has started…
pubmed.ncbi.nlm.nih.gov → The operation couldn’t be completed. (kCFErrorDomainCFNetwork error 2.)
Google:
Lookup has started…
pubmed.ncbi.nlm.nih.gov → 34.107.134.59
Hi @grant.wray!
What’s the plain text output you get from the following commands?
dig +tcp +short @1.1.1.1 id.server ch txt
dig +trace @1.1.1.1 pubmed.ncbi.nlm.nih.govOf course, today it’s working correctly!
> "LHR"
>
> ; <<>> DiG 9.10.6 <<>> +trace @1.1.1.1 pubmed.ncbi.nlm.nih.gov
> ; (1 server found)
> ;; global options: +cmd
> . 517695 IN NS a.root-servers.net.
> . 517695 IN NS b.root-servers.net.
> . 517695 IN NS c.root-servers.net.
> . 517695 IN NS d.root-servers.net.
> . 517695 IN NS e.root-servers.net.
> . 517695 IN NS f.root-servers.net.
> . 517695 IN NS g.root-servers.net.
> . 517695 IN NS h.root-servers.net.
> . 517695 IN NS i.root-servers.net.
> . 517695 IN NS j.root-servers.net.
> . 517695 IN NS k.root-servers.net.
> . 517695 IN NS l.root-servers.net.
> . 517695 IN NS m.root-servers.net.
> . 517695 IN RRSIG NS 8 0 518400 20210508050000 20210425040000 14631 . VRowJ98FAdfO9wGKjJRrm1llMgqsIy2i9NQ9teQyO4J71s5S2NdD/GG7 x4ssMnkmZ1BSVE8jWQjP2uPuzYxK++ILDLM5pjCdbpbcJlOQSqWgAF0a zCjHmGuh14r29m0C8jm+mqRZ83ioEtcYgzmiEMLzREx7OCYZM14XnP2o l5aSe1Cx495WGCGvy8E1ugUn5ZAUygdduDVGHBeNWApfAAKqmTttnO0m YBCzVTgvzPJecHcdiuTZrpDTtfzgCb9tMAd5+QUdfPMTsb4cKisAvd8a m7lGdrgV1dQiwzwL2urSJpToA3N2pVpuPuFtcpt5O8vvUjEcOihgOfaT VudmBg==
> ;; Received 525 bytes from 1.1.1.1#53(1.1.1.1) in 14 ms
gov. 172800 IN NS a.gov-servers.net.
gov. 172800 IN NS b.gov-servers.net.
gov. 172800 IN NS c.gov-servers.net.
gov. 172800 IN NS d.gov-servers.net.
gov. 86400 IN DS 7698 8 2 6BC949E638442EAD0BDAF0935763C8D003760384FF15EBBD5CE86BB5 559561F0
gov. 86400 IN RRSIG DS 8 1 86400 20210508050000 20210425040000 14631 . O2CzA/q8R7mh31A7mzdb1OTF7RgjeVEfVd+xMtBs55PVzlY7dzUB3C67 d1f1HhyBIfrjPdJF6Vubjqn2F4fykE0NvjBZOrC99yEURLwP+Ac4w32B Onfiy3f+BF5JOeFK1luALKRHFbAbeYIsG4L803YmTMzeh4KyN3/XiNCx dqHjITg2s+c32T2MsimGX0qKGQurRn4ogfdv2aGFR/ZOhywiPP0aT5vw KxgTbsLT5wBQhmWc4XHS4wiXUiBICk4wd5xTY0WTVTAppfPHso0MsVlg VzxyOe6bbPtkxA+F15VXC8AMMBlxLkZluRxfPu51RjYL3moHo7WJuR0v dsoXFQ==
;; Received 642 bytes from 198.97.190.53#53(h.root-servers.net) in 26 ms
nih.gov. 86400 IN NS ns.nih.gov.
nih.gov. 86400 IN NS ns3.nih.gov.
nih.gov. 86400 IN NS ns2.nih.gov.
nih.gov. 3600 IN DS 18384 7 2 A11B5272ABC52150EFAD05ABB5625254537EC9C148450CEA3C7A63DB 42EAB5CE
nih.gov. 3600 IN DS 18384 7 1 187CAD6C17B96809AC334FCF6841C2AB3989655E
nih.gov. 3600 IN RRSIG DS 8 2 3600 20210502051007 20210425051007 48498 gov. sLCaN4GpwA/2MJl0M7X5cGAlb0qz6SRJXeZZC9MWUsliT4SuRDuUEY8m 4+2jq6ofPVM/kP34jjzEOB9NfEzIcrWsD9YlPcEHKubNQi15g99MRFNr ya5waPaSiA/tdd4oJjGHoAUkYFKo+owCGp8Q1aLQCpjcYcz6lIY+lltQ 8MkNG2f4RBWQBOOrOJGJYFJfMJgr1e8PUzlqH8Io5fimrA==
;; Received 432 bytes from 69.36.153.30#53(c.gov-servers.net) in 28 ms
pubmed.ncbi.nlm.nih.gov. 3600 IN CNAME pubmed20.wip.ncbi.nlm.nih.gov.
pubmed.ncbi.nlm.nih.gov. 3600 IN RRSIG CNAME 7 5 3600 20211017104002 20210420104002 52670 ncbi.nlm.nih.gov. T39vgpKf5jz71itwJWgULcFdcwasRFL6SbRZFHwqBzvfNmf+CBjKLGM4 SLw6xmM4OxKkL61GrKm4ZDjTk9ZyVJt5GjZWSWD4to8oXP4VsvLpMHvZ avOoVuy3XnRvimHPbOarga5LOWHKqRz/+HExW7CVVMlSVUK5eLh26G13 DcYOxtqE24Yyhgkbegi+n+PrMrygg6lan4UqEuoNbr8vpBW1SFbloCke JZUiqufQiQy+C6rG43AlQBuB1q6MswoQ0EX8BKr4TeRPtXIJbQuRTG5V bVBM6zdi/lW1isNLrVUWYQ2PXR0RzQcbK2LxypFJNIH84PFw+BnHTjln VZPq2g==
wip.ncbi.nlm.nih.gov. 7200 IN NS gslb01.nlm.nih.gov.
wip.ncbi.nlm.nih.gov. 7200 IN NS gslb02.nlm.nih.gov.
wip.ncbi.nlm.nih.gov. 7200 IN NS gslb03.nlm.nih.gov.
wip.ncbi.nlm.nih.gov. 86400 IN DS 24081 7 1 2736D36D4CF83E5E2CF26D4512B218988BB6B7A1
wip.ncbi.nlm.nih.gov. 86400 IN RRSIG DS 7 5 86400 20211017104002 20210420104002 52670 ncbi.nlm.nih.gov. MPnBixHkQ6snEUKD9wH6efqGMYsXMVsV39VJanVxryWsUB+Vy1iA1SsJ hIw78j2oKFhQUs0cZYjbfw4n49kuf+aq62iPzDaImYxuWQP7Heaju7uE UY2k7bzPqBK8XvsBHgUqtkhXQgJCTOUjt9FsVbsBEAORPx8HOWh8U5Bv d/C0q6yDTGTi27JPGSifRm15ul4b9DVMDfq+wsn8h8a+UObOJb46cTH4 JaQa1tow4Ufs8e54UymIO3u4EEQ2Qf7Ji+uCWBAbFxsfqyLVkZy1kLov Zn3MiplUSaOOOPeQj5dloWGTiNn1xjw/PGMcSFzwozBCyknqaW+WE5NI UGJHWQ==
;; Received 1944 bytes from 165.112.4.230#53(ns3.nih.gov) in 108 ms