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
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
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.