[DNSOP] Re: Introducing Relative Label for DNS

[Q Misell]

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
,
LEI 875500FXNCJPAPF3PD10. ICO register №: 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 № UK3718474 and № UK3718468,
respectively.


On Thu, 15 Aug 2024 at 18:04, Ben van Hartingsveldt  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

Re: [DNSOP] Working Group Last Call for draft-ietf-dnsop-dnssec-bootstrapping

[Q Misell]

Hi all,

Just a quick note (as requested by Peter Thomassen) to say that we (
https://glauca.digital) have implemented
draft-ietf-dnsop-dnssec-bootstrapping for our registrar’s CDS bootstrapping.

Thanks,
Q
--

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
,
LEI 875500FXNCJPAPF3PD10. ICO register №: 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 № UK3718474 and № UK3718468,
respectively.
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop