Hi Joe, The domain whatsapp.com doesn't guarantee integrity to you (they have dnssec turned off, at least last I checked). It's possible that someone got in your middle and inserted a bogus record. This being said I'M ignorant to the fact that nlnetlabs have changed their internal database, so this is likely not a corruption issue but stems from the wire.
Hopefully my 2 cents are helpful. -peter On Sun, Sep 15, 2019 at 06:23:28PM -0700, Joe Barnett wrote: > I've been seeing some issues which I believe to be related to dns/resolving. > The short of it is that the results of > > # dig web.whatsapp.com > > start out as: > > ; <<>> DiG 9.4.2-P2 <<>> web.whatsapp.com > ;; global options: printcmd > ;; Got answer: > ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 57665 > ;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 0 > > ;; QUESTION SECTION: > ;web.whatsapp.com. IN A > > ;; ANSWER SECTION: > web.whatsapp.com. 3595 IN CNAME mmx-ds.cdn.whatsapp.net. > mmx-ds.cdn.whatsapp.net. 55 IN A 31.13.70.49 > > ;; Query time: 6 msec > ;; SERVER: 192.168.254.254#53(192.168.254.254) > ;; WHEN: Sun Sep 15 14:46:24 2019 > ;; MSG SIZE rcvd: 87 > > which seems reasonable (and functional), but then soon become: > > ;; Warning: Message parser reports malformed message packet. > > ; <<>> DiG 9.4.2-P2 <<>> web.whatsapp.com > ;; global options: printcmd > ;; Got answer: > ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 40939 > ;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 0 > > ;; QUESTION SECTION: > ;web.whatsapp.com. IN A > > ;; ANSWER SECTION: > web.whatsapp.com. 3528 IN CNAME mmx-ds.cdn.whatsapp.net. > mmx-ds.cdn.whatsapp.net. 30772 RESERVED0 A \# 4 1F0D4631 > > ;; Query time: 2 msec > ;; SERVER: 192.168.254.254#53(192.168.254.254) > ;; WHEN: Sun Sep 15 14:47:31 2019 > ;; MSG SIZE rcvd: 87 > > At which point I am no longer able to access web.whatsapp.com. Given that > whatsapp is a facebook property, I tried the above against facebook.com, > www.facebook.com, instagram.com, and www.instagram.com as well. With the > exception of instagram.com, the other three (facebook, www.facebook, > www.instagram) return a hex (?) formatted version of the IP address, similar > to what is seen in the later of the above examples. My thinking is (or was) > that there are some issues relating to fb's DNS. From outside of my > network, however, other resolvers seem to be able to continually resolve the > above names correctly. I don't know what those resolvers are, but > specifically I am referring to whatever Linode and DigitalOcean use in the > nameservers they provide to their basic Linux vms (I am using the default > network config in my vms at Linode and DigitalOcean). I have a suspicion > that Linode uses unbound, but I do not know how to verify that. Oh, as far > as I can tell, those facebook-family names *seem* to be the only names for > which I see this behavior -- all other names that I have tried to run > through dig (and nslookup) seem to return reasonable and seemingly correct > results. > > A bit about my (home) network. I have Cox cable internet service, an Arris > SBG7580-AC, and an OpenBSD 6.5 machine that sits between the modem and the > rest of the network. I(we) do use the modem in router mode (but without > using the built-in WiFi) as my wife's work git-up consists of a > pre-configured black-box of a Juniper device. Not wanting that device in > the rest of our network, I set the modem to "RoutedWithNAT" and the two > network devices plug into the modem, but provide two separate networks. For > remote ingress into the rest of the network, I set the modem's DMZ to point > to the OpenBSD box. My pf.conf does the usual small network stuff including > NAT, a bit of redirection, etc. It has changed very little in the past > several years. My unbound.conf is also nearly unchanged since I first set > it up when OpenBSD dropped bind and replaced it with unbound. My OpenBSD > machine provides name resolving for the rest of the network. My > unbound.conf follows: > > server: > interface: 0.0.0.0 > interface: ::1 > do-ip6: no > > access-control: 0.0.0.0/0 refuse > access-control: 127.0.0.0/8 allow > access-control: 192.168.0.0/16 allow > access-control: 10.0.0.0/24 allow > access-control: 172.16.0.0/24 allow > access-control: ::0/0 refuse > access-control: ::1 allow > > hide-identity: yes > hide-version: yes > > # ftp://FTP.INTERNIC.NET/domain/named.cache > root-hints: "/var/unbound/etc/named.cache" > > # uncomment to enable DNSSEC > auto-trust-anchor-file: "/var/unbound/db/root.key" > > ### various local-zone, local-data, and local-date-ptr ### > > remote-control: > control-enable: yes > control-use-cert: yes > control-interface: /var/run/unbound.sock > > do-ip6, root-hints, and auto-trust-anchor-file are somewhat recent additions > to my unbound.conf, but I experience the same behavior with unbound.conf as > above, and also when I comment out those three additions (bringing it back > to a configuration that has worked for several years). > > My OpenBSD machine is an APU2 which I have been using without issue for over > a year. My backup machine is an ALIX2D3 I think it is called. Other than > the APU running amd64, and the ALIX running i386, the machines are otherwise > configured exactly the same. The APU2 has been consistently maintained, and > this behavior did start soon after I applied the libexpat update via > syspatch. The ALIX machine, however, has not been patched (meaning it > contains 6.5 as it was at release). I do not know much about the inner > workings of DNS, and thinking that, perhaps, the packets contain XML and > that the recent libexpat update is causing issues, I backed the update out > of the APU2, but still get the same results. Similarly, swapping the > (non-updated) ALIX in place of the APU2 results in the same behavior. > > Please forgive my verbosity, but I figured more info is probably better than > less. My knowledge of DNS and other network services is limited -- I hope I > have explained this in a way that can be understood. > > Thanks, > > Joe
