Hello Emeric,
On Mon, 2 Nov 2020 at 15:41, Emeric Brun <[email protected]> wrote: > > Hi All, > > We are currently studying to develop a DNS messages load balancer (into > haproxy core) I find this a little surprising given that there already is a great DNS load-balancer out there (dnsdist) from the folks at powerdns and when I look at the status of the haproxy resolver, I don't feel like DNS sparkes a huge amount of developer interest. Loadbalancing DNS will certainly require more attention and enthusiasm than what the resolver code get's today, and even more important: long term maintenance. > After a global pass on RFCs (DNS, DNS over TCP, eDNS, DNSsec ...) we noticed > that practices on DNS have largely evolved > since stone age. > > Since the last brainstorm meeting I had with Baptiste Assmann and Willy > Tarreau, we were attempted to make some > assumptions and choices and we want to submit them to community to have your > thoughts. > > Reading RFCs, I notice multiple fallback cases (if server not support eEDNS > we should retry request without eDNS The edns fallback should be obsolete and has been disabled on the large public resolver on flagday 2019. https://dnsflagday.net/2019/ > or if response is truncated we should retry over TCP This is and always will be very necessary. Deploying the haproxy resolver feature would be a lot less dangerous if we would support this (or make all requests over TCP in the first place). > So we decide to make the assumption that nowadays, all modern DNS servers > support both TCP (and pipelined requests > as defined in rfc 7766) and eDNS. In this case the DNS loadbalancer will > forward messages received from clients in UDP > or TCP (supporting eDNS or not) to server via pipelined TCP conn. That's probably a good idea. You still have to handle all the UDP pain on the frontend though. > In addition, I had a more technical question: eDNS first purpose is clearly > to bypass the 512 bytes limitation of standard DNS over UDP, > but I did'nt find details about usage of eDNS over TCP which seems mandatory > if we want to perform DNSsec (since DNSsec > exloit some eDNS pseudo-header fields). The main question is how to handle > the payload size field of the eDNS pseudo header > if messages are exchanged over TCP. I'm not sure what the RFC specifically says, but I'd say don't send the "UDP payload size" field if the transport is TCP and ignore/filter it when received over TCP. not a dns expert here though, lukas
