Re: [Add] Fwd: New Version Notification for draft-schwartz-svcb-dns-00.txt

[Steffen Nurpmeso <[e-mail]>]

[dropping the DNS only lists i am not subscribed to]

Ben Schwartz wrote in
 <CAHbrMsDtFNDB5TDz=HNejVi_RMbq_8Q6=o6iW_gyDr=[e-mail]>:
 |Hi ADD and DPRIVE,
 |
 |I've noticed three recent drafts that propose to use the SVCB format:
 |draft-mglt-add-rdp, draft-tapril-ns2, and
 |draft-pauly-add-resolver-discovery.  These drafts, across multiple

I do not want to be counterproductive, having read only one of
those drafts, and having read all of DNS except for zone transfer
related RFCs >15 years ago in order to create a caching stub
resolver, but i "like" DNS, and am fascinated of this protocol
that is in use for such a long time, and still scales and is
omnipresent.
-Today- Yesterday i have reread RFC 6763 and RFC 2782 and really
like all of it.  Is there a "benefit in changing established
practice".

  I never liked IDNA, i would have imposed a policy to rise the
  length limit by then, using UTF-8 (or UTF-7, maybe, as still in
  IMAP, though not have read the draft of v2 yet) and as of today
  i would presume all in-use name servers could serve those
  requests, aka even long domain names could be assigned all over
  the world.  Its version 2 introduced the incompatibilities that
  ought to be avoided.

I personally do not see an improvement in introducing yet another
RR in order to support this.  Maybe i should look in bind code or
so and test whether it would be harder to return the favoured or
desired set of RR combinations for a RR type or a question for
a specific SRV.  But even a clause that says "if that RR is
provided HTTPS transport is a MUST" does not justify that for me.
I.e., you could ask for "dnss://" and get A/AAAA for http[123]://
in combination also.  Of course SVCB is more explicit.  But

   o  Address a set of long-standing issues due to HTTP(S) clients
   not implementing support for SRV records, as well as due to
   a limitation that a DNS name can not have both CNAME and NS RRs
   (as is the case for zone apex names))

draft-jennings-http-srv never made it.  _https._tcp is no option
therefore as of today.  I really had to read the possibly one year
plus IETF discussion history on why this did not make it.

But i think the above is unfair, it misses the context.  I could
imagine they did not implement it because it is still unnecessary
as of today in practice, there is /etc/service or an equivalent,
and since port numbers are part of the standards the answer you
get by getservbyname(3) aka getservent(3), as of today, is
sufficient.  It comes from BSD 4.3 or even BSD 4.2 (commit by
Kirk McKusick dating 1985-05-15 says "manual page first
distributed with 4.2BSD", "+.TH GETSERVENT 3N "9 February 1983",
i did not look for code).

And, wow!, this is not far from 40 years!  And it still serves.

Also, HTTP is often accompanied with hypertext aka HTML++, where
URLs are a vivid part, so that special needs for port numbers
etc. can simply be fed into the machinery via href= etc. etc.  And
i think almost everybody who uses the web ("normal users") for
some time "has already seen" port numbers 80, 8080, and
increasingly 443 "sometime".  But especially the former two.

So i do not get your thing above at all.
If, with IPv6 and the IoT, the above does no longer SRV, then what
is missing to SRV, port etc it can all carry along.

  o  Provide an HSTS-like indication signaling for the duration of
  the DNS RR TTL that the HTTPS scheme should be used instead of
  HTTP (see Section 7.6).

I mean that can very well be bundled with anything that needs to
be implemented anew.  But sure, non-S is leaving.

  ...
   1.  Issue parallel AAAA/A and SVCB queries for the name HOST.

Maybe just another reason why this is not yet implemented widely
for such omnipresent things like HTTP.  But noone cares no more
about increasing packet sizes etc., so "just bundling" and getting
more in return without additional roundtrips is surely a nice
thing, EDNS is also 20 years or more.  Just like OCSP stapling
etc., it is just increasingly used (one more thing _i_ have to
do), whereas just a few years ago the additional cost of OCSP was
the reason it was not implemented in a widely used OSS HTTP
server (i use myself).

The draft also talks about "anticipating protocols", therefore
envisions simply replacing the established SRV with this new RR.
You know, i do not like TXT, being explicit is better, but then
again the TXT answers are standardized, so i guess that is ok.
It surely can serve another defined format for SRV.

...

For a different draft, i like the X.509 constraint option for the
"MUD" way of RFC 8520, to resolve the "refrigerator" hang of mine.
From a user point of view i like the idea that all devices
identify themselves "cryptographically save".  Even if all light
bulbs pass the very same client certificate along.  I could
imagine they contact my DHCP/DTLS server, and if i ok the
certificate further connections are allowed to invoke a dhcpcd
hook here, for example.  If the constraints are so that really
nothing more than an URL can be passed along, initiating "MUD" via
DHCP hook i can imagine.  Hard to believe the industry wants to
flood the world with tiny devices which cannot do D?TLS handshakes
aka present at least a X509 certificate.
Here i personally would be fine with just using a subjectAltName
addition or a defined nsComment content, these are available for
a long time.

I only wanted to add this.

--steffen
|
|Der Kragenbaer,                The moon bear,
|der holt sich munter           he cheerfully and one by one
|einen nach dem anderen runter  wa.ks himself off
|(By Robert Gernhardt)