On Fri, Jun 22, 2018 at 3:13 PM Mukund Sivaraman <m...@mukund.org> wrote:
> On Fri, Jun 22, 2018 at 03:02:35PM -0400, Warren Kumari wrote: > > On Fri, Jun 22, 2018 at 8:57 AM Joe Abley <jab...@automagic.org> wrote: > > > > > On 19 Jun 2018, at 17:03, Ray Bellis <r...@bellis.me.uk> wrote: > > > > > > > On 19/06/2018 17:44, Tony Finch wrote: > > > > > > > >> SRV should have been part of the fix (and it was invented early > > > >> enough to be!) but it wasn't a complete fix without support from the > > > >> application protocols. > > > > > > > > AIUI, a large part of the supposed issue with SRV was the inertia of > the > > > > installed base of browsers that wouldn't know how to access them. > > > > > > > > Ironically the proposed fix seems to require upgrades to the > > > > installed base of one of the most important network infrastructure > > > > services on the planet. > > > > > > > > Meanwhile, a very large portion of the installed base of web browsers > > > > gets automatically and silently upgraded every month or so... > > > > > > I think so long as there's a fallback for clients that don't yet have > SRV > > > implemented (e.g. publish A/AAAA RRSets at the same owner name as the > SRV > > > RRSet, and specify the behaviour by SRV-compliant servers in the event > that > > > both are present) this is not a plausible engineering argument. > > > > > > Processing an SRV might require additional DNS lookups to get name -> > SRV > > > -> SRV target -> address, but that's a one-time hit per TTL and I think > > > it's a stretch to paint that as definitely a problem. Modelling is > required > > > and worst cases remain to be understood. > > > > > > > It certainly is the case that a number of browser / large web > properties > > have stated that an additional DNS lookup is a price that they are not > > willing to pay, especially for something not "critical". > > > > I believe that this also would require firing off simultaneous lookups > for > > SRV along with the A and AAAA (or, even worse, firing off a SRV, waiting > > for the "nooerror" error and *then* trying for the A / AAAA) and waiting > > for the long tail before you even know of you need to resolve the target. > > With additional-from-cache (default on), BIND will return address of > target of SRV if it is already in cache. The second RTT will get > amortized. It won't take a lot to make it fetch and return the target > too, if it isn't found in cache. > > Ah, fair nuff. I had tested this against a local bind instance, but didn't think to manually trigger the target lookup to get it into the cache. After doing so, it does indeed stuff it in the additional section. I'm not sure if my host (OS X) will make use of it, but that's a local issue... W dig -t srv _xmpp-server._tcp.crab.im ; <<>> DiG 9.11.1-P3 <<>> -t srv _xmpp-server._tcp.crab.im ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 56937 ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 4, ADDITIONAL: 5 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4096 ; COOKIE: 93617acb30a0870d29a435625b2d4c107cbf4333363923bb (good) ;; QUESTION SECTION: ;_xmpp-server._tcp.crab.im. IN SRV ;; ANSWER SECTION: _xmpp-server._tcp.crab.im. 300 IN SRV 10 0 5269 malganis.fleshless.org. ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4096 ; COOKIE: d54c5241ef721df5f76b0d7e5b2d4c188a89ef7e1293b2c4 (good) ;; QUESTION SECTION: ;_xmpp-server._tcp.crab.im. IN SRV ;; ANSWER SECTION: _xmpp-server._tcp.crab.im. 292 IN SRV 10 0 5269 malganis.fleshless.org. ;; AUTHORITY SECTION: crab.im. 259191 IN NS ns1lmy.name.com. crab.im. 259191 IN NS ns4htz.name.com. crab.im. 259191 IN NS ns3cgw.name.com. crab.im. 259191 IN NS ns2fkr.name.com. ;; ADDITIONAL SECTION: ns1lmy.name.com. 292 IN A 162.88.61.47 ns2fkr.name.com. 292 IN A 162.88.60.47 ns3cgw.name.com. 292 IN A 162.88.61.49 ns4htz.name.com. 292 IN A 162.88.60.49 ;; Query time: 1 msec ;; SERVER: 127.0.0.1#53(127.0.0.1) ;; WHEN: Fri Jun 22 15:20:56 EDT 2018 ;; MSG SIZE rcvd: 280 root@ron[0]:/etc/namedb# dig -t srv _xmpp-server._tcp.crab.im @localhost ; <<>> DiG 9.11.1-P3 <<>> -t srv _xmpp-server._tcp.crab.im @localhost ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 64703 ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 512 ;; QUESTION SECTION: ;malganis.fleshless.org. IN A ;; ANSWER SECTION: malganis.fleshless.org. 299 IN A 176.9.22.146 ;; Query time: 110 msec ;; SERVER: 8.8.8.8#53(8.8.8.8) ;; WHEN: Fri Jun 22 15:21:51 EDT 2018 ;; MSG SIZE rcvd: 67 root@ron[0]:/etc/namedb# dig -t srv _xmpp-server._tcp.crab.im @localhost ; <<>> DiG 9.11.1-P3 <<>> -t srv _xmpp-server._tcp.crab.im @localhost ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 47059 ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 4, ADDITIONAL: 6 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4096 ; COOKIE: 58159e9daff595240cd3d0d45b2d4c53ea5cc1bb748254a9 (good) ;; QUESTION SECTION: ;_xmpp-server._tcp.crab.im. IN SRV ;; ANSWER SECTION: _xmpp-server._tcp.crab.im. 233 IN SRV 10 0 5269 malganis.fleshless.org. ;; AUTHORITY SECTION: crab.im. 259132 IN NS ns2fkr.name.com. crab.im. 259132 IN NS ns3cgw.name.com. crab.im. 259132 IN NS ns1lmy.name.com. crab.im. 259132 IN NS ns4htz.name.com. ;; ADDITIONAL SECTION: malganis.fleshless.org. 295 IN A 176.9.22.146 ns1lmy.name.com. 233 IN A 162.88.61.47 ns2fkr.name.com. 233 IN A 162.88.60.47 ns3cgw.name.com. 233 IN A 162.88.61.49 ns4htz.name.com. 233 IN A 162.88.60.49 ;; Query time: 0 msec ;; SERVER: 127.0.0.1#53(127.0.0.1) ;; WHEN: Fri Jun 22 15:21:55 EDT 2018 ;; MSG SIZE rcvd: 296 > [muks@jurassic ~]$ dig -t srv _xmpp-server._tcp.conference.banu.com > > ; <<>> DiG 9.11.3-RedHat-9.11.3-4.fc27 <<>> -t srv _xmpp-server._ > tcp.conference.banu.com > ;; global options: +cmd > ;; Got answer: > ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 42270 > ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 4 > > ;; OPT PSEUDOSECTION: > ; EDNS: version: 0, flags:; udp: 4096 > ; COOKIE: 0578a97e07ef62a47b1993205b2d491527ff6b5b4672bea0 (good) > ;; QUESTION SECTION: > ;_xmpp-server._tcp.conference.banu.com. IN SRV > > ;; ANSWER SECTION: > _xmpp-server._tcp.conference.banu.com. 3543 IN SRV 0 0 5269 > jabber.banu.com. > > ;; AUTHORITY SECTION: > banu.com. 3003 IN NS ns2.akira.org. > banu.com. 3003 IN NS ns1.banu.com. > > ;; ADDITIONAL SECTION: > jabber.banu.com. 3599 IN A 46.4.129.229 > ns2.akira.org. 3004 IN A 46.4.129.253 > ns1.banu.com. 3003 IN A 46.4.83.135 > > ;; Query time: 0 msec > ;; SERVER: 127.0.0.1#53(127.0.0.1) > ;; WHEN: Sat Jun 23 00:38:05 IST 2018 > ;; MSG SIZE rcvd: 222 > > [muks@jurassic ~]$ > > Mukund > -- I don't think the execution is relevant when it was obviously a bad idea in the first place. This is like putting rabid weasels in your pants, and later expressing regret at having chosen those particular rabid weasels and that pair of pants. ---maf
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
