domain: object normalization
Hi, I keep on bumping into something with the RIPE database. I'm used to the pedantic trailing dot in hostnames, such as 'www.bit.nl.'; I also always write domains like so: '122.109.193.in-addr.arpa.'. $ whois -h whois.ripe.net 122.109.193.in-addr.arpa. % This is the RIPE Whois server. % The objects are in RPSL format. % % Rights restricted by copyright. % See http://www.ripe.net/ripencc/pub-services/db/copyright.html %ERROR:101: no entries found % % No entries found in the selected source(s). Without the trailing dot, this works just fine. Is it feasable to have the scanner normalize the hostname/domain into something that your backend can look up ? -- Met vriendelijke groet, BIT BV / Ing P.B. van Pelt PBVP1-RIPE (PGPKEY-4DCA7E5E)
On 2004-08-06 11:33:38 +0200, Pim van Pelt wrote:
Hi,
I keep on bumping into something with the RIPE database. I'm used to the pedantic trailing dot in hostnames, such as 'www.bit.nl.'; I also always write domains like so: '122.109.193.in-addr.arpa.'.
$ whois -h whois.ripe.net 122.109.193.in-addr.arpa. % This is the RIPE Whois server. % The objects are in RPSL format. % % Rights restricted by copyright. % See http://www.ripe.net/ripencc/pub-services/db/copyright.html
%ERROR:101: no entries found % % No entries found in the selected source(s).
Without the trailing dot, this works just fine. Is it feasable to have the scanner normalize the hostname/domain into something that your backend can look up ?
Sure, this is straightforward. We do this for IP lookups now, for instance: %WARNING:905: fixed lookup key % % The key "193.0.1" has been changed to "193.0.1.0" for lookup. The server will return a similar warning for these cases: %WARNING:905: fixed lookup key % % The key "122.109.193.in-addr.arpa." has been changed to "122.109.193.in-addr.arpa" for lookup. -- Shane Kerr RIPE NCC
%WARNING:905: fixed lookup key % % The key "193.0.1" has been changed to "193.0.1.0" for lookup.
uh, that should that not be 193.0.0.1?
The server will return a similar warning for these cases:
%WARNING:905: fixed lookup key % % The key "122.109.193.in-addr.arpa." has been changed to "122.109.193.in-addr.arpa" for lookup.
as both 193.0.1 and domains with trailing dots are quite legal syntax, is a warning appropriate? of what are you warning? randy
Randy Bush wrote:
The server will return a similar warning for these cases:
%WARNING:905: fixed lookup key % % The key "122.109.193.in-addr.arpa." has been changed to "122.109.193.in-addr.arpa" for lookup.
as both 193.0.1 and domains with trailing dots are quite legal syntax, is a warning appropriate? of what are you warning?
Would "NOTE:" meet your PoV? -C.
The server will return a similar warning for these cases:
%WARNING:905: fixed lookup key % % The key "122.109.193.in-addr.arpa." has been changed to "122.109.193.in-addr.arpa" for lookup.
as both 193.0.1 and domains with trailing dots are quite legal syntax, is a warning appropriate? of what are you warning?
Would "NOTE:" meet your PoV?
truth is, i have a hard time caring a lot. but the pedant in me asks what you would say if they had entered 192.000.000.001? would that also require constructive criticism or comment? randy
Hi Randy, Randy Bush wrote:
%WARNING:905: fixed lookup key % % The key "193.0.1" has been changed to "193.0.1.0" for lookup.
uh, that should that not be 193.0.0.1?
It probably should be.
The server will return a similar warning for these cases:
%WARNING:905: fixed lookup key % % The key "122.109.193.in-addr.arpa." has been changed to "122.109.193.in-addr.arpa" for lookup.
as both 193.0.1 and domains with trailing dots are quite legal syntax, is a warning appropriate? of what are you warning?
We are warning that people might have made a typo, instead of using another valid form of an address or a name. It also indicates that the actual key in the database is [slightly] different.
randy
Regards, Andrei Robachevsky RIPE NCC
[ old thread, but I've been away ] Andrei Robachevsky wrote:
Hi Randy,
Randy Bush wrote:
%WARNING:905: fixed lookup key % % The key "193.0.1" has been changed to "193.0.1.0" for lookup.
uh, that should that not be 193.0.0.1?
It probably should be.
No, the rules assume that any octets missing are added on as zeros at the end. So: 193/8 becomes 193.0.0.0/8 The engine also sets any non-zero bits to 0 after the CIDR boundary, so: 161.15/14 becomes 161.12.0.0/14 These rules are the same whether the network part is specified or not.
The server will return a similar warning for these cases:
%WARNING:905: fixed lookup key % % The key "122.109.193.in-addr.arpa." has been changed to "122.109.193.in-addr.arpa" for lookup.
as both 193.0.1 and domains with trailing dots are quite legal syntax, is a warning appropriate? of what are you warning?
We are warning that people might have made a typo, instead of using another valid form of an address or a name. It also indicates that the actual key in the database is [slightly] different.
The server outputs these changes as a warning - we found that users would get confused otherwise sometimes, especially in the case where we set bits to zero. -- Shane Kerr RIPE NCC
% The key "193.0.1" has been changed to "193.0.1.0" for lookup. uh, that should that not be 193.0.0.1? It probably should be. No, the rules assume that any octets missing are added on as zeros at the end.
"The rules"? The rules as implemented, obviously. But there are rules under which 193.0.1 is filled out to 193.0.0.1; it sees 193.0 as a network portion and 1 as a host portion, the latter being a single 16-bit number expressed in decimal. (For example, 193.0.12345 would become 193.0.48.57.) I'm sure I found this in some RFC, but I can't recall which one, and some grepping doesn't find it. Perhaps my memory is flaking out, or perhaps I just haven't found the right grep pattern. /~\ The ASCII der Mouse \ / Ribbon Campaign X Against HTML mouse@rodents.montreal.qc.ca / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B
hi, On Thu, Sep 02, 2004 at 12:01:14PM -0400, der Mouse wrote:
% The key "193.0.1" has been changed to "193.0.1.0" for lookup. uh, that should that not be 193.0.0.1? It probably should be. No, the rules assume that any octets missing are added on as zeros at the end.
"The rules"? The rules as implemented, obviously.
Of course - and that's why it's printing a warning: the database cannot lookup the search term "as it was entered", and needs to interpret it - which may or may not be what you would expect. So it tells you what it made of it. (And of course the behaviour can be changed, if there is a strong voice for it in the DB WG - this is what it's for, after all :) ) Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 65398 (60210) SpaceNet AG Mail: netmaster@Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 80807 Muenchen Fax : +49-89-32356-299
%WARNING:905: fixed lookup key % % The key "193.0.1" has been changed to "193.0.1.0" for lookup. uh, that should that not be 193.0.0.1? It probably should be. No, the rules assume that any octets missing are added on as zeros at the end. So:
193/8 becomes 193.0.0.0/8
The engine also sets any non-zero bits to 0 after the CIDR boundary, so:
161.15/14 becomes 161.12.0.0/14
These rules are the same whether the network part is specified or not.
you might want to be a bit more in line with internet standards. apologies for being too off balance here at apnic to give you an exact ref. but 127.1 is 127.0.0.1 etc. randy
The engine also sets any non-zero bits to 0 after the CIDR boundary, so:
161.15/14 becomes 161.12.0.0/14
These rules are the same whether the network part is specified or not.
you might want to be a bit more in line with internet standards. apologies for being too off balance here at apnic to give you an exact ref. but 127.1 is 127.0.0.1 etc.
Randy, you're showing your age. Yes, I know that inet_aton() on most systems interpret IP addresses specified with fewer-than-4 octets the way you indicate, and that this probably has roots down in arcane Internet History. The fact that the BSD documentation for inet_aton() makes explicit reference to class A/B/C networks points to this being a rather old convention. Also, inet_aton() is used to interpret an IP address when it stands alone (i.e. no mask given), which isn't really the case here. However, leaving aside the issue of the exact historical reference, the question remains why it would be a useful convention to adhere to in this particular context. Personally, I think it would add more confusion, because it mixes old classfull rules with classless notation, and would force you to put otherwise needless junk in your lookup string to force the "right" interpretation: in order to look up 161.15.0.0/14, you could not write 161.15/14, because that would become 161.0.0.15/14, so instead you'd have to write e.g. 161.15.1/14, which would become 161.15.0.1/14, which when masked with the prefix, becomes the intended 161.15.0.0/14. Perhaps if you disagree you could explain why this would be useful? There's also something to be said for not rocking the boat, as I think the current implementation has done what it does now for quite a while. Therefore, let's rather stick with the current rules. Regards, - Håvard
On 03.09 09:57, Randy Bush wrote:
you might want to be a bit more in line with internet standards. apologies for being too off balance here at apnic to give you an exact ref. but 127.1 is 127.0.0.1 etc.
The specific behavior of the RIPE database has been agreed in 1994 and is described in ripe-121. The rationale for this behavior is different from inet_aton(); in particular the typical query is for more than one address and often based on a prefix in slash notation. Using inet_aton() behavior was discussed at the time but considered too confusing in combination with prefix notation and thus not appropriate for the application. Harvard explained this already Changing this behavior will not only confuse human users but also break automated processes. I consider this a Bad Idea. Daniel
participants (9)
-
Andrei Robachevsky -
Carsten Schiefner -
Daniel Karrenberg -
der Mouse -
Gert Doering -
Havard Eidnes -
Pim van Pelt -
Randy Bush -
Shane Kerr