[DNSOP] Re: Introducing Relative Label for DNS

[Ben van Hartingsveldt <[e-mail]>]

That could be a solution, but I doubt if that is a good one. The Label 
Type has the smallest range of all DNS parameters. Most private use 
ranges appear as part of in 16-bit (65536) parameters or 8-bit (256) 
parameters. Label Type is actually 6-bits (64), assuming you want to use 
10xxxxxx for it.

Also, I don't want this 0x40 label type not in a private use range. Yes, 
the label is used in confined systems, so other systems don't need to 
implement it. The label type is only used on authoritve servers, so for 
DNS Operators that want to use it for their zones. Recursive servers, 
like 1.1.1.1 and 8.8.8.8 should not use this. Recursive servers only 
keep track of full absolute records and aren't aware of any zones and 
zone cuts, so the relative label type must not appear there.

So, simply said: The relative label type is only for DNS Operators of 
Authoritive DNS servers that want to save their records relatively in 
binary (fully confined) AND to give their customers the possibility to 
view/modify relative records using DNS UPDATE (partly confined, because 
visible by customer). I think that last thing makes the label type to 
important to just throw in the private use range.

Q Misell schreef op 2024-08-16 09:15:
> 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 [3], LEI
> 875500FXNCJPAPF3PD10. ICO register №: ZA782876 [4]. 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 [1].
>>>>> - mail.example.com [2]. IN MX 10 mx
>>>>> - mail.example.com [2]. IN MX 10 mx.example.com [1].
>>>>> 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]
> 
> 
> Links:
> ------
> [1] http://mx.example.com
> [2] http://mail.example.com
> [3] 
> https://find-and-update.company-information.service.gov.uk/company/12417574
> [4] https://ico.org.uk/ESDWebPages/Entry/ZA782876
> _______________________________________________
> DNSOP mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]