[getdns-api] Adding an extension to highlight common DNS errors

[Phil Pennock]

On 2013-01-27 at 08:48 -0800, Paul Hoffman wrote:
> Now I am thinking of adding an extension called
> "add_warning_for_broken_dns" that would add the name "broken_dns" (a
> list) to an element in the replies_tree when it finds one or more DNS
> errors. One value in that list would be "CNAME as target". What might
> others be?

IP address as hostname field in MX record.

IP address as NS hostname field.  As AFSDB hostname field.

There's a theme there: expected value type mismatch, IP incorrectly
given, but folks often expect it to work anyway.  Which ties into the
CNAME too.

Invalid regex in NAPTR?  Or would that just never be followed, so never
be an issue?

SRV RRset which combines a target of "." (not available at this domain)
with other targets != ".".  In this case, the work-around is to skip the
"." records from the response?

Although not formally standardised (AFAICR), there's a de facto standard
that MX records use the same rule for ". means not offered" as SRV
records, so the same check for MX too.

I suspect that, by contrast, an SRV record with a port of 0 given a host
might mean something special in a given protocol and it's up to the
application to skip those records instead of trying to send packets, and
the API should not disable those by default.  It's not a DNS error, it's
a semantic value error.

If folks disagree then:

  Speakers of a protocol which uses SRV to include a host record but not
  specify an endpoint for a connection are doing something "weird" and
  should set an option?  In which case, beware that port 0 is acceptable
  (and normal) when the target is ".".

  But if you're going that semantically deep, then IP addresses of
  0.0.0.0 are also bad, normally, and a client might argue those should
  be filtered too.  In the interest of drawing a line somewhere, and not
  hard-coding extensive knowledge of addresses (eg, _tcp SRV record with
  a name which resolves into multicast), it seems sanest to declare all
  of these the responsibility of the caller to check, and so also allow
  through SRV records with a port of 0

which is all an argument for leaving ports of 0 and IPs of 0.0.0.0 well
enough alone, it's not a DNS error.  It might be appropriate for the
documentation, when describing the filtering, to include a warning and a
reminder to the application developer that they still need to not
blindly trust DNS responses and, for security reasons, apply their own
filters on what values are acceptable.


So my two recommendations:
 * unexpected_ip_address
 * redirection_dot_target_not_alone

-Phil