Better recognize IPv6 address primitives in the JSON like format

[bortzmeyer]

A comment in the sample stubby configuration file says
"IPv6 addresses ending in :: are not yet supported (use ::0)". But it
is also true for addresses STARTING in '::'.

'0::1' is accepted, but
'::1' triggers a very unhelpful "Could not parse config file [...] Generic error".

[keltia]

127.0.0.1@8053 generates the same error here.

[zyrill]

@keltia Are you sure you've configured everything correctly?
The following works for me:

• 127.0.0.1@453
• 0::1@453
• 192.168.66.1@453

[keltia]

Here is what I get with my stubby.yaml file.

364 [20:45] roberto@lonrach:local/etc> stubby -C /usr/local/etc/stubby.yaml
Could not parse config file # Specifies whether to run as a recursive or stub resolver
# For stubby this MUST be set to GETDNS_RESOLUTION_STUB
resolution_type: GETDNS_RESOLUTION_STUB

dns_transport_list:
  - GETDNS_TRANSPORT_TLS

listen_addresses:
  - 127.0.0.1@8053

upstream_recursive_servers:
# Quad9
  - address_data: 9.9.9.9
    tls_auth_name: "dns.quad9.net"
  - address_data: 2620:fe::fe
    tls_auth_name: "dns.quad9.net"
, "Generic error"
Could not parse config file "/usr/local/etc/stubby.yaml": Generic error

What is interesting is that if I use the default stubby.yml file, it works.

[ArchangeGabriel]

You’ve likely made a typo in the file. Can you share the raw stubby.yaml file?

[zyrill]

The Quad9 stuff is wrong. Delete it.

[keltia]

Here is the entire file.

# Specifies whether to run as a recursive or stub resolver
# For stubby this MUST be set to GETDNS_RESOLUTION_STUB
resolution_type: GETDNS_RESOLUTION_STUB

dns_transport_list:
  - GETDNS_TRANSPORT_TLS

listen_addresses:
  - 127.0.0.1@8053

upstream_recursive_servers:
# Quad9
  - address_data: 9.9.9.9
    tls_auth_name: "dns.quad9.net"
  - address_data: 2620:fe::fe
    tls_auth_name: "dns.quad9.net"

[zyrill]

see above. Delete Quad9 and use one of the provided servers that comes with the example file.

[keltia]

@zyrill the whole point is to use Quad9 :)

[bortzmeyer]

@zyrill You're clearly wrong. I use this configuration file and it works:

listen_addresses:
  - 0::1@8053
# https://github.com/getdnsapi/getdns/issues/358

dns_transport_list:
  - GETDNS_TRANSPORT_TLS

upstream_recursive_servers:
# Quad9
   - address_data: 9.9.9.9
     tls_auth_name: "dns.quad9.net"
   - address_data: 2620:fe::fe
     tls_auth_name: "dns.quad9.net"

[zyrill]

Rly... interesting. I used those and since there weren't any keys provided, the config check said invalid. Must have been using it wrong. I hope there's going to be better documentation - I obviously don't understand well enough how to use it.

[hanvinke]

I think it is just the extension - if I rename my working stubby.yml file to stubby.yaml I too get a generic error:
stubby -C /usr/etc/stubby/stubby.yaml

, "Generic error"
Could not parse config file "/usr/etc/stubby/stubby.yaml": Generic error

[keltia]

Ok, if I rename the file as stubby.yml it works. I'll dig into this.

I do not see the point of line https://github.com/getdnsapi/stubby/blob/a43be56e28f3a802f74b7c5b19b4b4c5fbaa908a/src/stubby.c#L270. Why would you care whether it is named .yml or not? If it parse as YAML, fine.

[wtoorop]

Well... Stubby parsed its configuration in a JSON like format before we had parsing in YAML format.
So to not break backwards compatibility and to make the distinction between JSON and YAML we decided to test for filename extension. The default config filenames end in .yml, so that is where the inflexibility in filename extension came from. Addressed in this commit getdnsapi/stubby@70832ecc
Thanks for discovering and reporting!

[keltia]

Thanks for the commit. Maybe the error message needs to be more specific?