Hi Conrad! I hope you're fine.
sorry to revive this very old thread, but I was wondering if there is still > interest in this, now that the DNS subsystem has been refactored? > Of course we do :) > I was looking at implementing SRV records and noticed that the default UDP > message size of 512 has even become a build-time constant now, so the patch > would need some additional work, but I'd be happy to do so if you'd still > be open to merging it. > > I think I did it like this because, for now we don't announce in the request we do support longer responses. So we can support up to 4096 bytes responses (maybe more) if we send the appropriate request. I did a first (incomplete) implementation about SRV records, and I think we should open a thread on the mailing list to discuss about it. You can find it here: https://www.bedis9.net/static/0010-WIP-MINOR-dns-processing-of-SRV-record-types-TODO.patch (it's old, I don't know if it still applies, but you get the idea) > As another point of interest, many of our production systems DNS responses > don't fit into a UDP packet anymore, so we have to rely on TCP fallback a > lot. Would such a thing have any chance of getting merged? Or would there > be fundamental concerns with that approach? I mean, it could of course be > made opt-in only for example... > That definitively makes sense. I can't say now transport connection layer should be "hardcoded" (I mean either TCP or UDP set by configuration without any failover) or if a failover could be managed by HAProxy at runtime based on response content. It remembers me I should update and publish the diagram showing the relation between the structures involved in the DNS resolver. This will be useful for you if you want to implement the TCP stuff :) I'm clearly very open to this type of feature, because I guess that some other people will have the same requirements. Please note that for now, we are limited to 16KB (or a tune.bufsize) to parse the DNS response. Do you think this is enough? Thanks a lot, > Conrad > > Thanks to you! Baptiste > > On 07/03/2016 09:05 PM, Baptiste wrote: > >> It's very nice having support for EDNS0, but IMHO it shouldn't be > >> enabled by default if it doesn't fallback. > > > > Hi Remi, > > > > My intention was to not enable this feature by default. > > > > Baptiste > > > > -- > Conrad Hoffmann > Traffic Engineer > > SoundCloud Ltd. | Rheinsberger Str. 76/77, 10115 Berlin, Germany > > Managing Director: Alexander Ljung | Incorporated in England & Wales > with Company No. 6343600 | Local Branch Office | AG Charlottenburg | > HRB 110657B >
