Re: [DNSOP] call to work on edns-client-subnet
Barry Margolin pointed out an amusing interaction between two stupid DNS tricks on the bind-users list: https://lists.isc.org/pipermail/bind-users/2014-May/093171.html If you have an authoritative server with ANAME or CNAME flattening support, and the target of the ANAME is a CDN that does source-based answer selection, then the synthetic A / records will be based on the auth server address rather than the client address, unless you have some special arrangement between the auth server and the CDN like edns-client-subnet support. Tony. -- f.anthony.n.finch d...@dotat.at http://dotat.at/ Tyne, Dogger: South or southwest 4 or 5, occasionally 6 later. Slight or moderate. Rain then showers. Good, occasionally poor. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] call to work on edns-client-subnet
Tony Finch wrote: Barry Margolin pointed out an amusing interaction between two stupid DNS tricks on the bind-users list: https://lists.isc.org/pipermail/bind-users/2014-May/093171.html If you have an authoritative server with ANAME or CNAME flattening support, and the target of the ANAME is a CDN that does source-based answer selection, then the synthetic A / records will be based on the auth server address rather than the client address, unless you have some special arrangement between the auth server and the CDN like edns-client-subnet support. madness. this way lies madness. the dns design had moving parts and nonmoving parts. the dns implementation is becoming something else entirely. see also What DNS Is Not https://queue.acm.org/detail.cfm?id=1647302. vixie ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] call to work on edns-client-subnet
Moin! On 08 May 2014, at 17:47, Paul Vixie p...@redbarn.org wrote: Tony Finch wrote: Barry Margolin pointed out an amusing interaction between two stupid DNS tricks on the bind-users list: https://lists.isc.org/pipermail/bind-users/2014-May/093171.html If you have an authoritative server with ANAME or CNAME flattening support, and the target of the ANAME is a CDN that does source-based answer selection, then the synthetic A / records will be based on the auth server address rather than the client address, unless you have some special arrangement between the auth server and the CDN like edns-client-subnet support. madness. this way lies madness. the dns design had moving parts and nonmoving parts. the dns implementation is becoming something else entirely. There is madness, but the madness is in mixing authoritative and recursive functions in one server and not in using DNS to direct traffic. After all that's what all lookups do, give you an IP address you connect to. All of this also is secondary to edns-client-subnet, which is something we should work on IMHO. So long -Ralf ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] call to work on edns-client-subnet
Ralf Weber wrote: ... There is madness, but the madness is in mixing authoritative and recursive functions in one server and not in using DNS to direct traffic. while i'm on record has holding that view, it turns out that RFC 1035 does describe recursion and authority as co-residing in a server. so while this is in my view a dangerous practice and a bad idea, it's well supported by the scriptures. After all that's what all lookups do, give you an IP address you connect to. i don't think so. dns lookups have many purposes unrelated to returning IP addresses. i'd like to see 100 more things like SSHFP this decade. vixie ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] call to work on edns-client-subnet
#1 - support doing the work to finalize the edns-client-subnet standard. now... (I hope my inline response is accepted by the readers of this wg's list, I would note that someone's quoting is all jacked up... oh well) pull up waders On Thu, May 8, 2014 at 12:17 PM, Paul Vixie p...@redbarn.org wrote: Ralf Weber wrote: ... There is madness, but the madness is in mixing authoritative and recursive functions in one server and not in using DNS to direct traffic. It seems, to me at least, that a bunch of the problems with dns 'tricks' which are more than: Oh good, my zone loads! Lookey, I have an A record! what is an A record again? are that folk should not play with sharp knives if they aren't prepared to get cut occasionally. Ideally you understand the implications of tricks like: bind views dns anycast edns-client-subnet etc before you deploy them... That's all beside the point of good documentation being available to support inter-operability between vendor code for these features though. Should the IETF mint a standard for 'feature-X' in the software system that makes up the DNS? Where's the bar used to measure whether or not a feature has critical enough mass/interest to be written up? Should all feature ideas get adopted and then those which prove to wither be permitted to die out before WGLC? while i'm on record has holding that view, it turns out that RFC 1035 does describe recursion and authority as co-residing in a server. so while this is in my view a dangerous practice and a bad idea, it's well supported by the scriptures. After all that's what all lookups do, give you an IP address you connect to. i don't think so. dns lookups have many purposes unrelated to returning IP addresses. i'd like to see 100 more things like SSHFP this decade. ah, so you seem to be in the camp of 'let a thousand flowers bloom' or whatever... that seems like fun as well. Back on topic though, should the edns-client-subnet work get attention and potentially move forward in this WG? -chris ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] call to work on edns-client-subnet
On Thu, May 8, 2014 at 9:15 AM, Ralf Weber d...@fl1ger.de wrote: There is madness, but the madness is in mixing authoritative and recursive functions in one server and not in using DNS to direct traffic. That's a pretty big assumption to jump to. It's pretty unlikely that all ANAME implementors do that, as they'd have significant availability problems. I'd say it's likely that some query the ANAME target periodically and put what they find into the authoritative data store. Of course that's even less compatible with edns-client-subnet, but there you go. -- Colm ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
