Opened 8 years ago

Closed 8 years ago

#1184 closed defect (duplicate)

Resolver/root_addresses is not used

Reported by: jreed Owned by:
Priority: medium Milestone: Year 3 Task Backlog
Component: resolver Version:
Keywords: Cc:
CVSS Scoring: Parent Tickets:
Sensitive: no Defect Severity: High
Sub-Project: DNS Feature Depending on Ticket:
Estimated Difficulty: 0 Add Hours to Ticket: 0
Total Hours: 0 Internal?: no

Description (last modified by jreed)

Resolver/root_addresses has default of ::1 port 53.

But src/bin/resolver/ has hard-coded addresses (it used to use an f.root address hardcoded in asiolink).

It logs:

2011-08-17 06:17:57.903 WARN  [b10-resolver.resolver] RESOLVER_NO_ROOT_ADDRESS no root addresses available

Attempting to change it fails with:

> config show Resolver/root_addresses
Resolver/root_addresses []      list    (default)
> config add Resolver/root_addresses
> config show Resolver/root_addresses
Resolver/root_addresses[0]/address      "::1"   string  (default)
Resolver/root_addresses[0]/port 53      integer (default)
> config commit
Error: Address must contain both the IPaddress and port
Configuration not committed

Setting both will allow it to commit. (It will not commit with just setting the address.)

I restarted bind10 and it logged my new setting:

2011-08-17 06:28:07.947 INFO  [b10-resolver.resolver] RESOLVER_SET_ROOT_ADDRESS setting root address

But tcpdump still shows it using the hardcoded entry. (In my several attempts, it always starts with the IPv4 address.)

So to fix this ticket I propose:

1) remove the hardcoded addresses from

2) Put the addresses into

Note: Consider at this time to allow root_addresses to contain many addresses, so add all of them now.

(Maybe even add a unused "label" or "name" for each of them so they can be identified. But that doesn't matter to me.)

3) make resolver work for when the Resolver/root_addresses is changed, regardless if port is changed or not.

(I think only a single port is useful, so don't need to allow configurable port per address, but it is fine if we continue this way.)

4) make sure logging is correct. Probably the RESOLVER_NO_ROOT_ADDRESS will never be logged again after this is fixed.


Change History (3)

comment:1 Changed 8 years ago by jreed

  • Description modified (diff)

comment:2 Changed 8 years ago by shane

  • Milestone changed from New Tasks to Year 3 Task Backlog

comment:3 Changed 8 years ago by jreed

  • Resolution set to duplicate
  • Status changed from new to closed

Duplicate of 1073. Added these details there. Closing this one.

Note: See TracTickets for help on using tickets.