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.
[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
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
