“localhost”.
Stuart Cheshire
[*] If you think it’s stupid to suggest a host might not treat “127.0.0.1” as
meaning loopback, why is that any more stupid than suggesting that a host might
not treat “localhost” as meaning loopback? Both are just as arbitrary
l-dnssd-mdns-relay>
Service Discovery Broker
<https://tools.ietf.org/html/draft-sctl-discovery-broker>
We welcome others to join us at the Hackathon. Please let us know if you’d like
to come along and join in the testing.
Stuart Cheshire
___
DNS
xibility in the specification was to avoid putting
unnecessary constraints on future uses of DSO that we haven’t anticipated yet.
Stuart Cheshire
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
client, what
are the first bytes received over that TCP connection? Are they a DNS header
and message body? Are they a TLS handshake message? Can it be either? How does
the server know?
Stuart Cheshire
___
DNSOP mailing list
DNSOP@ietf.org
https
t message or DSO
unacknowledged message to a server. If a server receives a DNS
request message (i.e., QR=0) where the Primary TLV is the Retry Delay
TLV, this is a fatal error and the server MUST forcibly abort the
connection immediately.
The updated draft is available at:
<https://tools.ietf.org/html/draft-ietf-dnsop-session-signal-07>
Stuart Cheshire
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
ne. Moving forward we expect that most application
protocols that need security will only run over TLS, making this “dual
personality” behavior rare.
Stuart Cheshire
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
of a
given zone implements procedures and controls at a high level."
(Quoted from [RFC6841], Section 2)
I’m unclear on what these mean. Can we add more explanatory text?
These states are
defined in [RFC4033] and [RFC4035], although the two definitions
differ a bit.
Can we elaborate with more details about *how* these definitions differ?
Stuart Cheshire
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
session."
> which indicates that the client may leave the session open longer than
> indicated by the inactive timer of the server. However section 7.1.1 say that
> the client MUST close the connection when the timer is expired.
A connection with
ning robots, which
can be located (as it was in your example), “in the right-upper corner of a
living room.”
Stuart Cheshire
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
-names-problem seems to focus far too
intently on the issue names. (But then, that is what ICANN is in the business
of selling, so maybe it’s not surprising.) The substance of RFC 6761 is about
enabling special behaviours, and using special names to trigger those spe
ction in the DNS Push document, but I
think it would be better to have that specification in the keepalive document.
Thoughts?
Stuart Cheshire
Begin forwarded message:
> From: internet-dra...@ietf.org
> Subject: [dnssd] I-D Action: draft-ietf-dnssd-push-06.txt
> Date: 21 March 2016 at 1
for all DNS servers. Think of it as a
different protocol, that happens to leverage existing DNS protocols and message
formats instead of inventing new protocols and message formats.
The draft explains it in more detail.
DNSOP feedback on the draft would be appreciated.
Stu
if it were a normal DNS
domain name will probably not work as desired, for reasons 4, 5,
and 6 above.
Stuart Cheshire
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
bmit a quick two-page draft describing the usage would
be a wonderful contribution to greater IETF understanding of what’s going on.
Observing that certain weird names are hitting the root name servers is a
useful first step. Understanding *why* that’s happening would be even better.
ETF community, for someone to step forward and tell us
*why* those names are in use, are leaking out to the root name servers, and
what the intended use is for these names. (I assume that “leaking out to the
root name servers and getting NXDOMAIN” is *not* the intended use.
then argue for that. Let’s use this IETF
discussion process to get some clarity on which names are local-use and which
ones are not.
Stuart Cheshire
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
y use .10.in-addr.arpa.
I think human-interface factors make such names a non-starter. The people doing
this want memorable easy-to-type names.
Stuart Cheshire
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
osts them $10/year, say) to use that
home gateway product in their own home. Such products ship today with “.home”
hard-coded into them, and all our pontificating about registration processes is
not going to change that.
Stuart Cheshire
___
DNSOP
18 matches
Mail list logo
