Re: [DNSOP] abandoning ANAME and standardizing CNAME at apex

[Warren Kumari <[e-mail]>]

On Fri, Jun 22, 2018 at 3:13 PM Mukund Sivaraman <[e-mail]> 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 <[e-mail]> wrote:
> >
> > > On 19 Jun 2018, at 17:03, Ray Bellis <[e-mail]> 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