Curious difference in glue TTL for root servers
There's a difference in the TTL of glue records returned in a priming query from different root servers. There's nothing wrong with a nameserver lowering the TTL in a response [RFC2181], but it's an observable difference in behavior. Perhaps some DNS implementation is clamping the glue to TTLs of the NS records. Both TTLs are observed on multiple root server letters respectively. [muks@jurassic ~]$ dig +nord +short @l.root-servers.net root-servers.net soa a.root-servers.net. nstld.verisign-grs.com. 2020060800 14400 7200 1209600 3600000 [muks@jurassic ~]$ dig +nord @l.root-servers.net . ns ; <<>> DiG 1.1.1.20200608151533.e8a2352e96 <<>> +nord @l.root-servers.net . ns ; (1 server found) ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 26630 ;; flags: qr aa; QUERY: 1, ANSWER: 13, AUTHORITY: 0, ADDITIONAL: 27 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4096 ;; QUESTION SECTION: ;. IN NS ;; ANSWER SECTION: . 518400 IN NS a.root-servers.net. . 518400 IN NS b.root-servers.net. . 518400 IN NS c.root-servers.net. . 518400 IN NS d.root-servers.net. . 518400 IN NS e.root-servers.net. . 518400 IN NS f.root-servers.net. . 518400 IN NS g.root-servers.net. . 518400 IN NS h.root-servers.net. . 518400 IN NS i.root-servers.net. . 518400 IN NS j.root-servers.net. . 518400 IN NS k.root-servers.net. . 518400 IN NS l.root-servers.net. . 518400 IN NS m.root-servers.net. ;; ADDITIONAL SECTION: a.root-servers.net. 518400 IN A 198.41.0.4 b.root-servers.net. 518400 IN A 199.9.14.201 c.root-servers.net. 518400 IN A 192.33.4.12 d.root-servers.net. 518400 IN A 199.7.91.13 e.root-servers.net. 518400 IN A 192.203.230.10 f.root-servers.net. 518400 IN A 192.5.5.241 g.root-servers.net. 518400 IN A 192.112.36.4 h.root-servers.net. 518400 IN A 198.97.190.53 i.root-servers.net. 518400 IN A 192.36.148.17 j.root-servers.net. 518400 IN A 192.58.128.30 k.root-servers.net. 518400 IN A 193.0.14.129 l.root-servers.net. 518400 IN A 199.7.83.42 m.root-servers.net. 518400 IN A 202.12.27.33 a.root-servers.net. 518400 IN AAAA 2001:503:ba3e::2:30 b.root-servers.net. 518400 IN AAAA 2001:500:200::b c.root-servers.net. 518400 IN AAAA 2001:500:2::c d.root-servers.net. 518400 IN AAAA 2001:500:2d::d e.root-servers.net. 518400 IN AAAA 2001:500:a8::e f.root-servers.net. 518400 IN AAAA 2001:500:2f::f g.root-servers.net. 518400 IN AAAA 2001:500:12::d0d h.root-servers.net. 518400 IN AAAA 2001:500:1::53 i.root-servers.net. 518400 IN AAAA 2001:7fe::53 j.root-servers.net. 518400 IN AAAA 2001:503:c27::2:30 k.root-servers.net. 518400 IN AAAA 2001:7fd::1 l.root-servers.net. 518400 IN AAAA 2001:500:9f::42 m.root-servers.net. 518400 IN AAAA 2001:dc3::35 ;; Query time: 33 msec ;; SERVER: 199.7.83.42#53(199.7.83.42) ;; WHEN: Fri Jun 19 03:52:09 IST 2020 ;; MSG SIZE rcvd: 811 [muks@jurassic ~]$ dig +nord +short @m.root-servers.net root-servers.net soa a.root-servers.net. nstld.verisign-grs.com. 2020060800 14400 7200 1209600 3600000 [muks@jurassic ~]$ dig +nord @m.root-servers.net . ns ; <<>> DiG 1.1.1.20200608151533.e8a2352e96 <<>> +nord @m.root-servers.net . ns ; (1 server found) ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 45391 ;; flags: qr aa; QUERY: 1, ANSWER: 13, AUTHORITY: 0, ADDITIONAL: 27 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4096 ;; QUESTION SECTION: ;. IN NS ;; ANSWER SECTION: . 518400 IN NS d.root-servers.net. . 518400 IN NS g.root-servers.net. . 518400 IN NS i.root-servers.net. . 518400 IN NS l.root-servers.net. . 518400 IN NS j.root-servers.net. . 518400 IN NS f.root-servers.net. . 518400 IN NS c.root-servers.net. . 518400 IN NS b.root-servers.net. . 518400 IN NS m.root-servers.net. . 518400 IN NS a.root-servers.net. . 518400 IN NS e.root-servers.net. . 518400 IN NS k.root-servers.net. . 518400 IN NS h.root-servers.net. ;; ADDITIONAL SECTION: a.root-servers.net. 3600000 IN A 198.41.0.4 b.root-servers.net. 3600000 IN A 199.9.14.201 c.root-servers.net. 3600000 IN A 192.33.4.12 d.root-servers.net. 3600000 IN A 199.7.91.13 e.root-servers.net. 3600000 IN A 192.203.230.10 f.root-servers.net. 3600000 IN A 192.5.5.241 g.root-servers.net. 3600000 IN A 192.112.36.4 h.root-servers.net. 3600000 IN A 198.97.190.53 i.root-servers.net. 3600000 IN A 192.36.148.17 j.root-servers.net. 3600000 IN A 192.58.128.30 k.root-servers.net. 3600000 IN A 193.0.14.129 l.root-servers.net. 3600000 IN A 199.7.83.42 m.root-servers.net. 3600000 IN A 202.12.27.33 a.root-servers.net. 3600000 IN AAAA 2001:503:ba3e::2:30 b.root-servers.net. 3600000 IN AAAA 2001:500:200::b c.root-servers.net. 3600000 IN AAAA 2001:500:2::c d.root-servers.net. 3600000 IN AAAA 2001:500:2d::d e.root-servers.net. 3600000 IN AAAA 2001:500:a8::e f.root-servers.net. 3600000 IN AAAA 2001:500:2f::f g.root-servers.net. 3600000 IN AAAA 2001:500:12::d0d h.root-servers.net. 3600000 IN AAAA 2001:500:1::53 i.root-servers.net. 3600000 IN AAAA 2001:7fe::53 j.root-servers.net. 3600000 IN AAAA 2001:503:c27::2:30 k.root-servers.net. 3600000 IN AAAA 2001:7fd::1 l.root-servers.net. 3600000 IN AAAA 2001:500:9f::42 m.root-servers.net. 3600000 IN AAAA 2001:dc3::35 ;; Query time: 104 msec ;; SERVER: 202.12.27.33#53(202.12.27.33) ;; WHEN: Fri Jun 19 03:51:46 IST 2020 ;; MSG SIZE rcvd: 811 [muks@jurassic ~]$ Mukund
My guess is that some implementations take the glue from the root zone and some take it from the root-servers.net zone (which has the 3600000 TTL). DW
On Jun 18, 2020, at 3:26 PM, Mukund Sivaraman <muks@mukund.org> wrote:
There's a difference in the TTL of glue records returned in a priming query from different root servers. There's nothing wrong with a nameserver lowering the TTL in a response [RFC2181], but it's an observable difference in behavior. Perhaps some DNS implementation is clamping the glue to TTLs of the NS records. Both TTLs are observed on multiple root server letters respectively.
[muks@jurassic ~]$ dig +nord +short @l.root-servers.net root-servers.net soa a.root-servers.net. nstld.verisign-grs.com. 2020060800 14400 7200 1209600 3600000 [muks@jurassic ~]$ dig +nord @l.root-servers.net . ns
; <<>> DiG 1.1.1.20200608151533.e8a2352e96 <<>> +nord @l.root-servers.net . ns ; (1 server found) ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 26630 ;; flags: qr aa; QUERY: 1, ANSWER: 13, AUTHORITY: 0, ADDITIONAL: 27
;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4096 ;; QUESTION SECTION: ;. IN NS
;; ANSWER SECTION: . 518400 IN NS a.root-servers.net. . 518400 IN NS b.root-servers.net. . 518400 IN NS c.root-servers.net. . 518400 IN NS d.root-servers.net. . 518400 IN NS e.root-servers.net. . 518400 IN NS f.root-servers.net. . 518400 IN NS g.root-servers.net. . 518400 IN NS h.root-servers.net. . 518400 IN NS i.root-servers.net. . 518400 IN NS j.root-servers.net. . 518400 IN NS k.root-servers.net. . 518400 IN NS l.root-servers.net. . 518400 IN NS m.root-servers.net.
;; ADDITIONAL SECTION: a.root-servers.net. 518400 IN A 198.41.0.4 b.root-servers.net. 518400 IN A 199.9.14.201 c.root-servers.net. 518400 IN A 192.33.4.12 d.root-servers.net. 518400 IN A 199.7.91.13 e.root-servers.net. 518400 IN A 192.203.230.10 f.root-servers.net. 518400 IN A 192.5.5.241 g.root-servers.net. 518400 IN A 192.112.36.4 h.root-servers.net. 518400 IN A 198.97.190.53 i.root-servers.net. 518400 IN A 192.36.148.17 j.root-servers.net. 518400 IN A 192.58.128.30 k.root-servers.net. 518400 IN A 193.0.14.129 l.root-servers.net. 518400 IN A 199.7.83.42 m.root-servers.net. 518400 IN A 202.12.27.33 a.root-servers.net. 518400 IN AAAA 2001:503:ba3e::2:30 b.root-servers.net. 518400 IN AAAA 2001:500:200::b c.root-servers.net. 518400 IN AAAA 2001:500:2::c d.root-servers.net. 518400 IN AAAA 2001:500:2d::d e.root-servers.net. 518400 IN AAAA 2001:500:a8::e f.root-servers.net. 518400 IN AAAA 2001:500:2f::f g.root-servers.net. 518400 IN AAAA 2001:500:12::d0d h.root-servers.net. 518400 IN AAAA 2001:500:1::53 i.root-servers.net. 518400 IN AAAA 2001:7fe::53 j.root-servers.net. 518400 IN AAAA 2001:503:c27::2:30 k.root-servers.net. 518400 IN AAAA 2001:7fd::1 l.root-servers.net. 518400 IN AAAA 2001:500:9f::42 m.root-servers.net. 518400 IN AAAA 2001:dc3::35
;; Query time: 33 msec ;; SERVER: 199.7.83.42#53(199.7.83.42) ;; WHEN: Fri Jun 19 03:52:09 IST 2020 ;; MSG SIZE rcvd: 811
[muks@jurassic ~]$ dig +nord +short @m.root-servers.net root-servers.net soa a.root-servers.net. nstld.verisign-grs.com. 2020060800 14400 7200 1209600 3600000 [muks@jurassic ~]$ dig +nord @m.root-servers.net . ns
; <<>> DiG 1.1.1.20200608151533.e8a2352e96 <<>> +nord @m.root-servers.net . ns ; (1 server found) ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 45391 ;; flags: qr aa; QUERY: 1, ANSWER: 13, AUTHORITY: 0, ADDITIONAL: 27
;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4096 ;; QUESTION SECTION: ;. IN NS
;; ANSWER SECTION: . 518400 IN NS d.root-servers.net. . 518400 IN NS g.root-servers.net. . 518400 IN NS i.root-servers.net. . 518400 IN NS l.root-servers.net. . 518400 IN NS j.root-servers.net. . 518400 IN NS f.root-servers.net. . 518400 IN NS c.root-servers.net. . 518400 IN NS b.root-servers.net. . 518400 IN NS m.root-servers.net. . 518400 IN NS a.root-servers.net. . 518400 IN NS e.root-servers.net. . 518400 IN NS k.root-servers.net. . 518400 IN NS h.root-servers.net.
;; ADDITIONAL SECTION: a.root-servers.net. 3600000 IN A 198.41.0.4 b.root-servers.net. 3600000 IN A 199.9.14.201 c.root-servers.net. 3600000 IN A 192.33.4.12 d.root-servers.net. 3600000 IN A 199.7.91.13 e.root-servers.net. 3600000 IN A 192.203.230.10 f.root-servers.net. 3600000 IN A 192.5.5.241 g.root-servers.net. 3600000 IN A 192.112.36.4 h.root-servers.net. 3600000 IN A 198.97.190.53 i.root-servers.net. 3600000 IN A 192.36.148.17 j.root-servers.net. 3600000 IN A 192.58.128.30 k.root-servers.net. 3600000 IN A 193.0.14.129 l.root-servers.net. 3600000 IN A 199.7.83.42 m.root-servers.net. 3600000 IN A 202.12.27.33 a.root-servers.net. 3600000 IN AAAA 2001:503:ba3e::2:30 b.root-servers.net. 3600000 IN AAAA 2001:500:200::b c.root-servers.net. 3600000 IN AAAA 2001:500:2::c d.root-servers.net. 3600000 IN AAAA 2001:500:2d::d e.root-servers.net. 3600000 IN AAAA 2001:500:a8::e f.root-servers.net. 3600000 IN AAAA 2001:500:2f::f g.root-servers.net. 3600000 IN AAAA 2001:500:12::d0d h.root-servers.net. 3600000 IN AAAA 2001:500:1::53 i.root-servers.net. 3600000 IN AAAA 2001:7fe::53 j.root-servers.net. 3600000 IN AAAA 2001:503:c27::2:30 k.root-servers.net. 3600000 IN AAAA 2001:7fd::1 l.root-servers.net. 3600000 IN AAAA 2001:500:9f::42 m.root-servers.net. 3600000 IN AAAA 2001:dc3::35
;; Query time: 104 msec ;; SERVER: 202.12.27.33#53(202.12.27.33) ;; WHEN: Fri Jun 19 03:51:46 IST 2020 ;; MSG SIZE rcvd: 811
[muks@jurassic ~]$
Mukund _______________________________________________ rssac-caucus mailing list rssac-caucus@icann.org https://secure-web.cisco.com/1VMGhS4FLagiiJzOBsS2eR_PeLSC9ab0jLxn0Wb50EOVQBZ...
_______________________________________________ By submitting your personal data, you consent to the processing of your personal data for purposes of subscribing to this mailing list accordance with the ICANN Privacy Policy (https://secure-web.cisco.com/1unE8RKvmE0495psGjK7onXoVtKIu1ke1lqJewPoLq2K_qy...) and the website Terms of Service (https://secure-web.cisco.com/1fHBRgZrLRRzXakVdjkKKJ1oa9gRMgRxSEhWaUWuyaCq_i-...). You can visit the Mailman link above to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on.
I think it should be the same as it is a transfer from master to slaves and nothing should be changed. Sent from my iPhone
On Jun 19, 2020, at 12:34 AM, Wessels, Duane via rssac-caucus <rssac-caucus@icann.org> wrote:
My guess is that some implementations take the glue from the root zone and some take it from the root-servers.net zone (which has the 3600000 TTL).
DW
On Jun 18, 2020, at 3:26 PM, Mukund Sivaraman <muks@mukund.org> wrote:
There's a difference in the TTL of glue records returned in a priming query from different root servers. There's nothing wrong with a nameserver lowering the TTL in a response [RFC2181], but it's an observable difference in behavior. Perhaps some DNS implementation is clamping the glue to TTLs of the NS records. Both TTLs are observed on multiple root server letters respectively.
[muks@jurassic ~]$ dig +nord +short @l.root-servers.net root-servers.net soa a.root-servers.net. nstld.verisign-grs.com. 2020060800 14400 7200 1209600 3600000 [muks@jurassic ~]$ dig +nord @l.root-servers.net . ns
; <<>> DiG 1.1.1.20200608151533.e8a2352e96 <<>> +nord @l.root-servers.net . ns ; (1 server found) ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 26630 ;; flags: qr aa; QUERY: 1, ANSWER: 13, AUTHORITY: 0, ADDITIONAL: 27
;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4096 ;; QUESTION SECTION: ;. IN NS
;; ANSWER SECTION: . 518400 IN NS a.root-servers.net. . 518400 IN NS b.root-servers.net. . 518400 IN NS c.root-servers.net. . 518400 IN NS d.root-servers.net. . 518400 IN NS e.root-servers.net. . 518400 IN NS f.root-servers.net. . 518400 IN NS g.root-servers.net. . 518400 IN NS h.root-servers.net. . 518400 IN NS i.root-servers.net. . 518400 IN NS j.root-servers.net. . 518400 IN NS k.root-servers.net. . 518400 IN NS l.root-servers.net. . 518400 IN NS m.root-servers.net.
;; ADDITIONAL SECTION: a.root-servers.net. 518400 IN A 198.41.0.4 b.root-servers.net. 518400 IN A 199.9.14.201 c.root-servers.net. 518400 IN A 192.33.4.12 d.root-servers.net. 518400 IN A 199.7.91.13 e.root-servers.net. 518400 IN A 192.203.230.10 f.root-servers.net. 518400 IN A 192.5.5.241 g.root-servers.net. 518400 IN A 192.112.36.4 h.root-servers.net. 518400 IN A 198.97.190.53 i.root-servers.net. 518400 IN A 192.36.148.17 j.root-servers.net. 518400 IN A 192.58.128.30 k.root-servers.net. 518400 IN A 193.0.14.129 l.root-servers.net. 518400 IN A 199.7.83.42 m.root-servers.net. 518400 IN A 202.12.27.33 a.root-servers.net. 518400 IN AAAA 2001:503:ba3e::2:30 b.root-servers.net. 518400 IN AAAA 2001:500:200::b c.root-servers.net. 518400 IN AAAA 2001:500:2::c d.root-servers.net. 518400 IN AAAA 2001:500:2d::d e.root-servers.net. 518400 IN AAAA 2001:500:a8::e f.root-servers.net. 518400 IN AAAA 2001:500:2f::f g.root-servers.net. 518400 IN AAAA 2001:500:12::d0d h.root-servers.net. 518400 IN AAAA 2001:500:1::53 i.root-servers.net. 518400 IN AAAA 2001:7fe::53 j.root-servers.net. 518400 IN AAAA 2001:503:c27::2:30 k.root-servers.net. 518400 IN AAAA 2001:7fd::1 l.root-servers.net. 518400 IN AAAA 2001:500:9f::42 m.root-servers.net. 518400 IN AAAA 2001:dc3::35
;; Query time: 33 msec ;; SERVER: 199.7.83.42#53(199.7.83.42) ;; WHEN: Fri Jun 19 03:52:09 IST 2020 ;; MSG SIZE rcvd: 811
[muks@jurassic ~]$ dig +nord +short @m.root-servers.net root-servers.net soa a.root-servers.net. nstld.verisign-grs.com. 2020060800 14400 7200 1209600 3600000 [muks@jurassic ~]$ dig +nord @m.root-servers.net . ns
; <<>> DiG 1.1.1.20200608151533.e8a2352e96 <<>> +nord @m.root-servers.net . ns ; (1 server found) ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 45391 ;; flags: qr aa; QUERY: 1, ANSWER: 13, AUTHORITY: 0, ADDITIONAL: 27
;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4096 ;; QUESTION SECTION: ;. IN NS
;; ANSWER SECTION: . 518400 IN NS d.root-servers.net. . 518400 IN NS g.root-servers.net. . 518400 IN NS i.root-servers.net. . 518400 IN NS l.root-servers.net. . 518400 IN NS j.root-servers.net. . 518400 IN NS f.root-servers.net. . 518400 IN NS c.root-servers.net. . 518400 IN NS b.root-servers.net. . 518400 IN NS m.root-servers.net. . 518400 IN NS a.root-servers.net. . 518400 IN NS e.root-servers.net. . 518400 IN NS k.root-servers.net. . 518400 IN NS h.root-servers.net.
;; ADDITIONAL SECTION: a.root-servers.net. 3600000 IN A 198.41.0.4 b.root-servers.net. 3600000 IN A 199.9.14.201 c.root-servers.net. 3600000 IN A 192.33.4.12 d.root-servers.net. 3600000 IN A 199.7.91.13 e.root-servers.net. 3600000 IN A 192.203.230.10 f.root-servers.net. 3600000 IN A 192.5.5.241 g.root-servers.net. 3600000 IN A 192.112.36.4 h.root-servers.net. 3600000 IN A 198.97.190.53 i.root-servers.net. 3600000 IN A 192.36.148.17 j.root-servers.net. 3600000 IN A 192.58.128.30 k.root-servers.net. 3600000 IN A 193.0.14.129 l.root-servers.net. 3600000 IN A 199.7.83.42 m.root-servers.net. 3600000 IN A 202.12.27.33 a.root-servers.net. 3600000 IN AAAA 2001:503:ba3e::2:30 b.root-servers.net. 3600000 IN AAAA 2001:500:200::b c.root-servers.net. 3600000 IN AAAA 2001:500:2::c d.root-servers.net. 3600000 IN AAAA 2001:500:2d::d e.root-servers.net. 3600000 IN AAAA 2001:500:a8::e f.root-servers.net. 3600000 IN AAAA 2001:500:2f::f g.root-servers.net. 3600000 IN AAAA 2001:500:12::d0d h.root-servers.net. 3600000 IN AAAA 2001:500:1::53 i.root-servers.net. 3600000 IN AAAA 2001:7fe::53 j.root-servers.net. 3600000 IN AAAA 2001:503:c27::2:30 k.root-servers.net. 3600000 IN AAAA 2001:7fd::1 l.root-servers.net. 3600000 IN AAAA 2001:500:9f::42 m.root-servers.net. 3600000 IN AAAA 2001:dc3::35
;; Query time: 104 msec ;; SERVER: 202.12.27.33#53(202.12.27.33) ;; WHEN: Fri Jun 19 03:51:46 IST 2020 ;; MSG SIZE rcvd: 811
[muks@jurassic ~]$
Mukund _______________________________________________ rssac-caucus mailing list rssac-caucus@icann.org https://secure-web.cisco.com/1VMGhS4FLagiiJzOBsS2eR_PeLSC9ab0jLxn0Wb50EOVQBZ...
_______________________________________________ By submitting your personal data, you consent to the processing of your personal data for purposes of subscribing to this mailing list accordance with the ICANN Privacy Policy (https://secure-web.cisco.com/1unE8RKvmE0495psGjK7onXoVtKIu1ke1lqJewPoLq2K_qy...) and the website Terms of Service (https://secure-web.cisco.com/1fHBRgZrLRRzXakVdjkKKJ1oa9gRMgRxSEhWaUWuyaCq_i-...). You can visit the Mailman link above to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on.
_______________________________________________ rssac-caucus mailing list rssac-caucus@icann.org https://mm.icann.org/mailman/listinfo/rssac-caucus
_______________________________________________ By submitting your personal data, you consent to the processing of your personal data for purposes of subscribing to this mailing list accordance with the ICANN Privacy Policy (https://www.icann.org/privacy/policy) and the website Terms of Service (https://www.icann.org/privacy/tos). You can visit the Mailman link above to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on.
On Thu, Jun 18, 2020 at 10:34:40PM +0000, Wessels, Duane wrote:
My guess is that some implementations take the glue from the root zone and some take it from the root-servers.net zone (which has the 3600000 TTL).
You are probably right. If this is the case, then there is the question of which is more correct for use as glue. Though the root servers also serve the root-servers.net zone and are authoritative for them, when glue exists as glue within the root zone, should the root namesevers not use the glue in preference? Ignoring the case of . and root-servers.net, assume a secondary authoritative NS is configured for a parent zone and child zone a couple of levels within the parent domain, which are transferred in from different primary NSs (under control of different entities). The authoritiative NS does not know if the parent and/or slave are delegated to it (as a resolver would) - it just serves zone data. If one is to assume that the parent zone is delegated to the NS, and the child zone is delegated to some other nameserver (whereas a similarly named zone exists on this NS), it seems more correct that glue that exists as glue within the parent zone be used, and not address records from the child zone (even though the NS thinks it is configured as an authority for the child). Mukund
On Fri, Jun 19, 2020 at 04:55:52AM +0530, Mukund Sivaraman wrote:
On Thu, Jun 18, 2020 at 10:34:40PM +0000, Wessels, Duane wrote:
My guess is that some implementations take the glue from the root zone and some take it from the root-servers.net zone (which has the 3600000 TTL).
You are probably right. If this is the case, then there is the question of which is more correct for use as glue. Though the root servers also serve the root-servers.net zone and are authoritative for them, when glue exists as glue within the root zone, should the root namesevers not use the glue in preference?
Ignoring the case of . and root-servers.net, assume a secondary authoritative NS is configured for a parent zone and child zone a couple of levels within the parent domain, which are transferred in from different primary NSs (under control of different entities). The authoritiative NS does not know if the parent and/or slave are delegated
parent and/or *child zone* are delegated
to it (as a resolver would) - it just serves zone data. If one is to assume that the parent zone is delegated to the NS, and the child zone is delegated to some other nameserver (whereas a similarly named zone exists on this NS), it seems more correct that glue that exists as glue within the parent zone be used, and not address records from the child zone (even though the NS thinks it is configured as an authority for the child).
Mukund
On 19. 06. 20 1:29, Mukund Sivaraman wrote:
On Fri, Jun 19, 2020 at 04:55:52AM +0530, Mukund Sivaraman wrote:
On Thu, Jun 18, 2020 at 10:34:40PM +0000, Wessels, Duane wrote:
My guess is that some implementations take the glue from the root zone and some take it from the root-servers.net zone (which has the 3600000 TTL).
You are probably right. If this is the case, then there is the question of which is more correct for use as glue. Though the root servers also serve the root-servers.net zone and are authoritative for them, when glue exists as glue within the root zone, should the root namesevers not use the glue in preference?
Ignoring the case of . and root-servers.net, assume a secondary authoritative NS is configured for a parent zone and child zone a couple of levels within the parent domain, which are transferred in from different primary NSs (under control of different entities). The authoritiative NS does not know if the parent and/or slave are delegated
parent and/or *child zone* are delegated
to it (as a resolver would) - it just serves zone data. If one is to assume that the parent zone is delegated to the NS, and the child zone is delegated to some other nameserver (whereas a similarly named zone exists on this NS), it seems more correct that glue that exists as glue within the parent zone be used, and not address records from the child zone (even though the NS thinks it is configured as an authority for the child).
I would say it does not matter because glue and auth data are supposed to be the same [https://tools.ietf.org/html/rfc1034#section-4.2.2] so implementations should be free to chose either approach. Anyway this is probably material for dnsop WG. -- Petr Špaček @ CZ.NIC
On Fri, Jun 19, 2020 at 10:10:43AM +0200, Petr Špaček wrote:
On 19. 06. 20 1:29, Mukund Sivaraman wrote:
On Fri, Jun 19, 2020 at 04:55:52AM +0530, Mukund Sivaraman wrote:
On Thu, Jun 18, 2020 at 10:34:40PM +0000, Wessels, Duane wrote:
My guess is that some implementations take the glue from the root zone and some take it from the root-servers.net zone (which has the 3600000 TTL).
You are probably right. If this is the case, then there is the question of which is more correct for use as glue. Though the root servers also serve the root-servers.net zone and are authoritative for them, when glue exists as glue within the root zone, should the root namesevers not use the glue in preference?
Ignoring the case of . and root-servers.net, assume a secondary authoritative NS is configured for a parent zone and child zone a couple of levels within the parent domain, which are transferred in from different primary NSs (under control of different entities). The authoritiative NS does not know if the parent and/or slave are delegated
parent and/or *child zone* are delegated
to it (as a resolver would) - it just serves zone data. If one is to assume that the parent zone is delegated to the NS, and the child zone is delegated to some other nameserver (whereas a similarly named zone exists on this NS), it seems more correct that glue that exists as glue within the parent zone be used, and not address records from the child zone (even though the NS thinks it is configured as an authority for the child).
I would say it does not matter because glue and auth data are supposed to be the same [https://tools.ietf.org/html/rfc1034#section-4.2.2] so implementations should be free to chose either approach.
It does matter, because the entity controlling the glue records in the parent zone and the entity controlling the auth data (which may not be the correct entity matching the delegation in the DNS) can be different. This is unlike the case for additional section entries added due to SRV in the answer, and CNAME chains, which can be constructed from multiple locally authoritative zones and even local cache. A resolver is free to discard such data as untrustworthy. Resolvers such as BIND do so and perform additional resolutions for the targets. But a resolver cannot discard glue.
Anyway this is probably material for dnsop WG.
It was sent here because this was observed on the root servers. I'll follow up on dnsop. Mukund
On 19. 06. 20 10:34, Mukund Sivaraman wrote:
On Fri, Jun 19, 2020 at 10:10:43AM +0200, Petr Špaček wrote:
On 19. 06. 20 1:29, Mukund Sivaraman wrote:
On Fri, Jun 19, 2020 at 04:55:52AM +0530, Mukund Sivaraman wrote:
On Thu, Jun 18, 2020 at 10:34:40PM +0000, Wessels, Duane wrote:
My guess is that some implementations take the glue from the root zone and some take it from the root-servers.net zone (which has the 3600000 TTL).
You are probably right. If this is the case, then there is the question of which is more correct for use as glue. Though the root servers also serve the root-servers.net zone and are authoritative for them, when glue exists as glue within the root zone, should the root namesevers not use the glue in preference?
Ignoring the case of . and root-servers.net, assume a secondary authoritative NS is configured for a parent zone and child zone a couple of levels within the parent domain, which are transferred in from different primary NSs (under control of different entities). The authoritiative NS does not know if the parent and/or slave are delegated
parent and/or *child zone* are delegated
to it (as a resolver would) - it just serves zone data. If one is to assume that the parent zone is delegated to the NS, and the child zone is delegated to some other nameserver (whereas a similarly named zone exists on this NS), it seems more correct that glue that exists as glue within the parent zone be used, and not address records from the child zone (even though the NS thinks it is configured as an authority for the child).
I would say it does not matter because glue and auth data are supposed to be the same [https://tools.ietf.org/html/rfc1034#section-4.2.2] so implementations should be free to chose either approach.
It does matter, because the entity controlling the glue records in the parent zone and the entity controlling the auth data (which may not be the correct entity matching the delegation in the DNS) can be different.
This is unlike the case for additional section entries added due to SRV in the answer, and CNAME chains, which can be constructed from multiple locally authoritative zones and even local cache. A resolver is free to discard such data as untrustworthy. Resolvers such as BIND do so and perform additional resolutions for the targets. But a resolver cannot discard glue.
Anyway this is probably material for dnsop WG.
It was sent here because this was observed on the root servers. I'll follow up on dnsop.
Okay, let's continue our diagreement there. -- Petr Špaček @ CZ.NIC
On Fri, Jun 19, 2020 at 10:39:37AM +0200, Petr Špaček wrote:
On 19. 06. 20 10:34, Mukund Sivaraman wrote:
On Fri, Jun 19, 2020 at 10:10:43AM +0200, Petr Špaček wrote:
On 19. 06. 20 1:29, Mukund Sivaraman wrote:
On Fri, Jun 19, 2020 at 04:55:52AM +0530, Mukund Sivaraman wrote:
On Thu, Jun 18, 2020 at 10:34:40PM +0000, Wessels, Duane wrote:
My guess is that some implementations take the glue from the root zone and some take it from the root-servers.net zone (which has the 3600000 TTL).
You are probably right. If this is the case, then there is the question of which is more correct for use as glue. Though the root servers also serve the root-servers.net zone and are authoritative for them, when glue exists as glue within the root zone, should the root namesevers not use the glue in preference?
Ignoring the case of . and root-servers.net, assume a secondary authoritative NS is configured for a parent zone and child zone a couple of levels within the parent domain, which are transferred in from different primary NSs (under control of different entities). The authoritiative NS does not know if the parent and/or slave are delegated
parent and/or *child zone* are delegated
to it (as a resolver would) - it just serves zone data. If one is to assume that the parent zone is delegated to the NS, and the child zone is delegated to some other nameserver (whereas a similarly named zone exists on this NS), it seems more correct that glue that exists as glue within the parent zone be used, and not address records from the child zone (even though the NS thinks it is configured as an authority for the child).
I would say it does not matter because glue and auth data are supposed to be the same [https://tools.ietf.org/html/rfc1034#section-4.2.2] so implementations should be free to chose either approach.
It does matter, because the entity controlling the glue records in the parent zone and the entity controlling the auth data (which may not be the correct entity matching the delegation in the DNS) can be different.
This is unlike the case for additional section entries added due to SRV in the answer, and CNAME chains, which can be constructed from multiple locally authoritative zones and even local cache. A resolver is free to discard such data as untrustworthy. Resolvers such as BIND do so and perform additional resolutions for the targets. But a resolver cannot discard glue.
Anyway this is probably material for dnsop WG.
It was sent here because this was observed on the root servers. I'll follow up on dnsop.
Okay, let's continue our diagreement there.
You are right actually Petr. While preparing an example to demonstrate what I was thinking of, it turned out that this is the same situation as when a NS serves both the parent and child zones of a cut, and it doesn't matter. I don't know why I couldn't wrap my mind around it for so long. Mukund
FYI, we recently wrote a paper about measuring whether clients preferred parent glue or child glue (and other things). Here's a link to a copy of it if anyone is interested in it: https://www.isi.edu/~hardaker/papers/2019-10-cache-me-ttls.pdf On Fri, Jun 19, 2020 at 3:48 AM Mukund Sivaraman <muks@mukund.org> wrote:
On Fri, Jun 19, 2020 at 10:39:37AM +0200, Petr Špaček wrote:
On 19. 06. 20 10:34, Mukund Sivaraman wrote:
On Fri, Jun 19, 2020 at 10:10:43AM +0200, Petr Špaček wrote:
On 19. 06. 20 1:29, Mukund Sivaraman wrote:
On Fri, Jun 19, 2020 at 04:55:52AM +0530, Mukund Sivaraman wrote:
On Thu, Jun 18, 2020 at 10:34:40PM +0000, Wessels, Duane wrote: > My guess is that some implementations take the glue from the root zone > and some take it from the root-servers.net zone (which has the 3600000 > TTL).
You are probably right. If this is the case, then there is the question of which is more correct for use as glue. Though the root servers also serve the root-servers.net zone and are authoritative for them, when glue exists as glue within the root zone, should the root namesevers not use the glue in preference?
Ignoring the case of . and root-servers.net, assume a secondary authoritative NS is configured for a parent zone and child zone a couple of levels within the parent domain, which are transferred in from different primary NSs (under control of different entities). The authoritiative NS does not know if the parent and/or slave are delegated
parent and/or *child zone* are delegated
to it (as a resolver would) - it just serves zone data. If one is to assume that the parent zone is delegated to the NS, and the child zone is delegated to some other nameserver (whereas a similarly named zone exists on this NS), it seems more correct that glue that exists as glue within the parent zone be used, and not address records from the child zone (even though the NS thinks it is configured as an authority for the child).
I would say it does not matter because glue and auth data are supposed to be the same [https://tools.ietf.org/html/rfc1034#section-4.2.2] so implementations should be free to chose either approach.
It does matter, because the entity controlling the glue records in the parent zone and the entity controlling the auth data (which may not be the correct entity matching the delegation in the DNS) can be different.
This is unlike the case for additional section entries added due to SRV in the answer, and CNAME chains, which can be constructed from multiple locally authoritative zones and even local cache. A resolver is free to discard such data as untrustworthy. Resolvers such as BIND do so and perform additional resolutions for the targets. But a resolver cannot discard glue.
Anyway this is probably material for dnsop WG.
It was sent here because this was observed on the root servers. I'll follow up on dnsop.
Okay, let's continue our diagreement there.
You are right actually Petr. While preparing an example to demonstrate what I was thinking of, it turned out that this is the same situation as when a NS serves both the parent and child zones of a cut, and it doesn't matter. I don't know why I couldn't wrap my mind around it for so long.
Mukund _______________________________________________ rssac-caucus mailing list rssac-caucus@icann.org https://mm.icann.org/mailman/listinfo/rssac-caucus
_______________________________________________ By submitting your personal data, you consent to the processing of your personal data for purposes of subscribing to this mailing list accordance with the ICANN Privacy Policy (https://www.icann.org/privacy/policy) and the website Terms of Service (https://www.icann.org/privacy/tos). You can visit the Mailman link above to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on.
-- Wes Hardaker USC/ISI
participants (5)
-
Abdalmonem Tharwat Galila -
Mukund Sivaraman -
Petr Špaček -
Wes Hardaker -
Wessels, Duane