Hi Lukas, > 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.
Thanks for this comment :) >> 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/ > Good to know, It confirms basic DNS is from stone age. >> 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. Exactly, not all UDP pain, fallbacks will be handled by clients :) (handle this on backend side would be the worst pain) > >> 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. payload size field is part of the pseudo header def, we can't wipe this, but it would be a kind of "maximum message size" thing in case of TCP I suppose. > not a dns expert here though, Really appreciate. R, Emeric
