DNS Resolver - getting IPv6 results when there is no IPv6?
-
Incidentally, both C and Python have a gethostbyname() function. I don't see any mention of choosing IPv4 or IPv6.
-
@Gertjan Some of the devices (like my work-issued laptop) I can't change any settings because I'm not an administrator. Others aren't my computers (roomates, friends when we aren't in lockdown for a pandemic, smartphones that have IPv6 when they are on 4G) and probably shouldn't be changed.
I've already tried the block-IPv6 checkbox (I've had an ISP before with broken IPv6 implementation and had to use that before we moved) didn't seem to make a difference so I put it back to allowed.
My Linux Mint box (main machine) I have a "Scope:Link" IPv6 address when I look at ifconfig but no global IPv6 address...and the router has no IPv6 address for the WAN.
I'll try and find the right filters to capture only DNS traffic in Wireshark and see if I can make any sense of what apps are requesting (if I can reproduce it...)
EDIT: That was quicker than I expected...yeah seems command line 'ftp' is asking for AAAA records. I don't understand why though, or what to do about it yet..
I do notice, this time it listed both IPs on the command line...I think when I have trouble it only lists the IPv6. So maybe that's something with when my upstream DNS hickups on one of the queries somehow?
Resolving cddis.nasa.gov (cddis.nasa.gov)... 198.118.242.40, 2001:4d0:241a:442::52 Connecting to cddis.nasa.gov (cddis.nasa.gov)|198.118.242.40|:21... connected. Logging in as anonymous ... Logged in!EDIT2:
And while I didn't happen to have wireshark up at the try when it reproduced the error, sure enough I got a different result on the temrinal...Resolving cddis.nasa.gov (cddis.nasa.gov)... 2001:4d0:241a:442::52 Connecting to cddis.nasa.gov (cddis.nasa.gov)|2001:4d0:241a:442::52|:21... failed: Connection timed out. -
@mmiller7 said in DNS Resolver - getting IPv6 results when there is no IPv6?:
And while I didn't happen to have wireshark up
You can always use Packet Capture and download the capture so you can read it with Wireshark.
-
Finally reproduced during capture. I think I see why it's not using IPv4, but I don't know why it's having a server-failure code?
-
Well will ya look at that there -- client did a AAAA query - who would of thunk it there @JKnott...
Why would it it do that I wonder????? He doesn't have an IPv6 address... <rolleyes>
As to why your getting back SERVFAIL... your going to have to follow those breadcrumbs... resolves here just fine.
;cddis.nasa.gov. IN A ;; ANSWER SECTION: cddis.nasa.gov. 3599 IN CNAME ftp.cddis.eosdis.nasa.gov. ftp.cddis.eosdis.nasa.gov. 14399 IN A 198.118.242.40Its a cname, so maybe you have problem with the cname... Part of the problem when you throw your dns over the fence to someone like 1.1.1.1 or 8.8.8.8 and it doesn't work.. Its a black box... Now resolving on the other hand.. That you just see why - does the authoritative ns not answer, walk the tree down to see where it has problem... Other then hey googledns whats IP for www.domain.tld??
In your sniff - your dns query took 2.25 seconds to get a response.. Dude all kinds of shit would fail.. why do you have such a long response time.. A common timeout for dns is 2 seconds, then would switch over to tls maybe.. Maybe that worked.. I would take a serious look to your dns if that is typical??
Your query should be ms, not whole seconds..
A query to say 1.0.0.1 was 11ms for that.
;; Query time: 11 msec ;; SERVER: 1.0.0.1#53(1.0.0.1) -
And probably 80% of the time it (and other sites) resolve just fine here. Then randomly it won't.
Is there somewhere on pfSense that I don't know about where it may be logging what happened or what failed to respond? Is there a way to make it log failures to get responses from upstream without logging the billions of good requests from everything all over my network to wade thru?
Since it's infrequent that it fails, I don't know how I can easily tell where it's failing without some kind of logs to analyze.. pfSense is the DNS server for everything on my LAN, then it sends it off to the upstream servers. I would have thought with 4 DNS servers from 2 providers it should be able to resolve reliably from one of them? Does it not try others if the first doesn't answer?
-
You got an answer... It was FAIL, and it took 2.25 seconds.. That is not correct..
How long does something that is not cached locally take to respond? typically?
-
@mmiller7 said in DNS Resolver - getting IPv6 results when there is no IPv6?:
Does it not try others if the first doesn't answer?
It does, after timeout... Which quite often the client has already given up... And your not asking 4, your using 4 different IPs for 2 different services that are both anycast... The odds that one of those would fail and the other pass is just not realistic..
Servfail is not timeout.. So why would it check the other one - why would NS x be able to resolve it, while others said its broken!
If you want to blast multiple ns and get the first response - then use dnsmasq as the forwarder.. It does that out of the box, but can be switched to sequential mode. Unbound would be sequential..
Off the top I don't know you can not just log servfail ;) highly unlikely. But your client can give you that right away... Just query with something that you can see the actual response with, other than just some application client.
First thing would of done when you were just getting back IPv6 in your ftp client would of did a dig to that fqdn to see what was coming back..
dig
host
nslookupAll would of shown you the servfail response.. You could put nslookup debug mode to get more info... But dig is really the tool of choice..
Also 80% of the time is HORRIBLE... 99.999% of the time is how dns should work and you shouldn't even have to think about it.. If your having so many issues that you just off the top of your head throw out it works 80% of the time, you got some serious problems...
-
My understanding of dnsmasq is it is just a forwarder - doesn't have the same features I'm using (local DNS resolution, VPN/DHCP/static DNS, DNSSEC, SSL/TLS, Query Name Minimization, Prefetch caching, etc.
While my internet is fast, there is sometimes high latency (I've had hours of multi-second PING replies) and low speeds (like 40-100Mbps instead of 500Mbps as usual for my Gigabit))/low packet loss (around 0.1-0.2% for a short bit usually at least 1 day a week according to the pfSense graphs) so I try to utilize a number of the pfSense caching features because it can make a noticeable performance difference at peak times (evenings/weekends). ISP's answer is "its working right now" and "we have high demand right now" when I call. I've also ruled out my pfSense box for those issues going straight to the modem, so I have to live with that.
The more strange thing, these issues really do seem to have cropped up in just the past ~2 weeks. It started a few days before I realized 2.4.5 was released (I noticed when I logged in to check why things were acting up).
-
So your doing DOT - that would explain your 80% success rate and shit response time of 2.25 seconds vs couple of ms..
You understand when you forward..Where you forward does dnssec or doesn't.. If it doesn't you asking for it does squat!! So yeah if you forward to dns that is doing dnssec, you auto get dnssec... So that doesn't matter.. You want dnssec support in unbound because its a RESOLVER.. Your using it as just a forwarder - so pointless what features it supports or doesn't your just asking something upstream..
If your concern is OMG my isp might be sniffing that I want to go to ftp.nasa.gov - and you don't have a normal vpn you can hide that from them... Then ok that would necessitate utter shit for dns performance by forwarding everything to xyz over tls..
Seems to me all your pain is self inflicted because you feel your dns is spying on your dns queries and you trust both cloudflare and google so much more that your just going to hand them all your dns queries, all of them.. And why not make it slower to boot.. Because ya know what dns was a bit too fast before ;) So I want to complicate the shit out of it, and slow it down over encrypted tls..
And then just use a wide open protocol that is not encrypted to grab some stuff via ftp, that my isp can just see everything I grab anyway - but you know F them for being able to see dns query for it ;) hehehehe
-
@johnpoz said in DNS Resolver - getting IPv6 results when there is no IPv6?:
You got an answer... It was FAIL, and it took 2.25 seconds.. That is not correct..
How long does something that is not cached locally take to respond? typically?
When it works correctly it seems more or less instant. Looking at the one Wireshark where it worked maybe 0.1 second or less between the request and reply that had an IP?
I notice now in the one that did work when I captured it got SERVFAIL for both A and AAAA followed by a success on both. I don't understand that either.
@johnpoz said in DNS Resolver - getting IPv6 results when there is no IPv6?:
Servfail is not timeout.. So why would it check the other one - why would NS x be able to resolve it, while others said its broken!
Seems like in my case, that is the case though. Sometimes it can't be resolved by at least one (still don't know how to tell WHICH upstream one was queried if it stops at the first "dunno" reply?)
I see this at work annoyingly often where one DNS server (they use MS AD servers) will be "fussy" and return failures when another works, for some reason it mainly seems to affect Linux clients not Windows there. Go figure.
Off the top I don't know you can not just log servfail ;) highly unlikely. But your client can give you that right away... Just query with something that you can see the actual response with, other than just some application client.
Just tried 'dig' from my computer and I don't see where it gives me much useful. Got a fail from pfSense 192.168.1.1, but why? Which upstream failed? I wish I had like a DNS Traceroute.
matthew@Inspiron13-7378 $ dig cddis.nasa.gov ; <<>> DiG 9.10.3-P4-Ubuntu <<>> cddis.nasa.gov ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 26682 ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4096 ;; QUESTION SECTION: ;cddis.nasa.gov. IN A ;; Query time: 2444 msec ;; SERVER: 192.168.1.1#53(192.168.1.1) ;; WHEN: Sat Apr 04 10:55:46 EDT 2020 ;; MSG SIZE rcvd: 43 matthew@Inspiron13-7378 $ dig cddis.nasa.gov ; <<>> DiG 9.10.3-P4-Ubuntu <<>> cddis.nasa.gov ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 22536 ;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4096 ;; QUESTION SECTION: ;cddis.nasa.gov. IN A ;; ANSWER SECTION: cddis.nasa.gov. 593 IN CNAME ftp.cddis.eosdis.nasa.gov. ftp.cddis.eosdis.nasa.gov. 14393 IN A 198.118.242.40 ;; Query time: 263 msec ;; SERVER: 192.168.1.1#53(192.168.1.1) ;; WHEN: Sat Apr 04 10:55:51 EDT 2020 ;; MSG SIZE rcvd: 90Also 80% of the time is HORRIBLE... 99.999% of the time is how dns should work and you shouldn't even have to think about it.. If your having so many issues that you just off the top of your head throw out it works 80% of the time, you got some serious problems...
I can't disagree there! Used to be rock solid and I never did think about it.
-
@johnpoz said in DNS Resolver - getting IPv6 results when there is no IPv6?:
So your doing DOT - that would explain your 80% success rate and shit response time of 2.25 seconds vs couple of ms..
Why would it have just recently happened then? Previously it's been quite solid for a couple years.
You understand when you forward..Where you forward does dnssec or doesn't.. If it doesn't you asking for it does squat!! So yeah if you forward to dns that is doing dnssec, you auto get dnssec... So that doesn't matter.. You want dnssec support in unbound because its a RESOLVER.. Your using it as just a forwarder - so pointless what features it supports or doesn't your just asking something upstream...
How is it "just a forwarder" if it's also providing DNS for my LAN hosts to find each other? Upstream DNS has no idea what my local hosts are...clearly it's doing SOMETHING.
If your concern is OMG my isp might be sniffing that I want to go to ftp.nasa.gov - and you don't have a normal vpn you can hide that from them... Then ok that would necessitate utter shit for dns performance by forwarding everything to xyz over tls..
Seems to me all your pain is self inflicted because you feel your dns is spying on your dns queries and you trust both cloudflare and google so much more that your just going to hand them all your dns queries, all of them.. And why not make it slower to boot.. Because ya know what dns was a bit too fast before ;) So I want to complicate the shit out of it, and slow it down over encrypted tls..
Everything I read keeps saying that things should be moving to encrypted...heck lately the trend is individual apps moving to DoH which introduces all sorts of new problems like not being able to resolve LAN addresses anymore without extra steps to disable it. So you're saying all the rest of everywhere saying to use it is wrong?
And again, it was working for better than a year without monkeying with DNS at all...until a couple weeks ago.
I also am not fond of the ISP's DNS servers that redirect unknown lookups to random sketchy search sites. Which more often than not, ends up happening when I mis-type something and end up somewhere I really don't want to be. That's more what I'm concerned about protecting against...somehow having my DNS queries modified without my consent and returning something they shouldn't.
And then just use a wide open protocol that is not encrypted to grab some stuff via ftp, that my isp can just see everything I grab anyway - but you know F them for being able to see dns query for it ;) hehehehe
Well, I'd find HTTP/HTTPS more convenient (I hate FTP, it's a pain) but being the government I suppose they have some rule that says it has to be obsolete. This just happened to be something I can reproduce (or notice?) more often with the DNS problem than other websites, and notice more being that it's a more painful process to fetch files. The whole having to "log in" adds more steps that makes it slower too vs a simple HTTP request. But I can't change the host that what I am interested in is on.
-
@mmiller7 said in DNS Resolver - getting IPv6 results when there is no IPv6?:
Previously it's been quite solid for a couple years.
Really you been running dot for 2 years? Just you jumped on it like day one? As to why it could of recently happened - I don't know the whole planet in their houses doing internet could have something to do with it ;) heheh
How is it "just a forwarder" if it's also providing DNS for my LAN hosts to find each other?
You mean like every single caching NS since the beginning of DNS has done?
Here is the thing - if you have problems with a client connecting to something - just check the dns with a simple cmd.. It takes like .3 seconds to do.. You don't have to sniff.. To see what dns is responding to you with.. Be it the record in X amount time, from cache or had to forward or resolve, or servfail, or NX, etc. etc.
I also am not fond of the ISP's DNS servers that redirect unknown lookups to random sketchy search sites
Nobody does - doesn't mean you have to forward to somewhere, resolve fixes that nonsense - and you get the info direct from the horses mouth...
BTW if you don't want your local NS (unbound) to return IPv6, you can do that with simple
private-address: ::/0In your unbound custom option box.. But that wouldn't of solved your issue, still wouldn't of work with you not being able to resolve the A record for the fqdn you were trying to get to.
-
@johnpoz said in DNS Resolver - getting IPv6 results when there is no IPv6?:
@mmiller7 said in DNS Resolver - getting IPv6 results when there is no IPv6?:
Previously it's been quite solid for a couple years.
Really you been running dot for 2 years? Just you jumped on it like day one? As to why it could of recently happened - I don't know the whole planet in their houses doing internet could have something to do with it ;) hehehActually yeah...started playing TLS back when it required manually adding entries to the config file because it wasn't a checkbox, and at that time also had to go thru figuring out which other web DNS hosts supported it. There weren't many! Once I fixed it so I only had DNS servers that properly supported DNSSEC and TLS as the only ones for pfSense to look at, things went very smooth from there on with no noticeable change in performance. Obviously if you put in a server that doesn't support the security features it breaks badly. Once I got it, I didn't touch it not wanting to break it more.
I think it was around the same time I discovered my ISP (Cox back where I lived at the time) was injecting code into HTTP pages, altering the pages in-flight to provide in-browser updates about their email services which was REALLY not cool. That's when I became more paranoid about my ISP tampering with my data.
Not so much I'm worried about ISP spying...but I do want some assurance the bits I get are the bits that were sent to me, unaltered by anyone inbetween. Which I don't think is an unreasonable expectation, and DNSSEC+TLS seemed a reasonable step to take given what I observed with plan HTTP traffic being modified at one point. I used to think it was stupid, until I had that experience. Now I (as much headache as it adds) agree it's worthwhile to add encryption to stuff in-flight.
That's my take on it anyway. I wish it wasn't necessary.
How is it "just a forwarder" if it's also providing DNS for my LAN hosts to find each other?
You mean like every single caching NS since the beginning of DNS has done?
Here is the thing - if you have problems with a client connecting to something - just check the dns with a simple cmd.. It takes like .3 seconds to do.. You don't have to sniff.. To see what dns is responding to you with.. Be it the record in X amount time, from cache or had to forward or resolve, or servfail, or NX, etc. etc.
I do, but this intermittent nature seems hard to figure out. If the application fails and I run the dig command it all looks good, now what? Run it again the app works. Later repeat. Drives me nuts.
I also am not fond of the ISP's DNS servers that redirect unknown lookups to random sketchy search sites
Nobody does - doesn't mean you have to forward to somewhere, resolve fixes that nonsense - and you get the info direct from the horses mouth...
I am under the impression "Query Name Minimization" helps with that? I would rather go to the most direct source possible when I can.
BTW if you don't want your local NS (unbound) to return IPv6, you can do that with simple
private-address: ::/0In your unbound custom option box.. But that wouldn't of solved your issue, still wouldn't of work with you not being able to resolve the A record for the fqdn you were trying to get to.
I'll give that a shot. If I can at least make it so it fails completely vs getting an address that it thinks is good but can't possibly work, that would be an improvement (in my eyes).
