Pdns: dnsdist: Allow RDATA access

[enilfodne]

• Program: dnsdist
• Issue type: Feature request

Short description

dnsdist is really flexible and provides a lot of functionality, but it seems that it can't iterate over a dns response's records. This may be useful for security, traffic optimization, auditing and various other use-cases.

Usecase

I would like to add RFC1918 filtering, in order to prevent dns-rebinding attacks.

Description

With the proposed changes, dns-rebind in dnsdist might look like:

-- define RFC1918 ranges
rfc1918 = newNMG()
rfc1918:addMask("10.0.0.0/8")
rfc1918:addMask("172.16.0.0/12")
rfc1918:addMask("192.168.0.0/16")

function preventDNSRebind(dr)
    for record in dr.response do
        if rfc1918:match(record.rdata) then
            return DNSResponseAction.Drop, ''
        end
    end

    return DNSResponseAction.None, ""
end

addLuaResponseAction(RCodeRule(dnsdist.NOERROR), preventDNSRebind)

_Note: If you're planning on implementing this, you should know that Plex uses RFC1918 addresses, in order to issue valid x509 certificates to their clients._

[zeha]

2 cents:

1) this sample conveniently leaves out the fact that there might be more than one qtype in the response, which doesn't even have to be an A.
2) i think parsing replies in general is out, but giving access to the full dns packet parsed with a dr:parseData() method might be acceptable?

[Habbie]

You can already do this in the Recursor today.

[enilfodne]

this sample conveniently leaves out the fact that there might be more than one qtype in the response, which doesn't even have to be an A.

The sample is not valid code anyway, its just some pseudocode thrown together. Proper parsing/filtering is TBD if/when its even possible to access the response.

i think parsing replies in general is out, but giving access to the full dns packet parsed with a dr:parseData() method might be acceptable?

Do you know why this is the case? AFAICS there's access to the response headers, why would the contents be any different?

I think there's something similar to what i would like to see, but its just not exposed through an API. Of course its for logging purposes, but the functionality is there.

You can already do this in the Recursor today.

Thanks for the heads-up.

[rgacogne]

Do you know why this is the case? AFAICS there's access to the response headers, why would the contents be any different?

We try hard not to parse the response in dnsdist, because it has a huge performance impact and exposes a lot of code to parse all the DNS record types. We do some parsing for features like protobuf when we need to, but it's limited to a few types and is only done for some responses.

We could implement a way to request the parsing of responses from Lua like suggested by @zeha, exposing the name, type, class, TTL and raw content of records to Lua and perhaps also some helpers to deal with raw content for some types like A or AAAA, but we will most likely never have the kind of knowledge about records that the recursor has

[dimaslv]

RDATA access will also allow to make some kind of split horizon.
For example, to drop all responses with private addresses in RDATA.

[ZAZmaster]

I join the question. I'd like to get this functionality to filter the response of private addresses!