At Mon, 03 Aug 2009 08:02:40 +0200, Florian Weimer <f...@deneb.enyo.de> wrote:
> > What does a recursive server that implements the DNS redirect service > > do in this case? > > Empty responses are typically rewritten. Okay, then what about the followup question? >> If it's the latter, what if only one of A and AAAA answers is empty >> (which is actually today's common situation)? I've quickly tested it against OpenDNS. Its server seems to behave as follows: 1. if the query name has A but no AAAA, it returns an empty answer for a AAAA query 2. if the query name has AAAA but no A, it returns a "lied" A for an A query (while returning a correct answer for a AAAA query) Aside from the point that any weird thing could happen with such a server in the first place, case #2 is more problematic because a dual stack end host may not be able to connect to an IPv6-only web server that the host could otherwise, depending on the destination address selection algorithm in the host. > > then I guess authoritative server implementors who don't like > > NXDOMAIN redirect could introduce a "auto-site-finder" option, > > defaulting to yes, which automatically adds a wildcard name (of some > > meaningless RR type) at the apex of each authoritative zone:-) > > I don't think this trick will work. Why not? Because (1) the "redirect" (or "lying") server does/will also redirect an empty response as I've seen above? Or (2) because it's less likely that we can make consensus about preserving empty responses? Or (3) because it's less likely that even with such an IETF-wide consensus the service providers will ignore it to keep the revenue they can get from the "redirection" trick? Or (4) because authoritative zone administrators will dislike this option and disable it anyway? Or (5) other purely technical reason? If it's (3), I see it. But if that's our conclusion even with the (IMO) clearer technical problem than that of simple NXDOMAIN redirection (i.e., we may not reach the intended server with empty response redirection while we can't reach the "intended" server in the NXDOMAIN case with or without redirection anyway), I personally don't see a point to keep discussing this draft, at least about the "web error redirect" part. I thought the general sense within this group to keep the discussion was that "providers will do whatever they want, no matter what the IETF states, but we can at least make it 'less harmful' by publishing a guideline document". Now if we even give up making it 'less harmful', I don't see a point in publishing a 'current practice' document and would rather spend time on "draft-arends-dns- response-modification-considered-harmful-00." --- JINMEI, Tatuya Internet Systems Consortium, Inc. _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
