Proposal to change the syntax of "nserver:" attribute
[Apologies for duplicate mails] 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 update the 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 without a trailing "." [ipv4_address] is an IPv4 address of the name server [ipv6_address] is an IPv6 address of the name server If [domain_name] is followed by an IP address, it must be inside the zone 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.test.net 168.0.0.1 nserver: ns1.test.net 0::0 nserver: ns1.example.com nserver: ns1.d1.example.com All other variants of the values will be rejected. End-of-line comments starting with '#' will be still allowed. 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: DNS checks applicable to glue records will be added to the Zone Delegation Checker (http://www.ripe.net/rs/reverse/delcheck/delcheck_descr.html) -- Katie Petrusha RIPE NCC
Hoi Katie, 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.
Thanks for your efforts, -- Met vriendelijke groet, BIT BV / Ing P.B. van Pelt PBVP1-RIPE (PGPKEY-4DCA7E5E)
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! -- Katie Petrusha RIPE NCC
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!
Pim van Pelt wrote:
Hoi Katie,
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.
Thanks for your efforts,
Hi Pim, the trailing '.' has a very spezial meaning. In hostnames it is simply not allowed. So in /etc/hosts you will not find it. If you ask 'name' then /etc/hosts will be the first to answer. If you ask 'name.' then only DNS will answer. Some browsers and all mailer do this. For DNS (the resolver lib) that '.' means this is an FDN. Dont add the search path to it. That is very importan for the Bind DNS server data files. Regards Peter and Karin Dambier -- Peter and Karin Dambier The Public-Root Consortium Graeffstrasse 14 D-64646 Heppenheim +49(6252)671-788 (Telekom) +49(179)108-3978 (O2 Genion) +49(6252)750-308 (VoIP: sipgate.de) mail: peter@peter-dambier.de mail: peter@echnaton.serveftp.com http://iason.site.voila.fr/ https://sourceforge.net/projects/iason/
Mornin' 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!
nserver: [domain_name] /or/ nserver: [domain_name] [ipv4_address] /or/ nserver: [domain_name] [ipv6_address]
What's the reason not to use one line per server and list all v4 an/or v6 addresses within that one line?
If [domain_name] is followed by an IP address, it must be inside the zone that is being delegated. Any level of a glue name is supported within the valid domain name syntax.
<nitpick>s/inside the zone/inside the domain</nitpick>, since one might have a name server even in a deeper zone. _Unless_ however this was meant as a requirement, but then I can't understand the second sentence.
domain: example.com nserver: ns1.test.net 168.0.0.1 nserver: ns1.test.net 0::0 nserver: ns1.example.com nserver: ns1.d1.example.com
That should probably read 'domain: test.net' (or better s/test/example/).
Consequences for the delegation checks:
DNS checks applicable to glue records will be added to the Zone Delegation Checker (http://www.ripe.net/rs/reverse/delcheck/delcheck_descr.html)
Since I've not found the keyword glue on this page, could these checks be circulated to the dns-wg in advance, please? Thanks, Peter
On Mon, May 15, 2006 at 10:30:20AM +0200, Peter Koch wrote: Dear Peter,
nserver: [domain_name] /or/ nserver: [domain_name] [ipv4_address] /or/ nserver: [domain_name] [ipv6_address]
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...
If [domain_name] is followed by an IP address, it must be inside the zone that is being delegated. Any level of a glue name is supported within the valid domain name syntax.
<nitpick>s/inside the zone/inside the domain</nitpick>, since one might have a name server even in a deeper zone. _Unless_ however this was meant as a requirement, but then I can't understand the second sentence.
The intention is to accept something like: domain: test.net nserver: ns1.test.net 168.0.0.1 nserver: ns2.d2.test.net ... etc (glue any level under <domain>, like a.b.c.x.y.z.test.net) 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.
domain: example.com nserver: ns1.test.net 168.0.0.1 nserver: ns1.test.net 0::0 nserver: ns1.example.com nserver: ns1.d1.example.com
That should probably read 'domain: test.net' (or better s/test/example/).
yes.
Consequences for the delegation checks:
DNS checks applicable to glue records will be added to the Zone Delegation Checker (http://www.ripe.net/rs/reverse/delcheck/delcheck_descr.html)
Since I've not found the keyword glue on this page, could these checks be circulated to the dns-wg in advance, please?
All the DNS checks applicable to the 'normal' nameservers currently will be also applied to the glue nameservers. 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 2) Glue name must be within the same domain (already listed above) Hopefully that makes it clear. After getting all the comments and corrections, I can resend the updated version of the proposal. -- Katie Petrusha RIPE NCC
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 15 May 2006, at 14:10, Peter Koch wrote:
e164.arpa, but than I'd also have thought there's no need for glue in that domain in the first place ...
I'm not sure why you'ld think that. One way to do it is like you ppl at DENIC do. 9.4.e164.arpa. 14400 IN NS enum1.denic.de. 9.4.e164.arpa. 14400 IN NS enum2.denic.de. 9.4.e164.arpa. 14400 IN NS enum3.denic.de. It's not the only way. 4.4.e164.arpa. 14400 IN NS ns2.4.4.e164.arpa. 4.4.e164.arpa. 14400 IN NS ns3.4.4.e164.arpa. 4.4.e164.arpa. 14400 IN NS ns4.4.4.e164.arpa. 4.4.e164.arpa. 14400 IN NS ns1.4.4.e164.arpa. Here is even a mixture. 3.5.3.e164.arpa. 14400 IN NS enum1.eu.afilias.info. 3.5.3.e164.arpa. 14400 IN NS ns01.3.5.3.e164.arpa. 3.5.3.e164.arpa. 14400 IN NS ns02.3.5.3.e164.arpa. Some people see the second method as "cleaner". This will need glue. /Niall
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
Hi, {I keep copying the db-wg on this DNS issue not to split the thread. db chairs, pls advise privately} On Tue, May 16, 2006 at 12:13:53PM +0200, Katie Petrusha wrote:
... 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?
Well, in this particular constellation I'd assume the names "glued" are not generic anyway, so after some going back and forth my suggestion is to simply require that the name be authoritatively served from that server. E.g. dns1.9.9.e164.arpa and dns2.0.9.9.e164.arpa should be able to answer queries for A/AAAA RRs for their respective names authoritatively.
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.
Sure, my remark was not meant to challenge these demands, just that things you never believe to happen in practice eventually will happen :-)
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.
Me personally does not "believe" in multi-homed name servers, but I'd really like to read other's opinions. -Peter
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
On Fri, Jun 02, 2006 at 10:51:17AM +0200, Daniel Roesen wrote: Dear Daniel, Thanks for your input. From the delegation checker point of view, every pair "<name> <IP>" is treated as a separate entity, undergoing its own checks, hence my preference for the syntax that reflects this. However if anybody else has strong preferences for either variant of the syntax, please let us know, so we could wrap this discussion up and send final proposal.
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
-- Katie Petrusha RIPE NCC
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.
On Mon, May 15, 2006 at 09:02:50AM +0200, Katie Petrusha wrote: Dear colleagues, [Apologies for duplicate mails] As I've got no further feedback, I am sending below the corrected version of the proposal with all the comments taken into account. Please comment on if something is not clear or wrong. ------------- 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 [ipv6_address] is an IPv6 address of the name server 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 168.0.0.1 nserver: ns1.d1.example.com 0::0 All other variants of the values will be rejected. End-of-line comments starting with '#' will be still allowed. 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 * glue record name is inside the domain to be delegated -- Katie Petrusha RIPE NCC
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?
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. IMHO, Doug -- If you're never wrong, you're not trying hard enough
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
Jeroen Massar wrote:
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
As RFC4291, 2.2.1 is not really a section,
I was using the same notation that Marcos had used. And yes, that was what I was referring to.
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.
From my point of view, what I do is *always* rewrite the addresses to the compressd form and in lowercase (caps are to screamish ;)
I definitely agree with lowercasing the addresses. hth, Doug -- If you're never wrong, you're not trying hard enough
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
Jeroen Massar wrote:
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.
Assuming all elements of your argument above are correct, I believe that this supports my suggestion. If you can deal with the addresses programatically regardless of the storage method, this is an argument (in my mind/experience) for storing them in a consistent, lowest common denominator format (read, human-parsable), such as the full, uncompressed form.
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.
Yes, this is exactly the kind of problem I'd like to see avoided, given that this part of the db must be rewritten anyway.
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. Regards, Doug -- If you're never wrong, you're not trying hard enough
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
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.
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
Hi Katie. <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.
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
Hi, 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? 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
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
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? randy
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
participants (10)
-
Carsten Schiefner -
Daniel Roesen -
Doug Barton -
Havard Eidnes -
Jeroen Massar -
Katie Petrusha -
Marcos Sanz/Denic -
Niall O'Reilly -
Peter Dambier -
Peter Koch -
Pim van Pelt -
Randy Bush -
Wilfried Woeber, UniVie/ACOnet