|
| grendelt wrote:
| " _HTTP over DNS over HTTPS_ "
| mikeponders wrote:
| 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.
| EvanAnderson wrote:
| 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.
| woodruffw wrote:
| 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
| spc476 wrote:
| 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.
| ehPReth wrote:
| Too bad; this would be really cool to 'own' your E.164 domain
| in some cases
| nighthawk454 wrote:
| Reminded me of Corey Quinn's "Route53 as a database"
|
| https://www.lastweekinaws.com/blog/route-53-amazons-premier-...
| spenczar5 wrote:
| That is given a slide in the talk, yep.
| pram wrote:
| 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.
| sunaurus wrote:
| Was it at least private DNS?
| teddyh wrote:
| 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.
| ericpauley wrote:
| They may be referring to private resolvers used within a
| private address range (e.g., https://docs.aws.amazon.com/Ro
| ute53/latest/DeveloperGuide/ho...)
| teddyh wrote:
| 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.
| ericpauley wrote:
| 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.
| teddyh wrote:
| 6. The network is secure.
|
| -- https://en.wikipedia.org/wiki/Fallacies_of_distributed
| _compu...
| fiddlerwoaroof wrote:
| That's assuming a generic network
| ericpauley wrote:
| 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?
| zyberzero wrote:
| 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).
| exabrial wrote:
| Sadly, we can't have browsers that use SRV records.
| teddyh wrote:
| HTTPS records are (reportedly) coming soon(tm):
| 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.
| manuel_w wrote:
| 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
| Nextgrid wrote:
| 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?
| aaronmdjones wrote:
| 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).
| evantahler wrote:
| Link to pdf slides
| https://fosdem.org/2023/schedule/event/dns_bizarre_and_unusu...
| trebligdivad wrote:
| lspci has an option to update it's database over DNS (lspci -q)
| VLM wrote:
| 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.
| xdfgh1112 wrote:
| There should be a whole website about failed 90/00s web
| technologies that didn't take off.
| bitlax wrote:
| https://news.ycombinator.com/item?id=31704789
| taftster wrote:
| 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.
| crabbone wrote:
| 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.
| p_l wrote:
| 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)
| ttyprintk wrote:
| ClamAV passes its versioning via DNS. No need to open outbound
| HTTP.
| unixhero wrote:
| As a TXT dns entry? Or?
| seedie wrote:
| Yes, the domain to query is current.cvd.clamav.net
___________________________________________________________________
(page generated 2023-02-25 23:00 UTC) |