Re: Sparklight and DNSSEC
Philip Prindeville writes: > How many ISP's squelch DNSSEC like that? I hope it's not a common practice! More common than you'd like to think. See Geoff's excellent world map at https://stats.labs.apnic.net/dnssec Note that no validation implies no signatures for downstream resolvers. Which makes the non-validating resolvers useless in a forwarder statements, like you discovered. And useless in many other situations as well. You can't do DANE for example. FWIW, we (as in Telenor Norway) enabled validation in 2015, along with most of the other major Norwegian ISPs, after being educated with a sufficiently powerful LART by the local domain registry (NORID). They invited all the local resolver operators for a workshop in May 2015, focusing on the importance of validation. This is the primary reason Norway is green on that map.. I must admit I was a bit worried in the beginning. But we've had surprisingly few problems. And no major issues AFAIR. There's really no reason to avoid dnssec-validation in 2022. Just go poke your ISP if they've disabled it. Bjørn -- Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
TTL is varying across nameservers
There is something strange going on with the TTL of my domain across nameservers on the internet. This is how its configured on ns1.stokkie.net and ns2.stokkie.net : $ dig +norecurse +ttlid stokkie.net @84.87.53.162 ; <<>> DiG 9.8.1 <<>> +norecurse +ttlid stokkie.net @84.87.53.162 ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 54209 ;; flags: qr aa; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 2 ;; QUESTION SECTION: ;stokkie.net. IN A ;; ANSWER SECTION: stokkie.net.86400 IN A 84.87.53.162 ;; AUTHORITY SECTION: stokkie.net.86400 IN NS ns2.stokkie.net. stokkie.net.86400 IN NS ns1.stokkie.net. ;; ADDITIONAL SECTION: ns1.stokkie.net.86400 IN A 84.87.53.162 ns2.stokkie.net.86400 IN A 92.67.169.193 ;; Query time: 2 msec ;; SERVER: 84.87.53.162#53(84.87.53.162) ;; WHEN: Sun Sep 25 07:40:40 2022 ;; MSG SIZE rcvd: 113 $ $ dig +norecurse +ttlid stokkie.net @92.67.169.193 ; <<>> DiG 9.8.1 <<>> +norecurse +ttlid stokkie.net @92.67.169.193 ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 15700 ;; flags: qr aa; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 2 ;; QUESTION SECTION: ;stokkie.net. IN A ;; ANSWER SECTION: stokkie.net.86400 IN A 84.87.53.162 ;; AUTHORITY SECTION: stokkie.net.86400 IN NS ns1.stokkie.net. stokkie.net.86400 IN NS ns2.stokkie.net. ;; ADDITIONAL SECTION: ns1.stokkie.net.86400 IN A 84.87.53.162 ns2.stokkie.net.86400 IN A 92.67.169.193 ;; Query time: 13 msec ;; SERVER: 92.67.169.193#53(92.67.169.193) ;; WHEN: Sun Sep 25 07:41:33 2022 ;; MSG SIZE rcvd: 113 $ Here the nameserver of my ADSL ISP, resolver1.kpn.net : $ dig +ttlid stokkie.net @194.151.228.18 ; <<>> DiG 9.8.1 <<>> +ttlid stokkie.net @194.151.228.18 ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 47231 ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0 ;; QUESTION SECTION: ;stokkie.net. IN A ;; ANSWER SECTION: stokkie.net.79291 IN A 84.87.53.162 ;; Query time: 8 msec ;; SERVER: 194.151.228.18#53(194.151.228.18) ;; WHEN: Sun Sep 25 07:43:40 2022 ;; MSG SIZE rcvd: 45 $ Here the nameserver of my ADSL ISP, resolver2.kpn.net : $ dig +ttlid stokkie.net @194.151.228.34 ; <<>> DiG 9.8.1 <<>> +ttlid stokkie.net @194.151.228.34 ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 55404 ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0 ;; QUESTION SECTION: ;stokkie.net. IN A ;; ANSWER SECTION: stokkie.net.86400 IN A 84.87.53.162 ;; Query time: 28 msec ;; SERVER: 194.151.228.34#53(194.151.228.34) ;; WHEN: Sun Sep 25 07:44:22 2022 ;; MSG SIZE rcvd: 45 $ Here the public DNS server of Google : $ dig +ttlid stokkie.net @8.8.8.8 ; <<>> DiG 9.8.1 <<>> +ttlid stokkie.net @8.8.8.8 ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 29668 ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0 ;; QUESTION SECTION: ;stokkie.net. IN A ;; ANSWER SECTION: stokkie.net.21599 IN A 84.87.53.162 ;; Query time: 2033 msec ;; SERVER: 8.8.8.8#53(8.8.8.8) ;; WHEN: Sun Sep 25 07:46:03 2022 ;; MSG SIZE rcvd: 45 $ Here's the second time Google : $ dig +ttlid stokkie.net @8.8.8.8 ; <<>> DiG 9.8.1 <<>> +ttlid stokkie.net @8.8.8.8 ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 3080 ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0 ;; QUESTION SECTION: ;stokkie.net. IN A ;; ANSWER SECTION: stokkie.net.21600 IN A 84.87.53.162 ;; Query time: 23 msec ;; SERVER: 8.8.8.8#53(8.8.8.8) ;; WHEN: Sun Sep 25 07:46:18 2022 ;; MSG SIZE rcvd: 45 $ Is this proper behavior ? -- Robert M. Stockmann - RHCE Network Engineer - UNIX/Linux Specialist crashrecovery.org st...@stokkie.net -- Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: TTL is varying across nameservers
Hi Robert, On Sun, 25 Sep 2022, Robert M. Stockmann wrote: There is something strange going on with the TTL of my domain across nameservers on the internet. This is how its configured on ns1.stokkie.net and ns2.stokkie.net : $ dig +norecurse +ttlid stokkie.net @84.87.53.162 ; <<>> DiG 9.8.1 <<>> +norecurse +ttlid stokkie.net @84.87.53.162 ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 54209 ;; flags: qr aa; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 2 ;; QUESTION SECTION: ;stokkie.net. IN A ;; ANSWER SECTION: stokkie.net.86400 IN A 84.87.53.162 <- snip -> Here the nameserver of my ADSL ISP, resolver1.kpn.net : $ dig +ttlid stokkie.net @194.151.228.18 ; <<>> DiG 9.8.1 <<>> +ttlid stokkie.net @194.151.228.18 ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 47231 ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0 ;; QUESTION SECTION: ;stokkie.net. IN A ;; ANSWER SECTION: stokkie.net.79291 IN A 84.87.53.162 <- snip -> Here the public DNS server of Google : $ dig +ttlid stokkie.net @8.8.8.8 ; <<>> DiG 9.8.1 <<>> +ttlid stokkie.net @8.8.8.8 ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 29668 ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0 ;; QUESTION SECTION: ;stokkie.net. IN A ;; ANSWER SECTION: stokkie.net.21599 IN A 84.87.53.162 <- snip -> Here's the second time Google : $ dig +ttlid stokkie.net @8.8.8.8 ; <<>> DiG 9.8.1 <<>> +ttlid stokkie.net @8.8.8.8 ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 3080 ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0 ;; QUESTION SECTION: ;stokkie.net. IN A ;; ANSWER SECTION: stokkie.net.21600 IN A 84.87.53.162 <- snip -> Is this proper behavior ? Yes, it is. The queried dns servers are caching servers and answer from the cache. The first time, they get the result from the authoritative server with a TTL of 86400. When they serve the answer from the cache, they will reduce the TTL by the amount of seconds since they got it from the authoritative server - i.e. the TTL would be 0 after one day and the caching server (or any server downstream) *must* get a new record from the authoritative server. Though, I find it interesting, that the TTL of the google dns server *increases* between the queries - are you sure, the order is right? regards, Erich -- Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
