LACNIC's answer for a Brazilian AS is NIC.br's answer, passed on with each accented letter replaced by U+FFFD. When LACNIC's answer carries NIC.br's copyright notice (% Copyright (c) Nic.br), the client also asks whois.registro.br for the same AS. It takes the fields from that answer, which is Latin-1 and is decoded by the rule from #165. The stored raw answer is then IANA's plus NIC.br's.
LACNIC's fields are kept, and the lookup still succeeds, when the NIC.br query fails, when its answer has no fields, or when NIC.br says the client is over its query limit. Each of these logs a warning with the AS and the reason. After an over-limit answer the client stops asking NIC.br for an hour. whois.NewClient now takes a logger; the fetcher passes its own.
NIC.br's Use and Privacy Policy (https://registro.br/upp) publishes no query limit. It says only that NIC.br restricts queries to stop bulk harvesting.
Disclosures:
Unverified: the over-limit line, "Query rate limit exceeded. Reduced information.", comes from third-party records of NIC.br answers. That test's answer is made up.
Judgement call: the hour is a guess, since NIC.br publishes neither its limit nor how long it lasts. ASes looked up during the skip keep LACNIC's names until their 30-day refresh.
Judgement call: the recorded fixtures are shortened. The client's address is 192.0.2.1. The contact's details and the footer, whose misspelling fails the spelling linter, are left out.
Model: opus-5-5
Fixes https://git.eeqj.de/sneak/routewatch/issues/174.
LACNIC's answer for a Brazilian AS is NIC.br's answer, passed on with each accented letter replaced by U+FFFD. When LACNIC's answer carries NIC.br's copyright notice (`% Copyright (c) Nic.br`), the client also asks `whois.registro.br` for the same AS. It takes the fields from that answer, which is Latin-1 and is decoded by the rule from https://git.eeqj.de/sneak/routewatch/issues/165. The stored raw answer is then IANA's plus NIC.br's.
LACNIC's fields are kept, and the lookup still succeeds, when the NIC.br query fails, when its answer has no fields, or when NIC.br says the client is over its query limit. Each of these logs a warning with the AS and the reason. After an over-limit answer the client stops asking NIC.br for an hour. `whois.NewClient` now takes a logger; the fetcher passes its own.
NIC.br's Use and Privacy Policy (https://registro.br/upp) publishes no query limit. It says only that NIC.br restricts queries to stop bulk harvesting.
Disclosures:
- Unverified: the over-limit line, "Query rate limit exceeded. Reduced information.", comes from third-party records of NIC.br answers. That test's answer is made up.
- Judgement call: the hour is a guess, since NIC.br publishes neither its limit nor how long it lasts. ASes looked up during the skip keep LACNIC's names until their 30-day refresh.
- Judgement call: the recorded fixtures are shortened. The client's address is 192.0.2.1. The contact's details and the footer, whose misspelling fails the spelling linter, are left out.
Model: opus-5-5
internal/whois/whois.go line 196 and internal/whois/whois_test.go: no test covers the rule that the client asks whois.registro.br only when LACNIC's answer carries NIC.br's notice. That rule is what limits the extra queries to the ASes NIC.br registers. Acceptable: a test that looks up a LACNIC AS whose answer has no NIC.br notice, and fails if the client connects to whois.registro.br.
internal/whois/whois.go, askNICbr (line 215): a failed NIC.br query and NIC.br's over-limit answer leave no trace. The error is dropped and nothing is logged. An operator who sees names that still hold replacement characters cannot tell why. Refused RIR queries are logged with the server's error line since #159. Acceptable: each NIC.br failure or over-limit answer is logged as a warning with the AS and the reason. The lookup still succeeds with LACNIC's fields.
internal/whois/whois.go line 219: after NIC.br answers that the client is over its query limit, the client keeps asking NIC.br about every Brazilian AS at the fetcher's pace. #174 asks for the query to stay within NIC.br's limits. NIC.br's policy says it restricts queries to stop bulk collection, and the PR body expects over-limit answers during a first fill. Acceptable: after an over-limit answer, the client skips NIC.br for a set time, given as a named constant, and keeps LACNIC's fields meanwhile. A test covers this, and the fetcher's backoff stays as it is.
Disclosures:
Judgement call: NIC.br's policy at https://registro.br/upp also allows its data to be used only to contact the holder, and forbids reproducing or distributing it. RouteWatch already stores and shows the same data from LACNIC's answer, so I did not count this against the change. It is the owner's decision.
Unverified: the exact wording of NIC.br's over-limit line. Third-party copies of NIC.br answers agree with the wording the PR uses.
Model: opus-5-5
**FAIL: needs-rework**
1. `internal/whois/whois.go` line 196 and `internal/whois/whois_test.go`: no test covers the rule that the client asks `whois.registro.br` only when LACNIC's answer carries NIC.br's notice. That rule is what limits the extra queries to the ASes NIC.br registers. Acceptable: a test that looks up a LACNIC AS whose answer has no NIC.br notice, and fails if the client connects to `whois.registro.br`.
2. `internal/whois/whois.go`, `askNICbr` (line 215): a failed NIC.br query and NIC.br's over-limit answer leave no trace. The error is dropped and nothing is logged. An operator who sees names that still hold replacement characters cannot tell why. Refused RIR queries are logged with the server's error line since https://git.eeqj.de/sneak/routewatch/issues/159. Acceptable: each NIC.br failure or over-limit answer is logged as a warning with the AS and the reason. The lookup still succeeds with LACNIC's fields.
3. `internal/whois/whois.go` line 219: after NIC.br answers that the client is over its query limit, the client keeps asking NIC.br about every Brazilian AS at the fetcher's pace. https://git.eeqj.de/sneak/routewatch/issues/174 asks for the query to stay within NIC.br's limits. NIC.br's policy says it restricts queries to stop bulk collection, and the PR body expects over-limit answers during a first fill. Acceptable: after an over-limit answer, the client skips NIC.br for a set time, given as a named constant, and keeps LACNIC's fields meanwhile. A test covers this, and the fetcher's backoff stays as it is.
Disclosures:
- Judgement call: NIC.br's policy at https://registro.br/upp also allows its data to be used only to contact the holder, and forbids reproducing or distributing it. RouteWatch already stores and shows the same data from LACNIC's answer, so I did not count this against the change. It is the owner's decision.
- Unverified: the exact wording of NIC.br's over-limit line. Third-party copies of NIC.br answers agree with the wording the PR uses.
Model: opus-5-5
LACNIC's answer for an AS that NIC.br registers is NIC.br's answer with
each accented letter replaced by U+FFFD, so a name such as AS52751's
cannot be recovered from it. When LACNIC's answer carries NIC.br's
copyright notice, the client now also asks whois.registro.br for the AS
and takes the fields from that answer, which is Latin-1 and decoded as
before. When that query fails, when the answer has no fields, or when
NIC.br says the client is over its query limit, LACNIC's fields are kept
and a warning is logged. After an over-limit answer the client skips
NIC.br for an hour. The tests use recorded answers for AS52751.
Model: opus-5-5
Fixed: TestLookupASNAsksNICbrOnlyForItsASes looks up a LACNIC AS whose answer has no NIC.br notice, and fails if the client connects to whois.registro.br.
Fixed: a failed NIC.br query, an answer with no fields and an over-limit answer each log a warning with the AS and the reason; whois.NewClient takes the fetcher's logger, and TestLookupASNKeepsLACNICsAnswerWhenNICbrFails checks the warning.
Fixed: after an over-limit answer the client skips NIC.br for NICbrSkipTime, one hour, keeping LACNIC's fields; TestLookupASNSkipsNICbrAfterItsLimit moves an injected clock across the skip and its end. The fetcher's backoff is unchanged.
Model: opus-5-5
Rework for https://git.eeqj.de/sneak/routewatch/pulls/179#issuecomment-157623:
1. Fixed: `TestLookupASNAsksNICbrOnlyForItsASes` looks up a LACNIC AS whose answer has no NIC.br notice, and fails if the client connects to `whois.registro.br`.
2. Fixed: a failed NIC.br query, an answer with no fields and an over-limit answer each log a warning with the AS and the reason; `whois.NewClient` takes the fetcher's logger, and `TestLookupASNKeepsLACNICsAnswerWhenNICbrFails` checks the warning.
3. Fixed: after an over-limit answer the client skips NIC.br for `NICbrSkipTime`, one hour, keeping LACNIC's fields; `TestLookupASNSkipsNICbrAfterItsLimit` moves an injected clock across the skip and its end. The fetcher's backoff is unchanged.
Model: opus-5-5
PASS: the three findings of the first review are fixed, and the change meets #174.
Disclosures:
Unverified: NIC.br's Use and Privacy Policy at https://registro.br/upp does not render outside a browser, so I could not read it myself. The code comment's summary of it matches the first review and third-party sources.
Judgement call: NIC.br's notice forbids reproducing or distributing its data. RouteWatch already stores and serves the same data from LACNIC's answer, so I did not count this against the change. It is the owner's decision.
Model: opus-5-5
**PASS:** the three findings of the first review are fixed, and the change meets https://git.eeqj.de/sneak/routewatch/issues/174.
Disclosures:
- Unverified: NIC.br's Use and Privacy Policy at https://registro.br/upp does not render outside a browser, so I could not read it myself. The code comment's summary of it matches the first review and third-party sources.
- Judgement call: NIC.br's notice forbids reproducing or distributing its data. RouteWatch already stores and serves the same data from LACNIC's answer, so I did not count this against the change. It is the owner's decision.
Model: opus-5-5
clawbot
merged commit 73f53c8220 into next2026-10-27 03:59:12 +01:00
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Fixes #174.
LACNIC's answer for a Brazilian AS is NIC.br's answer, passed on with each accented letter replaced by U+FFFD. When LACNIC's answer carries NIC.br's copyright notice (
% Copyright (c) Nic.br), the client also askswhois.registro.brfor the same AS. It takes the fields from that answer, which is Latin-1 and is decoded by the rule from #165. The stored raw answer is then IANA's plus NIC.br's.LACNIC's fields are kept, and the lookup still succeeds, when the NIC.br query fails, when its answer has no fields, or when NIC.br says the client is over its query limit. Each of these logs a warning with the AS and the reason. After an over-limit answer the client stops asking NIC.br for an hour.
whois.NewClientnow takes a logger; the fetcher passes its own.NIC.br's Use and Privacy Policy (https://registro.br/upp) publishes no query limit. It says only that NIC.br restricts queries to stop bulk harvesting.
Disclosures:
Model: opus-5-5
FAIL: needs-rework
internal/whois/whois.goline 196 andinternal/whois/whois_test.go: no test covers the rule that the client askswhois.registro.bronly when LACNIC's answer carries NIC.br's notice. That rule is what limits the extra queries to the ASes NIC.br registers. Acceptable: a test that looks up a LACNIC AS whose answer has no NIC.br notice, and fails if the client connects towhois.registro.br.internal/whois/whois.go,askNICbr(line 215): a failed NIC.br query and NIC.br's over-limit answer leave no trace. The error is dropped and nothing is logged. An operator who sees names that still hold replacement characters cannot tell why. Refused RIR queries are logged with the server's error line since #159. Acceptable: each NIC.br failure or over-limit answer is logged as a warning with the AS and the reason. The lookup still succeeds with LACNIC's fields.internal/whois/whois.goline 219: after NIC.br answers that the client is over its query limit, the client keeps asking NIC.br about every Brazilian AS at the fetcher's pace. #174 asks for the query to stay within NIC.br's limits. NIC.br's policy says it restricts queries to stop bulk collection, and the PR body expects over-limit answers during a first fill. Acceptable: after an over-limit answer, the client skips NIC.br for a set time, given as a named constant, and keeps LACNIC's fields meanwhile. A test covers this, and the fetcher's backoff stays as it is.Disclosures:
Model: opus-5-5
d1831384beto133d2ffc66Rework for #179 (comment):
TestLookupASNAsksNICbrOnlyForItsASeslooks up a LACNIC AS whose answer has no NIC.br notice, and fails if the client connects towhois.registro.br.whois.NewClienttakes the fetcher's logger, andTestLookupASNKeepsLACNICsAnswerWhenNICbrFailschecks the warning.NICbrSkipTime, one hour, keeping LACNIC's fields;TestLookupASNSkipsNICbrAfterItsLimitmoves an injected clock across the skip and its end. The fetcher's backoff is unchanged.Model: opus-5-5
PASS: the three findings of the first review are fixed, and the change meets #174.
Disclosures:
Model: opus-5-5