#DomainNameSystem

2025-07-17

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

2025-07-17

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

#DomainNameSystem #BendersTest

2025-07-17

[…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

2025-07-17

[…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

2025-07-17

[…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

2025-07-17

[…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

2025-07-17

If you thought that using a third-party public resolving proxy DNS server gained you economies of scale because you shared a cache with other people, think again.

I ran Bender's Test (news.ycombinator.com/item?id=4) in a loop, once every 10 seconds, intermittently over a couple of days.

I added an on-machine resolving proxy DNS server on 127.0.0.1, my ISP's proxy DNS servers, and #Quad9's, #GooglePublicDNS's, and #CloudFlare's 2nd IP addresses to Bender's set.

Results reveal that if one conflates latency with cache misses, or claims that there must be better cache hits compared to using one's own proxy DNS server on-machine (or even on-LAN), one hasn't a clue as to the quite different reality of these third-party public DNS servers.

In detail:

[Continued…] #DomainNameSystem #BendersTest

Ars Technica Newsarstechnica@c.im
2025-07-16

Hackers exploit a blind spot by hiding malware inside DNS records arstechni.ca/hs9B #domainnamesystem #Security #malware #Biz&IT #DNS

2025-07-15

An Indian company hi-jacked the route to #CloudFlare's 1.1.1.0/24 network today for about half an hour.

There was a flurry of multiple submissions to #HackerNews about "1.1.1.1 is down".

Reading the discussions, I did not see anyone having my reaction, which was "It is? I hadn't noticed.".

People for whom this was a total non-event, for whatever reason, of course tend to self-select out of such discussions.

radar.cloudflare.com/routing/a

#DNS #BGP #Tata #DomainNameSystem

2025-04-22

@robpumphrey

I should probably mention this flaw on the #nslookup flaws page. The BIND DNS client library doesn't continue on to the next server if it receives a response without the "RA" flag; but nslookup does.

A flaw going back to at least 2009, from a quick look at the people asking questions about it, but introduced since I last touched that page in 2004; as I believe I included all of the known major gotchas of the time. (-:

jdebp.uk/FGA/nslookup-flaws.ht

#DomainNameSystem

2025-04-22

@robpumphrey

If it's (intentionally) not providing proxy DNS service (which is what "recursion not available" translates to), then you had best just take it out of resolv.conf completely. That's not the sort of DNS server that belongs in resolv.conf.

The resource record set type is actually immaterial here. The C library expects complete answers from things in /etc/resolv.conf, not partial answers, which is what it will be getting from that DNS server.

#DomainNameSystem

2025-02-03

@johncarlosbaez

There are all sorts of things that non-academic but technical people can prepare for, like ensuring that github.com/cisagov/dotgov-data is cloned outwith the U.S.A. and not on a WWW site run by a U.S.A. multinational, in case someone has the really dumb idea of abusing the #DomainNameSystem to censor stuff.

(Of course they will, doubters. People use the DNS as a blocking tool all of the time. Inexpert political appointees will think the same.)

2025-02-01

@ianb @klausfiend

Technical information at mastodonapp.uk/@JdeBP/11392736

Also notice that The Grauniad did not add the www. subdomain.

#USPolitics #FAA #DomainNameSystem

2025-02-01

Here's some technical information that is pertinent to current events.

The DNS data for the gov. zone can currently be found in a git repository at github.com/cisagov/dotgov-data , which one can clone with the usual tools.

Almost none of its on-GitHub forks are up to date.

The faa.gov. subdomain is not part of gov. but is delegated to Akamai, with the primary copy of the data apparently held by Akamai.

Akamai performed an update to Edge DNS on 2025-01-23, but akamaistatus.com reports no Edge DNS incidents since then.

Neither faa-mc-egm1.faa.gov. nor faa-ct-egm1.faa.gov. are currently responding to DNS requests from me.

dotideahub.gov. is delegated only to those 2.

faa.gov. is not delegated to those 2 by the gov. data, but Akamai's servers publish them in the NS record set which will then be cached.

www.faa.gov. is a client-side alias for www.faa.gov.edgekey.net. .

Of course faa.gov. cannot both have a CNAME and be a delegation point at the same time.

#DomainNameSystem #FAA

halil denizhalildeniz
2024-12-25

Hello everyone.

In today's article, we will examine in detail what is dns and how it works.

I wish everyone a good reading:
denizhalil.com/2023/07/04/what

Alameen KarimMerali :verified:brotheralameen@ioc.exchange
2024-09-27

This is the magazine article I had written for the PECB and as you can see, it’s ready to be published into the magazine. This is gonna be good. Images are in low resolution because they still need to purchase it before publication.

#Magazine #PECB #Certification #CertificationBody #InfoSec #InformationSecurity #InfoSecExpert #InformationSecurityExpert #ISP #InternetServiceProvider #Safcomms #SafcommsLimited #DNS #DomainNameSystem #MagazineArticle #Writer #InfoSecMag #CyberSecMag #InformationSecurityMagazine #CyberSecurityMagazine #Mag

Alameen KarimMerali :verified:brotheralameen@ioc.exchange
2024-09-19

We, at Safcomms Limited, are now fully registered to do work with the United States Federal Government.

Our Entity Identification Information on the Federal System is as follows:

CAGE Code: U28H3
SAM ID: RPSNFL4DZ7N3

We are now ready to receive contract opportunities as necessary by the US Federal Government and propose to contracts as contractors for the Federal Government.

The FBI seems unresponsive to wanting to work with us on Federal Contracts. Nonetheless, I’m sure the NSA and other branches of the Federal Government would be willing and open to work with us. Nonetheless, we are yet working on future plans to work with them with a decision that may take weeks to months before a final decision is made for the company to work with the NSA and other higher hierarchies of the Federal Government of the United States as there’s still systems to setup for the company and other complications which the FBI is made aware of and cannot be stated as it’s confidential and significant to National and International Security.

#Government #Contracting #GovernmentContractor #Subcontractor #Federal #FederalContractor #Civilian #CivilianContractor #FederalGovernment #UnitedStates #USA #UnitedStatesofAmerica #NSA #FBI #Contract #Fed #National #International #Security #SAMGov #SAM #SystemforAwardsManagement #NationalSecurity #InternationalSecurity #NatSec #IntSec #IntlSec #ISP #InternetServiceProvider #DNS #DomainNameSystem #Quantum #QuantumSystem #QuantumComputing #QuantumComputer #echarging #electroniccharging #wirelesscharging

Alameen KarimMerali :verified:brotheralameen@ioc.exchange
2024-09-18

Safcomms Limited DNS now comes with secure masking. We help mask your IP Address by providing you with ours to hide yourself without using a VPN. To purchase our DNS Service, contact me right away. Evidence as shown in the picture from the WiFi Analyzer Software.

#DNS #DomainName #DomainNameSystem #InternetService #Internet #InternetServiceProvider #Networking #ComputerNetworking #ComputerNetwork #Network #Cybersecurity #CyberSec #InformationSecurity #InfoSec #Masking #HidingYourIP #HideYourIP #NoVPN #NoIP #IPSec

2024-08-27

@underseamonkey

In my experience, not understanding how the DNS works (as opposed to merely what the DNS does) is quite common.

#DomainNameSystem

2024-03-29

what currently existing #decentralized #domainnamesystem alternatives are there? I'm willing to sacrifice the Human-meaningful property on Zooko's triangle and I don't want a cryptocurrency based system

Client Info

Server: https://mastodon.social
Version: 2025.07
Repository: https://github.com/cyevgeniy/lmst