On Mon, Jul 22, 2019 at 04:55:33PM -0400, Ladislav Lhotka wrote:
> Juergen Schoenwaelder <j.schoenwael...@jacobs-university.de> 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.
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.
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 netmod@ietf.org
> > > 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
--
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/>
_______________________________________________
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod
