Subject: Re: [netmod] 6991bis: domain-name

From: Juergen Schoenwaelder <[email-masked]>
Date: Sun, 21 Jul 2019 22:30:47 +0200

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.

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.

/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-masked]
> 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/>

---

From: Ladislav Lhotka <[email-masked]>
Date: Mon, 22 Jul 2019 16:55:33 -0400

Juergen Schoenwaelder <[email-masked]> 
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. 
> 
> 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.

Lada
 
>> 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]\.?)'  + 
>>     '|\.'; 
>>  NEW  
>>     pattern 
>>  Lada  --  Ladislav Lhotka Head, CZ.NIC Labs PGP Key ID: 
>> 0xB8F92B08A9F76C67 
>> _______________________________________________ netmod mailing 
>> list [email-masked] 
> --  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/>

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 23 Jul 2019 00:07:55 +0200

On Mon, Jul 22, 2019 at 04:55:33PM -0400, Ladislav Lhotka wrote:
> Juergen Schoenwaelder <[email-masked]> writes:
> 
> > Lada,
> > 
>    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.
 
> 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

> > > 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]\.?)'     +
> > > '|\.';  Lada  --  Ladislav Lhotka Head, CZ.NIC Labs PGP Key ID:
> > > 0xB8F92B08A9F76C67 _______________________________________________
> > > netmod mailing list [email-masked]
> > --  Juergen Schoenwaelder           Jacobs University Bremen gGmbH

---

From: Ladislav Lhotka <[email-masked]>
Date: Mon, 22 Jul 2019 18:41:42 -0400

> 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.

> 	 names including wildcards or forward slashes are not

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

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 24 Jul 2019 09:00:57 +0200

>          in-addr.arpa delegations [RFC 2317]." 

Yes, this is better. I will put the following in the next revision:

     "The domain-name type represents a DNS domain name.  The
      name SHOULD be fully qualified whenever possible. This
      type does not support wildcards (see RFC 4592) and
      classless in-addr.arpa delegations (see RFC 2317).

And I will remove the sentence you wanted to remove since the above
more clearly explains when to use / not to use this type.

/js

---

From: William Lupton <[email-masked]>
Date: Wed, 24 Jul 2019 10:18:32 +0100

I think that "or" is slightly better here:

"...does not support wildcards (see RFC 4592) *or* classless in-addr.arpa
delegations (see RFC 2317)"

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 24 Jul 2019 11:39:08 +0200

Yes, changed in my sources.

/js

---

From: Ladislav Lhotka <[email-masked]>
Date: Wed, 24 Jul 2019 09:08:38 -0400

On Wed, 2019-07-24 at 10:18 +0100, William Lupton wrote:
> "...does not support wildcards (see RFC 4592) or classless in-addr.arpa

I agree, thanks.

Lada