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

[Paul Hoffman]

On Jan 27, 2013, at 5:10 PM, Phil Pennock <getdns-api-phil at spodhuis.org> wrote:

> 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.

I feel like I need to take a shower. But now that you say it, I can believe that they probably exist in non-trivial sample sizes. Will add.

> 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.

Can you be more specific here?

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

You do *not* want the API to evaluate the regexp.

> 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?

That is not prohibited in RFC 2782, and in fact it seems allowed:
            If there is precisely one SRV RR, and its Target is "."
            (the root domain), abort.
To me, that means that there might be more than one SRV RR, where one has a Target of ".".

> 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.

This is not prohibited by 1035, so I don't want to flag it as an error.

> 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.

I do not want the API making decisions that are not encoded in RFCs.

> 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.

I don't want to have the API doing anything that could later restrict protocol changes.

> So my two recommendations:
> * unexpected_ip_address
> * redirection_dot_target_not_alone

Yes to the former, no to the latter unless SRV folks think that it is actually a violation.

--Paul Hoffman