Potential DNS Forwarder Bug
-
I've run into this issue several times now over at least two different release versions, over the past few months at 2 different locations, with it recurring at one of them at least 3 times that I'm aware of.
It seems that somehow the DNS Forwarding service gets "stuck" and refuses to pass any A records when AAAA records exist. A reboot of the service does correct the issue however.
Forwarder is configured to forward to our internal AD/DNS server which then queries the ISP server, however queries directly to it and the ISP server resolve correctly.
Does this seem like a bug? Or is there just some config issue on my side?
> mail.google.com Server: UnKnown Address: 10.0.0.1 Non-authoritative answer: Name: googlemail.l.google.com Address: 2607:f8b0:400a:801::1016 Aliases: mail.google.com ## Restart DNS Forwarder Service ## > mail.google.com Server: UnKnown Address: 10.0.0.1 Non-authoritative answer: Name: googlemail.l.google.com Addresses: 2607:f8b0:400a:801::1016 173.194.33.53 173.194.33.54 Aliases: mail.google.com -
You sure its just not a mismatch in the TTL and your happen to hit a query when the A records have expired compared to the AAAA
What client was this from? you sure your doing q query type any query, or did you just doing a specific A or AAAA query, etc
If you see it again, try doing a specific query for the one your missing be it AAAA or A
-
Client was nslookup under Windows 7, just doing a basic query request no changes to default settings made.
I don't believe it was a TTL issue, as several queries were made over a period of a few minutes. (Our ISP has no IPv6 connectivity, any results returned like this effectively black hole the site. As such this tends to be the first indication we receive of these issues, followed up by the troubleshooting I performed a few minutes later, so the Forwarder would have returned these results at least twice (Once for OS/Browser and once for nslookup) over approximately a 2-3 minute span.
I'll do a more through test of query types and such next time I see this.
-
The DNS forwarder and DNS servers in general don't have anything to do with whether you get an A or AAAA, they return what the client asks for. If you're getting v6 it's because your client is requesting an AAAA. It's not possible for an AAAA to be returned for an A query.
-
Well the ttl for that record is 300 seconds, so a 2 - 3 minutes is well within that span.
Yeah your going to have to verify, but if windows 7 has ipv6 enabled Im pretty sure it sends a sends AAAA first, before A - so its quite possible that if AAAA was still cached you got an answer for that, but nothing for A and might not have even done the query?
If you Don't want to use ipv6 in your network, and you don't want AAAA returned I would suggest you completely disable IPv6 on your clients.
Simple
reg add hklm\system\currentcontrolset\services\tcpip6\parameters /v DisabledComponents /t REG_DWORD /d 255Would do it on the windows machines. But cmb is correct you shouldn't be getting back answers you did not query for, so either you did a query for ANY or you did both a AAAA and A query.. Which order they went out in would be up to how you have configured your machine I would assume. Windows will like ipv6 over ipv4 I am sure of that.
So I have my windows box tweaked to prefer ipv4 over ipv6 even though I have ipv6 enabled. In that reg key I stated above I use
0x20 to prefer IPv4 over IPv6 by changing entries in the prefix policy table.Not sure if that changes the behavior of how the queries go out, but testing with nslookup - seems to send out A first in my case. You would have to sniff how your queries go out when your browser asks for them.
Now I do believe that there is RFC to be able to combine multiple requests in 1 query, but I doubt that is happening. I would have to assume your sending 2 different queries and getting back answers fast enough to put them in your nslookup response. Or your doing a Any query?
Need to verify your doing a specific A query, since yes I agree if you do a A query and there is no record for it - then dnsmasq should go out and do a query for it. Even if delayed too much in response that your nslookup doesn't see it - in the next query you should.
Need to verify exactly what query types your requesting. If you asking for A and not getting it, and you think its because dnsmasq is not forwarding the request?? Guess you could verify that by doing a sniff on the wan of pfsense to see if the query for A goes out to your forwarders, do you get a response?
Or its also possible you have run into something where your dnsmasq is just not forwarding any queries at all, and your just getting back what is in its cache? And in your case only AAAA is there, so that is what you get back. They are different records, and can have different TTLs so its possible that 1 expires before the other by quite some time, depending.
-
Ok, so it took awhile until I ran into this again, but here are my results.
It does seem to be TTL related, as it did resolve itself around the 5 minute mark, however there are still issues that may need to be looked at.
The nslookup queries from below are not the only tests I ran, so any delayed results as mentioned previously should most certainly have resulted in a correct response later. Both upstream dns servers configured on the pfsense device returned correct results, albeit slightly newer.
I didn't manage to grab a sniff of the traffic before the issue corrected itself, but I will make sure I do that first thing the next time this pops up.
C:\Users\Mikuki>nslookup Default Server: UnKnown Address: 10.20.20.1 > mail.google.com Server: UnKnown Address: 10.20.20.1 Non-authoritative answer: Name: googlemail.l.google.com Address: 2607:f8b0:400a:801::1016 Aliases: mail.google.com > server 8.8.8.8 Default Server: google-public-dns-a.google.com Address: 8.8.8.8 > mail.google.com Server: google-public-dns-a.google.com Address: 8.8.8.8 Non-authoritative answer: Name: googlemail.l.google.com Addresses: 2607:f8b0:400a:800::1016 173.194.33.21 173.194.33.22 Aliases: mail.google.com > server 10.20.20.1 Default Server: [10.20.20.1] Address: 10.20.20.1 > mail.google.com Server: [10.20.20.1] Address: 10.20.20.1 Non-authoritative answer: Name: googlemail.l.google.com Address: 2607:f8b0:400a:801::1016 Aliases: mail.google.com > set type=aaaa > mail.google.com Server: [10.20.20.1] Address: 10.20.20.1 Non-authoritative answer: Name: googlemail.l.google.com Address: 2607:f8b0:400a:801::1016 Aliases: mail.google.com > set type=a > mail.google.com Server: [10.20.20.1] Address: 10.20.20.1 Non-authoritative answer: Name: mail.google.com >
