Authoritative nameservers
The zone is distributed across four authoritative nameservers, separated by network and domain and reachable over IPv4 and IPv6. The parent-domain delegation matches the nameservers declared by the zone.
Site engineering
How www.openmilanese.it is built.
A static website designed around the same principles used for production infrastructure: simplicity, clear responsibility boundaries, secure defaults, verification and rollback.
Objective: publish professional content without introducing server-side dynamic components, browser tracking or unnecessary external dependencies.
First public layer
Publishing begins before the web server.
Before a browser can negotiate TLS or request a page, the domain must be correctly delegated, reliably resolved and protected throughout the DNS chain. The domain and DNS therefore form the first layer of the website’s public architecture.
DNSSEC across the chain
The DS record in the parent domain cryptographically connects the delegation to the zone keys. Validating resolvers can therefore verify the authenticity and integrity of DNS responses without confusing this protection with encryption or confidentiality.
IPv4 and IPv6 publishing
The domain and web service are published through A and AAAA records. Compatible clients can reach the site directly over IPv6 while IPv4 remains available for networks without complete IPv6 connectivity.
Controlled certificate issuance
CAA records restrict ordinary and wildcard certificate issuance to authorised Certification Authorities. A dedicated contact receives reports concerning non-compliant issuance requests.
Email authentication
Microsoft 365 handles reception. SPF restricts authorised senders, DKIM signs messages and DMARC requires strict alignment with a reject policy, sending reports to a dedicated address.
DNS as infrastructure
Delegations, DNSSEC signatures, application records, CAA authorisations and email authentication must remain consistent with the published services. Migrations and decommissioning are therefore managed with propagation, dependencies and recovery in mind.
Wildcard records are not used: every public hostname must be intentionally defined in the zone. The authoritative service responds over UDP and TCP and does not expose public zone transfers or recursive resolution.
Design principles
Simple does not mean improvised.
Reducing the component count is an architectural decision. Every retained element must have a clear purpose, observable behaviour and a replacement or rollback path.
Fewer exposed components
No CMS, database, application runtime or public administration panel. The site serves only the static resources required for reading it.
Privacy by design
No cookies, advertising systems, remote fonts or browser-side analytics. Pages require no account and collect no data through web forms.
Explicit URLs and behaviour
Canonical URLs, hreflang, permanent redirects, the 404 page and cache policies are defined and verified rather than delegated to implicit server behaviour.
Repeatable, reversible releases
Each package declares a version and includes checksums, deployment tooling and post-release checks. A timestamped backup is created before replacement.
Responsibility boundaries
Each policy at the correct layer.
The frontend and backend do not blindly duplicate the same functions. Configuration follows the real request path.
- HAProxy, public frontend
- TLS termination, HTTPS publication, HSTS, backend selection and management of the Internet-facing boundary.
- Apache, HTTP backend
- DocumentRoot, absolute canonical redirects, error handling, content security headers, compression and cache policies.
- Static content
- HTML semantics, accessibility, technical SEO metadata, structured data, language links and references to local versioned assets.
- Release process
- Backup, content synchronisation, permissions, Apache configuration validation and end-to-end tests against public URLs.
Apache receives HTTP from the proxy. Public HTTPS redirects therefore use absolute destinations and do not rely on the scheme observed on the backend connection.
HTTP security
Controls aligned with a static site.
The policies remove browser capabilities that are not required and explicitly constrain authorised origins. They complement, rather than replace, patching and server hardening.
Content Security Policy
Resources are limited to the site origin; framing, objects, forms, application connections, media and workers that are not required are disabled.
Browser policies
nosniff, restricted referrers, frame denial, cross-origin isolation and disabled unused capabilities through Permissions Policy.
Transport at the frontend
HTTPS and HSTS are handled by HAProxy, the TLS termination point. The backend does not present certificates to the public client.
Reporting channel
The standard /.well-known/security.txt path publishes a contact, policy and verifiable expiry date.
Performance and caching
Updatable content, cacheable assets.
HTML pages must be replaceable quickly; immutable assets can be retained by the browser for much longer.
Immediate revalidation
HTML pages may be stored by the browser, but they must be revalidated before each reuse. Updated navigation, metadata and published content therefore become available without waiting for a long expiry.
Cache-Control: no-cache, max-age=0, must-revalidateVersioned names and annual caching
Core CSS, JavaScript and images include a date in the filename. A content change creates a new URL, while the previous resource remains genuinely immutable.
site.20260803.css · site.20260803.js · lab.20260801.css → max-age=31536000, immutableTechnical SEO
Indexing based on canonical URLs.
The Italian and English versions link to each other symmetrically, while the sitemap exposes only the destinations intended for indexing.
- Absolute canonical URL for every indexable page.
- Italian, English and
x-defaulthreflang. - XML sitemap with canonical pages only and modification dates.
- Structured data for the website, profile, person, article and breadcrumb.
- Open Graph and Twitter Card metadata with a local image.
- HTTP 301 redirects for compatibility URLs.
Publishing
A release is a verifiable sequence.
The package contains more than public files: it includes the tooling required to install, validate and, when necessary, restore the previous version.
- SourcesContent and server configuration are kept in one package.
- VersionThe release number and changed asset names are updated.
- ChecksumsSHA-256 hashes verify the integrity of distributed files.
- DeploymentBackup, synchronisation, permissions and Apache configuration.
- VerificationHTTP status, redirects, canonical links, headers, caching and expected content.
./verify.sh https://www.openmilanese.it
Essential privacy
What is not required is not collected.
A static architecture eliminates entire categories of data processing and reduces the number of parties and services involved in visiting the site. Normal technical service logs and emails sent voluntarily are described in the dedicated privacy notice.
Read the privacy notice →- No technical or profiling cookies set by the site.
- No Web Storage or persistent browser identifier.
- No account, login or personal area.
- No web forms or contact database.
- No third-party fonts, CDN resources or scripts.
- No analytics executed in the browser.
- No advertising or remarketing system.
Security reporting
Reporting a security issue
Vulnerabilities, malfunctions or anomalous website behaviour can be reported to webmaster@openmilanese.it. Phishing, spam, impersonation or other abuse involving the domain can be reported to abuse@openmilanese.it. Both contacts are published in the standard security.txt file.
Useful information
- affected URL or resource;
- description of the observed behaviour;
- minimum reproduction steps;
- estimated technical impact;
- relevant headers or timestamps.
Testing boundaries
- do not impair service availability or integrity;
- do not access data beyond what is strictly required;
- do not send credentials or third-party personal data;
- do not perform destructive or persistent activity;
- do not assume a reward or public acknowledgement.
This page describes the security reporting channel for the personal website www.openmilanese.it; it is not a bug bounty programme and does not promise a specific response time.