What might make more sense is to define a range (via standards action) for private use, as there is in other DNS parameters. ------------------------------
Any statements contained in this email are personal to the author and are not necessarily the statements of the company unless specifically stated. AS207960 Cyfyngedig, having a registered office at 13 Pen-y-lan Terrace, Caerdydd, Cymru, CF23 9EU, trading as Glauca Digital, is a company registered in Wales under № 12417574 <https://find-and-update.company-information.service.gov.uk/company/12417574>, LEI 875500FXNCJPAPF3PD10. ICO register №: ZA782876 <https://ico.org.uk/ESDWebPages/Entry/ZA782876>. UK VAT №: GB378323867. EU VAT №: EU372013983. Turkish VAT №: 0861333524. South Korean VAT №: 522-80-03080. AS207960 Ewrop OÜ, having a registered office at Lääne-Viru maakond, Tapa vald, Porkuni küla, Lossi tn 1, 46001, trading as Glauca Digital, is a company registered in Estonia under № 16755226. Estonian VAT №: EE102625532. Glauca Digital and the Glauca logo are registered trademarks in the UK, under № UK00003718474 and № UK00003718468, respectively. On Thu, 15 Aug 2024 at 18:04, Ben van Hartingsveldt <ben.vanhartingsveldt= 40yocto....@dmarc.ietf.org> wrote: > Dear all, > > Thanks for the responses I received. I got some useful feedback that > helped me improve the drafts. > > As Peter Thomassen already mentioned earlier, I was talking about a > label type mainly for confined systems only. Except for some small > exceptions, a record will never leave the DNS server in its relative > form. This means that introducing it will not break current DNS, because > the label type is only used in systems that want to use it, and systems > should not expect other systems to support it too, so I'm really talking > about confined systems here. I wanted to clarify that, because I didn't > yet use that word in my drafts and there seemed some confusion about it. > > After all, I still hope I succeed in registering the label at IANA. I > still think there is usecase for it. At least, I will use it in my > confined systems, but some others might too. However, the registration > procedure at IANA for this registry is "Standards Action", so it seems > to me that the IESG has to approve it too, else I would have gone for > independent submission. > > Also, when I create a new draft that adds the word "confined" to the > text, what other things should I add, change or remove in order to > improve it? Because some interpreted my draft differently, are there > some texts I wasn't fully clear? Please let me know. > > Thanks in advance > > Ben > > Ben van Hartingsveldt schreef op 2024-07-26 09:07: > > Dear all, > > > > Today, I released a new version of the draft: > > https://datatracker.ietf.org/doc/html/draft-yocto-dns-relative-label-02. > > > I replaced the term "record" with "resource record", updated the > > reference to the EDNS RFC, and added an Acknowledgements section. > > > > @Peter Thomassen: Is it possible to make some list with all interop > > problems for this draft? With such list, I can look for ways to address > > them; or that I conclude to reframe the draft to be for confined > > systems only. > > > > Ben > > > > Ben van Hartingsveldt schreef op 2024-07-23 08:56: > >> Dear all, > >> > >> Today, I released a new version of the draft: > >> https://datatracker.ietf.org/doc/html/draft-yocto-dns-relative-label-01. > > >> I tried to clarify things a little bit more, added some examples and > >> fixed some references. > >> > >> Ben > >> > >> Ben van Hartingsveldt schreef op 2024-07-21 18:50: > >>> Dear all, > >>> > >>> In the recent years I started working on my own coded DNS server, > >>> because I was done with the synchronization between BIND and > >>> DirectAdmin that broke all the time. It resulted in a Java server > >>> that is running on 4 IPs for some years now. Because of this, I had > >>> to read many RFCs to have it pass tests like Zonemaster, DNSViz, > >>> IntoDNS, etc. While reading and implementing things, I also came > >>> across some shortcomings of DNS. On advice of someone at SIDN, I will > >>> share my draft that I published today. It solves one of the > >>> shortcomings that DNS has in its core: relative domain names. > >>> > >>> I'm talking about > >>> > https://datatracker.ietf.org/doc/html/draft-yocto-dns-relative-label-00. > >>> This draft is meant to solve the problem that we cannot use relative > >>> domain names in the DNS system, specificly in DNS UPDATE and in > >>> binary zone files. This also means that this draft is not meant for > >>> use with the QUERY opcode (except for possibly AXFR and IXFR). Let me > >>> explain those two usecases. > >>> > >>> 1) DNS UPDATE: In DNS UPDATE it is possible to update the zone using > >>> DNS itself. This can be used in routers when dynamic DNS is wanted, > >>> but also in other situations. Imagine wanting to add an MX record. > >>> Using a webinterface, you are likely able to chooses one of the > >>> following four options: > >>> - mail IN MX 10 mx > >>> - mail IN MX 10 mx.example.com. > >>> - mail.example.com. IN MX 10 mx > >>> - mail.example.com. IN MX 10 mx.example.com. > >>> However, using DNS UPDATE you are only able to add the record with > >>> fourth format; both record name and FQDN field have to be absolute. > >>> This means that when I return to the webinterface, I will likely see > >>> absolute domain names, even when I use relative domain names in my > >>> other records. My draft wants to give the client more control over > >>> when to use relative and when to use absolute domain names by adding > >>> a new label type. > >>> > >>> 2) Binary Zone Files: Since BIND 9, it is possible to save zones in a > >>> binary format. This is possible to enable/disable using > >>> `masterfile-format`. It is possible to convert the textual format to > >>> binary and vice versa. However, when converting to binary, the zone > >>> file will loose the knowledge of knowing which domain names where > >>> absolute and which where relative. This means that converting the > >>> zone back from binary to text will likely give you a zone with only > >>> absolute domain names. As with DNS UPDATE, this is a shortcoming of > >>> the wire format used by DNS. > >>> > >>> That is why I wrote this draft. Like BIND, my own DNS system also > >>> uses binary zone storage and in the future I'm planning to implement > >>> DNS UPDATE too. I also believe my draft is not yet perfect. I'm not a > >>> native English speaker and maybe just format to mention something > >>> important. That is why I want you to give your honest opinion on this > >>> topic. Do you agree with the problem? Does DNS need such label? Did I > >>> make a typo? Etc. > >>> > >>> Please let me know. > >>> > >>> Thanks in advance > >>> > >>> Ben van Hartingsveldt > >>> > >>> _______________________________________________ > >>> DNSOP mailing list -- dnsop@ietf.org > >>> To unsubscribe send an email to dnsop-le...@ietf.org > >> > >> _______________________________________________ > >> DNSOP mailing list -- dnsop@ietf.org > >> To unsubscribe send an email to dnsop-le...@ietf.org > > > > _______________________________________________ > > DNSOP mailing list -- dnsop@ietf.org > > To unsubscribe send an email to dnsop-le...@ietf.org > > _______________________________________________ > DNSOP mailing list -- dnsop@ietf.org > To unsubscribe send an email to dnsop-le...@ietf.org >
_______________________________________________ DNSOP mailing list -- dnsop@ietf.org To unsubscribe send an email to dnsop-le...@ietf.org
