On Tue, Sep 27, 2022 at 9:17 AM Gould, James <jgould= [email protected]> wrote:
> Gavin, > > I believe the domain-level TTL applies to the records it owns, which > include the DS, NS, and DNAME. The host-level TTL applies to the records > it owns, which include the A and AAAA. In your examples, if we're talking > about the NS TTL of the example.com delegating name server ns1.example.com, > it would be 3600 for both. If the ns1.example.com host TTL was set to > 86400, it would be applied to the A and AAAA glue records. > > -- Each RRSet can have its own TTL different from other RRSets with the same name (ie, the TTL for A records can be different for AAAA records). Are you referring to the host-level TTL which is at the Registry level ? You could define those to be the same. tim > > > JG > > > > James Gould > Fellow Engineer > [email protected] > <applewebdata://13890C55-AAE8-4BF3-A6CE-B4BA42740803/[email protected]> > > 703-948-3271 > 12061 Bluemont Way > Reston, VA 20190 > > Verisign.com <http://verisigninc.com/> > > On 9/27/22, 6:48 AM, "Gavin Brown" <[email protected]> wrote: > > Thanks Rick and Jim for the feedback. I am happy to accept the idea of > the extension working for both domain and host objects and will work > towards making that a part of the next version. > > One point for possible further discussion is the "priority" of TTL > values: I am going to state that the TTL value of the host object takes > priority over the TTL of the superordinate domain. So if: > > com default TTL: 172800 > example.com TTL: 3600: > ns1.example.com TTL: (undefined) > > then the TTL for NS records delegating to ns1.example.com should be > 3600, but if > > com default TTL: 172800 > example.com TTL: 3600: > ns1.example.com TTL: 86400 > > then the TTL should be 86400. > > G. > > > On 26 Sep 2022, at 13:41, Rick Wilhelm <[email protected]> wrote: > > > > Gavin, > > > > Just a +1 for having this extension cover both the domain and host > objects. > > > > The sibling glue model has enough deployment that having the > extension cover both models makes sense. > > > > > > One other thing… and this is not a call for a change, just > concurrence to an existing design choice that is in the draft. I like the > behavior described for Server Processing of TTL Values (Section 4, > paragraph 2) where the description covers the scenario where the TTL values > are outside the range. > > > > The doc says to reject the command with a 2004 “Parameter value > range error”. I was wondering if this might be “too aggressive” for a > <create> (it clearly makes sense for an <update>), but after some thought, > I agree with the current behavior. > > > > First, it’s consistent. Second, since the extension is optional > (and since hosts links are optional on domain::create, the extension is > “2x-optional”), it is better to “fast fail” due to validation enforcement. > Because to let the <domain::create> go through and have the invalid values > flagged with only a warning is more likely to lead to confusion in the > future. That is, a client that is not properly respecting the limits of > the TTL values is also unlikely to be heading a hypothetical warning value. > > > > So, bottom line, after some thought, I like the way that this works. > > > > > > Thanks > > Rick > > > > > > > > > > > > From: regext <[email protected]> on behalf of Gould, James > <[email protected]> > > Date: Monday, September 19, 2022 at 9:48 AM > > To: [email protected] <[email protected]>, > [email protected]<[email protected]> > > Cc: [email protected] <[email protected]> > > Subject: [EXTERNAL] Re: [regext] Fwd: New Version Notification for > draft-regext-brown-epp-ttl-01.txt > > > > CAUTION: This email came from outside your organization. Don’t trust > emails, links, or attachments from senders that seem suspicious or you are > not expecting. > > > > Gavin, > > > > The TTL for the A/AAAA records need to be applied to the host object > and the TTL for the NS and DS records need to be applied to the domain > object. Setting the A/AAAA TTL at the host object level would apply to > registries that implement sibling glue as well as CentralNic and TANGO that > implement in-bailiwick only glue. > > > > -- > > > > JG > > > > > > > > James Gould > > Fellow Engineer > > [email protected] > <applewebdata://13890C55-AAE8-4BF3-A6CE-B4BA42740803/[email protected]> > > > > 703-948-3271 > > 12061 Bluemont Way > > Reston, VA 20190 > > > > Verisign.com < > http://secure-web.cisco.com/1rl_OvR6_k8szzz82KnsefauK2VVokmHEilpYRTh_bVhZ8bgeo-8SaO5imViM18jSfegFFfsa2CWcLPV7Gbp2E_kjmnltoelhZ7LF9LAeSmcY7DaH_J4I2ojQR4Ljeaj4ywnV-AvV8uX8osivccNRe5haKolMCxQA4O4m828dwyjBYh9BuIM9UZiWzgiqdUb7vig4eH4LiZxaDLZ5RxHPl5V_tNJAbtFnW4Yo8sUlZxyIcDYV3kUic7u7vbswy3Us/http%3A%2F%2Fverisigninc.com%2F > > > > > > On 9/16/22, 9:17 PM, "regext on behalf of Gavin Brown" < > [email protected] on behalf of [email protected]> wrote: > > > > Hi Thomas, > > > > Thanks for the suggestions. I will add them to the next version. > > > > G. > > > > > On 15 Sep 2022, at 01:11, Thomas Corte (TANGO support) < > [email protected]> wrote: > > > > > > On 9/14/22 13:35, Gavin Brown wrote: > > > > > >> Greetings all, > > >> > > >> Many years ago CentralNic had a proprietary EPP extension for > managing > > >> the TTL values of domain names. ... > > >> > > >> However I've had a bit of feedback about the draft since then, so > I've > > >> just published a new version and am now sharing it with the WG for > > >> feedback. > > > > > > I have two comments: > > > > > > 1) The specification should probably address the effect of the > TTLs on > > > IDN variants. If a registry supports IDN variants as attributes of > a > > > domain name (either automatically added or via an extension), they > will > > > usually add some DNS records dedicated to these variants to the > TLD zone, > > > so the spec should specify that the same TTL is applied to these > > > dedicated records as well. If IDN variants are managed as their > own > > > objects, they can receive their own specific TTL values. > > > > > > 2) I'd suggest to add this boilerplate text (or something similar) > to the > > > draft: > > > > > > "EPP uses XML namespaces to provide an extensible object management > > > framework and to identify schemas required for XML instance parsing > > > and validation. These namespaces and schema definitions are used to > > > identify both the base protocol schema and the schemas for managed > > > objects. The XML namespace prefixes used in examples (such as the > > > string "ttl" in "xmlns:ttl") are solely for illustrative purposes. > A > > > conforming implementation MUST NOT require the use of these or any > > > other specific namespace prefixes." > > > > > > This is a pet peeve of mine, as some registries still haven't > managed to > > > implement this correctly. > > > > > >> In our implementation, glue records are only published if the > > >> superordinate domain is delegated to them, and the current > > >> specification assumes the same design choice. However this is > > >> obviously not true for other registries, so being able to change > the > > >> TTL on a host object independently of the superordinate domain > may be > > >> needed to account for scenarios where the client wishes to change > the > > >> TTL of all NS records *except* those of the superordinate domain. > > >> However I am not sure if this is a scenario that justifies the > > >> additional complexity entailed - but I'd appreciate the list's > input > > >> on that point. > > > > > > Our own TANGO system's zone generation also suppresses glue > records if > > > they're unnecessary, so I'd agree that the extra complexity > shouldn't be > > > required. > > > > > > Best regards, > > > > > > Thomas > > > > > > -- > > > TANGO REGISTRY SERVICES® > > > Knipp Medien und Kommunikation GmbH Thomas Corte > > > Technologiepark Phone: +49 231 9703-222 > > > Martin-Schmeisser-Weg 9 Fax: +49 231 9703-200 > > > D-44227 Dortmund E-Mail: [email protected] > > > Germany > > > > > > > > > > > > > > > > > > > -- > > Gavin Brown > > Head of Registry Services > > CentralNic Group plc (LSE:CNIC) > > > https://secure-web.cisco.com/14iQKw6gpSA8BoJOmhv6QjiaCTMGaV1jtoe_uIp8bRMky-K_waMharMEg1LYAtlWQzbHVPm2AmR56O6ydcDKobgVBEd8Mp95GJ4pfxuUZclcuaVBTXohuG6UFiZL8xJ3nqGu2mdmXKQsJPMkec8furVUgjMJNBPl8lwD5Bq0rklXDq-hFZXWTKZmWa5fb8Uwnk0OsfYNX4uZhal8J_rCVACHGBTdRrXemWcsjenM7fbYJzUttkEdStu8R7PY547eg/https%3A%2F%2Fcentralnicregistry.com > > > > Cal: > https://secure-web.cisco.com/1hJ_Ypbd5OAM--cIUke4ujR8-8LTMV4cqpfYs9QUL3-xaEmFm7OPW_RKJa5TaJZ-HneITtwkOeMVSKTCbmrMbjcErDdz8Dn9s8KdDKMHHT_n0P5y-9uAWYPonAmrg9XVm72gORCQ9yh_SEzHxdAInQcg2pxTqBSDiW21bw4Msfzp7DQlftiKFeHB_z6wxjFlsu1gkcEBSt3buj5OUNEPih8pWx70nO2sXSue_OSN30cn26q27kvkyDHix9BcqlRSV/https%3A%2F%2Fcnic.link%2Fgbcalendar > > > > CentralNic Group plc is a company registered in England and Wales > with company number 8576358. Registered Offices: Saddlers House, Gutter > Lane, London EC2V 6BR. > > > > > https://secure-web.cisco.com/1dbi9wWVJ28DEfKsxyfgDEQU-jFqu7mdY6XAsqbxvETOtZUTia8UHVG3wWzYeRemA7OPimBJnEWIQ_chpT9e5Sa-J20mZ-lg7OKtsrHauuCHNraZIrO2sRn6I4uLLUnXzu7GzOmhVsqGk-bob53BCqaJDheGvFW_lx1FJtJFFdvwqJk7jnOmAXoXJh9o7jqHERzAzFZQabrHdQPUpCk_gViXXZQ3itKXVeka3mdJHHng6f07BY0VfTk3jZ8prKebY/https%3A%2F%2Fwww.centralnic.com > > > > _______________________________________________ > > regext mailing list > > [email protected] > > > https://secure-web.cisco.com/17iGVT_AU5IsvLflCUT5ypMVunmm1fTgnPxEcMeRIVbSjVZJoJIWdWHyw157N9qknJiHgZkxVaZWRtrflXFk_7WtXpCWF_Gwe7PdF_lmQJh07SRN5vMVGi3XbZKgIdtWTMfx3R-diYwdR5a2_tC-ByoLYtPrGe7Mnivy3oZbVWZlEGNeiP0fE_5Nccxc5kNkVoPC0hdk-f9gyPQAaiVMskLu5OoHGs-thMpK2RAklTTuW5nbCC9f53GvnO4SlCwKo/https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fregext > > > > _______________________________________________ > > regext mailing list > > [email protected] > > > https://secure-web.cisco.com/1uk2fr6SbgeYDiRtLSfE1gPeoIP4OayW3D3MTev2AuxEowvJhHH5o8fP6ofVKpbYk9eTqZ6S_bmtbQDKx6fUf7P0ImAG5so__X7EpvZHBGu0GQA8PzfkmDBeu9g4bXGCQGT1ysLBknZZg_7-n-dHO5uk8_hYLo-fuzU_ybXQyiqzl69mzdnKeapHFIPRb3TeJWcErjbiXngDHUvXL5Ur1C6UaheiImxW8XMzN-XaVOPVP-cCFSMh1GMJa1ZRxmBla/https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fregext > > > > -- > Gavin Brown > Head of Registry Services > CentralNic Group plc (LSE:CNIC) > > https://secure-web.cisco.com/1lktPhnXJ36QcWwB_nWDEJX9acgMw_YC_GzImtZ2c5yvEGow5GLZMQ0ORxKlFsxwT51e51Wp2-pgNTSc8_HV_jVGV0W8gJCGuEUvxLe7cjMooPXHRuuTmHphXBiz06r5oP2oMPVE5cMWm29pkLEVLfdvPL9UfUMlurzdH8E6VBTvAjOVEM_CInVFIOc1gnXi918T4uyFvu7N52YFOPOoCVqUbZF6_zzx8fZ_xK1Nsf1a6iJubj2RqsEZZZXNV9oA7/https%3A%2F%2Fcentralnicregistry.com > > Cal: > https://secure-web.cisco.com/1lWudxzTziTfT5hvKxlPQaNV-2-MrZRMowg9M6FcmrV_lz70NlhT-i43go4JssAwqRncGzIeaczGpjsJ6YPNNgZMp9RYvNH1_A7fLus-n8dClA7yXy65qmTS_xx2CT4V85u1RP-AhKqBnqJ4HGXvI8nYCIE0FdGSPaM6GJl-Tx914ebRVnyU3Zo7TatfJnujyZDo5KeyAklCr5bxK64X7bMaKoCCG884wb3OgzjkXciohIki5KfWTZ-ugD4kFRCY0/https%3A%2F%2Fcnic.link%2Fgbcalendar > > CentralNic Group plc is a company registered in England and Wales with > company number 8576358. Registered Offices: Saddlers House, Gutter Lane, > London EC2V 6BR. > > > https://secure-web.cisco.com/14_4cnKxNaqSyp1oKSQfhdnzhHvyxCD2B0Gk1eOyOeEJtIaTWO3IgtpdDX8gtW75lANjmeH_mrNdl0n8N1ruZgDVkcXp7j7mZMeocw4Hziv5o4efgOflfVzaflSEmswIhMqtWUrYvOQiiSkqAI_tR1TNoCVzbDmQV5vF3Tdxr3LMABlhGn5Z3e53Ku1gkVPGMPdHLfTDxCgGRHFkgcr6fVnODqsvP6DW4g-lufDNjPJEoErcVCqlYNats-NU4rl4K/https%3A%2F%2Fwww.centralnic.com > > > _______________________________________________ > regext mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/regext >
_______________________________________________ regext mailing list [email protected] https://www.ietf.org/mailman/listinfo/regext
