This archive is retained to ensure existing URLs remain functional. It will not contain any emails sent to this mailing list after July 1, 2024. For all messages, including those sent before and after this date, please visit the new location of the archive at https://mailman.ripe.net/archives/list/[email protected]/
[ncc-services-wg] Proposal: optimized rev-DNS operations
- Previous message (by thread): [ncc-services-wg] Proposal: optimized rev-DNS operations
- Next message (by thread): [ncc-services-wg] Proposal: optimized rev-DNS operations
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Jim Reid
jim at rfc1035.com
Fri Oct 25 01:19:10 CEST 2019
> On 24 Oct 2019, at 22:22, Kurt Kayser <kurt_kayser at gmx.de> wrote: > > please have a look at a new proposal: > > Purpose: optimize Reverse-DNS operations > > 1. Assumption: There is a ton of negative reverse-DNS replies (no PTR-record/NXDOMAIN) returned from the RIPE NCC rev-DNS-Servers, for all not-yet-delegated address-blocks they are responsible for (also called “lame” delegations ?). Nope. A lame delegation occurs when the parent has NS records for some child zone and the targets of those NS records are not authoritative for the child zone. If you’re getting NXDOMAIN responses, these are coming from authoritative servers. Therefore those answers cannot be the result of lame delegations. > 2. Question: How could this be optimized or at least encouraged to be fixed? First you need to define the problem you think needs to be fixed. Then what you mean by optimise. Neither of these things are clear. > There should be NO information about WHO requested rev-DNS values or when. Just a simple, aggregated summary of top requested addresses/blocks. Fair enough, but why? Producing more statistics is generally a good thing, provided it serves a useful purpose that people need/want or fixes a genuine problem. That purpose seems to be missing from your suggestion. At best it’s unclear. > 3. In case a member opts-in to view such statistics, one could decide to actively reply to such reverse-DNS requests and instead offer “good results” for requests, the address owners would never would see. That’s a bad idea. Sorry. First off, who is going to opt-in to view such statistics and why? What practical good will it do them? Of course it’s nice to know zone A gets X queries and zone B gets Y. But what real-world benefits does that provide? And why only for NCC members? They’re by no means the only people doing lookups on reverse zones that are co-ordinated by the NCC or hosted on the NCC's DNS servers. Next, are you *really* suggesting people should specially configure their name servers to give bogus answers (or “good results”) for reverse zones held by someone else? Please think of the consequences and the potential for mischief. Not to mention the extra administrative and operational overheads someone will have provisioning and maintaining their (faked) private copies of those zones. It’s hard enough for many address holders to do reverse DNS properly for their own address space. Do you think they’d choose to do that for somebody else’s address space? And get it right? You should also consider that some address holders have made a conscious decision to leave their reverse zones empty, especially for v6 space. Why second guess their motives? If those reverse zones/delegations are signed, your locally-faked zones are not going to validate. That could create serious operational problems. In such circumstances an NXDOMAIN from the real name servers instead of a SERVFAIL from the fake ones would a much, much better outcome. To get around that I suppose you could create even worse configuration and provisioning problems by faking trust anchors for the pretend copies of someone else’s zones. Yuk! > 4. As a result: better performance, less errors through better infomation for RIR-members. Nope. At best you might shave ~50ms off an initial lookup from a local resolver which goes to a local (bogus) name server instead of a real one sitting in someone else’s network. After that, the usual DNS benefits of caching and negative caching will kick in. I'm not sure what errors would be reduced either or why that matters. An NXDOMAIN response is not necessarily an error. It says “the name/qtype/class you looked up doesn’t exist”. Which might well be the truth rather than a mistake by some DNS administrator. That definitive response from the true source may well be more important than a faked answer from a non-definitive DNS server. BTW, what’s your definition of "better information”? That’s not clear either. There don’t appear to be any useful performance benefits or worthwhile reasons to take this idea forward. At least, not yet. Therefore I do not support this proposal. That said, there might be some value in asking the NCC to produce more statistics about its reverse DNS infrastructure. Maybe that could be a topic for a separate policy proposal. If you are minded to pursue your idea, I suggest you start in the DNS Working Group. That will be the best place to get help on how to define problem statements and use cases and then analyse possible solutions for DNS-related stuff. Once that is done, you might end up with something concrete that could be turned into a policy (either here or in the DNS WG) for the NCC to implement. RIPE’s DNS expertise is concentrated in the DNS WG, though some of it lurks in this WG. IMO there’s nothing in your proposal for the NCC Services WG to consider. At present it’s far too immature. A lot more work needs to be done first, some of it in the DNS WG. Note too that many of the questions above are rhetorical. You don’t need to immediately answer them here. Though they will need to be answered and clarified if/when there’s further work on your suggestion and a clearer policy proposal starts to emerge.
- Previous message (by thread): [ncc-services-wg] Proposal: optimized rev-DNS operations
- Next message (by thread): [ncc-services-wg] Proposal: optimized rev-DNS operations
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]