[DNS Resolver] unable to resolve paypal.com sometimes
-
Hi,
I activated Unbound on my pfsense appliance, and I'm unable accessing paypal.com sometimes. I make a "dig paypal.com" on different computers, and this is the same answer : no ip for paypal.com . Now it's working, maybe tomorrow it won't work.
Pfsense up-to-date (2.3.2), DNS server configured are :
127.0.0.1
80.67.169.12
80.67.169.40
2001:910:800::12
2001:910:800::40On "DNS Resolver", these option are activated :
DNSSEC Support
Forwarding Mode
Register DHCP leases in the DNS Resolver
Register DHCP static mappings in the DNS ResolverI don't know how to investigate this problem. I think i didn't setup correctly something, but i don't figure what… Could you help me?
Megagolgoth
-
" Forwarding Mode"
Well ask ns your forwarding to why its not resolving.. Do all of your forwarders support dnssec? If your going to use the forwarder mode, you might as well just use actual forwarder atleast it can ask all of your forwarders all at the same time and use the first response. With unbound it asks 1 at a time. So if your first one doesn't answer then yeah you can have timeouts, etc.
When you did, your asking pfsense or some other dns directly on your clients. What is the status of your response when you query?
dig paypal.com
; <<>> DiG 9.10.4-P2 <<>> paypal.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 754
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 4, AUTHORITY: 4, ADDITIONAL: 1;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;paypal.com. IN A;; ANSWER SECTION:
paypal.com. 300 IN A 64.4.250.24
paypal.com. 300 IN A 64.4.250.23
paypal.com. 300 IN A 66.211.169.3
paypal.com. 300 IN A 66.211.169.66;; AUTHORITY SECTION:
paypal.com. 300 IN NS ns2.p57.dynect.net.
paypal.com. 300 IN NS ns1.p57.dynect.net.
paypal.com. 300 IN NS ns4.p57.dynect.net.
paypal.com. 300 IN NS ns3.p57.dynect.net.;; Query time: 34 msec
;; SERVER: 192.168.9.253#53(192.168.9.253)
;; WHEN: Sun Aug 07 05:39:48 Central Daylight Time 2016
;; MSG SIZE rcvd: 189You will notice that the TTL of paypal is very short 5 minutes.. so yeah if your having issues with your dns and it has to ask over and over and over again because of the short ttl then sure your problem going to see problems with it resolving. I show paypal.com dnssec valid, but maybe your forwarder does not support it?
-
Hi,
For the moment i'm not able getting a resolution for paypal.com :
$ dig paypal
; <<>> DiG 9.10.3-P4-Ubuntu <<>> paypal
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 62276
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1280
;; QUESTION SECTION:
;paypal. IN A;; AUTHORITY SECTION:
. 39199 IN SOA a.root-servers.net. nstld.verisign-grs.com. 2016090700 1800 900 604800 86400;; Query time: 92 msec
;; SERVER: 127.0.1.1#53(127.0.1.1)
;; WHEN: Wed Sep 07 20:46:24 CEST 2016
;; MSG SIZE rcvd: 110I didn't know much on DNS stuf…
-
Check the Resolver Logs, maybe restart it so it will log messages.
-
"dig paypal"
You didn't ask for www.paypal.com you ask for paypal. which yea not going to resolve and you got told go ask the root servers..
-
I don't know how to investigate this problem. I think i didn't setup correctly something, but i don't figure what… Could you help me?
And do you need to use the Forwarding mode, why not leave the DNS Server lines empty and use unbound with Forwarding mode disabled ?
-
I am curious what your using for dns??
;; SERVER: 127.0.1.1#53(127.0.1.1)
Tells me you asked the local host that you did the query on that was running some sort of caching dns? Which is setup to do what resolver or forward, forward to where? But again yeah paypal. is never in a million years going to resolve no matter what you are using.. Its not a valid fqdn on the public internet.
-
"dig paypal"
You didn't ask for www.paypal.com you ask for paypal. which yea not going to resolve and you got told go ask the root servers..
You're right so :
dig paypal.com; <<>> DiG 9.10.3-P4-Ubuntu <<>> paypal.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 64506
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;paypal.com. IN A;; Query time: 73 msec
;; SERVER: 127.0.1.1#53(127.0.1.1)
;; WHEN: Wed Sep 07 21:53:37 CEST 2016
;; MSG SIZE rcvd: 3 -
";; SERVER: 127.0.1.1#53(127.0.1.1)"
So what are you running on 127.0.1.1 (localhost) clearly your not on pfsense, clearly your not asking pfsense - so what is running on that box for dns?
Do a dig direct to one of their authoritative servers..
example
[2.3.2-RELEASE][root@pfSense.local.lan]/root: dig @ns1.p57.dynect.net paypal.com; <<>> DiG 9.10.4-P2 <<>> @ns1.p57.dynect.net paypal.com
; (2 servers found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 20591
;; flags: qr aa rd; QUERY: 1, ANSWER: 2, AUTHORITY: 4, ADDITIONAL: 1
;; WARNING: recursion requested but not available;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;paypal.com. IN A;; ANSWER SECTION:
paypal.com. 300 IN A 64.4.250.23
paypal.com. 300 IN A 64.4.250.24;; AUTHORITY SECTION:
paypal.com. 300 IN NS ns1.p57.dynect.net.
paypal.com. 300 IN NS ns3.p57.dynect.net.
paypal.com. 300 IN NS ns4.p57.dynect.net.
paypal.com. 300 IN NS ns2.p57.dynect.net.;; Query time: 16 msec
;; SERVER: 208.78.70.57#53(208.78.70.57)
;; WHEN: Wed Sep 07 20:01:54 UTC 2016
;; MSG SIZE rcvd: 157 -
I deactivate the "Enable Forwarding Mode", and it's working better.
-
again your not asking pfsense your asking something running on that local host you ran that command 127.0.1.1 is a loopback address it is only the local machine, just the same as 127.0.0.1, pfsense doesn't use that for dns, nor does pfsense out the box have dig. So your running it on some other box that is asking itself. Which then in turn does what? Forwards to pfsense, forwards somewhere else?
Yes if you have pfsense in forwarder mode, and that forwarder or connection to that forwarder is bad then your going to have issue. Pfsense is resolver mode will walk down from roots. Which may or may not take a few ms longer depending on your network connectivity, etc. But you are always sure your getting the info direct from the horses mouth..
For all we know what your forwarding is taking a long time.. And the second time you tried it had gotten an answer and cached it… What was the ttl on you return query that worked?
-
You're right
#netstat -tulpn |grep 53
tcp 0 0 192.168.122.1:53 0.0.0.0:* LISTEN 3985/dnsmasq
tcp 0 0 127.0.1.1:53 0.0.0.0:* LISTEN 3302/dnsmasq
udp 0 0 0.0.0.0:5353 0.0.0.0:* 2597/avahi-daemon:
udp 0 0 192.168.122.1:53 0.0.0.0:* 3985/dnsmasq
udp 0 0 127.0.1.1:53 0.0.0.0:* 3302/dnsmasq
udp6 0 0 :::5353 :::* 2597/avahi-daemon:and
$ ps aux | grep 3985
libvirt+ 3985 0.0 0.0 49984 2560 ? S 07:03 0:00 /usr/sbin/dnsmasq –conf-file=/var/lib/libvirt/dnsmasq/default.conf --leasefile-ro --dhcp-script=/usr/lib/libvirt/libvirt_leaseshelperIt's related to Qemu/KVM and LibVirt.
I think those provide a relay for VM and system through dnsmasq for the DNS, but dnsmasq is forwarding with no cache
-
so it doesn't cache? that is pointless.. Where does it forward? What is is config?
-
dnsmasq conf :
cat /var/lib/libvirt/dnsmasq/default.conf
[sudo] Mot de passe de dje :
##WARNING: THIS IS AN AUTO-GENERATED FILE. CHANGES TO IT ARE LIKELY TO BE
##OVERWRITTEN AND LOST. Changes to this configuration should be made using:
## virsh net-edit defaultor other application using the libvirt API.
dnsmasq conf file created by libvirt
strict-order
user=libvirt-dnsmasq
pid-file=/var/run/libvirt/network/default.pid
except-interface=lo
bind-dynamic
interface=virbr0
dhcp-range=192.168.122.2,192.168.122.254
dhcp-no-override
dhcp-lease-max=253
dhcp-hostsfile=/var/lib/libvirt/dnsmasq/default.hostsfile
addn-hosts=/var/lib/libvirt/dnsmasq/default.addnhosts
