41–50 of 128 posts
Running a local DNS server on these devices is also not possible?
Can a user access ifconfig and change interface settings, e.g. adding an alias?
In terms of networking, these devices appear to be crippled. Yet they do not have to be if they're built using code from BSD's.
Nice hack. Of course reverse dns doesn't work :-) I suppose it kinda sorta could if you tracked where a request came from and what IP you sent it and if you got a reverse lookup you could undo that, but still it is clever!
Reverse DNS is controlled by the company that owns the actual IP address. There's no way for a random website to change responses for it (unless they own the IP range, or were delegated control)
Nice hack. Of course reverse dns doesn't work :-) I suppose it kinda sorta could if you tracked where a request came from and what IP you sent it and if you got a reverse lookup you could undo that, but still it is clever!
Reverse DNS is controlled by the company that owns the actual IP address. There's no way for a random website to change responses for it (unless they own the IP range, or were delegated control)
When you reverse map an IP you look up b4.b3.b2.b1.in-addr.arpa. where b1 - b4 are bytes 1 through 4 (in reverse order) of the IP address. So 10.1.2.3 becomes 3.2.1.10.in-addr.arpa. The interesting bit is you send this to some dns resolver, typically in the 'generic' world your machine got the address of a resolver (and maybe a backup) from the DHCP server that gave it the IP address. When that dns server sees this request what it is supposed to do is to either tell you to 'go fish' and here is the IP of a server than can help, or 'recursively resolve' by forwarding on your request. Now if you run a vanilla BIND or djbdns setup you will get short circuited by it recognizing a 'private' address and not resolving it, if it did try the root servers tell you to go away as well. But if you recognized it as a private address and sent it back to xip.io DNS servers on a lark, they could "pretend" to be authorative for the domain and return you a cname record that pointed back to your fake name.
I admit it is a hack on top of another hack but as long as we're writing custom DNS servers why not go all in? :-)
Earlier quoted context omitted.
Reverse DNS is controlled by the company that owns the actual IP address. There's no way for a random website to change responses for it (unless they own the IP range, or were delegated control)
Isn't it controlled by whoever is running the .arpa domain?
[1] If you ever wondered how openDNS or your ISP sends you spammy web pages when you try to resolve something that doesn't exist, or how the hotel hijacks your browser into giving you a login page, this is it. You look for google.com it notes you haven't logged in and returns the address for its paywall as the answer.
Oh except if you are running dnssec in which case it is a lot harder to lie about what you are authoritative for. But on my dns servers at home they all think they are authoritative for 10.in-addr.arpa. so that they will answer queries for that network.
Why is this better than adding an entry to my hosts file?
Earlier quoted context omitted.
Sometimes vhosts are convenient, sometimes they're even mandatory. For example, with XMPP servers, multi-user chat and any components must live on a subdomain. So if your main server is running on example.com then the MUC server is, say, conference.example.com and component "foo" is foo.example.com. No way around it short of hacking the source (and, if I'm not mistaken, violating standards.) This is just one situatio…
> For example, with XMPP servers, multi-user chat and any components must live on a subdomain. This is only necessary if you want users outside your domain to access your component. While you probably want to do so for MUC, you might not necessarily want to bother for your user directory or gateways. I've run many servers over the years and long since stopped creating a host/subdomain for each component.
[~]$ dig foo.169.254.84.1.xip.io
foo.169.254.84.1.xip.io. 600 IN CNAME foo.daze1.xip.io.
foo.daze1.xip.io. 600 IN A 169.254.84.1
[~]$ dig +short NS xip.io
[~]$
xip.io. 86400 IN NS ns-1.xip.io.
xip.io. 86400 IN NS ns6.gandi.net.
;; Received 86 bytes from 2001:678:5::1#53(b.nic.io) in 60 ms
[~]$ dig @ns6.gandi.net. SOA xip.io
;; ->>HEADERWhy is this better than adding an entry to my hosts file?
I've identified several technical problems with this domain, and this isn't an example of how to properly operate DNS. 37signals is setting an absurdly low TTL on these records (10 minutes; the answers never change, I absolutely do not understand the logic behind this TTL), which means every 10 minutes you're re-resolving a local address , through a CNAME (so two DNS round trips, and in my case this resolution took b…