Syntax of the "nserver:" Attribute in Domain Objects
[Apologies for duplicate emails] Dear colleagues, Following on from the removal of the forward DOMAIN objects from the RIPE Database, all DOMAIN objects are now used for either reverse DNS or ENUM delegations. For both these cases, the "nserver:" attribute is required. Currently this attribute is optional and there are many objects in the RIPE Database that do not have any "nserver:" attributes. These objects are ignored by the DNS provisioning service, because they have no operational value. The RIPE NCC proposes to make the "nserver:" attribute mandatory in DOMAIN objects and delete any objects from the RIPE Database that do not have this attribute. To simplify the parsing of DOMAIN objects, the RIPE NCC also proposes to deprecate the list option on the "nserver:" attribute (a list, when used in combination with end-of-line comments and continuation lines, is very complex to parse). This means adding multiple name servers to a single attribute will no longer be allowed. For example, an attribute currently formatted as: nserver: ns1.example.com ns2.example.net will have to be rewritten as: nserver: ns1.example.com nserver: ns2.example.net If glue records are required, they would be written like this: nserver: ns1.2.0.192.in-addr.arpa 192.0.2.1 nserver: ns1.2.0.192.in-addr.arpa 2001:db8::1 nserver: ns2.2.0.192.in-addr.arpa 192.0.2.2 nserver: ns2.2.0.192.in-addr.arpa 2001:db8::2 There are a number of domain objects in the RIPE Database which use the list feature, and list multiple name servers in a single "nserver:" attribute. As part of this syntax change, we would update these objects to use the new syntax. This would not affect DNS delegation in any way. This message has been sent to both the DNS and Database working groups, but we ask that discussion of this matter be kept on the DNS WG mailing list. Regards, Anand Buddhdev RIPE NCC
On Fri, Jul 27, 2012 at 02:57:57PM +0200, Anand Buddhdev wrote:
The RIPE NCC proposes to make the "nserver:" attribute mandatory in DOMAIN objects and delete any objects from the RIPE Database that do not have this attribute.
{no hats} For domain objects covering the reverse space, I believe this makes sense. For ENUM (for those who remember), this might be different due to layer 9 involvement. Numbers are small, though and I do not recall a non-delegation entry precedent.
To simplify the parsing of DOMAIN objects, the RIPE NCC also proposes to deprecate the list option on the "nserver:" attribute (a list, when used in combination with end-of-line comments and continuation lines, is very complex to parse). This means adding multiple name servers to a single attribute will no longer be allowed. For example, an attribute currently formatted as:
nserver: ns1.example.com ns2.example.net
will have to be rewritten as:
nserver: ns1.example.com nserver: ns2.example.net
If glue records are required, they would be written like this:
nserver: ns1.2.0.192.in-addr.arpa 192.0.2.1 nserver: ns1.2.0.192.in-addr.arpa 2001:db8::1 nserver: ns2.2.0.192.in-addr.arpa 192.0.2.2 nserver: ns2.2.0.192.in-addr.arpa 2001:db8::2
While I agree with the first move, I do not see the beauty in the second. It would appear more natural to me to list all IP addresses on a single line after the name server's name. -Peter
On Aug 20 2012, Peter Koch wrote:
On Fri, Jul 27, 2012 at 02:57:57PM +0200, Anand Buddhdev wrote: [...snip...]
If glue records are required, they would be written like this:
nserver: ns1.2.0.192.in-addr.arpa 192.0.2.1 nserver: ns1.2.0.192.in-addr.arpa 2001:db8::1 nserver: ns2.2.0.192.in-addr.arpa 192.0.2.2 nserver: ns2.2.0.192.in-addr.arpa 2001:db8::2
While I agree with the first move, I do not see the beauty in the second. It would appear more natural to me to list all IP addresses on a single line after the name server's name.
AOL :-) Although I have never had to use glue in our reverse domain delegations (it is perhaps a bit perverse to give NSs names in the reverse tree at all), I have been trying to nudge our forward zone providers towards thinking of the glue IPs for one NS as a *set*, rather than denormalised in the style of Anand's text. Without any notable success so far... :-( -- Chris Thompson University of Cambridge Computing Service, Email: cet1@ucs.cam.ac.uk New Museums Site, Cambridge CB2 3QH, Phone: +44 1223 334715 United Kingdom.
Peter Koch wrote: [...]
If glue records are required, they would be written like this:
nserver: ns1.2.0.192.in-addr.arpa 192.0.2.1 nserver: ns1.2.0.192.in-addr.arpa 2001:db8::1 nserver: ns2.2.0.192.in-addr.arpa 192.0.2.2 nserver: ns2.2.0.192.in-addr.arpa 2001:db8::2
While I agree with the first move, I do not see the beauty in the second.
Well, I guess it takes Anand to describe the motivations for the changes, but from a SW point of view, it might be a tad more "beautiful" to move away from lists in the tag:value pairs. this *might* make parsing cleaner. OTOH, unless implicitely required by business rules or otherwise, I presume it would be allowed to submit nserver: ns1.2.0.192.in-addr.arpa 192.0.2.1 nserver: ns2.2.0.192.in-addr.arpa 2001:db8::2 nserver: ns1.2.0.192.in-addr.arpa 2001:db8::1 nserver: ns2.2.0.192.in-addr.arpa 2001:db8::2 or any other permutations? Leading to complex value gathering code again...
It would appear more natural to me to list all IP addresses on a single line after the name server's name.
-Peter
Wilfried
On 21/08/2012 10:28, Wilfried Woeber, UniVie/ACOnet wrote: Hi Peter, Wilfried,
Well, I guess it takes Anand to describe the motivations for the changes, but from a SW point of view, it might be a tad more "beautiful" to move away from lists in the tag:value pairs. this *might* make parsing cleaner.
Simple attribute:value pairs are indeed easier to parse in code. At the moment, the syntax allows for lists in nserver: attributes, so a user could, in theory, submit something like this: nserver: ns1.example.com # first name server 192.0.2.1 # IPv4 address of name server 2001:db8::1 # IPv6 address of name server ns2.example.com 192.0.2.2 2001:db8::2 # name server and glue together This is quite complex to parse, because the code has to deal with the comments and continuation lines, and then try to make sense of what is a name server and what is glue in that single line. There are currently 599900 domain objects in the RIPE Database, of which only 18 use the list syntax in nserver attributes. We have to maintain extra code just to deal with these, so we would really like it if the syntax were restricted to simple attribute:value pairs.
OTOH, unless implicitely required by business rules or otherwise, I presume it would be allowed to submit
nserver: ns1.2.0.192.in-addr.arpa 192.0.2.1 nserver: ns2.2.0.192.in-addr.arpa 2001:db8::2 nserver: ns1.2.0.192.in-addr.arpa 2001:db8::1 nserver: ns2.2.0.192.in-addr.arpa 2001:db8::2
or any other permutations? Leading to complex value gathering code again...
Yes, this would of course be allowed. The code to handle these would simply transform each line into the following DNS records: ns1.2.0.192.in-addr.arpa 172800 IN A 192.0.2.1 ns2.2.0.192.in-addr.arpa 172800 IN AAAA 2001:db8::2 ns1.2.0.192.in-addr.arpa 172800 IN AAAA 2001:db8::1 ns2.2.0.192.in-addr.arpa 172800 IN AAAA 2001:db8::2 In a DNS zone, the order of the records does not matter, and the DNS server into which this zone is loaded will handle it (duplicates would be discarded too). The code to turn such nserver attributes into DNS records is not at all complex.
It would appear more natural to me to list all IP addresses on a single line after the name server's name.
This does look more natural. However, we'd have to write code to expect the following: nserver: ns1.example.com <addr1> <addr2> ... <addrN> This is easier to parse than the current list syntax, but code would still have to transform this into appropriate records for delegation testing and eventual delegation. We still prefer the simple syntax of: nserver: name <optional address> However, we're quite eager to hear from our users to see what they think. Regards, Anand Buddhdev RIPE NCC
Hi Anand, Anand Buddhdev wrote:
On 21/08/2012 10:28, Wilfried Woeber, UniVie/ACOnet wrote:
Hi Peter, Wilfried,
Well, I guess it takes Anand to describe the motivations for the changes, but from a SW point of view, it might be a tad more "beautiful" to move away from lists in the tag:value pairs. this *might* make parsing cleaner.
Simple attribute:value pairs are indeed easier to parse in code. At the moment, the syntax allows for lists in nserver: attributes, so a user could, in theory, submit something like this:
nserver: ns1.example.com # first name server 192.0.2.1 # IPv4 address of name server 2001:db8::1 # IPv6 address of name server ns2.example.com 192.0.2.2 2001:db8::2 # name server and glue together
I didn't even think about that possibility :-)
This is quite complex to parse, because the code has to deal with the comments and continuation lines, and then try to make sense of what is a name server and what is glue in that single line.
There are currently 599900 domain objects in the RIPE Database, of which only 18 use the list syntax in nserver attributes. We have to maintain extra code just to deal with these, so we would really like it if the syntax were restricted to simple attribute:value pairs.
This settles it for me.
OTOH, unless implicitely required by business rules or otherwise, I presume it would be allowed to submit
nserver: ns1.2.0.192.in-addr.arpa 192.0.2.1 nserver: ns2.2.0.192.in-addr.arpa 2001:db8::2 nserver: ns1.2.0.192.in-addr.arpa 2001:db8::1 nserver: ns2.2.0.192.in-addr.arpa 2001:db8::2
or any other permutations? Leading to complex value gathering code again...
Yes, this would of course be allowed. The code to handle these would simply transform each line into the following DNS records:
ns1.2.0.192.in-addr.arpa 172800 IN A 192.0.2.1 ns2.2.0.192.in-addr.arpa 172800 IN AAAA 2001:db8::2 ns1.2.0.192.in-addr.arpa 172800 IN AAAA 2001:db8::1 ns2.2.0.192.in-addr.arpa 172800 IN AAAA 2001:db8::2
ACK, I was making up complexity in my mind which isn't necessary.
In a DNS zone, the order of the records does not matter, and the DNS server into which this zone is loaded will handle it (duplicates would be discarded too). The code to turn such nserver attributes into DNS records is not at all complex.
It would appear more natural to me to list all IP addresses on a single line after the name server's name.
This does look more natural. However, we'd have to write code to expect the following:
nserver: ns1.example.com <addr1> <addr2> ... <addrN>
This is easier to parse than the current list syntax, but code would still have to transform this into appropriate records for delegation testing and eventual delegation.
We still prefer the simple syntax of:
nserver: name <optional address>
However, we're quite eager to hear from our users to see what they think.
Of course.
Regards,
Anand Buddhdev RIPE NCC
Wilfried (not wearing any hats, writing just as an LIR Manager)
On Tue, Aug 21, 2012 at 12:48:49PM +0200, Anand Buddhdev wrote:
ns1.2.0.192.in-addr.arpa 172800 IN A 192.0.2.1 ns2.2.0.192.in-addr.arpa 172800 IN AAAA 2001:db8::2 ns1.2.0.192.in-addr.arpa 172800 IN AAAA 2001:db8::1 ns2.2.0.192.in-addr.arpa 172800 IN AAAA 2001:db8::2
In a DNS zone, the order of the records does not matter, and the DNS server into which this zone is loaded will handle it (duplicates would be discarded too). The code to turn such nserver attributes into DNS records is not at all complex.
are you suggesting that the above should be valid, just because subsequent DNS zone processing would eliminate the duplicate?
This does look more natural. However, we'd have to write code to expect the following:
nserver: ns1.example.com <addr1> <addr2> ... <addrN>
This is easier to parse than the current list syntax, but code would still have to transform this into appropriate records for delegation testing and eventual delegation.
Indeed, but what is the issue?
We still prefer the simple syntax of:
nserver: name <optional address>
I was under the impression that the objects in the RIPE DB have semantics in and of themselves, not just exist as syntactic glue (no pun) for the provisioning system. That makes me think the reasoning is a bit backwards. I won't die over this, but let me say that on a meta level i sense a shift in engineering paradigms that may be more indicative of my aging than a worrying trend.
However, we're quite eager to hear from our users to see what they think.
It would ineed be helpful if more members of the community contributed here. -Peter
Apart from the argument about syntax, what are (or will be) the rules about whether glue is required or not? That is: are in-domain nserver attributes required to specify at least one IP address? And are IP addresses for not-in-domain nserver attributes illegal? or ignored? In theory, at least, there is the always awkward question of "sibling glue", as in domain: 1.168.192.in-addr.arpa nserver: ns.2.168,192.in-addr.arpa [an-IP-address?] domain: 2.168.192.in-addr.arpa nserver: ns.1.168.192.in-addr.arpa [an-IP-address?] whose nserver attributes are individually not-in-domain. -- Chris Thompson University of Cambridge Computing Service, Email: cet1@ucs.cam.ac.uk New Museums Site, Cambridge CB2 3QH, Phone: +44 1223 334715 United Kingdom.
participants (4)
-
Anand Buddhdev -
Chris Thompson -
Peter Koch -
Wilfried Woeber, UniVie/ACOnet