The launch of Cloudflare's new 1.1.1.1 DNS service has brought much fanfare and a heap of praise. More choice is always a good thing, and support for both DNS-over-TLS and DNS-over-HTTPS make 1.1.1.1 an interesting option. In this post I'm going to explain why I won't use it yet, and why you might not want to switch either without doing some testing first.

Fastest isn't always best

Cloudflare touts 1.1.1.1 as "the Internet's fastest DNS directory." In terms of pure response time, they might be right. But when dealing with DNS, response time is only part of the equation. Just as important are the replies you get from a DNS server, the IP addresses it hands out in response to domain queries. Responses from centralized DNS services are sometimes unsatisfactory and can lead to service degradation. The answers come fast, but are they the right ones?

I like to use a telephone analogy here. Imagine you dial 9-1-1 and your call is answered so quickly you never even hear it ring. But it turns out you've been connected to a dispatcher in a city hundreds of miles away, and while she can send the authorities, it's going to take them awhile to reach you. The response was fast, yes, but it wasn't optimal. You would probably have preferred to speak to your local 9-1-1 dispatcher instead, even if you had to wait 3 or 4 rings for them to pick up the phone.

So, too, is the case with DNS. Public name servers may answer faster than your ISP's DNS, but that speed is negated if the servers they point you to are very distant.

Testing public resolvers for speed

Cloudflare makes bold speed claims, so I've done some basic testing to gauge how 1.1.1.1 stacks up against other options. Measurements were taken of the following DNS services:

• 1.1.1.1 - Cloudflare
• 4.2.2.4 - Level3
• 8.8.8.8 - Google
• 9.9.9.9 - GCA/PCH/IBM
• 75.75.75.75 - Comcast (customer-only)

Because 1.1.1.1 is promoted as a consumer DNS service, all observations below are from my residential Comcast cable connection in Memphis, TN.

Latency

Cloudflare's service appears to have robust connectivity and a diverse geographic presence. 1.1.1.1 is physically closer to me than other common public DNS options. The server I'm routed to, 172.69.197.23, is 7 network hops out, with an average ping of only 13.1 ms. It responds to an RFC4892 query with mem01, so is presumably located here in Memphis. That's about even with Comcast's 75.75.75.75, which also has an anycast presence in town, and it beats the other public resolvers. See the traceroutes for details.

NXDOMAIN

For the first round of DNS testing, I queried each server for 100 invalid domains in the .com zone to gauge NXDOMAIN response time. (4.2.2.4 hijacks NXDOMAIN and returns two advertising servers instead.)

  [parse@word ~]$ for i in {1..100}; do dig A $(head /dev/urandom | sha1).com \ 
      @1.1.1.1; sleep 5; done > 1.1.1.1.nxdomain.txt &

Cold queries

Next, I queried 100 randomly generated hostnames on a domain configured for wildcard DNS. This test was intended to measure "cold" or uncached query response time.

  [parse@word ~]$ for i in {1..100}; do dig A $(head /dev/urandom | sha1).shaun.ga \ 
      @1.1.1.1; sleep 5; done > 1.1.1.1.cold.txt &

Likely cached queries

Finally, I queried the top 100 domains on the Cisco Umbrella list. DNS servers are likely to have answers for these popular domains cached, improving response time.

  [parse@word ~]$ head -100 top-1m.csv | cut -f2 -d"," | dos2unix > top-100.txt
  [parse@word ~]$ while read host; do dig A $host @1.1.1.1; sleep 5; \
      done < top-100.txt > 1.1.1.1.top.txt &

The same series of tests was performed against all 5 DNS services. The output from each test was processed to calculate the mean average query times in millisecond...

Today I saw an interesting IMAP probe. These are usually background noise, occurring by the hundreds each day and mostly trying weak passwords against non-existent accounts. This particular login attempt was made on a valid alias, so I took a few seconds to dig deeper, and found an indicator of attack I hadn't seen before.

Immediately preceding the IMAP authentication attempt, the same IP address had issued one HTTP GET request and two HTTP POST requests for /autodiscover/autodiscover.xml on the same domain (the file doesn't exist). Not being familiar with autodiscover.xml, I looked up the documentation and it's a WPAD-like configuration discovery scheme for Outlook. Aside from people whose own Outlook clients and/or Exchange servers are spamming their own web server logs with requests, I couldn't find many people talking about seeing it in their httpd logs. autodiscover.xml doesn't seem to be commonly scanned, spidered, or abused.

The HTTP and IMAP requests all originated at an IP allocated to mail.ru: 5.61.237.36. As far as I can tell, mail.ru doesn't offer any services that hand out IPs to their users, making it likely that the traffic came directly from mail.ru equipment. At first I suspected mail.ru must have an "add a remote account" feature like Gmail does, and someone figured out how to script it to run IMAP probes. Clever! mail.ru does, in fact, have some capability to collect mail from third-party accounts; I managed to find an English help page about using it for POP3. There's no mention of IMAP here, but their English documentation may be lacking or out of date.

If an attacker was automating scans through the mail.ru service, though, I'd expect to find more recorded incidents. There are only a smattering of reports on AbuseIPDB, and none on blocklist.de. The lack of widespread abuse activity leads me to believe this isn't an automated scan at all; instead, someone is using mail.ru's remote collection feature to manually target specific accounts.

If you don't use Outlook/Exchange and don't get any legitimate web requests for autodiscover.xml, it might be useful to add that string to your IDS or your log watcher.

Facebook's data collection tactics make waves

With Facebook and Cambridge Analytica in the news, Facebook's threat to privacy is finally getting the widespread attention it deserves. Beyond the obvious political propaganda concerns, the wider implications of Facebook's data collection are coming to light, and some of the examples are alarming. Multiple users have downloaded their history and discovered that Facebook had records of all of their phone calls and text messages.

In addition to siphoning up phone-related data, much of the web has become infected with Facebook tracking beacons that collect your browsing history on desktop PCs and mobile devices. When you see a Facebook "Like" or "Share" button on a web page, your browser typically loads these directly from Facebook's servers. Some websites without visible Facebook widgets will instead load a tiny invisible image known as a web bug or tracking pixel. Facebook logs where all of these requests come from, along with enough metadata to identify your specific browser like a fingerprint: your IP address, your browser's name and version, your screen resolution, any Facebook cookies you may have, and more.

This tracking all takes place whether you're logged into Facebook or not, and even if you don't have a Facebook account at all. Facebook maintains "shadow profiles" of unregistered users, and will correlate all of their surveillance with your real identity if they can obtain it through marketing partners or other means.

A comprehensive approach to blocking Facebook is required

Faced with pervasive data collection from multiple angles, what's a concerned person to do?

Abandoning your Facebook account and deleting the apps make a good first step, but this effort isn't sufficient to stop Facebook from watching what you do online. To avoid leaking data about your Internet usage habits to Facebook, a more proactive security stance is needed. I recommend a multi-layered approach:

• Uninstall all Facebook-owned apps.
  This will end any direct collection of phone data you never intended Facebook to see.

• Install privacy-enhancing browser extensions.
  These browser extensions can recognize and block specific beacon code.

• Block Facebook in DNS.
  By sinkholing Facebook's domains, you'll eliminate most of their tracking and speed up web browsing.

• Firewall Facebook from the network.
  Firewall rules will catch connection attempts to new or unknown Facebook-owned domains.

Not all of these steps are accessible to everyone. The latter two require some advanced technical skills (or a chunk of time to spend learning), and are easier if you have a computer on your network acting as a dedicated hardware router. Implement the layers you can. Each safeguard you add leaves you better protected than you were before.

Security Layer 0: Uninstall all Facebook-owned apps and disengage

Skill level: Beginner

If you have any of the following apps, consider them tainted and remove them from all your devices: phones, tablets, iPods, everything. Having these apps installed gives Facebook direct access to your device, and may imply legal consent to various forms of data collection.

• Facebook
• Messenger
• Instagram
• WhatsApp

Start by deleting the Facebook app. Get rid of the others on that list, too; they're all owned by Facebook, and the extent of data sharing between them is unclear. You might also take a few minutes to evaluate settings in your other apps, disabling the "Facebook Connect" feature wherever you find it.

If you're ready to permanently sever ties with Facebook, login to Facebook in a web browser and delete your account.

Many folks aren't ready for this level of commitment, and that's okay. Using a web browser, log in to Facebook and post a "goodbye" status update so people know you're no longer reachab...

Let's Encrypt, a leading issuer of SSL/TLS certificates, has taken a big step forward by adding support for Certificate Transparency. This capability, now merged into Let's Encrypt's Boulder CA suite, resolves a long-standing feature request by embedding Signed Certificate Timestamps (SCTs) into newly minted certificates. Because the SCT is attached directly to the certificate, no additional server modules or configuration is needed by site administrators.

Certificate Transparency support allows websites using Let's Encrypt certificates to implement the Expect-CT HTTP header. This header provides additional security by instructing web browsers to verify the certificates they receive against public certificate transparency logs. Forged or otherwise malicious certificates are often absent from these logs, and will never contain the correct SCT, making them easier to detect when a site uses Expect-CT.

The feature was officially enabled on March 29.

What Certificate Transparency does

In a perfect world, every time you connect to a website (or other service) over TLS, you'd be able to trust the certificate presented by the remote host as long as it's issued by a valid Certificate Authority that you also trust. But digital trust isn't perfect. Private signing keys sometimes get compromised, and CAs occasionally exhibit unscrupulous behavior, resulting in forged or mis-issued certificates that look valid but are controlled by a malicious actor. These certs can be used to intercept traffic, inject resources, or perform other man-in-the-middle style attacks.

Certificate Transparency (RFC6962) helps mitigate this problem by introducing additional verification into the chain of trust. The foundation lies in certificate logs, which are implemented as immutable, cryptographically signed ledgers that can be viewed and audited by the public. (If you're into buzzwords, you can think of a certificate log as a blockchain for SSL certs.) Public certificate logs are currently operated by Google, Cloudflare, DigiCert, Certly, Izenpe, WoSign, Venafi, CNNIC, StartCom, and Comodo, with other services like crt.sh providing an index to their data.

When a participating CA like Let's Encrypt mints a new certificate, they submit it to one or more certificate logs, creating a permanent visible record of its issuance. The certificate log, in turn, responds to the CA with a signed certificate timestamp (SCT) corresponding to the log entry. These logs and signatures are routinely monitored by domain owners, security researchers, and intellectual property firms. The idea is that all of this auditing means bogus certificates will be spotted early and can be quickly revoked, minimizing the fallout from counterfeits.

Automated certificate verification through Expect-CT

Certificate log monitoring only solves one aspect of the forgery threat model, because only certificates that are proactively submitted to the public logs can be inspected. An attacker who creates a malicious certificate isn't likely to publish it and tip their hand. Such certificates are often narrowly deployed to target specific individuals or groups, keeping them hidden from organizations that perform routine auditing. A system is also needed for individual end users to detect problem certificates, and this piece of the puzzle can be addressed with the Expect-CT HTTP header.

In 2017, engineers at Google proposed a new HTTP header called Expect-CT (draft specification). By implementing this header, a website operator can tell visitors' browsers that the site's legitimate TLS/SSL certificate is published in certificate logs, and that any o...

If you run a mail server, whether it's for your own personal email or for your company and its employees, one of the biggest challenges you'll face is keeping spam at bay. Fortunately, several organizations maintain DNSBLs available for public use. These blacklists of known spammer servers and networks are the biggest hammer in a mail admin's toolbox, and are easy to configure in most common MTAs.

Used wisely, a good selection of DNSBLs can reject most of your incoming spam early in the SMTP conversation. This prevents your server from having to process those messages through other, more resource-intensive filtering strategies. On the other hand, each blacklist you enable adds another potential DNS lookup for every incoming message, and another opportunity for false positives that discard legitimate mail. To that end, it's a good idea to keep an eye on how the DNSBLs you choose are working on your system.

In this post I'll share some methods for gauging how DNSBLs are performing on a Postfix install. If you're following along with a production system, you might want to copy its maillog to another server for processing, especially if its size exceeds your free RAM.

Gathering statistics

In judging a blacklist, there are two important metrics to consider:

1. How many junk transactions is it helping you block? A DNSBL that only identifies a handful of abusive senders per day may not be worth keeping around.

2. How many false positives are being generated? Even the most permissive of blacklists will flag some legitimate senders as spammy from time to time.

False positives can be a tough nut to crack, because no amount of monitoring can guess when someone's expected messages didn't arrive. Only your users can provide that insight. You should make yourself (or your ticket system) approachable to your users so they can let you know when the system doesn't meet their expectations. Follow up on each report, and if a DNSBL is responsible for missing mail, weigh the benefits of its continued use against its rate of false positives.

A DNSBL's rejection rate is much easier to figure out. To discover the numbers, we'll consult the Postfix log file(s). In its default configuration, Postfix records a DNSBL rejection with a maillog entry that looks like this:

Feb  6 20:11:39 mailman postfix/smtpd[21916]: NOQUEUE: reject: RCPT from unknown[60.177.228.194]: 
554 5.7.1 Service unavailable; Client host [60.177.228.194] blocked using sbl-xbl.spamhaus.org; 
https://www.spamhaus.org/query/ip/60.177.228.194; from=<user@helo-host> to=<user@rcpt-host> 
proto=ESMTP helo=<example.com>

Since the entries are all formatted the same way, we can use some standard Linux text processing utilities to crunch the log and gather the target numbers. Here's a bash one-liner to tally up the number of messages rejected using each DNSBL. I've broken it into three lines for illustrative purposes:

grep "$(date +%b\ %e)" /var/log/maillog* | grep 'Service unavailable' |  \
cut -f $((20 + $(date +%e | tr -cd ' ' | wc -c))) -d' ' |                \
sort -n | uniq -c | sort -nr

The first line filters the maillog files for records from today that indicate a DNSBL rejection. (If your maillog rotates into zipped files, you may need to hack on this a bit.)

That funky second line determines where to find the DNSBL hostnames in the log records. If you imagine each maillog entry as a list of columns separated by spaces, the DNSBL's hostname appears in field #20... Unless the current day of the month is only 1 digit long. In that case, Postfix pads the date with a space, so we have to shift one more column to the right.

The last line performs the accounting and sorts everything into a list.

Running that command, I get the following sample output:

   5490 sbl-xbl.spamhaus.org;
     66 dyna.spamrats.com;
     60 psbl.surriel.com;
     52 truncate.gbudb.net;
     25 spam.dnsbl.anonmails.de;
     11 noptr.spamrats.com;
      8 dnsbl.dronebl.or...

It looks like there's a new referer spam campaign underway, with a fresh batch of hosts to block. This one is predominantly promoting Russian and Ukrainian websites. I first caught wind of it from Dave Horsfall, who in late January mentioned on an anti-spam mailing list that he'd seen pills24h.com in his web access logs. I found that domain in my logs too, made a note to look further, and today I got around to poking at it a little.

Since I don't run WordPress or any common blog software, I was surprised to see referer spam suddenly hitting this site in earnest. Most modern spambots are intelligent enough to only target sites vulnerable to their spam. The мудак behind this campaign isn't so discerning, although he's at least bright enough to use IPs that aren't listed in the Stop Forum Spam blacklist. The abuse originates in snowshoe fashion from space allocated to Ukrainian provider Kyivstar / Golden Telecom (AS15895).

Offending hosts

For your blocking pleasure, here are the IPs involved in the spamming campaign:

5.248.196.93
5.248.199.158
5.248.253.101
37.115.112.228
37.115.184.155
37.115.185.9
46.118.113.100
46.118.114.175
46.118.116.121
46.118.125.21
46.118.127.172
46.118.152.50
46.118.225.78
46.119.113.175
46.119.114.157
46.119.115.60
46.119.118.96
46.119.121.22
46.119.121.71
46.119.122.170
46.119.123.218
46.119.126.51
46.211.13.134
134.249.48.151
134.249.53.158
134.249.55.53
134.249.66.84
178.137.16.45
178.137.16.174
178.137.18.222
178.137.55.200
178.137.82.153
178.137.86.85
178.137.86.152
178.137.88.8
178.137.88.90
178.137.91.90
178.137.92.135
178.137.162.218
178.137.165.61
178.137.167.106
178.137.178.122
178.159.37.55
178.159.49.228
188.163.72.38
188.163.79.63

Here are the domains each host has been pimping.

5.248.196.93

beachtoday.ru

5.248.199.158

avtovykup.kz

5.248.253.101

4inn.ru

37.115.112.228

komukc.com.ua
pills24h.com
studentguide.ru

37.115.184.155

balkanfarma.org
fishtauto.ru
gazel-72.ru
iptvuk.co.uk
krasivoe-hd.net
natprof.ru
petrushka-restoran.ru
pills24h.com
rocketchange.ru

37.115.185.9

filesclub.net

46.118.113.100

svetka.info

46.118.114.175

bird1.ru
pills24h.com
t-rec.su

46.118.116.121

doxyporno.com
raschtextil.com.ua

46.118.125.21

gazel-72.ru
krasivoe-hd.net

46.118.127.172

online-sbank.ru

46.118.152.50

pornohd1080.online

46.118.225.78

no-rx.info
pills24h.com

46.119.113.175

avtorskoe-vino.ru
cryptoswap.biz
electronic-component.org
doxyporno.com
kinoduh.ru
kollekcioner.ru
popugauka.ru
raschtextil.com.ua
supermama.top
superoboi.com.ua
truebeauty.cc
whoiswho.crimea.ua

46.119.114.157

sildenafil-tadalafil.info

46.119.115.60

drugs-no-rx.info
englishtopik.ru

46.119.118.96

komputers-best.ru
magnetic-bracelets.ru
scat.porn

46.119.121.22

www.xn--80aaajkrncdlqdh6ane8t.xn--p1ai (IDN: www.мягкиеокнасаранск.рф)

46.119.121.71

5elementov.ru
buynorxx.com
en.home-task.com
pillscheap24h.com
spy-app.info

46.119.122.170

www.inet-shop.su
www.sundrugstore.com

46.119.123.218

perl.dp.ua

46.119.126.51

pills24h.com

46.211.13.134

polyana-skazok.org.ua
strady.org.ua
suzuki-metropolis.kiev.ua
td-l-market.ru

134.249.48.151

kozhakoshek.com
meriton.ru
metallo-konstruktsii.ru

134.249.53.158

bonkers.name
skinali.photo-clip.ru
zelena-mriya.com.ua

134.249.55.53

gazel-72.ru
profnastil-moscow.ru

134.249.66.84

rql.kiev.ua

178.137.55.200

all-news.kz

178.137.16.45

chatroulette.life
drugs-no-rx.inf...

While doing a bit of housecleaning on a system, I hit a subversion error I've never seen before:

[user@host]$ svn ci -m "Replace symlink with hard copy of file"
svn: E145001: Commit failed (details follow):
svn: E145001: Node '/path/to/my/myfile' has unexpectedly changed kind

I'd replaced a symlink, which was already versioned, with a copy of the target file itself. I'm usually pretty good at convincing subversion to accept whatever arcane mangling I've done, but it just wouldn't take this one, and Google was no help. I was able to get things right again with the nuclear option, removing the offending object from version control and then adding it back. Specifying --keep-local removes the file from the subversion repo but leaves it in place on disk.

[user@host]$ svn status
~       myfile
[user@host]$ svn rm --keep-local myfile
D         myfile
[user@host]$ svn ci -m "Remove symlink, will add back as a file"
Deleting       myfile
Committed revision 1602.
[user@host]$ svn add myfile
A         myfile
[user@host]$ svn ci -m "Adding hard copy of what used to be a symlink"
Adding         myfile
Transmitting file data .
Committed revision 1603.

All fixed.

This week I finally took the plunge and upgraded most of the servers I work with from PHP 7.1 to PHP 7.2. (Some of them still can't be brought forward due to dependencies that use mcrypt.) I ran into a few snags with the upgrade to 7.2 and thought I'd document them here. This may be useful if you:

• Run CentOS 6 (6.9 in my case),
• Want to install PHP 7.2,
• Need pthreads support in PHP, and
• Prefer to compile PHP from source

Executive summary

In order to build PHP 7.2 with pthreads on CentOS 6, you must upgrade to autoconf 2.64, which can't presently be done through the yum package manager. You'll also have to first build PHP 7.2 without pthreads, then use this "bootstrap" copy to prepare the pthreads extension before compiling PHP a second time.

autoconf 2.64

Start by installing autoconf 2.64. The latest version available through yum is 2.63, which isn't sufficient to build PHP's configure script.

It's critical that you supply the --prefix=/usr option when configuring autoconf. The default installation prefix for the generic autoconf distribution is /usr/local, but CentOS 6 keeps it in /usr. If you forget to set the correct prefix, you're going to wind up with two different versions of autoconf installed, and who wants that?

curl -Lo autoconf-2.64.tar.gz ftp://ftp.gnu.org/pub/gnu/autoconf/autoconf-2.64.tar.gz
tar xfz autoconf-2.64.tar.gz
cd autoconf-2.64
./configure --prefix=/usr
make && make install

Make sure the correct version has been properly installed. autoconf --version should show:

autoconf (GNU Autoconf) 2.64
Copyright (C) 2009 Free Software Foundation, Inc.
[..snip..]

Bootstrap PHP 7.2

Compiling PHP 7.2 with pthreads presents a bit of a Catch-22: in order to build the pthreads extension, you need to have the 7.2 version of PHP (more accurately, a version with ZEND_MODULE_API_NO >= 20170718) and its libraries already installed. To work around this scenario, it's necessary to compile and install a minimal version of the PHP 7.2 CLI first, then use this "bootstrap" version to prepare pthreads.

Start by obtaining the latest PHP 7.2 source distribution and doing a minimal build. The only option you need to pass to configure this time around is --enable-maintainer-zts, to turn on thread safety. Don't worry about other modules (mysqli, PDO, etc.) as you're not going to be keeping this version of PHP installed for long. If you also run PHP as an Apache module, disregard that for now and just build the CLI version.

curl -Lo php-7.2.1.tar.gz http://us3.php.net/get/php-7.2.1.tar.gz/from/this/mirror
tar xfz php-7.2.1.tar.gz
cd php-7.2.1
./configure --enable-maintainer-zts
make
make install

Verify that a thread-safe version of PHP 7.2 has been installed. The output of php -v should indicate a 7.2 version number and the ( ZTS ) signature.

PHP 7.2.1 (cli) (built: Jan 8 2018 17:14:36) ( ZTS )
[..snip..]

Prepare pthreads

Obtain and prepare the pthreads extension. Note there's a dot . as the final argument to git clone. If you don't use git, you can manually download a .zip file of the pthreads source.

cd ext      #this should put you in the php-7.2.1/ext directory
mkdir pthreads && cd pthreads
git clone https://github.com/krakjoe/pthreads.git .
phpize && ./configure && make install

If you receive error output that includes the following,

php_pthreads.c:38:3: error: #error "pthreads requires PHP 7.2, ZTS in versions 7.0 and 7.1 is broken"

...this means that your bootstrap PHP 7.2 didn't install properly, and you have an older PHP command line binary on your system. You should repeat the bootstrapping step above.

Build your final PHP 7.2

Now it's time to build PHP 7.2 for real. Return to the main PHP source tree, clean up the artifacts from the bootstrap build, and generate a new configure script. ...

I hate when a redesign gets in the way of a good thing.

Zap2it.com has been my choice for TV listings for many years. They briefly rebranded as "Screener" in 2016, with a new domain that broke my bookmarks and a bright yellow theme that broke my eyeballs. That venture didn't go very far; the Zap2it name returned after a few months, at which point I updated my TV listings bookmark (again) and went on with my life.

Tonight I went to see what's on TV and my trusty bookmark took me to a 404 page. Compounding matters, visiting the main Zap2it.com page showed me a totally blank "TV Listings Grid" section. This is the unfortunate hallmark of a website that won't work properly if LocalStorage is disabled.

I normally keep LocalStorage turned off, because it presents a bundle of privacy issues and I've found that the simplest way to deal with them is to reject the feature altogether. When I find a site like Zap2it that refuses to work with dom.storage_enabled set to false, sometimes I'll enable the feature temporarily and examine what's happening under the hood. My experience is that most sites demanding LocalStorage fall into one of two categories:

1. Overzealous LocalStorage: dozens or even hundreds of key/value pairs are stored, most of which aren't read or used by the application. The site is essentially offloading analytics data storage onto its visitors for some later, unknown purpose.

2. Gratuitous LocalStorage: a handful of small key/value pairs are stored, a use case that doesn't require LocalStorage at all. This breaks the site for visitors with DOM storage disabled, while providing no tangible benefit to the developer.

The new Zap2it interface falls into the second category. The site places the following tuples into the browser's LocalStorage:

Zap2it.overlay.shownOverlay: true
Zap2it.provider.search.result: {"providerResults": //JSON containing my local TV providers
Zap2it.gridScroll.scrollTop: null
Zap2it.gridpos.gridpos: null
Zap2it.providerData.provider: {"lineupId:" //JSON identifying the TV provider I chose

That's it. I suppose if I signed up for an account, it would probably store my username and a session ID, too, but there's nothing fancy going on here. This could all be stored in traditional cookies, which are easier for users to manage, without crippling the UI for the privacy-conscious audience.

While I was poking at the site, I found a workaround to keep getting the listings, which itself requires a bit of a hack.

The new Zap2it listings grid has a "Print" button. That link generates a searchable PDF of the full TV listings table, and accepts all of its parameters directly from the query string, no LocalStorage required. Getting here is fairly easy:

• Temporarily enable LocalStorage
• Go to the Zap2it front page
• Dismiss the tutorial dialog
• Enter your ZIP code
• Choose your TV provider
• When the grid appears, click "Print" in the upper right
• Copy the PDF's URL, which contains the parameters for your local listings
• Disable LocalStorage again

Of course, no good workaround comes without a challenge.

The PDF generator URL contains a time= parameter that holds the epoch timestamp corresponding to the most recent half-hour programming block; that is, it points to either :00 or :30 of the current hour. This tells the Zap2it application where to start the TV listings grid. I can't bookmark that directly or else I'm always going to see the listings for January 6, 2018. But this is a necessary element: omitting it results in a 502 Gateway Timeout error; lacking a user-supplied start time, Zap2it is probably trying to crunch every TV program my provider has ever shown.

As a workaround to the workaround, I wrote a little PHP script and put it on one of my local servers. It figures out the correct epoch timestamp, embeds it into ...

Today Bert Huber from PowerDNS announced a new DNS-based geolocation service. Given an IP, it returns the corresponding latitude and longitude coordinates. Using it is simple; to look up the coordinates for IP address 1.2.3.4, just reverse the octets and query the TXT record for 4.3.2.1.geo.lua.powerdns.org. I don't see any official details from PowerDNS yet, just Bert's tweet, but based on the domain, the service appears to be using PowerDNS' Lua capabilities.

The usual caveats about geolocation apply:

$ dig +short TXT 73.52.93.172.geo.lua.powerdns.org
"33.745800 -117.826202"

Despite that server living in Dallas, the coordinates that come back are for Tustin, CA. That's because the ARIN allocation for 172.93.48.0/21 points to a corporate address in Tustin. Any geolocator operating from MaxMind's data will make the same "mistake," so this isn't a shortcoming of the PowerDNS service specifically.

If you currently use a web-based geolocation API, especially if your existing solution uses MaxMind geodata, the new PowerDNS service looks like a viable replacement. Queries over DNS will almost always be faster than a web API, because UDP doesn't have the handshake overhead that TCP does, and DNS provides the potential for caching.