#domainnamesystem — Public Fediverse posts
Live and recent posts from across the Fediverse tagged #domainnamesystem, aggregated by home.social.
-
Because I'm a DNS implementor too.
The main people to have adopted that are the people who were already doing things its way.
Microsoft didn't back then, & still does not now. #djbdns, likewise. MaraDNS, likewise.
Of the 3, MaraDNS is the one that specifically calls out that there is a difference in its doco, although the other 2 document the different ways that they do wildcards.
I was pointing this out when it was still a draft.
https://groups.google.com/g/comp.protocols.dns.bind/c/yfgFVyU95rA/m/Fy69mSzL1j0J
-
Because I'm a DNS implementor too.
The main people to have adopted that are the people who were already doing things its way.
Microsoft didn't back then, & still does not now. #djbdns, likewise. MaraDNS, likewise.
Of the 3, MaraDNS is the one that specifically calls out that there is a difference in its doco, although the other 2 document the different ways that they do wildcards.
I was pointing this out when it was still a draft.
https://groups.google.com/g/comp.protocols.dns.bind/c/yfgFVyU95rA/m/Fy69mSzL1j0J
-
So you're not interested in those who go the whole hog and run their own private root content DNS servers. (-:
http://jdebp.info/Softwares/djbwares/guide/dns-private-root.html
-
So you're not interested in those who go the whole hog and run their own private root content DNS servers. (-:
http://jdebp.info/Softwares/djbwares/guide/dns-private-root.html
-
Don't fall into the trap of treating RFC4592 as a spec.
It's still a proposed standard, and there's a *lot* of stuff in the DNS RFC world that seems like a spec, until one hits the real world and finds that it's a decade-or-more wild goose chase that the RFCs don't tell you has failed to take off.
https://news.ycombinator.com/item?id=44320497
The reality is that RFC4592 didn't take off, either. *No-one* has adopted it that wasn't the implementation that it sought to ossify.
-
Don't fall into the trap of treating RFC4592 as a spec.
It's still a proposed standard, and there's a *lot* of stuff in the DNS RFC world that seems like a spec, until one hits the real world and finds that it's a decade-or-more wild goose chase that the RFCs don't tell you has failed to take off.
https://news.ycombinator.com/item?id=44320497
The reality is that RFC4592 didn't take off, either. *No-one* has adopted it that wasn't the implementation that it sought to ossify.
-
No, I'm not mixing things. I was there. I was there when the wildcard draft was made, trying to point out various problems in it, 2 years before publication. I was also there doing the user support, and I can tell you from a lot of actual experience with end users and this stuff that you are quite wrong.
Wildcards were one of the things that users asked about, over and over. BIND wasn't intuitive. Indeed people are still saying so on StackExchage 20 years later.
-
No, I'm not mixing things. I was there. I was there when the wildcard draft was made, trying to point out various problems in it, 2 years before publication. I was also there doing the user support, and I can tell you from a lot of actual experience with end users and this stuff that you are quite wrong.
Wildcards were one of the things that users asked about, over and over. BIND wasn't intuitive. Indeed people are still saying so on StackExchage 20 years later.
-
I hope not, if working like #djbdns is the goal.
RFC4592 has a tree-structure model of domain name existence that prevents wildcards from working in some cases in a way that the djbdns table-structure model does not prevent.
Using the RFC4592 example:
When one does an MX lookup for _telnet._tcp.example. or ghost.*.example. it returns a non-empty record set because of the @ wildcard at *.example. .
In the RFC4592 model, the *.example. wildcard does not get applied.
-
I hope not, if working like #djbdns is the goal.
RFC4592 has a tree-structure model of domain name existence that prevents wildcards from working in some cases in a way that the djbdns table-structure model does not prevent.
Using the RFC4592 example:
When one does an MX lookup for _telnet._tcp.example. or ghost.*.example. it returns a non-empty record set because of the @ wildcard at *.example. .
In the RFC4592 model, the *.example. wildcard does not get applied.
-
#DNS-Probleme: .de-Domains nicht erreichbar | heise online https://www.heise.de/news/DNS-Probleme-de-Domains-nicht-erreichbar-11283192.html #denic #DomainNameSystem
-
#DNS-Probleme: .de-Domains nicht erreichbar | heise online https://www.heise.de/news/DNS-Probleme-de-Domains-nicht-erreichbar-11283192.html #denic #DomainNameSystem
-
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 -
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
-
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
-
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
-
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
-
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.
-
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.
-
Hackers exploit a blind spot by hiding malware inside DNS records - Hackers are stashing malware in a place that’s largely out o... - https://arstechnica.com/security/2025/07/hackers-exploit-a-blind-spot-by-hiding-malware-inside-dns-records/ #domainnamesystem #security #malware #biz #dns
-
Hackers exploit a blind spot by hiding malware inside DNS records - Hackers are stashing malware in a place that’s largely out o... - https://arstechnica.com/security/2025/07/hackers-exploit-a-blind-spot-by-hiding-malware-inside-dns-records/ #domainnamesystem #security #malware #biz #dns
-
Hacked ISP infects users receiving unsecure software updates - Enlarge (credit: Marco Verch Professional Photographer and Speaker)
... - https://arstechnica.com/?p=2041175 #domainnamesystem #dnspoisoning #infections #security #malware #biz&it
-
DNS glitch that threatened Internet stability fixed; cause remains unclear - Enlarge
For more than four days, a server at the very core of... - https://arstechnica.com/?p=2026566 #domainnamesystem #rootservers #security #biz #dnssec #dns
-
Microsoft plans to lock down Windows DNS like never before. Here’s how. - Enlarge (credit: Getty Images)
Translating human-readable doma... - https://arstechnica.com/?p=2021987 #domainnamesystem #microsoft #security #windows #biz #ztdns