A library exists to open doors, so every filtering choice it makes is contested — except this one. A domain built solely to harvest a patron's benefits password is not an idea anyone is defending. This page is about wiring a feed of DNS-verified, currently-live phishing domains into shared terminals, guest Wi-Fi and staff mail without logging a single patron query.
Libraries have spent decades arguing carefully about filters. That argument does not apply to a domain whose entire reason for existing is to steal a password.
Anyone who has sat through a board meeting about internet policy knows the shape of the debate. Category filtering is a blunt instrument applied to human ideas, and it fails in both directions at once: it blocks a teenager researching sexual health, a job seeker reading about addiction recovery, a caregiver looking up a hospice, while quietly letting through the material somebody actually objected to. Every category list is somebody's editorial judgement about what a patron should be allowed to read, imposed at the network layer where no reference interview can soften it. Librarians are right to be sceptical of that, and the profession's discomfort is not squeamishness — it is an accurate read of what the tool does.
A phishing blocklist is a different kind of object entirely, and the difference is worth being precise about rather than glossing. It does not classify subject matter. It does not evaluate whether a page is wholesome or objectionable or age-appropriate. It answers exactly one narrow, factual question: has this specific hostname been observed and verified as a currently-live credential-harvesting site? A domain that exists to imitate a state unemployment portal and capture the social security number typed into it is not expressing a viewpoint. Removing it from the resolver takes nothing off any shelf, closes no line of enquiry, and denies no patron access to a single legitimate idea.
That distinction matters institutionally, not just philosophically. It means a director can adopt phishing blocking without reopening the filtering fight, without a policy revision that has to survive a public comment period, and without the awkward position of defending a vendor's taxonomy she did not write and cannot inspect. The written policy language is unusually easy: the library blocks hostnames verified as active credential theft infrastructure, it blocks nothing on the basis of subject matter or viewpoint, and the list is a factual inventory rather than an editorial one. Most boards will find that a shorter conversation than any other network decision they make that year.
It also happens to be the protection patrons most obviously need. Nobody walks into a branch and gets financially ruined by encountering an idea. People do get ruined by typing their benefits credentials into a page that looked exactly like the real one, on a machine they do not own, in a building they trusted to be safe. The library did not create that risk and cannot be blamed for it, but it is the institution standing between a patron and the keyboard — and it is the one entity in the chain with both the technical means and the professional motive to intervene quietly, at the resolver, before the page ever loads.
None of this is an argument that a blocklist is complete. It is a known-bad lookup, not a judgement about pages it has never seen, and any honest deployment note should say so plainly. What it does provide is a floor: the domains that have already been caught, verified as resolving, and confirmed as hostile are simply unavailable on library equipment. That floor is low-drama, cheap, defensible in front of a board, and — unlike every other filtering decision a library makes — genuinely costs the collection nothing.
The public access room is not a browsing lounge. It is where people without a home computer do the highest-stakes paperwork of their year.
If you wanted to design a population that phishing works best against, you would build the public access room. The people using it are, by definition, the ones who do not have a private device or reliable connectivity at home. They are disproportionately older, disproportionately new to the country, disproportionately between jobs, and disproportionately dealing with an agency deadline that has consequences. They are working under time pressure on an unfamiliar machine, often with a session limit counting down in the corner of the screen, and frequently on a task they have never done before and hope never to do again.
Who is actually sitting at station sevenAttackers are not indifferent to this. Impersonation of government services is one of the most reliably productive lures in circulation, because the target does not know what the real portal looks like either — nobody files for unemployment often enough to recognise a subtle deviation in the domain. A patron who has been told by a caseworker to "go to the state website and upload the documents" will search for it, and will click something. The malicious result and the genuine one are both blue links on a page, and the malicious one frequently has better copy.
Fake claim portals harvest the exact identity bundle needed to redirect a payment: name, SSN, date of birth, banking detail. Filed once, discovered weeks later.
Between January and April the impersonation volume aimed at revenue agencies and free-filing services climbs sharply, and the public terminals fill with people doing returns.
Fee-scam and fake status-check sites target people who cannot easily verify what the official process should cost or where it should live, and who fear asking.
The careers computers are a standing target for fake recruiter portals and work-from-home offers that open with an onboarding form and end with a bank account.
Open enrolment windows produce a predictable wave of look-alike marketplace and insurer domains aimed at people comparing plans on a deadline.
Assistance programmes are impersonated the moment they are announced, and the patrons applying are the least able to absorb the loss when it works.
The job-hunting corner deserves its own paragraph, because it is where the library's own service design increases exposure. Many branches signpost a bank of machines for employment searching, sometimes with a volunteer or a workforce-development partner nearby. That is exactly the audience for the work-from-home scam: an offer arrives, it looks generous, it asks for identity documents "for payroll onboarding" and then for a small equipment deposit or a bank login for direct deposit. The patron is not being careless. They are doing precisely what the system told them to do, on a machine the library provided, in response to a message that arrived while they were looking for work.
You can solve a meaningful part of it by making the destination unreachable. When the recruiter's "application portal" is a hostname already verified as active phishing infrastructure, the click produces a block page rather than a form, and the entire sequence stops before the patron has typed anything. That is the whole intervention: unglamorous, invisible when it works, and worth more to that patron than any awareness session the branch could realistically run.
A shared terminal turns one person's mistake into a queue of them, and the usual endpoint answers — per-user policy, managed identity, device trust — do not exist here.
Corporate security assumes a person owns a device. Everything downstream of that assumption — per-user policy, conditional access, a managed browser profile, an EDR agent that knows whose laptop it is — quietly collapses in a public access room. The machine is used by eleven different people before lunch. It has no identity of its own beyond a station number, and the only reliable statement you can make about its user is that they will be gone in forty minutes and someone else will sit down.
This changes the failure mode in a way worth thinking through. On a corporate laptop a phishing compromise is one person's problem and gets cleaned up alongside their account. On station seven it is closer to contamination. A patron who authenticated to a fake portal leaves behind a session that a reimaging script may or may not clear before the next booking. A patron who was walked through installing a "support tool" over the phone leaves that tool for whoever follows. Most branches run some form of session reset — deep freeze, a reimage on logoff, a profile wipe — and most of the time it works. But the reset happens after the harm, and the harm has already left the building in the form of credentials somebody else now holds.
The dangerous destination is unavailable in the first place, so nothing has to be cleaned up, and the protection does not depend on the reset script having run correctly, on the last patron having logged out, or on staff noticing anything at all. That last point is the operationally important one, because staff notice very little of what happens on the public machines and should not be expected to. Reference desks are busy, sight-lines to screens are deliberately limited for privacy reasons, and looking over a patron's shoulder is precisely the behaviour the profession has spent years designing out.
There is a second inheritance problem that people forget: bookmarks, autofill and browser history on machines where the reset is imperfect or manual. Branch staff frequently add a bookmark to help patrons find a resource, and those bookmarks accumulate over years without review. It is worth exporting that bookmark inventory once and running the hostnames through the batch endpoint — a hundred domains per request, one lookup each — to confirm that nothing added helpfully three years ago now points at a domain that has since changed hands. It is a twenty-minute job for a whole system's worth of machines, and it occasionally finds something.
The distinction that ends the argument: a category filter decides what a patron is permitted to read; a phishing blocklist decides only whether a hostname is currently pretending to be someone else in order to take their password. The first is an editorial judgement a library may reasonably refuse to make. The second is a fact about the network, and refusing to act on it protects nobody's freedom to read.
Patron confidentiality is not a preference the profession holds loosely. The feed model is the deployment that respects it structurally, rather than by promising to behave.
Your resolver or proxy sees a request, sends the hostname to a vendor, and receives a verdict. That is fine in a lot of environments and disqualifying in this one. It means a third party accumulates a record of what was looked up from your address space, and while the vendor almost certainly has a reassuring privacy policy, the library has no way to verify it, no way to audit deletion, and nothing to say to a patron who asks the one question librarians take most seriously: does anyone outside this building know what I looked at?
Instead of asking about each domain, you download the whole database — a single authenticated call to the feed endpoint, CSV with three columns of domain,category,dns_status, or JSON if you prefer to transform it — and load it into infrastructure you already run. From that moment the matching happens locally. A patron types a hostname, your Pi-hole or BIND or Unbound instance compares it against a local list, and answers. Nothing about that lookup crosses your firewall. There is no per-query traffic to log, no vendor-side record to subpoena, and no dependency on an outbound connection staying up.
This is worth writing into the privacy statement in plain words, because it is unusually strong and patrons will not assume it. The library downloads a list of known-hostile addresses once a day. The library does not send any record of what patrons look up to anyone. The comparison happens on library equipment. That is a claim the library can make without hedging, and it is architecturally true rather than contractually true — which is the difference that matters when someone asks you to prove it.
The build lands at 04:30 UTC, so a cron job in the small hours pulls the current CSV and reloads the resolver before opening. The subscription includes a daily changelog of domains added and removed, which matters more than it sounds: without it, a naive rebuild silently keeps yesterday's expired entries or wipes local exceptions, whereas a diff-driven update lets you see exactly what changed and keep the reload cheap. Because every domain in the database is DNS-verified as actively resolving, entries that go dark drop out on their own instead of accumulating as dead weight in a file your resolver has to parse every morning.
One authenticated download per day replaces thousands of per-query lookups. Feed downloads are unlimited on a subscription, so a nervous first week of hourly pulls costs nothing extra.
The list is designed for DNS sinkholes and firewall blocklists — Pi-hole, BIND RPZ, Unbound — so most libraries are adding a file to a box that already exists rather than buying an appliance.
Because matching is local, an upstream outage degrades your internet connection but never your protection. There is no verdict service to be unreachable at the wrong moment.
Nobody at a public library is running a security programme full time. The sequence below is deliberately small, reversible at every step, and does not require a project.
A free key from registration plus the documented check endpoint is enough to test the list against domains you have actually seen in staff mail. The /stats endpoint needs no key or credits at all, so you can confirm the database size and last update date before you have decided anything.
For most systems that is the recursive resolver serving the branch network, or the firewall that already holds a blocklist. If you run a captive portal for guest Wi-Fi, the DHCP-assigned resolver it hands out is the same control point, which means one change covers both the public terminals and every phone in the building.
Load the list but log matches without blocking. Two weeks of quiet observation tells you the real hit rate in your building, catches any surprise overlap with a resource your patrons genuinely use, and gives you a number to put in front of the board that came from your own network rather than a vendor's brochure.
The default "access denied" wording is wrong here and will generate desk traffic you do not want. Say what actually happened: this address has been verified as a fake login page, nothing about your search was recorded, and a member of staff can help you find the real site. That is a reference interview invitation, not a reprimand.
A cron entry shortly after the 04:30 UTC build, a download of the current CSV, a validity check on the file before it replaces the live one, and a resolver reload. Add a single alert if the file is older than forty-eight hours — a silently stale list is the only realistic way this deployment fails.
Bookmobiles and pop-up sites on cellular routers, partner community centres, and any hotspot lending programme can point at the same resolver or carry their own copy of the same file. Once the pull is scripted, each additional site is a configuration line rather than another purchase.
They are frequently sold together, argued about together, and treated as one policy question. Separating them is what lets a library adopt the uncontroversial half.
| Question a board will ask | Category filtering | Phishing-domain blocking | Running both |
|---|---|---|---|
| Does it restrict access to ideas? | Yes — that is its function | No — hostile hostnames only | Only through the category half |
| Who decides what goes on the list? | A vendor's taxonomy you cannot inspect | DNS verification that the host is live and hostile | Two lists with two different standards of proof |
| What does over-blocking cost a patron? | A blocked legitimate resource and a difficult conversation | A false positive on a real site — rare, and correctable locally | Both, and the patron cannot tell which list stopped them |
| Does it need patron browsing data to leave the building? | Usually yes, for cloud category lookups | No, if you deploy the feed locally | Depends entirely on the category product |
| Does it protect a patron's benefits login? | Not its job, and it will miss new lures | Yes, for domains already verified | Yes, via the phishing layer |
| How hard is the policy language? | Long, contested, and revisited annually | Two sentences that describe a factual test | The long version, plus a footnote |
| Typical cost shape for a small system | Per-seat or per-site licensing | One feed subscription, or a monthly plan for API use | Both bills |
Read across the bottom two rows and the practical argument appears. A library that has already decided against category filtering — for good, well-argued professional reasons — has not thereby decided against phishing blocking, and conflating the two leaves patrons exposed to the one harm the profession's principles do not require the library to tolerate. A library that already runs a category filter, perhaps because of a funding condition, still benefits: category products are built to classify subject matter and are not designed to keep pace with hostnames that appear and disappear inside a week.
The argument the table is makingThis is a known-bad lookup. It tells you that a domain has been observed, verified as resolving, and confirmed as phishing infrastructure. It does not evaluate a page it has never seen, and a clean result means "not on the list" rather than "safe." A domain registered an hour ago and used for the first time this afternoon will not be there yet. That is a real gap, it is shared by every blocklist that has ever existed, and the correct response is to treat this as one layer among several rather than as a guarantee — the same way libraries reason about our DNS filtering and email security use cases.
What makes the gap narrower than it sounds is the verification standard. Because inclusion requires an active A record, checked via rotating proxy infrastructure, the list is a picture of what is live rather than an archive of everything ever reported. Roughly 200,000 domains are active at any moment against nearly half a million observed all-time, which is the difference between a working blocklist and a file that grows forever and slows your resolver down without protecting anybody.
The public terminals are the obvious surface. Three quieter ones matter as much, and two of them are the library's own systems being impersonated rather than attacked.
Start with the e-resource proxy, because it is the asset most libraries under-defend. A patron reaching a licensed database from home goes through a proxy login that asks for a card number and PIN. That page is public, brandable, and predictable, which makes it easy to clone; and the credential behind it is valuable in a specific, unglamorous way. A stolen library card does not buy much on its own, but it does buy bulk access to publisher databases, and content-scraping operations are perfectly happy to run that theft at scale. The consequence lands on the library as a licence violation and a suspended platform, usually announced by an irritated vendor rather than discovered internally.
A short script that submits candidate hostnames — the obvious typo variants of your own proxy domain, plus anything a patron has ever reported as looking wrong — through the batch endpoint gives you a verified answer at one credit per domain, up to a hundred domains per request. It is not brand monitoring and does not pretend to be; it will tell you whether a specific hostname is confirmed live phishing infrastructure, which is exactly the question you want answered before you send a warning to cardholders. Libraries running a broader watch programme usually pair this with the brand protection approach.
The second quiet surface is the library's own website, and specifically anything on it that outlives the person who added it. Community resource directories, local history link collections, "help with benefits" pages, partner listings, event descriptions with registration links — these accumulate for years and are almost never re-verified. Domains lapse and get re-registered by somebody else. A quarterly job that extracts every outbound hostname from your CMS and runs it through the batch endpoint costs a trivial number of credits and occasionally saves you from the worst version of this problem, which is a phishing link sitting on a page with the library's name and logo above it. If your catalogue accepts user-generated content — patron reviews, reading lists, comments on local history items — the same check belongs in the submission path, called from your server so the key is never exposed in page source.
The third surface is staff email, and it is a different problem wearing the same clothes. Library IT teams are small, shared logins are more common than anyone likes to admit, and finance functions are frequently handled by one or two people whose addresses are published on the site for perfectly good public-accountability reasons. Invoice fraud and vendor-impersonation attempts land on those addresses regularly. Checking hostnames extracted from inbound links at the gateway, or from the message store after delivery, gives a verified verdict on the ones already known — a useful supplement to whatever filtering the mail platform provides, and the pattern described in more detail on the email security page.
The API key is the username chosen at registration, and it belongs on your server, never in a page that reaches a browser. Every one of these integrations is a server-side call. If you find yourself writing a fetch from client JavaScript, stop and put a small endpoint of your own in front of it.
checked, phishing_found and credits_used so your job can log a one-line summary.Most awareness material is illustrated with screenshots from years ago. A daily-refreshed list of live domains gives a teaching librarian something current to work from.
Public libraries run more practical internet-safety instruction than almost any other institution, usually as part of a broader digital-inclusion effort and usually to an audience that has been condescended to elsewhere. The recurring weakness of that teaching is not the teacher — it is the material. Curriculum packages age badly, the sample scam emails are visibly from another decade, and a class of adults who have been online for years can tell that the example is stale, which quietly undermines everything else in the session.
A feed of currently-resolving phishing domains is a teaching resource in a way that is easy to miss. You are not going to project live malicious sites in a classroom, and you should not. What you can do is work from the shapes: pull the current list, sort by the pattern you want to demonstrate, and build an exercise around the anatomy of the deception rather than any single instance. Show a group how many live domains at this moment contain a well-known brand name as a subdomain of something else entirely. Show how many end in a top-level domain the real organisation has never used. Show the difference between a hyphenated imitation and a genuine hostname, using examples that were verified as active this morning rather than in a textbook.
The daily changelog of added and removed domains supports a second kind of session, aimed at the volunteers and staff who help patrons at the desk. Watching a week of additions makes the churn viscerally obvious in a way no statistic does: these are hostnames that did not exist on Monday, were verified as resolving by Wednesday, and had gone dark by the following week. That observation teaches the correct instinct better than any rule of thumb, because it explains why "I would recognise a fake site" is not a strategy — the sites are new, they are numerous, and recognising them was never the job. The security awareness page goes further into building programmes around this material.
There is a nice symmetry in this that is worth saying out loud to a board. The same subscription that silently protects a patron who never attends a class also supplies the material for the class that teaches the patrons who do. One line in the budget, two entirely different kinds of service delivery, and neither of them requires the library to take a position on what anybody is allowed to read.
Two shapes of spending, one of which is small enough to hide inside an existing materials or technology line without a procurement process.
The credit route suits libraries whose use is occasional and bounded: quarterly link audits of the website, an annual sweep of staff bookmarks, checks on hostnames extracted from suspicious staff mail, and validation of user-submitted links in the catalogue. Credits are monthly subscriptions via PayPal, billed monthly, and priced by volume — the Growth plan is $99/month for 25,000 lookups at $0.0040 per lookup, the $99 Growth package is 25,000 , and the $249 Professional package is 100,000 . For a single library doing periodic audits rather than continuous checking, the smallest package is frequently a two-year supply, and the fourteen-day refund policy applies if under ten percent of the credits have been used.
The feed route is the one that actually protects the public terminals, because network-wide enforcement means every lookup is answered locally and no lookup is billed. The Daily Threat Feed is $499 per month, and the annual option adds the historical archive, priority support, custom format options, a dedicated account manager and 100,000 API credits — which conveniently covers the audit work described above without a separate purchase. Feed downloads are unlimited, so the cost does not move with the size of your network, the number of branches, or how busy the public access room gets.
For a single small library, $499 a month is a real number and it would be dishonest to pretend otherwise. This is where the consortium structure does the work it was invented for. A regional system, a co-operative, or a state library agency can hold one subscription and serve the pull to member branches, exactly as it already does for shared catalogue infrastructure and licensed databases. The per-branch arithmetic in that arrangement is the annual price divided across members, which for a co-operative of any size lands somewhere between negligible and invisible — and the members with no IT staff at all get the same protection as the members with a network engineer.
Above $4,000, bank transfer is available in place of PayPal, which matters more than it should for public institutions with card-payment restrictions and a purchase-order culture. Feed subscriptions can be paid the same way. If the requirement is genuinely larger — SFTP or S3 delivery into an existing state-level distribution pipeline, STIX/TAXII for a security operations centre that already ingests threat data, a custom update frequency, an SLA, or on-premise deployment — that is the enterprise tier and it is quoted rather than listed. The full credit table lives on the pricing page, and the delivery options are set out on the daily feed page.
One last piece of arithmetic that belongs in the board paper rather than the technical plan. The costs this prevents are not the library's costs, which is precisely why they never appear in a return-on-investment calculation and precisely why they are the biggest number in the room. A patron whose benefits claim is redirected loses a payment they were depending on and spends months proving it. A patron whose identity documents were uploaded to a fake immigration portal has a problem no branch can help with. The library's exposure in that scenario is reputational and moral rather than financial, and it is the kind of exposure that is very cheap to avoid and impossible to repair afterwards.
/stats endpoint requires no key, no credits and no authentication, and a free key from registration is enough to check individual domains by hand while you build the case internally.The objections below are the ones that come up in every conversation about this, and most of them deserve a straight answer rather than reassurance.
It depends entirely on what the list contains, and that is the question to ask rather than accepting the general framing. A category list is an editorial judgement about subject matter, and the objection is legitimate. This list contains hostnames verified as currently resolving and confirmed as credential-harvesting infrastructure — the category label in every response is simply phishing/malware. No idea becomes unavailable when one of them is blocked, no author loses a reader, and no line of enquiry closes. A library can hold a strong anti-filtering position and still block these without contradiction.
Not if you deploy the feed locally, which is the recommended pattern for exactly this reason. You download the full database once a day and load it into your own resolver or firewall. Every subsequent comparison happens on library equipment, so no record of any patron lookup is transmitted anywhere. The only outbound traffic is your nightly authenticated download of the list itself, which reveals nothing about who used a terminal or what they searched for. If you use the API check endpoint instead, each call does send that one hostname to the service — which is fine for auditing your own website's links, and is why patron-facing traffic should use the feed rather than the API.
Plan for it and it stops being a crisis. Keep a local allow-list that your reload script applies after the daily import, so an override survives the next update. Make the block page name the library and give a way to reach a person, because a patron who hits a false positive should be able to have the conversation immediately rather than concluding the library has decided they may not read something. Verification via active DNS resolution keeps the false-positive rate low, but no list is perfect, and the correction path matters more than the error rate.
No, and it is important not to present it that way to a funder. If your library operates a technology protection measure to satisfy a grant or programme condition, that condition speaks to categories of visual content and this list does not address it. The two sit alongside each other: the category product handles the compliance requirement, and the phishing feed handles a threat the category product was never designed to keep up with. Nothing here should be entered on a certification form as though it were a content filter.
Yes, and this is usually the highest-value part of the deployment because the guest network carries far more devices than the public access room does. If your captive portal hands out DHCP options, point the resolver at the box holding the list and every phone, tablet and laptop in the building is covered without an agent, an app, or anything the patron has to agree to. Devices using their own encrypted DNS will bypass it, which is worth knowing but not worth blocking over — the coverage you get from the default path is substantial, and the patrons most at risk are the least likely to have changed it.
The database is rebuilt every 24 hours with the daily build landing at 04:30 UTC, and each domain is DNS-verified through rotating proxy infrastructure so only hosts with an active A record are included. That verification standard is why the active count sits above 200,000 while the all-time observed figure is far larger — entries that stop resolving fall out rather than accumulating. A single check response carries last_checked as a date, dns_status of resolves, and a confidence of 0.98 for a confirmed match against 0.0 for no match. There is no partial score in between.
If your library already runs its own DNS resolver, this is a scheduled download and a reload — genuinely an afternoon for whoever maintains that box. If it does not, the honest answer is that you want to be part of a consortium or state-level arrangement where somebody else holds the subscription and runs the pull, and your branch simply points at their resolver. That is the same pattern already used for shared catalogues and licensed content, and it is the right shape for this too. Start by reading the API documentation and the feed options, then ask your co-operative whether anyone else has raised it.
Start with a free API key and the open statistics endpoint, run the list in monitor mode for a fortnight, and bring your own numbers to the board. If the public terminals and guest Wi-Fi are the priority, the daily feed is the deployment that keeps every patron query inside the building.
