[DNSOP] Re: Introducing Relative Label for DNS

[Q Misell <[e-mail]>]

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=
[e-mail]> 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 -- [e-mail]
> >>> To unsubscribe send an email to [e-mail]
> >>
> >> _______________________________________________
> >> DNSOP mailing list -- [e-mail]
> >> To unsubscribe send an email to [e-mail]
> >
> > _______________________________________________
> > DNSOP mailing list -- [e-mail]
> > To unsubscribe send an email to [e-mail]
>
> _______________________________________________
> DNSOP mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]
>