I presume it was copied form the DB Ref Man, which should be update to reflect relality. :-) I really appreciate the fact that the software accepts the trailing "." for an FQDN. Wilfried. Katie Petrusha wrote:

On Mon, May 15, 2006 at 09:10:06AM +0200, Pim van Pelt wrote:

Dear Pim,

...

One thing caught my eye:

...

[domain_name] is the fully qualified DNS name of the name server without a trailing "."

Considering 'bfib.ipng.nl' and 'bfib.ipng.nl.' end up pointing to the same hostname (the latter doing a somewhat better job), I don't understand why you would want to specify '... without the trailing "."'. I sometimes bump into this in other (related) areas such as looking up "*.in-addr.arpa.". It was discussed some time ago and IIRC the outcome was that the software is easily modified to accept this trailing dot. I'd prefer to see it that way.

You're right. This is rather a typo :( The names are accepted both with and without trailing dot now; it will stay that way. Thanks for noticing this!

Hello Katie,

and reject

domain: test.net nserver: ns2.example.com 168.0.0.1

Hope it is clearer now; any suggestions about better and clearer phrasing are appreciated.

That's fine, the owner name of the glue A/AAAA RR may be at any level greater or equal than the zone to be delegated. But ...

The only new glue-related checks will be: 1) Making sure all glue IPs listed in domain object are also listed in the zone at every nameserver

... this test might fail in otherwise correct configurations. Unless explicitly excluded, a glue RR may belong to a zone _below_ the delegated one, so the servers of the delegated zone cannot be expected to authoritatively know the A/AAAA RR(s). I'd not believe this is common in e164.arpa, but than I'd also have thought there's no need for glue in that domain in the first place ...

2) Glue name must be within the same domain (already listed above)

Yep. And the check should include the presence of mandatory glue RRs. With a miced v4/v6 environment, would a name server with v6 only glue be accepted (v4 only obviously is)? How many glue RRs would be allowed per name server entry? -Peter

On Mon, May 15, 2006 at 03:10:15PM +0200, Peter Koch wrote: Dear Peter, <skip>

...

domain: test.net nserver: ns2.example.com 168.0.0.1

Hope it is clearer now; any suggestions about better and clearer phrasing are appreciated.

That's fine, the owner name of the glue A/AAAA RR may be at any level greater or equal than the zone to be delegated. But ...

...

The only new glue-related checks will be: 1) Making sure all glue IPs listed in domain object are also listed in the zone at every nameserver

... this test might fail in otherwise correct configurations. Unless explicitly excluded, a glue RR may belong to a zone _below_ the delegated one, so the servers of the delegated zone cannot be expected to authoritatively know the A/AAAA RR(s).

Good point. Instead, this check could be implemented to just give a warning if IPs are not listed or differ. So that user can make sure this is intentional. Would that make sense? Alternative way would be just to omit this check alltogether.

I'd not believe this is common in e164.arpa, but than I'd also have thought there's no need for glue in that domain in the first place ...

There were already comments about this; I only have to mention that initial request to support ipv6 glue came from e164.arpa users.

...

2) Glue name must be within the same domain (already listed above)

Yep. And the check should include the presence of mandatory glue RRs.

Definitely.

With a miced v4/v6 environment, would a name server with v6 only glue be accepted (v4 only obviously is)?

It seems sensible to accept v6 only glue. Since the checks for ipv6-only nameserver will be done over IPv6, it should be accepted as long as it works. Again, this could be also implemented to give a warning to make sure this is indeed the intention.

How many glue RRs would be allowed per name server entry?

How many glue RRs per name server entry would you estimate would be needed? Obviously we will take estimation into account when implementing this. Also, from the operational point of view, would this limit be useful, or could it break something? Any feedback on this is also appreciated. Thanks very much for your comments! -- Katie Petrusha RIPE NCC

Dear Katie, On Mon, May 15, 2006 at 11:59:47AM +0200, Katie Petrusha wrote:

...

What's the reason not to use one line per server and list all v4 an/or v6 addresses within that one line?

'One name per line' syntax seemed to be more clear and short...

Hm, I disagree. I'd prefer a syntax like Peter proposes too. It's IMHO more logical to have one line per nameserver, and only list the glue addresses behind it. One nameserver, one line, with n (n >= 0) optional glue addresses. This would be logical and intuitive for me. All else needs more complicated parsing in mind and automated code. Sorry for the late comment, didn't have much time to follow discussions here lately. Feel free to ignore. :-) Best regards, Daniel -- CLUE-RIPE -- Jabber: dr@cluenet.de -- dr@IRCnet -- PGP: 0xA85C8AA0

Peter Koch wrote:

On Mon, May 15, 2006 at 09:02:50AM +0200, Katie Petrusha wrote:

...

We plan to automate management of DNS delegation in the e164.arpa zone (ENUM).

good!

A friendly "Us, too!" on behalf of the ENUM WG Co-Chairs as well. Best, -C.

Katie,

[ipv4_address] is an IPv4 address of the name server

[ipv6_address] is an IPv6 address of the name server

It would be helpful to include details about the accepted syntax for these addresses. For instance: [ipv4_address] is an IPv4 address of the name server in dotted quad form [ipv6_address] is an IPv6 address of the name server in the preferred textual canonical form (Sect 2.2.1, RFC 4291) The IPv6 textual compressed form (Section 2.2.2, RFC 4291) is/is not accepted (cross as necessary). The IPv4/IPv6 textual mixed form (Section 2.2.3, RFC 4291) is/is not accepted (cross as necessary).

nserver: ns1.example.com 168.0.0.1

It would be better to use RFC 3330 documentation IP addresses, e.g. nserver: ns1.example.com 192.0.2.0 Best regards, Marcos P.S. Btw, if non-preferred IPv6 textual forms are accepted, will the output of e.g. whois deliver the original or the preferred form?

On Thu, 2006-05-25 at 10:43 -0700, Doug Barton wrote:

Marcos Sanz/Denic wrote:

...

P.S. Btw, if non-preferred IPv6 textual forms are accepted, will the output of e.g. whois deliver the original or the preferred form?

In my experience this is a good place to apply the principle, "Be liberal in what you accept, and conservative in what you send." It would be more convenient to users if you accepted many different forms of IPv6 address, and more convenient for consumers of the data if those addresses were canonicalized into the full form of the address as in section 2.2.1 of RFC 4291.

As RFC4291, 2.2.1 is not really a section, I assume you mean: 8<---------------------------------------------------- 2.2. Text Representation of Addresses There are three conventional forms for representing IPv6 addresses as text strings: 1. The preferred form is x:x:x:x:x:x:x:x, where the 'x's are one to four hexadecimal digits of the eight 16-bit pieces of the address. Examples: ABCD:EF01:2345:6789:ABCD:EF01:2345:6789 2001:DB8:0:0:8:800:200C:417A Note that it is not necessary to write the leading zeros in an individual field, but there must be at least one numeral in every field (except for the case described in 2.). ----------------------------------------------------->8 And thus when I submit "whois -h whois.ripe.net 2001:0db8:1234/64" it would return an inet6num with (the /48 exists, the /64 doesn't) : 2001:db8:1234::/48 Is that what you meant? From my point of view, what I do is *always* rewrite the addresses to the compressd form and in lowercase (caps are to screamish ;) Greets, Jeroen

On Thu, 2006-05-25 at 11:40 -0700, Doug Barton wrote:

Jeroen Massar wrote:

...

On Thu, 2006-05-25 at 10:43 -0700, Doug Barton wrote:

...

Marcos Sanz/Denic wrote: [..] And thus when I submit "whois -h whois.ripe.net 2001:0db8:1234/64" it would return an inet6num with (the /48 exists, the /64 doesn't) :

2001:db8:1234::/48

Is that what you meant?

No. I was referring specifically to the case at hand, IPv6 addresses used as glue records. In my opinion, having the addresses always be canonicalized to the full form (not the compressed form) is easier to deal with on a number of levels, including db design, and inclusion in the DNS being the most important.

Compressed/uncompressed is a representation method, the parser which reads/exports into/from the database should not give anything about the external representation and can represent it differently internally. If you would argue for uncompressed being easier to parse by a program, then one should maybe better propose to store it completely in binary, hashtrees etc come to mind ;) Programs should use the OS provided, getaddrinfo() and inet_ntop() functions, these afaik on all platforms support any input format and print out usually compressed formats. In case most of the bits of an IPv6 address are used then there is no difference in compressed/uncompressed form, thus there is not much of an argument there for me. In DNS they are represented as 128-bit binary values, thus there is nothing to pick for representation. The tool that reads/writes should do it in a standard way, but there is no way of changing all tools and I've already soon too much that tools do it their own way, not using the OS provided interface or capsing the string etc. In the end for tool writers, as said before, be liberal in what you get -> rewrite the input to what you require. One thing there though, if you query the RIPE database, which I tend to do a lot, inet6num's are always different, even when created by the NCC, the format is sort of the same, but the contents are wildly variating, sometimes in compressed format, otherwise not, sometimes caps, sometimes not. It would be great to have a single format coming out of whois, if that would only help hurt the eyes a bit. Personally though I prefer the compressed form, as that is how I have been representing a lot of IPv6 addresses for a long time now. But as said that is a personal opinion of taste. Thus my 'vote': represent with compressed lowercase. But I could live with uncompressed too, as long as it would be done then also everywhere in a consistent fashion. Most inet6nums are compressed fortunately ;) Greets, Jeroen

On Thu, May 25, 2006 at 03:46:48PM -0700, Doug Barton wrote: Dear colleagues, I have updated the proposal; hopefully all parties are now satisfied with the changes. Please find the proposal below.

...

Thus my 'vote': represent with compressed lowercase. But I could live with uncompressed too, as long as it would be done then also everywhere in a consistent fashion.

On that we are in complete agreement.

Proposal for the change of "nserver:" syntax in "domain" object in the RIPE Whois Database ---------------------------------------------- Motivation: We plan to automate management of DNS delegation in the e164.arpa zone (ENUM). The provisioning system, with the RIPE Database as a front end, must support IPv6 glue records. It must also implement complete and consistent IPv4 glue record support. This will mean making changes to the RIPE Database syntax so that it specifies the glue record and the updated delegation checks. This proposal covers that syntax. Proposal: We suggest changing the syntax of the "nserver:" attribute in DOMAIN objects as follows: nserver: [domain_name] /or/ nserver: [domain_name] [ipv4_address] /or/ nserver: [domain_name] [ipv6_address] where [domain_name] is the fully qualified DNS name of the name server with or without a trailing "." [ipv4_address] is an IPv4 address of the name server, in decimal dotted quad form [ipv6_address] is an IPv6 address of the name server, in lowercase canonical form (Sect 2.2.1, RFC 4291) The IPv6 textual compressed form (Section 2.2.2, RFC 4291) is also accepted (see examples) and will be converted into lowercase canonical form. If [domain_name] is followed by an IP address, it must be inside the domain that is being delegated. Any level of a glue name is supported within the valid domain name syntax. Multiple name server lines will need to be used to specify multiple IP addresses for the same hostname. Examples: The following values would be accepted: domain: example.com nserver: ns1.example.com 192.0.2.1 nserver: ns1.d1.example.com 2001:db8:0:0:0:0:0:0 nserver: ns2.d1.example.com 2001:DB8:: nserver: ns2.d1.example.com 2001:db8:: All other variants of the values will be rejected. End-of-line comments starting with '#' will be still allowed. All IPv6 glue addresses in "nserver:" attribute will be represented in domain objects in the RIPE Whois Database in the lowercase uncompressed form, e.g. 2001:db8:0:0:0:0:0:0. Consequences for existing objects: We will not automatically modify any existing objects. Instead we suggest notifying the maintainers of objects that do not comply with the proposed syntax. This will cover around 150 objects. Consequences for the delegation checks: The introduction of the new syntax will add the following new DNS checks for glue records: * every glue record has at least one IPv4 or IPv6 address specified in domain object (error otherwise) * glue record name is inside the domain to be delegated (error otherwise) * glue nameserver should be authoritative for his own A/AAAA record (error otherwise) -- Katie Petrusha RIPE NCC

On Thu, Jun 01, 2006 at 02:35:24PM +0200, Carsten Schiefner wrote: Thanks Karsten, Posting the corrected proposal below.

Katie,

to avoid any ambiguity in:

Katie Petrusha wrote:

...

The IPv6 textual compressed form (Section 2.2.2, RFC 4291) is also accepted (see examples) and will be converted into lowercase canonical form.

and to also cover:

nserver: ns1.d1.example.com 2001:DB8:0:0:0:0:0:0

besides:

...

nserver: ns1.d1.example.com 2001:db8:0:0:0:0:0:0

I would like to see this paragraph rephrased to:

The IPv6 notation can be case insensitive, the textual compressed form (Section 2.2.2, RFC 4291) is also accepted (see examples). [ipv6_address] will always be converted into lowercase canonical form.

Best,

-C.

Motivation: We plan to automate management of DNS delegation in the e164.arpa zone (ENUM). The provisioning system, with the RIPE Database as a front end, must support IPv6 glue records. It must also implement complete and consistent IPv4 glue record support. This will mean making changes to the RIPE Database syntax so that it specifies the glue record and the updated delegation checks. This proposal covers that syntax. Proposal: We suggest changing the syntax of the "nserver:" attribute in DOMAIN objects as follows: nserver: [domain_name] /or/ nserver: [domain_name] [ipv4_address] /or/ nserver: [domain_name] [ipv6_address] where [domain_name] is the fully qualified DNS name of the name server with or without a trailing "." [ipv4_address] is an IPv4 address of the name server, in decimal dotted quad form [ipv6_address] is an IPv6 address of the name server, in lowercase canonical form (Section 2.2.1, RFC 4291) The IPv6 notation can be case insensitive, the textual compressed form (Section 2.2.2, RFC 4291) is also accepted (see examples). [ipv6_address] will always be converted into lowercase canonical form. If [domain_name] is followed by an IP address, it must be inside the domain that is being delegated. Any level of a glue name is supported within the valid domain name syntax. Multiple name server lines will need to be used to specify multiple IP addresses for the same hostname. Examples: The following values would be allowed: domain: example.com nserver: ns1.example.com 192.0.2.1 nserver: ns1.d1.example.com 2001:db8:0:0:0:0:0:0 nserver: ns2.d1.example.com 2001:DB8:: nserver: ns2.d1.example.com 2001:db8:: All other variants of the values will be rejected. End-of-line comments starting with '#' will be still allowed. All IPv6 glue addresses in "nserver:" attribute will be represented in domain objects in the RIPE Whois Database in the lowercase uncompressed form, i.e. 2001:db8:0:0:0:0:0:0. Consequences for existing objects: We will not automatically modify any existing objects. Instead we suggest notifying the maintainers of objects that do not comply with the proposed syntax. This will cover around 150 objects. Consequences for the delegation checks: The introduction of the new syntax will add the following new DNS checks for glue records: * every glue record has at least one IPv4 or IPv6 address specified in domain object (error otherwise) * glue record name is inside the domain to be delegated (error otherwise) * glue nameserver should be authoritative for his own A/AAAA record (error otherwise) -- Katie Petrusha RIPE NCC

On Thu, Jun 01, 2006 at 03:59:48PM +0200, Carsten Schiefner wrote: Carsten, I've corrected it :) Please find it below.

<NITPICKING>

...

[...]

Examples:

The following values would be allowed:

domain: example.com

nserver: ns1.example.com 192.0.2.1

nserver: ns1.d1.example.com 2001:db8:0:0:0:0:0:0

nserver: ns1.d1.example.com 2001:DB8:0:0:0:0:0:0

...

nserver: ns2.d1.example.com 2001:DB8::

nserver: ns2.d1.example.com 2001:db8::

All other variants of the values will be rejected.

[...] </NITPICKING>

Thanks & best,

-C.

Motivation: We plan to automate management of DNS delegation in the e164.arpa zone (ENUM). The provisioning system, with the RIPE Database as a front end, must support IPv6 glue records. It must also implement complete and consistent IPv4 glue record support. This will mean making changes to the RIPE Database syntax so that it specifies the glue record and the updated delegation checks. This proposal covers that syntax. Proposal: We suggest changing the syntax of the "nserver:" attribute in DOMAIN objects as follows: nserver: [domain_name] /or/ nserver: [domain_name] [ipv4_address] /or/ nserver: [domain_name] [ipv6_address] where [domain_name] is the fully qualified DNS name of the name server with or without a trailing "." [ipv4_address] is an IPv4 address of the name server, in decimal dotted quad form [ipv6_address] is an IPv6 address of the name server, in lowercase canonical form (Section 2.2.1, RFC 4291) The IPv6 notation can be case insensitive, the textual compressed form (Section 2.2.2, RFC 4291) is also accepted (see examples). [ipv6_address] will always be converted into lowercase canonical form. If [domain_name] is followed by an IP address, it must be inside the domain that is being delegated. Any level of a glue name is supported within the valid domain name syntax. Multiple name server lines will need to be used to specify multiple IP addresses for the same hostname. Examples: The following values would be allowed: domain: example.com nserver: ns1.example.com 192.0.2.1 nserver: ns1.d1.example.com 2001:db8:0:0:0:0:0:0 nserver: ns1.d1.example.com 2001:DB8:0:0:0:0:0:0 nserver: ns2.d1.example.com 2001:DB8:: nserver: ns2.d1.example.com 2001:db8:: All other variants of the values will be rejected. End-of-line comments starting with '#' will be still allowed. All IPv6 glue addresses in "nserver:" attribute will be represented in domain objects in the RIPE Whois Database in the lowercase uncompressed form, i.e. 2001:db8:0:0:0:0:0:0. Consequences for existing objects: We will not automatically modify any existing objects. Instead we suggest notifying the maintainers of objects that do not comply with the proposed syntax. This will cover around 150 objects. Consequences for the delegation checks: The introduction of the new syntax will add the following new DNS checks for glue records: * every glue record has at least one IPv4 or IPv6 address specified in domain object (error otherwise) * glue record name is inside the domain to be delegated (error otherwise) * glue nameserver should be authoritative for his own A/AAAA record (error otherwise) -- Katie Petrusha RIPE NCC

On Fri, Jun 02, 2006 at 01:22:47PM +0200, Havard Eidnes wrote: Dear Havard,

it's possible that I've overlooked the real background of this issue, so please forgive me for asking:

...

Motivation:

We plan to automate management of DNS delegation in the e164.arpa zone (ENUM). The provisioning system, with the RIPE Database as a front end, must support IPv6 glue records.

While I can agree that out of completeness it is good to have the support for glue records in the software, I still wonder if anyone has specifically asked for being able to name the name servers for these delegation points within the delegated domain?

Yes, this feature was explicitly requested.

This would be the only real reason for registering the glue information, as otherwise the glue information is not needed, and in fact might be extraneous information more likely to cause confusion and a maintenance problem than actually being helpful. Anyone for a "detect unneeded glue" feature? ;-)

After all, there's a strictly limited number of delegations which the RIPE database software needs to handle.

Regards,

- Håvard

-- Katie Petrusha RIPE NCC

Randy, all - Randy Bush wrote:

...

...

While I can agree that out of completeness it is good to have the support for glue records in the software, I still wonder if anyone has specifically asked for being able to name the name servers for these delegation points within the delegated domain? Yes, this feature was explicitly requested.

perhaps a clue record would be more appropriate?

sorry for being a month late with my answer - that somehow dropped off my table... Wrt. [c|g]lue[ful|less] ENUM delegations: after all it was felt inappropriate to allow ENUM registries to only use certain types of delegation - less for pure technical reasons, but more for ENUM Tier 0/1 intrinsic non-technical reasons. Hope that clarifies the point. Best, Carsten

In my experience this is a good place to apply the principle, "Be

Doug, liberal in

what you accept, and conservative in what you send." It would be more convenient to users if you accepted many different forms of IPv6 address, and more convenient for consumers of the data if those addresses were canonicalized into the full form of the address as in section 2.2.1 of RFC 4291.

I agree. And not only for the consumers, but also for the repository itself (no need to *additionally* store the original textual input, but only a normalized internal representation). Whether the full form address is capitalized or not, I wouldn't mind at this stage. These comments applied originally only to the IPv6 glue of nservers, but as Jeroen pointed out, inet6num objects would benefit from the suggestion, too. Regards, Marcos

On Fri, May 26, 2006 at 09:33:02AM +0100, Jay Daley wrote:

If it helps, in .uk we accept in any format, including dotted quad embedded in ipv6 and always output in compressed lower case. If you want an example see the whois entry for ml-associates.co.uk

just for clarification: you're _not_ accepting "IPv4-Compatible IPv6 Addresses" or "IPv4-Mapped IPv6 Addresses", are you? -Peter

On Fri, May 26, 2006 at 10:17:57AM +0100, Jay Daley wrote:

dotted quad notation. So of the form 2001::0010:192.168.1.1 We had a very long discussion about this with a registrar quoting RFCs back and forth and in the end agreed to do it.

yes, that won't hurt - whatever it's good for. The examples in section 2.2 of RFC 4291 show this format only for ::192.0.2.1 or ::FFFF:192.0.2.1 type addresses (without limiting it explicitly), and I'd rather not accept those. Whether or not the output format should be canonicalized is a different issue. Once you start it, it could be applied elsewhere (strip the trailing dot in domain names, adjust zip codes), but that's more the db wg's business. -Peter