As the post calls out, most certificate authorities will not issue certs against .arpa domains. I found this out the hard way when paying for CloudFlare's Advanced Certificates add-on for an .arpa domain I had successfully delegated and registered.
They return failures and exceptions when attempting to generate the certificate for the .arpa domain and then I spent months trying to get a refund (they are very slow to respond) and only caved once I threatened a chargeback for the service not working as advertised.
Many people, including myself, tend to look at .arpa and think "oh yes, thats PTR queries" but forget the DNS doesn't have a global rule that ONLY the PTR query can be sent to the domain.
It's just a domain. You can put anything into your zone. A, AAAA, PTR, TXT, you can even put HESIOD records if you want to party like its Kerberos nineteen ninety IV.
If you don't use it at all, they do take the prefixes away. I lost a prefix when I did a house move and a server move and took a couple years to get around to setting up the tunnel... They didn't undelegate the DNS until I poked them to either please let me have the prefix back or fix DNS.
I have native ipv6 at home and on my hosting, so that's nice. Unfortunately the he.net tunnels are used for a lot of abuse now and you treated like a bot if you use them to go to popular websites. :(
> feel free to provide fake information as it doesn’t verify any of it
Uhh... Please don't. This is how nice things get taken down due to abuse.
> This is handy because many (though not all) certificate authorities refuse to serve .arpa domains
IIRC, .arpa domains are based on locations in the address space. CAs are supposed to secure your connection to a specific entity, not only a specific location, so that's probably why.
You might not even need to go through HE. Many ISPs allow you to set your own PTR records / rDNS delegations if you ask them, since this is also necessary to host email servers.
There's certainly a process that is between form being submitted and all 5 of ns[1-5].he.net returning the new data. From experience with other DNS changes at he.net, successful response is returned over HTTP before the changes are visible via the name servers.
I don't see what's wrong with calling that process propagating a change. And since it's propagating the change to become available in DNS, propagating DNS fits. :P
That process doesn't really involve any caching resolvers between you and the authoritative, but since you had to wait for the changes to propagate to the authoritative servers and you're just doing more waiting until the caching resolvers re-query, I understand why people include waiting for caching revolvers when they say DNS propagation.
Anyway, I'm open to a good definition of "propagate" that specifically requires push or an active process rather than pull/polling; I don't really see a basis for that looking at merriam-webster[1]:
> 3a: to cause to spread out and affect a greater number or greater area : extend
> b : to foster growing knowledge of, familiarity with, or acceptance of (something, such as an idea or belief)
By changing the results on the authoritative and as caching recursive resolvers requery, the new results spread out and affect a greater number. By answering queries with the new data, as caching recursives requery, the servers foster growing knowledge of the new results. And certainly those definitions fit toward updating the authoritative servers.
As the post calls out, most certificate authorities will not issue certs against .arpa domains. I found this out the hard way when paying for CloudFlare's Advanced Certificates add-on for an .arpa domain I had successfully delegated and registered.
They return failures and exceptions when attempting to generate the certificate for the .arpa domain and then I spent months trying to get a refund (they are very slow to respond) and only caved once I threatened a chargeback for the service not working as advertised.
Many people, including myself, tend to look at .arpa and think "oh yes, thats PTR queries" but forget the DNS doesn't have a global rule that ONLY the PTR query can be sent to the domain.
It's just a domain. You can put anything into your zone. A, AAAA, PTR, TXT, you can even put HESIOD records if you want to party like its Kerberos nineteen ninety IV.
You can get a TLS certificate on .arpa.
https://crt.sh/?q=%25.arpa&exclude=expired&group=none
There are websites as well
https://5.8.7.1.7.1.3.2.6.1.9.4.e164.arpa/
Do these free HE assigned IPv6 prefix(es) just remain valid indefinitely even when not actually being used/routed?
If you don't use it at all, they do take the prefixes away. I lost a prefix when I did a house move and a server move and took a couple years to get around to setting up the tunnel... They didn't undelegate the DNS until I poked them to either please let me have the prefix back or fix DNS.
I have native ipv6 at home and on my hosting, so that's nice. Unfortunately the he.net tunnels are used for a lot of abuse now and you treated like a bot if you use them to go to popular websites. :(
That would be my assumption, although I wouldn't bet on it being as stable as a traditional domain registration
> feel free to provide fake information as it doesn’t verify any of it
Uhh... Please don't. This is how nice things get taken down due to abuse.
> This is handy because many (though not all) certificate authorities refuse to serve .arpa domains
IIRC, .arpa domains are based on locations in the address space. CAs are supposed to secure your connection to a specific entity, not only a specific location, so that's probably why.
You might not even need to go through HE. Many ISPs allow you to set your own PTR records / rDNS delegations if you ask them, since this is also necessary to host email servers.
> Once DNS finishes propagating
Say what?
A lie. DNS doesn't propagate.
There's certainly a process that is between form being submitted and all 5 of ns[1-5].he.net returning the new data. From experience with other DNS changes at he.net, successful response is returned over HTTP before the changes are visible via the name servers.
I don't see what's wrong with calling that process propagating a change. And since it's propagating the change to become available in DNS, propagating DNS fits. :P
That process doesn't really involve any caching resolvers between you and the authoritative, but since you had to wait for the changes to propagate to the authoritative servers and you're just doing more waiting until the caching resolvers re-query, I understand why people include waiting for caching revolvers when they say DNS propagation.
Anyway, I'm open to a good definition of "propagate" that specifically requires push or an active process rather than pull/polling; I don't really see a basis for that looking at merriam-webster[1]:
> 3a: to cause to spread out and affect a greater number or greater area : extend
> b : to foster growing knowledge of, familiarity with, or acceptance of (something, such as an idea or belief)
By changing the results on the authoritative and as caching recursive resolvers requery, the new results spread out and affect a greater number. By answering queries with the new data, as caching recursives requery, the servers foster growing knowledge of the new results. And certainly those definitions fit toward updating the authoritative servers.
[1] https://www.merriam-webster.com/dictionary/propagate
whoops good catch, I had thought it was a synonym for the record ttl's expiring
I'll go fix it now
But why
Perhaps you want a website for your Monterey cypress and want the domain macroc.arpa?