[DBWG] Malformed changed: fields in route: objects

[Yogesh]

Dear DGWG members,

 

We have worked on a fix to correct the malformed 'changed' attributes and we have implemented validation of the e-mail address to prevent similar problems in the AFRINIC database.

 

This issue will be resolved after the next scheduled deployment, on Tuesday 27 July 2021. You may it follow on https://status.afrinic.net/.

 

Best regards,

Yogesh Chadee

 

 

From: Yogesh Chadee <yogesh at afrinic.net> 
Sent: Monday, 19 July 2021 18:17
To: dbwg at afrinic.net
Subject: Re: [DBWG] Malformed changed: fields in route: objects

 

Hi,

 

Thank you very much for reporting this. The software engineering team will look into this bug immediately and correct it.

 

Kind regards,

Yogesh Chadee

 

From: Ronald F. Guilmette <mailto:rfg at tristatelogic.com> 
Sent: Sunday, 11 July 2021 07:23
To: hostmaster at afrinic.net <mailto:hostmaster at afrinic.net> ; dbwg at afrinic.net <mailto:dbwg at afrinic.net> 
Subject: [DBWG] Malformed changed: fields in route: objects

 

I am attempting to parse the contents of the changed: fields within

the route and route6 objects that are present in the redacted form of

the AFRINIC WHOIS data base that is available via FTP.  (The unredacted

form of the data base is still being pointlessly withiheld from legitimate

researchers such as myself, so I am obliged to work only with the redacted

form of the data base.)

 

The general form of any given changed: field within the data base appears

to be:

 

     changed:   email-address date

 

This simple format would be easy enough to parse with consistant results

if it were not for the two facts that (1) some few nitwits were allowed

to enter email addresses of the form:

 

     email-address<mailto:email-address>

 

combined with that fact that (2) AFRINIC's redaction process, via which

the redacted version of the data base is gnerated and placed onto AFRINIC's

FTP server apparently becomes confused by the above style of malformed

email addresses, with the result being that the content of (malformed)

changed: fields become truncated at the @ (at-sign) that appears within

the <mailto:XXX> part of these malformed changed: lines.  Thus, within

the redacted WHOIS data base, the lines in question end up looking like

this:

 

      changed:        ***@viva.co.zm <mailto:***@viva.co.zm%3cmailto:asif> <mailto:asif

 

Obviously, it is not pssoble to obtain the relevant date stamp in these

cases, because it has been improperly redacted out by AFRINIC's WHOIS

redaction process.

 

The affected IPv4 route objects are as follows:

 

routesum: 102.140.124.0/22 [328328] - Missing or malformed changed: field

routesum: 102.140.120.0/23 [328328] - Missing or malformed changed: field

routesum: 102.140.122.0/23 [328328] - Missing or malformed changed: field

routesum: 102.140.124.0/23 [328328] - Missing or malformed changed: field

routesum: 102.140.126.0/23 [328328] - Missing or malformed changed: field

routesum: 102.140.120.0/24 [328328] - Missing or malformed changed: field

routesum: 102.140.121.0/24 [328328] - Missing or malformed changed: field

routesum: 102.140.122.0/24 [328328] - Missing or malformed changed: field

routesum: 102.140.123.0/24 [328328] - Missing or malformed changed: field

routesum: 102.140.124.0/24 [328328] - Missing or malformed changed: field

routesum: 102.140.125.0/24 [328328] - Missing or malformed changed: field

routesum: 102.140.126.0/24 [328328] - Missing or malformed changed: field

routesum: 102.140.127.0/24 [328328] - Missing or malformed changed: field

routesum: 102.223.168.0/22 [328581] - Missing or malformed changed: field

 

In the case of IPv6 routes, only the following single IPv6 route object is

affected by this problem:

 

route6sum: 2c0f:ec88::/32 [328328] - Missing or malformed changed: field

 

It would be helpful if the hostmaster would correct the form and content of

all of the above malformed route objects.

 

It would also be helpful if the hostmaster would take whatever steps may

be necessary in order to insure that this type of prooblem does not creap

back into the data base in the future, i.e. by pre-filtering the email

addresses that will ultimately be placed into changed: lines in the data

base and by pre-checking them for reasonable and consistant syntactic form.

 

 

Regards,

rfg

 

_______________________________________________

DBWG mailing list

DBWG at afrinic.net <mailto:DBWG at afrinic.net> 

https://lists.afrinic.net/mailman/listinfo/dbwg

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.afrinic.net/pipermail/dbwg/attachments/20210723/6442b1c2/attachment.html>