In case anyone else is as unfamiliar as I was with the commands here: https://en.wikipedia.org/wiki/Dig_(command)
tldr is nice: https://tldr.ostera.io/dig
DNS Toys
101–110 of 111 posts
Re: DNS Toys
#102Earlier quoted context omitted.
This. I measured the difference using `tcpdump`, and this was my conclusion: > A big advantage of using DNS queries instead of HTTP queries is bandwidth: querying ns-aws.sslip.io requires a mere 592 bytes spread over 2 packets; Querying https://icanhazip.com/ requires 8692 bytes spread out over 34 packets—over 14 times as much! Admittedly bandwidth usage is a bigger concern for the one hosting the service than the on…
To be fair in the comparison; you can also query (via curl) icanhazip.com via HTTP instead of HTTPS, and it is only 5 packets and 385 bytes.
Good catch!
Re: DNS Toys
#103To others, yr.no is a free weather service with API: https://developer.yr.no I see that dns.toys use it.
Out of curiosity, I looked at the headers after clicking on your link and I found that it was sending Referrer as: https://news.ycombinator.com which is not an issue. But then I refreshed the page and saw the same Referrer again. So I checked where it was getting the Referrer from and it was not storing anything in localStorage, not in URL, nor in sessionStorage, nor in cookies. Any idea where the site was getting th…
Your browser remembers and replays it. localStorage/sessionStorage/cookies aren't available to parse by the time request headers are sent.
You'll notice this behavior goes away if you select the URL bar and hit enter (as if you were navigating to the site manually).
Re: DNS Toys
#104To others, yr.no is a free weather service with API: https://developer.yr.no I see that dns.toys use it.
Out of curiosity, I looked at the headers after clicking on your link and I found that it was sending Referrer as: https://news.ycombinator.com which is not an issue. But then I refreshed the page and saw the same Referrer again. So I checked where it was getting the Referrer from and it was not storing anything in localStorage, not in URL, nor in sessionStorage, nor in cookies. Any idea where the site was getting th…
Referer [sic] is determined by your browser, not the site. If you just refreshed the tab then its probably looking at the history.
Also, no browser that wants to make any claim of caring about privacy should still be sending cross-domain Referer headers by default which is yet another reason why Mozilla's privacy marketing is just that: marketing without substance.
Re: DNS Toys
#105I think it would work to use "time" etc as subdomains instead of TLD to be able to use any DNS server for the query.
Then you'd be at the mercy of caching in whatever recursive resolver is in between you and dns.toys. Sure, you can specify the TTL but if you give one to low many resolvers will ignore it and just make up their own.
Re: DNS Toys
#106To others, yr.no is a free weather service with API: https://developer.yr.no I see that dns.toys use it.
They also have nice graphs on their website. Been using yr.no as my primary site for weather info for years now.
Re: DNS Toys
#107Earlier quoted context omitted.
Out of curiosity, I looked at the headers after clicking on your link and I found that it was sending Referrer as: https://news.ycombinator.com which is not an issue. But then I refreshed the page and saw the same Referrer again. So I checked where it was getting the Referrer from and it was not storing anything in localStorage, not in URL, nor in sessionStorage, nor in cookies. Any idea where the site was getting th…
Referer [sic] is determined by your browser, not the site. If you just refreshed the tab then its probably looking at the history. Also, no browser that wants to make any claim of caring about privacy should still be sending cross-domain Referer headers by default which is yet another reason why Mozilla's privacy marketing is just that: marketing without substance.
sic is used to highlight that a spelling or grammar mistake in your writing is part of a direct quote being provided unaltered, and not your own mistake.
It isn't used to provide corrections.
Anyway, both spellings are fine in various regions.
Re: DNS Toys
#108"Prior art" for this is DNS block lists (DNSBLs). Typically these are used like this: your mail server gets an SMTP connection from some address (let's use the familiar IPv4 example): 10.20.30.40. You reverse these octets and do an "A" record dns query to some 40.30.10.10.dnsbl.example.com to look up that IP in example.com's list. If a match is returned, the address is listed. If you do a "TXT" record query, you can…
What is the difference between a block list and a black list? Is there a similar distinction between white list and allow list?
Re: DNS Toys
#109Earlier quoted context omitted.
Out of curiosity, I looked at the headers after clicking on your link and I found that it was sending Referrer as: https://news.ycombinator.com which is not an issue. But then I refreshed the page and saw the same Referrer again. So I checked where it was getting the Referrer from and it was not storing anything in localStorage, not in URL, nor in sessionStorage, nor in cookies. Any idea where the site was getting th…
Your browser remembers and replays it. localStorage/sessionStorage/cookies aren't available to parse by the time request headers are sent. You'll notice this behavior goes away if you select the URL bar and hit enter (as if you were navigating to the site manually).
Yeah you're right. Selecting the URL and hitting enter did clear the Referer. One comment says the browser identifies the Referer by looking at the history is that so?
Re: DNS Toys
#110Earlier quoted context omitted.
Out of curiosity, I looked at the headers after clicking on your link and I found that it was sending Referrer as: https://news.ycombinator.com which is not an issue. But then I refreshed the page and saw the same Referrer again. So I checked where it was getting the Referrer from and it was not storing anything in localStorage, not in URL, nor in sessionStorage, nor in cookies. Any idea where the site was getting th…
Referer [sic] is determined by your browser, not the site. If you just refreshed the tab then its probably looking at the history. Also, no browser that wants to make any claim of caring about privacy should still be sending cross-domain Referer headers by default which is yet another reason why Mozilla's privacy marketing is just that: marketing without substance.
Got it. So it gets the Referer from the browser history?