On Tue, 2019-07-23 at 00:07 +0200, Juergen Schoenwaelder wrote:
> On Mon, Jul 22, 2019 at 04:55:33PM -0400, Ladislav Lhotka wrote:
> > Juergen Schoenwaelder <[email protected]> writes:
> >
> > > Lada,
> > >
> > > I do not think we can simply enlarge the value set of inet:domain-name,
> > > existing implementations using inet:domain-name may (rightfully) not
> > > expect wildcards.
> >
> > On the other hand, the description says:
> >
> > It is designed to hold various types of domain names, including
> > names used for A or AAAA records (host names) and other records, ...
> >
> > So one could expect that all values that can appear e.g. in A/AAAA records
> > of DNS zone data are supported, which is not the case.
>
> The pattern does not allow wildcards and it did so back in RFC 6021.
> We can discuss whether this is wrong but allowing wildcards or other
> new characters I think should be done with care and considering
> existing implementations.
>
> > > What we can do is to create a new definition that has a larger value
> > > space. We can also consider to define inet:domain-name as a subset of
> > > such a larger type as long as it results in the same value space.
> >
> > My suggestion is to remove the above sentence from the description in the
> > next revision, and leave the rest to DNS folks. There are other interesting
> > issues, such as how to model internationalized domain names.
>
> I am not sure which problem is solved by removing the sentence.
There are many places where domain names are used. The description mentions
A/AAAA/SRV resource records even those the type is actually not well suited for
this use case.
>
> I would perhaps understand the suggestion to _add_ an explicit
> statement right at the top that wildcards or slashes are not
> supported:
>
> OLD:
>
> "The domain-name type represents a DNS domain name. The
> name SHOULD be fully qualified whenever possible.
>
> NEW:
>
> "The domain-name type represents a DNS domain name. The
> name SHOULD be fully qualified whenever possible. Domain
> names including wildcards or forward slashes are not
> supported.
But these two unsupported cases only make sense in the context of DNS zone data.
I would suggest instead
NEW:
"The domain-name type represents a DNS domain name. The
name SHOULD be fully qualified whenever possible.
This type is not intended for modeling DNS zone data, as
it does not support wildcards [RFC 4592] and classless
in-addr.arpa delegations [RFC 2317]."
Lada
>
> This would help clarify things. People that need to represent
> wildcards etc. then know that this type is not the right one for
> them.
>
> /js
>
> > Lada
> >
> > > /js
> > >
> > > On Fri, Mar 29, 2019 at 11:20:13AM +0100, Ladislav Lhotka wrote:
> > > > Hi, as a follow-up to my comment during the NETMOD session, I want
> > > > to propose the following update to the the inet:domain-name type.
> > > > The aim is to include use cases that are currently rejected: -
> > > > classless in-addr.arpa delegations [RFC 2317], i.e. labels like
> > > > "128/26" - wildcards [RFC 4592], e.g. "*.example.net" OLD
> > > > pattern
> > > > '((([a-zA-Z0-9_]([a-zA-Z0-9\-_]){0,61})?[a-zA-Z0-9]\.)*' +
> > > > '([a-zA-Z0-9_]([a-zA-Z0-9\-_]){0,61})?[a-zA-Z0-9]\.?)' + '|\.';
> > > > NEW pattern
> > > > '((\*\.)?(([a-zA-Z0-9_]([a-zA-Z0-9\-/_]){0,61})?[a-zA-Z0-9]\.)*'
> > > > + '([a-zA-Z0-9_]([a-zA-Z0-9\-/_]){0,61})?[a-zA-Z0-9]\.?)' +
> > > > '|\.'; Lada -- Ladislav Lhotka Head, CZ.NIC Labs PGP Key ID:
> > > > 0xB8F92B08A9F76C67 _______________________________________________
> > > > netmod mailing list [email protected]
> > > > https://www.ietf.org/mailman/listinfo/netmod
> > >
> > > -- Juergen Schoenwaelder Jacobs University Bremen gGmbH
> > > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany
> > > Fax: +49 421 200 3103 <https://www.jacobs-university.de/>
> >
> > --
> > Ladislav Lhotka
> > Head, CZ.NIC Labs
> > PGP Key ID: 0xB8F92B08A9F76C67
--
Ladislav Lhotka
Head, CZ.NIC Labs
PGP Key ID: 0xB8F92B08A9F76C67
_______________________________________________
netmod mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/netmod
