Missing from @drscriptt 's list are AAAA, HTTPS, and SVCB records.
AAAA has plenty of obvious choices.
You'll know the . convention for SRV, SVCB, and MX resource record sets, of course.
I shall just drop in my personal experience from earlier this year that an accidentally supplied HTTPS resource record can *definitely* break WWW traffic; because browsers in practice do not obey RFC9460 §2.4.2.
#djbdns
#DomainNameSystem
#SplitHorizon
#ReservedSuperDomains #DNS #HTTPS #SVCB
There are actually quite a few, nowadays. See RFCs 6762, 7686, and 8375.
example. is not the worst choice, although you could have gone with test. or internal. or intranet. .
Given your objective, any of the further ones that imply a residence or a corporation seem less well suited.
Although home.arpa.'s public delegation to the blackhole-{1,2}.iana.org. names is re-used.
https://github.com/jdebp/nosh/blob/trunk/source/examples/tinydns/split-horizon#L96
#djbdns #DomainNameSystem #SplitHorizon #ReservedSuperDomains #DNS
Kommentar zum #AWS-Fail: Hinter dem Sündenbock #DNS steht Hyperscaler-Inkompetenz | iX Magazin https://www.heise.de/meinung/Kommentar-zum-AWS-Ausfall-It-s-always-DNS-unless-it-isn-t-11077553.html #DomainNameSystem #Amazon #AmazonWebServices
Signal down: Messenger-App weltweit ausgefallen | heise online https://www.heise.de/news/Messenger-App-Signal-offenbar-weltweit-mit-Stoerungen-10778899.html #AWS #Amazon #AmazonWebServices #DNS #DomainNameSystem
Hier sieht man, wie viele Dienste #AWS nutzen ...
#AmazonWebServices: Globale Störung am Montagmorgen | heise online https://www.heise.de/news/Amazon-Web-Services-Globale-Stoerung-10778963.html #DNS #DomainNameSystem #Amazon
Thank you. But it actually tells me less than I already knew from cranking up developer tools and the server logs, and using direct observation. Which is, as I said, that the browsers continued to communicate with the origin domain's IP addresses, and did not switch to the target domain's.
#HTTPS alias-mode resource records that nominally upgrade from HTTP to HTTPS actually instead locked the browsers on a Windows machine out of my own WWW site for half a day.
Today's top tip:
Don't use HTTPS resource records.
I set some alias-mode ones up pointing from one domain to another domain. WWW browsers were supposed, per RFC9460 §2.4.2, to talk to the target domain.
All of my WWW browsers that picked up the records continued to send their requests to the IP address for *original* domain, and simply acted as if HSTS was turned on for that domain.
The example scenario in RFC9460 does not actually do what is stated in practice.
There are a much smaller number of people doing SVCB lookups, too. But, interestingly, they are doing them wrongly.
And with a direct correlation to some other abuses.
Which does make me think that, in an ironic twist, it is the bad actors running robot vulnerability probes and scrapers that are the early adopters of SVCB, here.
This does make you the second person in the world (if you picked up the source after I put it in yesterday) who can run
dnsqr https google.com
or even
dnsqr https jdebp.info
I didn't think that people were using this, it only having been accepted in November 2023, but I discovered a few lookups in my logs.
Today's #DomainNameSystem monstrosity:
The content DNS servers for vtb.com. respond with an 11KiB answer to an ANY query for vtb.com. This is the biggest amplification attack enabling domain in today's logs.
Coming in second are the content DNS servers for softcom.net., returning a 5KiB response to an ANY query.
I know that you have had a lot of suggestions, over the years and recently. software. is a fair enough choice, and is definitely on-point.
On balance, I am glad that you resisted the lure of putty.party. .
(-:
One could also ask why this red flag is not seen for the exchange. "glamour domain". Or for io. and nu. for that matter.
In reality, this lopsided mental model has its roots in ICANN digging its heels in during the 1990s. The fact that ICANN dug its heels in back then is reflective of the idea that many people do not share the idea that ccTLDs and gTLDs are somehow more credible than anything else, especially as we've watched many of the antics played with them over the decades, giving lie to that notion.
Hell, we only have uk. itself because the United Kingdom academic community domain-squatted in 1985. (-:
Have something to whet your appetites for #djbwares version 11.
If you don't know #djbdns, you probably won't notice what will make people who do know djbdns take interest. (-:
It's also going to contain the FreeBSD 13 build fixes that @ermo helped with.
Looking up www.bing.com. nowadays involves dnscache looking up intermediate domain names in org., com., net., and info.; the cross-dependencies of which regularly exceed dnscache's nested gluelessness limit above which it switches to a slower resolution algorithm.
Some quick tests indicate that raising this limit from 2 to 3 improves matters.
So this will be in #djbwares 11.
If I were @standupmaths , there would be some Terrible Python Code parsing the output of dnsqr and doing line fitting to the TTL values; and an entire video on how to estimate from such data how many real machines under the covers serve up some seemingly single service on the Internet, and a second channel one on how people did that from the Netcraft uptime graphs that it used to present a couple of decades ago.
And then a clever viewer switching from parsing text from a pipe to some proper Python DNS client library and achieving a 6283% speedup.
(-:
#DomainNameSystem #BendersTest #Python #TerriblePythonCode #StandUpMaths
[…Continued]
#Quad9, #GooglePublicDNS, and my ISP all appeared to respect their capped TTLs; having cache misses when the TTLs reached zero. Unsurprisingly.
I know, both from prior experience and having seen the code, that the on-machine cache respects its TTLs in like manner.
Anyone expecting this (quite conventional) behaviour would be greatly misled by CloudFlare, however.
Quad9 and Google Public DNS were better than #CloudFlare, in retention time or amount of re-population needed to fill every cache behind the anycast; but they with their more aggressive TTL capping got nowhere near as long an interval between cache misses that the on-machine cache has.
CloudFlare, however, in fact incurred cache misses multiple times per hour, at one point fetching anew on *all* of its caches after a mere 10 minute gap when the test was halted. The TTLs never even managed to count down to 41 days before there was a (sometimes global!) cache miss.
[…Continued]
The pattern is not ideal, because the anycasting is of course determined by moment-to-moment circumstances; but the multiple descending series of TTL values revealed that:
My ISP had at least 3 caches behind 2 apparent IP addresses.
#CloudFlare and #GooglePublicDNS had at least 8 caches behind 2 apparent IP addresses.
#Quad9 had at least 2 caches behind 2 apparent IP addresses, but it was not as simple as 1 cache per IP address. Sometimes they swapped, or gave identical results.
[Continued…] #DomainNameSystem #BendersTest
[…Continued]
Everyone properly counted down the TTLs.
Only the on-machine cache counted down monotonically as expected, however. The others had TTLs that counted down in the long term but jumped up and down in the short term.
There was a discernable pattern, thanks to the 10 second loop interval in my test. There were multiple series of descending TTLs, swapping in and out.
This pattern revealed that there are multiple caches behind anycast, even at my ISP; those caches not sharing data. They each get separately populated during the first few test loop iterations and re-populated.
[Continued…] #DomainNameSystem #CloudFlare #Quad9 #GooglePublicDNS #BendersTest
[…Continued]
The on-machine cache capped the 42 day TTL down to 1 week, as documented.
There was no pressure to evict the resource record set, even though the machine was not dedicated to just the test and other use was being made of the on-machine cache. There was no cache miss at all after the first one.
My ISP's proxy DNS servers also capped the TTL down to 1 week, interestingly.
Only #CloudFlare passed through the original 42 day TTL. The high TTLs might lead one to conclude that CloudFlare thus cached the longest and best. In reality it cached the shortest and worst, more on which in a moment.
#GooglePublicDNS and #Quad9 capped the 42 day TTL the most aggressively, the former reducing to a couple of days, the latter to a mere 12 hours. They turned out to do better than CloudFlare, however.
[Continued…] #DomainNameSystem #BendersTest
[…Continued]
The latency of the on-machine server, the total transaction time, was always in single milliseconds after the single very first cache miss query.
The actual latencies of all of the #Quad9, #GooglePublicDNS, and #CloudFlare public proxy DNS servers were in tens of milliseconds for cache hits.
My ISP's proxy DNS servers are 6 hops away, and also had an actual latency in the tens of milliseconds, but slightly shorter than those of the third-party ones. None of the third-party ones are in fact closer than 7 hops away.
The latency to the relevant content DNS server was in the hundreds of milliseconds, and the latencies of the third-party proxy DNS servers when they had cache misses were between this and twice this.
[Continued…] #DomainNameSystem #BendersTest
