home.social

#domainnamesystem — Public Fediverse posts

Live and recent posts from across the Fediverse tagged #domainnamesystem, aggregated by home.social.

fetched live
  1. @Habbie

    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.

    groups.google.com/g/comp.proto

    @ska
    #DomainNameSystem

  2. @Habbie

    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.

    groups.google.com/g/comp.proto

    @ska
    #DomainNameSystem

  3. @BastilleBSD

    So you're not interested in those who go the whole hog and run their own private root content DNS servers. (-:

    jdebp.info/Softwares/djbwares/

    #DomainNameSystem #djbwares

  4. @BastilleBSD

    So you're not interested in those who go the whole hog and run their own private root content DNS servers. (-:

    jdebp.info/Softwares/djbwares/

    #DomainNameSystem #djbwares

  5. @ska

    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.

    news.ycombinator.com/item?id=4

    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.

    #DomainNameSystem

  6. @ska

    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.

    news.ycombinator.com/item?id=4

    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.

    #DomainNameSystem

  7. @ska

    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.

    #DomainNameSystem

  8. @ska

    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.

    #DomainNameSystem

  9. @ska

    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.

    #DomainNameSystem

  10. @ska

    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.

    #DomainNameSystem

  11. @cks @lanodan

    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

  12. @cks @lanodan

    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

  13. @cks @lanodan @drscriptt

    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.

    github.com/jdebp/nosh/blob/tru

    #djbdns #DomainNameSystem #SplitHorizon #ReservedSuperDomains #DNS

  14. @cks @lanodan @drscriptt

    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.

    github.com/jdebp/nosh/blob/tru

    #djbdns #DomainNameSystem #SplitHorizon #ReservedSuperDomains #DNS

  15. @pmevzek

    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.

    #DomainNameSystem

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

    #HTTPS #DomainNameSystem

  17. @ermo

    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.

    #djbwares #DomainNameSystem #svcb

  18. @ermo

    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.

    #djbwares #DomainNameSystem #https

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

    #DomainNameSystem
    #DomainNameSystem

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

    #DomainNameSystem
    #DomainNameSystem

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

    #djbdns #dnscache #DomainNameSystem

  22. Hacked ISP infects users receiving unsecure software updates - Enlarge (credit: Marco Verch Professional Photographer and Speaker)

    ... - arstechnica.com/?p=2041175 #domainnamesystem #dnspoisoning #infections #security #malware #biz&it

  23. DNS glitch that threatened Internet stability fixed; cause remains unclear - Enlarge

    For more than four days, a server at the very core of... - arstechnica.com/?p=2026566 #domainnamesystem #rootservers #security #biz#dnssec #dns

  24. Microsoft plans to lock down Windows DNS like never before. Here’s how. - Enlarge (credit: Getty Images)

    Translating human-readable doma... - arstechnica.com/?p=2021987 #domainnamesystem #microsoft #security #windows #biz#ztdns