Bizarre and unusual uses of DNS | Hacker News Reader

Bizarre and unusual uses of DNS

fosdem.org

318 pointstodsacerdoti138 comments

Tangentially related: One can store SSH server host keys in DNS and tell the client to make use of them. (OpenSSH supports `VerifyHostKeyDNS=yes`.) This is an alternative to the client asking the user to confirm the server host key, which many people just blindly confirm.

I asked GitLab if they could make use of that, but it hasn't received much attention so far:

* https://gitlab.com/gitlab-com/www-gitlab-com/-/issues/10376

You'd need DNSSEC for this right? If not can't an MITM still intercept the DNS lookup and substitute their own key?

In fact, even if the original domain does support DNSSEC, can a userspace program such as the SSH client actually tell whether the record it just resolved was resolved using a DNSSEC-aware resolver?

Yes, you would need a DNSSEC-validating resolver, and no, ssh(1) can't confirm if the answer was actually validated or not.

There's an "ad" (Authenticated Data) flag in the DNS reply header that a resolver can set to 1 to indicate that it validated the answer, but an MITM can also just set that to 1. The client would have to do its own validation, and ssh(1) doesn't. Therefore, you can only safely use this if you use a DNSSEC-validating resolver, and you trust the resolver (e.g. you administer it yourself), and you have a trusted path between you and it (e.g. it's on your LAN).

> and no, ssh(1) can't confirm if the answer was actually validated or not.

Isn’t this a gap in the API? res_query/etc should provide some way to find out if the response is validated or not. That would require either (1) a validating resolver running locally, or (2) a remote validating revolver, accessed over a secure protocol (such as DoT or DoH), which the system administrator has elected to trust. But the system should be able to tell applications, via some API, whether (1) or (2) hold or not

This is [was; the quote in the parent was edited] incorrect, the response includes `header.ad`, which on Linux is controlled by both what the resolver responds with and `option trust-ad` in /etc/resolv.conf, so the administrator can choose if they trust their resolver via "trust-ad".

Thanks for clarifying, that makes more sense. I was just going by what the person I was replying to was saying.

The man pages on my Linux box are too old to mention the trust-ad option, although newer Linux man pages do.

glibc defines a RES_TRUSTAD bit which is equivalent, so applications can choose to request and trust the AD bit even if resolv.conf isn't configured to do so. However, that doesn't appear to be documented anywhere other than the header file and the NEWS file in the glibc distribution. Both RES_TRUSTAD and trust-ad were added in glibc 2.31 (released Feb 2020).

Yes, I mentioned the AD header. However, I stand by my statement that ssh(1) cannot confirm whether the answer was actually validated because an MITM could have set that flag.

EDIT: I meant for this to be a reply to my sibling comment.

If ssh is using the GNU C Library’s resolv functions, and it isn’t setting RES_TRUSTAD, then glibc will automatically clear the AD bit unless the sysadmin has configured the trustad option in resolv.conf. A competent sysadmin would only do that in cases where MITM is impossible - either a local validating resolver, or DoT/DoH to a remote validating resolver. It is true that ssh has to trust the sysadmin to be competent and not enable that option in cases where MITM is possible, but I think that’s a general assumption for security that the sysadmin is doing the right thing, otherwise there are numerous other possible insecure configurations which might break ssh’s security. To double foolproof it, ssh_config could come with its own trustad setting independent of resolv.conf, so you’d have to set both.

An example to work around this would be to run a validating resolver (for example unbound) on localhost of each host and have it forward to whatever DNS server you use today.

If you're on Ubuntu, you most likely have a local resolver running already.

On Ubuntu the default is to use systemd-resolved, which is actually a validating stub resolver. You just need to set DNSSEC=true (see man resolved.conf) and it will work*.

*: this is the definition of "work" that also means it won't resolve anything if anything is wrong with DNSSEC validation, but if you want to be secure you need it to fail closed.

There should be an option for "validate but still return invalid data, just reflect validity in the AD bit". Is there?

That way most things will still work even DNSSEC is broken, and apps with higher security requirements can opt-in to "fail if invalid", by passing setting the AD bit on queries, and checking if it is still there on responses.

I believe that is DNSSEC=allow-downgrade which is also the default.

I thought “allow-downgrade” meant it would return unsigned data, but not invalidly signed data? I was talking about the latter case not the former.

You could be right. I guess the documentation isn't terribly clear...

Perhaps a solution such as dnscrypt-proxy and configuring it to forward requests that match certain patterns to a validating resolver on the local network would work? Requests that didn't match could be forwarded to some other resolver that wasn't configured to validate.

Trusted path could also be DoH or DoT as well, but yeah, not just 53/udp in the clear over the internet.

This is fun but a more practical solution would be for “ssh host” to GET the host’s public key from https://host/.well-known/.

The OpenSSH daemon could host it for you if you could fit a tiny, vuln free httpd inside it — not an enormously onerous task given that the codebase already includes the implementation of a robust TCP daemon. Add ACME support and you’ve moved the TOFU MITM attack from being possible on every-new-client-connection to also having to coincide with the once-every-X-days for the HTTPS certificate renewal.

It’s a lot of new functionality which probably isn’t cool for the OpenSSH codebase, but it’s a pragmatic solution to plugging the gap between mankind’s universally deployed PKI and ssh’s ephemeral peer-to-peer verification.

So one needs to run an HTTP-Server for a host that only has SSH otherwise?

> but it's a pragmatic ...

I think we have different views of the word pragmatic if your pragmatic solution covers including a HTTP server in OpenSSH for serving a single (!) file while the other solution depends on something you most probably already use to connect to the server (DNS).

Hah, I’m surprised you zoomed in on that part. All you have to do for the protocol is blurt out “HTTP/1.1 200 OK\n\nssh-rsa AAAAf00fcafe…=“ on port 443 instead of “SSH-2.0-OpenSSH_xyz EtcEtc” on port 22. I wouldn’t (and didn’t) suggest you include code to respond with the contents of files, nor should you even bother parsing the request*.

The harder part is what is the client going to do? How will you implement TLS at each end? Your ssh client will want to link against an HTTP library that integrates with the client OS’s x509 PKI. That will be the axiom upon which your trust of the server is founded. OpenSSH’s client might trust their ssh host key because it was served in a connection signed by Let’s Encrypt, and the local copy of libcurl used libssl which found Let’s Encrypt in /etc/ssl/cacerts.pem etc etc.

The hardest part is adding a TLS implementation to the OpenSSH daemon and the crazy part is having it support ACME so it can fetch its own certificates**. There is precedent for this though — caddy includes support for negotiating issuance and renewal of SSL certificates via ACME:

https://caddyserver.com/

Adding a new feature like this comes with the responsibility of supporting it in production and fixing bugs (in this case, dealing with weird missing features) for the remaining lifetime of the product. It’s not something to be done as lightly as an HN comment, by any means. There are a lot of sensible reasons to use DNS to bootstrap trust but as others have pointed out it is a little naive to think that DNSSEC has anything like the level of deployment that HTTPS has achieved since ACME and Lets Encrypt showed up. I contend that it’s that aspect which makes my solution indeed a more practical method — pragmatic, even — of bootstrapping trust over The Internet in 2023.

* Yes, this will mean you cannot support clients that demand their content be encoded with xzip in ylang with zspace. We’re not writing a real httpd here, remember.

** If it’s using ACME HTTP then that makes the simplistic httpd a bit more complicated, of course. Now you have to blurt two responses instead of one.

> not an enormously onerous task given that the codebase already includes the implementation of a robust TCP daemon.

Yeah then you got at least two more problems. SSL and OCSP

Doesn't SSH already support using TLS keys for authentication? So, we can skip the whole HTTPS part of the equation.

No it has its own certificate system, it’s not TLS and it’s not even X.509.

Not being x.509 is arguably a good thing. :)

Jup, it does. And that was my first thought reading this as well.

Making SSH authentication dependent on HTTPS seems like a really bad idea.

However I'd wish the reverse is true, SSH via TLS connections, so I don't need to open another 22 port, and make my SSH hidden behind Cloudflare or something.

Making ssh authentication dependent on honesty seems like a really bad idea.

In that vein, is there something that could allow me to manage authorized_keys via DNS? Let's say I own capableweb.com, I'd love it if sshd could just read all records from keys.capableweb.com and use those as valid public keys.

I have bunch of personal servers, and bunch of keys in use, many of the servers are not automated (they're pets, not cattle), so when I rotate keys, it's sometimes a hassle.

Mostly asking just because it'd be fun.

As mentioned elsewhere in this thread, actually using SSHFP in a secure way is difficult.

Far better is to use SSH host certificates, then your known_hosts can simply have a @cert-authority * some-cert in it. (See https://www.lorier.net/docs/ssh-ca.html)

AuthorizedKeysCommand is what you are looking for.

https://man.openbsd.org/sshd_config#AuthorizedKeysCommand

That is indeed what seems to be the most useful out of all the replies, thanks a lot!

Be warned that when using this a lot of the security comes down to your own implementation of that command.

The suggested alternative using certificates is a much more standard way that has less ways to create holes in your security.

Maybe I'm missing something obvious, but seems to be much more up to the security of my DNS setup rather than the command.

The command would basically hit "keys.my-domain.example" and return the values of each TXT record. Not sure what could go wrong here, besides if I lose DNS access, I won't have access to the boxes. Probably add some sort of caching as well for that.

But otherwise, it seems to be much more about the security of what goes into "keys.my-domain.example".

That's what I meant. Just looking up a DNS record as an implementation sounds like a bad idea. You would have to set up thinks like DNSSec validation, and consider all the ways in which that could fail.

The cleanest way in your use case would be to store keys in an LDAP server instead of local users' authorized_keys You can plug any of your server to this LDAP and enjoy the same users and keys everywhere.

If you trust GitHub you could curl https://github.com/capableweb.keys on startup

I’ve set up an AuthorizedKeysCommand that uses unbound to get the authorized keys for the server via DNSSEC, with the ability to specify keys for whole servers, users on servers or globally for all servers. This is pretty neat for my few private boxes, I wouldn’t advise it for something bigger or enterprise, an ldap or similar seems better for that.

People scaling SSH authorization tend to set up SSH CAs (either directly, or baked into some higher-level management solution). SSH CAs scale down nicely, as well.

An SSH certificate authority is what I’d choose for that. Can work with both user keys and host keys. The host certs have a field for demonstrating their hostname; the user certs have a field restricting their username. So, as the certificate authority you have a little more power than what you can distribute via DNS.

Similar idea: This runs as a cron/systemd timer and updates your authorized_keys from your GitHub account.

https://github.com/shoenig/ssh-key-sync

https://github.com/samber/sync-ssh-keys/

There are also 'free for personal' use commercial systems that work in a similar way to some of the suggestions posted in the comments:

https://www.keystash.io

You might consider checking in an authorized_keys file? Not as fun as dns, but maybe easier. You can use ssh-keyscan to build the file.

A tiny bash script and a cronjob

It's also possible to distribute PGP keys this way. Probably a much better solution than the keyserver mess.

https://www.pgp.guide/pgp_dns/

Please don't put security stuff in DNS. DNS isn't secure and DNSSEC is a travesty. Just take the records it gives "under advisement" and confirm it over TLS or another secure transport protocol.

Can you be more specific in your criticism of DNSSEC?

This is the tptacek bat signal

https://sockpuppet.org/blog/2015/01/15/against-dnssec/

And yet here we are, eight years later, DNSSEC adoption still growing.

Grab any list of the top domains on the Internet. My go-to has been the "Moz 500" --- I don't know what it is, or whether it's any good, but it's easy to get. Then write the trivial shell loop to `dig ds $domain`, and count how many of the top domains are signed. Some patterns will emerge: government sites, unsurprisingly, have subscribed themselves to the de jure government PKI that DNSSEC is, and commercial sites overwhelmingly do not.

It's very easy to just check this for yourself. There are increasing numbers of domains signed every year, because registrars and product companies have baked DNSSEC in as a feature. But the vast majority of zones don't matter: nobody ever looks anything up in them. The figure of merit is how many important zones are signed.

> `dig ds $domain`

Amusingly for this method to work the resolver must understand DNSSEC. This is because DS records exist solely at the parent side of a delegation. A resolver that is not aware of DNSSEC will look to the child as it would for any other kind of record type.

The rate of DNSSEC signed zones is growing, but the number of recursive resolvers that hard fail on validation failures is static or going down.

Unfortunately the user experience for a DNSSEC signature failure is so bad, the only option if you run a large ISP or corporate network is to just use the answer you get anyway.

Since (regrettably, for other reasons), many people seem to be moving to use centralized resolvers which all, incidentally, do validate DNSSEC strictly, I doubt whether “number of recursive resolvers” is a valid proxy for “number of users using DNSSEC validation in practice” anymore.

In fact, I see a lot of people advocating for using centralized resolvers, and not even once have I seen a counter-argument in the form of DNSSEC validation being a problem.

What does it matter if your centralized resolver across the Internet is doing DNSSEC? The same on-path attacker DNSSEC was designed to address can defeat DNSSEC on the path between you and the resolver. It's a baffling design.

It matters because the topic was whether DNSSEC is growing or not, specifically whether more or fewer users are using DNSSEC validating resolvers. You’re not just moving the goalposts, you’re changing the topic entirely.

The horse has been beaten to death - DNSSEC is dead. It continues to see adoption on the authoritative side because turning it on in a basic state and letting it limp along costs almost nothing.

Many recursive servers do validate DNSSEC, but disable it on a per-zone basis when validation failures happen and users start to complain.

tptacek raises an additional good point that DNSSEC does nothing to protect the last mile of a query. It also provides zero confidentiality.

dnscrypt was always a superior implementation, but saw little uptake because people blindly believed the DNSSEC propaganda.

From my perspective, DNSSEC is very much alive, and moreso every year. At work, we only ever see requests for more DNSSEC from everybody; both customers and TLDs/registries. Nobody at conferences, both formally and in informal conversations, has said anything against DNSSEC in principle. I used to say that I ever only saw one person argue against DNSSEC; and it was here on HN. I guess that I can now say that it is two people, both here on HN.

If validation failures were that common, I would think I, working at a domain registrar and authoritative DNS provider, would hear about it. The last mile problem would be solved by DoT/DoH, no?

If anything is a “dead horse”, it’s dnscrypt. Are you claiming that DNSSEC is some sort of industry conspiracy?

It's a conspiracy, but not from the industry, which has broadly rejected it. :)

What “industry” would that be? Certainly not the DNS industry, or their customers (i.e. anybody who wants a domain name). Do you mean “rejected” in the same sense as how IPv6 is still only slowly being adopted?

I remember 15 years or so; a friend and I figured out that DNS got through my friends cellular connection even though the data limit were reached. We tested and set up a socks-over-dns-proxy back then and it worked! We loled and then never did anything more than that unfortunately (or it depends, we´d most likely be detected if we continued to use that, eh, solution).

This is really common in ‘airgapped networks’ so much that tools exist to create tunnels. I tested this on a job and upstream dns servers blocked me after about 1mb of traffic, it’s an abuse of a public service and a complete waste of resources (5-10x amplification) so something that’s completely understandable.

I imagine 10 years ago, controls may not have been so good though.

Edit: part of the rationale in some cases, I believe, is to facilitate captive portals for hotel wifi login etc.

About 15 years ago as well, a cruise ship I was on blocked most connections if you hadn't paid, but allowed DNS, so I tunneled some vpn over dns and it worked.

I want a comedy sketch for this where you’re explaining your traffic to a sysadmin.

“I just really like looking up A records from dig”

So true. Supposedly, worked in a couple cases, but they knew to accept the quote.

https://code.kryo.se/iodine/ comes to mind

Did y’all go to Northeastern? I had a classmate named Pete at the time who did the same. He landed at google, smart guy.

Reminds me of a hack with X.25 networks. Certain packet types werent billed, so people used them to communicate (something like hiding information in ICMP packets).

Another fun one I learned about recently: `e164.arpa` is a reserved domain for E.164 phone number to Internet address lookups[1]: you can query it for NAPTR records, which tell the client how to initiate a call over the Internet (via SIP) instead of over PSTN.

[1]: https://www.ietf.org/rfc/rfc2916.txt

I worked in that space for over a decade. While it's true, the use of E.164 in production was never done (usually, it's some subdomain from the Oligarchic Cell Phone companies). Second, it's never free. Nothing on the telephony network is free. Third, you get back data that includes a regex on how to transform the other data into something you can use---very convoluted.

Too bad; this would be really cool to 'own' your E.164 domain in some cases

e164.arpa was never used in production? By whom exactly? Because I can tell you it’s heavily in use currently by many large telecom/voip companies

Verizon for one, at least in the US. I know I used e164.arpa for testing purposes, until new management came in and demanded we use the domain we use in production for testing (because, well, production, I guess? Keep the configs as the same as much as possible?).

Now that I've name names (or a name), how about you? Who uses e164.arpa?

Voxeo/Aspect/Alvaria

Someone in the old days was playing around with VERY small RSS feeds in DNS TXT records. The slides mention blogging but at a UI level whereas this was "what if we put actual RSS feeds in DNS?" There was some sort of multiline protocol; don't remember how it worked. It never gained traction but I thought it was cool.

There was also something very weird with VRML files in the early 90s, like favicon but in 3d and shipped over DNS kind of idea. Yeah that got about zero traction also.

There should be a whole website about failed 90/00s web technologies that didn't take off.

WAP (which I hasten to say meant something else in the 90s, probably to its detriment)

Off the top of my head: VRML, Gopher, AOL, CompuServe, MSN, the blink and marquee tags, XHTML and the semantic web, ActiveX, VBScript, newsgroups

While those are (mostly) dead now, it would be unfair to say they never took off. In their day some of these were huge,and enormously influential on what we have today.

News (NNTP) basically _was_ the Internet before HTTP came along, and still exists today, albeit in niche form. I still check News every day.

Your standard seems to be "things that were one popular, but have been replaced." whereas the 90's were full of ideas that literally never took off. Like cuecat https://en.m.wikipedia.org/wiki/CueCat

And don't get me started on the blink tag. That was huge, if anything, overused. That was activly killed (for good reason) because it made most Web pages beyond horrible. For some reason non-computer people weren't happy unless like half the site was blinking all the time. It was beyond terrible.

Frankly the jury is still out on VR headsets (an idea from the 60s that simply won't die.)

The marquee tag isn't dead: https://developer.mozilla.org/en-US/docs/Web/HTML/Element/ma...

By now flash and Java applets are in this category too

Edit: never mind, these are dead now, but they definitely took off in their day.

Just because something's dead now doesn't mean that it never took off.

True, my bad.

pets-cemetery.com

I'm not sure if this was covered in the presentation, but DNS Toys (which can for example tell the weather, do units conversions, etc.) was featured on HN about 8 months ago:

DNS Toys (946 points) https://news.ycombinator.com/item?id=31704789

A prior company I worked at had API keys (like AWS) in TXT records that would be used in some bootstrapping. Thats uhh, certainly a convenient place to put them, yeah.

Was it at least private DNS?

In practice, there’s no such thing as “private” DNS. You can disable zone transfers and type “ANY” queries, but NSEC records of DNSSEC enable name enumeration, and public resolvers record and often publish the queries done through them.

Do not put any private information in DNS. It’s not made for it, and many, many systems which work with DNS assume in their design that all DNS data is public.

They may be referring to private resolvers used within a private address range (e.g., https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/ho...)

The DNS data is still not encrypted over the wire, and clients could use their own local resolver which in turn uses the private resolver. This local resolver will most probably be designed with the assumption that DNS data is public.

Route53 private DNS is resolved over link-local addresses, so whether the responses are encrypted is irrelevant. They're specifically designed for private resolution within a VPC.

6. The network is secure.

— https://en.wikipedia.org/wiki/Fallacies_of_distributed_compu...

Link-local networking in VPC is specifically designed to secure data that is plaintext at the application layer (DNS). It’s effectively communication with the hypervisor, not over some untrusted link.

If you don’t buy this, I guess you should start encrypting all your syscalls too?

> If you don’t buy this, I guess you should start encrypting all your syscalls too?

Don't forget to encrypt all .socket's, and maybe encrypt everything over at /dev as well.

If you believe a piece of link local infrastructure is a good carrier to trust your data, I have some great broken switches you may be interested in buying.

Or if you insist on it being a virtual stack, how about some DMA engines with transient errors that mix up your packet headers from their payloads?

The network is secure is a fallacy.

The “network” between the CPU and memory is also insecure. It’s turtles all the way down.

That’s assuming a generic network

You could possibly encrypt them.

Reminded me of Corey Quinn's "Route53 as a database"

https://www.lastweekinaws.com/blog/route-53-amazons-premier-...

That is given a slide in the talk, yep.

This is the kind of stuff that makes the internet fun. I really like the types of projects that exist simply to exist. People putting out things that have no reason except for the enjoyment.

It seems like we're missing this kind of stuff lately. Even the April 1st hacks have failed to be interesting on the same level. I wonder what has happened and why.

I made an elixir library called mechanical turk down that blocks until the newly created mechanical turk job gets a response to render the markdown

Yeah, and then this "enjoyment" spills into real-life widely used programs, s.a. Kubernetes. This is literally me, yesterday discovering a little "gotcha" of an L7 reverse proxy in Kubernetes:

    # netstat $(hostname) 40443
    Trying 10.X.X.X
    Connected to hostname.foo.bar
    Escape character is '^]'
    ...
    # ss -tpln | grep 40443
    #
    # lsof -i :40443
    #

This kind of fun makes you want to punch each individual ITF member as well as people in Kubernetes who decided it'd be cool to implement L7 proxy using DNAT.

Good that they didn't, then.

No, seriously, there is no L7 reverse proxy implemented using kube-proxy mechanism (aforementioned DNAT) - It's L4 proxy for supporting legacy code that doesn't support intelligently querying for endpoints (by SRV record, k8s API, or other service discovery protocol).

It's not even required to use it, Services can be declared to not need it (common example is using service mesh or ingress controller with http)

We are talking about Kubernetes ingress controllers, in particular, ngnix-based one.

Which doesn't use DNAT unless you explicitly configure it to do so.

nginx-ingress will read Service Endpoints through k8s API and resolve connections to specific pod IPs so long as your network is properly deployed.

Of course it's also possible to make it go through serviceIP (which by default is still implemented using DNAT in kube-proxy), but it's not recommended.

NodePorts like the example given earlier exist for dealing with external traffic from hosts unaware of (possibly unroutable) serviceIP and podIP ranges.

I had lots of !FUN! with nginx-ingress, but that's not one of its faults.

ClamAV passes its versioning via DNS. No need to open outbound HTTP.

Wonder if ClamAV might have learnt this trick from malware implementations.

I had set up dnsmasq once and spotted all these weird DNS requests coming out of our network. Turns out some Java installation builder software was using DNS to verify the license status of the software. They would do a lookup something like

$LICENSE_NUMBER.$NAME.$ZIPCODE.example.com

and the reply would indicate the license status.

As a TXT dns entry? Or?

Yes, the domain to query is current.cvd.clamav.net

Cooool.

  $ dig TXT current.cvd.clamav.net

  ...

  ;; QUESTION SECTION:
  ;current.cvd.clamav.net.                IN      TXT

  ;; ANSWER SECTION:
  current.cvd.clamav.net. 972     IN      TXT     "0.103.8:62:26823:1677366000:1:90:49192:334"

Link to pdf slides https://fosdem.org/2023/schedule/event/dns_bizarre_and_unusu...

Sadly, we can't have browsers that use SRV records.

HTTPS records are (reportedly) coming soon™: https://datatracker.ietf.org/doc/draft-ietf-dnsop-svcb-https...

TL;DR: HTTPS records are like SRV records without the weight number (but, crucially, including the priority number), and with some extra stuff to make the TLS handshake happier.

Note that there are both HTTPS and SVCB record types.

Regardless of the standard being finalized there's already some support in the wild. To name a few prominent ones iOS, macOS, Cloudflare, Akamai, and NS1 all support both types.

https://github.com/MikeBishop/dns-alt-svc/blob/main/svcb-imp...

> Note that there are both HTTPS and SVCB record types.

Yes, but the topic was web browsers, which would use the HTTPS record, not the SVCB one.

nice! thanks for the link, that gives me hope

DeCSS was at one time distributed via DNS:

http://decss.zoy.org/

I just tried it, it still works.

I once wrote a Chrome extension that uses DNS instead of HTTP to fetch web content: http://blog.zorinaq.com/cdn53-a-super-distributed-cdn/

Fun fact: you can store ~64 kB of data in a single TXT record

I was once working on a way to minimize PAC [1] file changes and came up with a hacky way to use DNS for this. The client would use isResolvable(parsedhost.pactest.int.domain.com) after some parsing of host, and use the result of the test to return either a PROXY result or DIRECT.

It resulted in an extra DNS query for every site being accessed, but because the query is internal and the client caches the result, it didn't add much load but otherwise worked well. Then it was just a matter of automating A record creation.

[1] https://en.wikipedia.org/wiki/Proxy_auto-config

Hesiod came out if project Athena. It was used for posix accounts. Similar function to directory services such as LDAP.

Last time I checked (several years ago). There source code was still available if you poked around the CMU FTP servers. It was unavailable via http.

Edit, it actually may not have been FTP, it may have been on their AFS volumes.

https://en.m.wikipedia.org/wiki/Hesiod_(name_service)

https://news.ycombinator.com/item?id=31704789

I know of at least one serious security incident (maybe this is mentioned in the talk but I didn't hear it) in which data was exfiltrated from the victim's network by patiently making successive dns queries, which were of course unfiltered as they were considered innocuous, for long hostnames in which segments of the data were encoded. It was not an easy thing to patch.

I think it's different than the one discussed in the slide, but VPN like SoftEther can obfuscate traffic as DNS, too.

https://www.softether.org/1-features/1._Ultimate_Powerful_VP...!)

lspci has an option to update it's database over DNS (lspci -q)

"HTTP over DNS over HTTPS"

All your counters, sets and lists you've got in Redis, with the equivalent of a WAF: https://github.com/m3047/rkvdns

You can bypass captive portals by using some of the ideas displayed in this presentation, but you will probably also need to have a server with a good unmetered connection and a cleverly named (sub)domain.

Iodine (https://github.com/yarrick/iodine) will do this. I did it with my home Internet connection as the server and found it very useful in a pinch.

Using DNS to exfiltrate arbitrary data thru firewalls that don’t log DNS requests is handy too.

Iodine can apparently only go up to 1Mbit because of Reasons™ per the documentation. I've always been curious why.

> and a cleverly named (sub)domain

What do you mean here?

- The One True Sysadmin will look through all the logs and find your server and block it and you'll have to pick another one next time

- The One True A(G)I will find your domain automagically and block it and you'll have to pick another one

...In all seriousness several MB of data to a DNS server will get you bitten at least once because someone somewhere is actually doing the job they're paid to do. But it'll probably be an exception.

As another replier noted, you might evade detection. But the reason I mentioned it is that captive portals (before authenticating) may not allow you at all to do DNS queries... except, for their own whitelisted domains. Depending on how they do it and how they wrote their rules, if they allow example.com you could potentially query example.com.mydomain.com

Another example is tic-tac-toe over DNS, https://github.com/Firemoon777/tic-tac-toe-dns

HTTPS://nip.io resolves to IP addresses as provided by the subdomain, a useful tool and demonstration in some circumstances

Reply on news.ycombinator.com