Re: [DNSOP] Mirja Kühlewind's Discuss on draft-ietf-dnsop-session-signal-12: (with DISCUSS and COMMENT)
ceived. A client cannot refuse to send keep-alives. A connection with an active mDNS relay subscription is never considered “inactive”, but a server may still require reasonable keep-alives to verify that the client is still there. > 3) There is another contraction regarding the inactive timer: > Sec 6.2 say > "A shorter inactivity timeout with a longer keepalive interval signals > to the client that it should not speculatively keep an inactive DSO > Session open for very long without reason, but when it does have an > active reason to keep a DSO Session open, it doesn't need to be > sending an aggressive level of keepalive traffic to maintain that > 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 an active mDNS relay subscription is never considered “inactive”, because there is still active client/server state, even if no traffic is flowing. A server may still require reasonable keep-alives to verify that the client is still there. Stuart Cheshire ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Status of draft-ietf-dnsop-terminology-bis
might inadvertently also include any NS records that appear in the zone What does “inadvertently” mean? Inadvertently how? Closest provable encloser: "The longest ancestor of a name that can be proven to exist. Note that this is only different from the Would it be informative to say, “that can be *cryptographically* proven to exist” ? Fast flux DNS: ... It is often used to deliver malware. Is this the whole story? I think short TTLs are also used to achive load balancing. The name “www.google.com” has a short TTL, but that’s not so that it can deliver malware. Reverse DNS, reverse lookup: "The process of mapping an address to a I would add that this is *not* IQUERY. During 2000, the abbreviation was redesignated to 'Address and Routing Parameter Area' in the hope of reducing confusion with the earlier network name." This is mysterious and unenlightening. Please state what the earlier network name was. Please say, “the abbreviation was redesignated from '' to 'Address and Routing Parameter Area'”. Otherwise, this text is just mysterious and confusing to the reader. These terms are strictly ways of referring to the relationship standing of two domains where one is a subdomain of the other. Maybe we should state explicitly that “subordinate” is a synonym for “subdomain”? Zone enumeration is different from zone content guessing where the guesser uses a large dictionary of possible labels Can we elaborate on *how* it is different? DNSSEC Policy (DP): A statement that "sets forth the security requirements and standards to be implemented for a DNSSEC-signed zone." (Quoted from [RFC6841], Section 2) DNSSEC Practice Statement (DPS): "A practices disclosure document that may support and be a supplemental document to the DNSSEC Policy (if such exists), and it states how the management 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
Re: [DNSOP] SRV-related _underscore registry (was Re: Call for Adoption: draft-crocker-dns-attrleaf)
On 29 Feb 2016, at 14:27, John R Levine wrote: > The existing port and service registry already has all of the _service names, > and is updated as people invent new services. What's the benefit of > duplicating it rather than just pointing to it? I agree. Where possible, it’s better to add to an existing registry, rather than creating an entirely new (but mostly overlapping) one. When we wrote RFC 6335 we made a conscious choice that 15 ASCII characters is short enough to be efficient over the air and not burdensome to implement in constrained devices, yet long enough for the set of available identifiers to be effectively unlimited, and long enough to allow for reasonably mnemonic identifiers where that is desired (at least in English, which we deemed acceptable since these are protocol identifiers, not generally seen by end users). A consequence of this abundant namespace is that it’s okay to have some identifiers in it that are not applicable in all contexts, and that’s preferable to having separate per-context namespaces, which risks having some identifier string appear in more than of those namespaces, with unrelated meanings. When RFC 6335 unified the two separate identifier namespaces there were four such unintended overlaps (esp, hydra, recipe, xmp), which fortunately were resolved amicably: <https://tools.ietf.org/html/rfc6335#section-10.1>. On 1 Mar 2016, at 09:55, Phillip Hallam-Baker wrote: > The _service._protocol approach in SRV is rather obviously a mistake. Given > the function of SRV, the protocol tag should have been on the RIGHT hand side > of the RR type, not the left. The choice of UDP or TCP should be an OUTPUT > from the service discovery process, not an input. We thought about this too, and concluded that few application protocols offer the luxury of running over both TCP and UDP (NFS and DNS being two examples that come to mind). In reality, most application protocols are defined as a bundle, such as application-protocol-over-UDP-over-IP, or application-protocol-over-TCP-over-IP, or application-protocol-over-TLS-over-TCP-over-IP. The application protocol name implicitly encodes the transport it expects. In an iPhone looking for AirPrint (i.e., IPP) printers were to be told that it had found an AirPrint printer that supported IPP, but only over SCTP, or DCCP, or whatever, the iPhone would simply fail to print on it, because the iPhone doesn’t implement IPP-over-foo. In retrospect, I wish we had defined all SRV service type identifiers to be simply “_app-proto._srv”, and let the specification of the “_app-proto” application protocol state what transport layer stack it requires. In practice what happens is that TCP-based protocols use “_tcp” and everything else uses “_udp” as the catch-all for all non-TCP protocols. RFC 6763 talks about this: <https://tools.ietf.org/html/rfc6763#section-7>. A common convention that seems to be emerging is that application protocols that run over TLS are given SRV service type identifiers ending in “-tls”, such as, “_dns-update-tls._tcp” and “_dns-push-tls._tcp”. This is just a convention for mnemonic convenience though, and not every service uses it. For example, IPP over TLS uses service type “_ipps._tcp”. When looking for AirPrint (i.e., IPP) printers a modern iPhone will browse for both “_ipp._tcp” and “_ipps._tcp”, and show a unified list to the user. In some ways this is not ideal, but engineering is often a pragmatic choice between imperfect solutions and picking the less bad one. 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
Re: [DNSOP] Comments on draft-ietf-dnsop-session-signal-06
have been changed such that some long-lived client operations can no longer be continued due to policy (REFUSED), and other long-lived client operations can no longer be performed due to the server no longer being authoritative for those names (NOTAUTH). In such cases the server MAY use any of the applicable RCODE values, or RCODE=NOERROR (routine shutdown or restart). Note that the selection of RCODE value in a Retry Delay message is not critical, since the RCODE value is generally used only for information purposes, such as writing to a log file for future human analysis regarding the nature of the disconnection. Generally clients do not modify their behavior depending on the RCODE value. The RETRY DELAY in the message tells the client how long it should wait before attempting a new connection to this server instance. For clients that do in some way modify their behavior depending on the RCODE value, they should treat unknown RCODE values the same as RCODE=NOERROR (routine shutdown or restart). A Retry Delay message from server to client is an unacknowledged message; the MESSAGE ID MUST be set to zero in the outgoing message and the client MUST NOT send a response. A client MUST NOT send a Retry Delay DSO request 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
Re: [DNSOP] [dnssd] Working Group Last Call - draft-ietf-dnsop-session-signal
I think Jan makes a good point. Suppose there’s a server that supports DNS over TCP, and DSO signaling, and Push Notifications, and DNS Update, and maybe other things. Now suppose a client connects to that server. The server doesn’t know what that client is going to do. The client may do queries over TCP, or DNS updates. It may do queries over TCP and use the DSO signaling to request a longer inactivity timeout. It may request Push Notifications (which are currently specified to require TLS). It may do all of those. When the server receives an incoming TCP connection request from a 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://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] draft-ietf-dnsop-session-signal: session establishment
On 27 Jan 2018, at 18:16, Paul Hoffman wrote: > Greetings. The -05 draft still has a complexity that I can can be easily > fixed. In a few places, it says that a session can be established by the > client sending a response-requiring DSO request message. For example, from > section 4.1: > A DSO Session is established over a connection by the client sending > a DSO request message of a kind that requires a response, such as the > DSO Keepalive TLV (see Section 6.1), and receiving a response, with > matching MESSAGE ID, and RCODE set to NOERROR (0), indicating that > the DSO request was successful. > > This logic requires a client to survey all the kinds of requests it knows to > find one appropriate for establishing the session. It also requires the > server to have to check the first message for any kind of response-requiring > request message. The intent was not that client software would make a run-time decision about how to initiate a DSO session. The intent was that a client *implementer* would make a design-time decision about how to initiate a DSO session. And, of course, “I’ll send a Keepalive request,” is a perfectly good design-time answer to that question. On the server side, the routine that generates and/or sends DSO response messages just needs to set a Boolean flag saying, “no-error response sent” (or, equivalently, “DSO session established”) when it sends a no-error DSO response. For implementations of only the base DSO spec (not extensions that build on DSO), the only response-requiring DSO request message is Keepalive, so it degenerates to the simple scenario you proposed -- a DSO session MUST be established by the client sending a Keepalive message. The reason we left the flexibility 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
[DNSOP] DNSSD (DNS-Based Service Discovery) testing at IETF 100 Hackathon
Ted Lemon and I are planning on doing an interop test of our DNSSD code at the IETF 100 Hackathon. Details can be found here: <https://www.ietf.org/registration/MeetingWiki/wiki/doku.php?id=100hackathon> We are planning to test the following protocols: DNS Stateful Operations <https://tools.ietf.org/html/draft-ietf-dnsop-session-signal> DNS Push Notifications <https://tools.ietf.org/html/draft-ietf-dnssd-push> Service Discovery Proxy <https://tools.ietf.org/html/draft-ietf-dnssd-hybrid> Service Discovery Relay <https://tools.ietf.org/html/draft-sctl-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 ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Status of "let localhost be localhost"?
I’m puzzled by much of this discussion. We want a way for an application to indicate that it wants a loopback connection to another port on the local host. People widely use “localhost” for this. But other people argue that a mere RFC can’t guarantee that a host doesn’t violate the assumption that “localhost” means “local host”. So, to indicate that it wants a loopback connection to another port on the local host, an application needs to use “127.0.0.1”. By, by the same logic, a mere RFC can’t guarantee that a host doesn’t violate the assumption that “127.0.0.1” means loopback. Who knows what a host OS will do with that address, if it does not follow the relevant RFCs? [*] Forgive me, I forgot, “127.0.0.1” is obsolete. I should have written, “::1”. I’ll try again: So, to indicate that it wants a loopback connection to another port on the local host, an application needs to use “::1”. By, by the same logic, a mere RFC can’t guarantee that a host doesn’t violate the assumption that “::1” means loopback. Who knows what a host OS will do with that address, if it does not follow the relevant RFCs? So, “127.0.0.1” and “::1” are not suitable, both because a host OS might choose not to follow the relevant RFCs, and more importantly, they’re both address-family-specific. What we really need is some symbolic way for an application to indicate unambiguously that it wants a loopback connection to another port on the local host. We should reserve a specific string and define that it has this meaning. Some operating systems will follow the specification, and will work as expected, and others will not, which is a bug. Don’t use those products. A nice mnemonic string would be good. Something memorable, which conveys the meaning, “local host”. I suggest “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. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [dnssd] Draft-ietf-dnsop-edns-tcp-keepalive and DNS Push Notifications
On 21 Mar 2016, at 20:02, Paul Wouters wrote: > Our document is in AUTH48 already, so making those kind of changed there > might be very difficult. I didn’t realise that. I agree, it’s too late to make substantive changes at this point. > Also, if you are so idle that you might run into tcp issues timing out, you > probably should be nice to the other end and close your tcp session. The idea of DNS Push Notifications is for moderately long-standing queries (on the order of 5-10 minutes) waiting to be notified of some change. For example, you go to print, but the printer is turned off. You walk down the hall and turn the printer on, and when you get back to your office your computer has been notified that a new printer has become available (without you having to repeatedly cancel and try again until the printer shows up). It’s not something that would be useful 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. Stuart Cheshire ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] Draft-ietf-dnsop-edns-tcp-keepalive and DNS Push Notifications
Dear Keepalive authors, Draft-ietf-dnssd-push-06 (see below) references draft-ietf-dnsop-edns-tcp-keepalive. However, at present, a more accurate title might be “draft-ietf-dnsop-edns-tcp-idle-timeout” instead of “draft-ietf-dnsop-edns-tcp-keepalive”, because while it tells the client how to learn what the idle timeout is, it doesn’t say anything about what the client does to actually keep a connection alive. Draft-ietf-dnssd-push-06 currently has the text included below. 1. It states what actions reset the idle timer. 2. It states that the client should send keepalive traffic before the idle timeout expires, but the server should not kill a connection until 1.5x the idle timeout, to allow for clock rate differences and propagation delays. 3. Particularly note the final paragraph, which calls for suggestions for a specified keepalive action. At both servers and clients, the generation or reception of any request, response, update, or keepalive message resets the keepalive timer for that connection. In the absence of any requests, responses, or update messages on a connection, a client MUST generate keepalive traffic before the idle timeout expires, or the server is entitled to close the connection. If a client disconnects from the network abruptly, without closing its connection, the server learns of this after failing to receive further traffic from that client. If no requests, responses, update messages or keepalive traffic occurs on a connection for 1.5 times the idle timeout, then this indicates that the client is probably no longer on the network, and the server SHOULD abort the connection with a TCP RST. [We need to discuss the nature of "the required keepalives". Are they TCP-layer keepalives? DNS-layer keepalives? There is currently no DNS-layer keepalive or 'no-op' operation defined. What would that operation be? A DNS QUERY containing zero questions? A DNS SUBSCRIBE containing zero questions? An "empty" DNS message over the TCP connection (just a pair of zero bytes, signifying a zero-length message)? One benefit of TCP-layer keepalives is that they transmit fewer bytes, and involve less software overhead for processing those bytes. Another benefit is that it is more feasible to implement these in networking offload hardware, which can allow devices to meet their TCP keepalive obligations while sleeping. This is particularly important for battery-powered devices like mobile phones and tablets. On the other hand, using TCP-layer keepalives requires an API for a client to tell the networking stack at what frequency to perform TCP- layer keepalives, and an API for a server to request the networking stack to inform it when TCP-layer keepalives are not received by the required deadline. TCP-layer keepalives also only verify liveness of the remote networking stack, whereas DNS-layer keepalives provide higher assurance of liveness of the remote server application software -- though this a limited benefit, since there is no reason to expect that DNS Push Notification server software will routinely become wedged and unresponsive.] I could define this specified keepalive action 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 16:58:41 Pacific Daylight Time > To: i-d-annou...@ietf.org > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the Extensions for Scalable DNS Service > Discovery of the IETF. > >Title : DNS Push Notifications > Authors : Tom Pusateri > Stuart Cheshire > Filename: draft-ietf-dnssd-push-06.txt > Pages : 31 > Date: 2016-03-21 > > Abstract: > The Domain Name System (DNS) was designed to return matching records > efficiently for queries for data that is relatively static. When > those records change frequently, DNS is still efficient at returning > the updated results when polled. But there exists no mechanism for a > client to be asynchronously notified when these changes occur. This > document defines a mechanism for a client to be notified of such > changes to DNS records, called DNS Push Notifications. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-dnssd-push/ > > There's also a htmlized version available at: > https://tools.ietf.org/html/draft-ietf-dnssd-push-06 > > A diff from the previous version is available at: > https://www.iet
Re: [DNSOP] New Version Notification for draft-adpkja-dnsop-special-names-problem-00.txt
king >group, by an ad-hoc working group, by expert review or any >combination of those approaches. [RFC6761] provides no direction. RFC 6761 says: When IANA receives a request to record a new "Special-Use Domain Name", it should verify, in consultation with the IESG, that the IETF "Standards Action" or "IESG Approval" document [RFC5226] includes the required "Domain Name Reservation Considerations" section stating how the special meaning of this name affects the behavior of hardware, software, and humans in the seven categories. If IANA and the IESG determine that special handling of this "Special-Use Domain Name" is appropriate, IANA should record the Special-Use Domain Name, and a reference to the specification that documents it, in the registry. I confess I has assumed that IANA would designate some person with the expertise and experience to evaluate whether “... special handling of this "Special-Use Domain Name" is appropriate ...”, much as requests for TCP and UDP ports are evaluated. That was my mistake. I should have been explicit about the intended review process. >For example, is large scale prior deployment an acceptable criteria? Large scale prior deployment should *not* be required -- that would just make squatting a necessary prerequisite for getting a special use name assigned. RFC 6761 was intended to provide a legitimate path for proposals to be evaluated on technical merit, rather than de facto squatting. >Going back to the previous point of prior usage of the protocol, in >the case of LOCALHOST, LOCAL and ONION, those particular domain names >were already in use by a substantial population of end-users at the >time they were requested to be added to the Registry. Rightly or >not, the practical cost of a transition was argued as a justification >for their inclusion in the registry. No. The justification for having an entry in the registry was to facilitate the desired special behaviour. The particular choice of what name went in the registry was influenced by existing usage, but the justification for having the entry itself was motivated by the desire for special behaviour. If the IETF process went a bit more smoothly, the IETF would have more participation in the choice of name *before* it becomes too late to easily change that. As I read it, draft-adpkja-dnsop-special-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 special behaviours is merely a means to the end. What is interesting and important, and worthwhile for the IETF to support, is the special behaviours, not the names. Stuart Cheshire ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Request for Comments on I-D about IoT DNS Name Autoconf
On 3 Nov 2015, at 01:51, Mr. Jaehoon Paul Jeong wrote: > Hi 6man, 6lo and dnsop folks, > > There will be a talk about IoT DNS Name Autoconfiguration > in 6man WG's morning session tomorrow, 11/4/2015. > > Title: DNS Name Autoconfiguration for Internet of Things Devices > https://tools.ietf.org/html/draft-jeong-6man-iot-dns-autoconf-00 This was not actually discussed in 6man, 6lo, or dnsop, so I’ll make some comments here. It’s hard to know where to start. Your document confuses device discovery with service discovery. What a device *is* tells you virtually nothing about what it *does*. The “device category” of my computer being “laptop” or “tablet” tells you *nothing* about what services it offers. Your document assumes that every search domain your tablet encounters (starbucks.com, narita-airport.co.jp, meeting.ietf.org, comcast.com) will allow your tablet to create global records in that domain. Clearly this is nonsense. Having put global address records into starbucks.com, your document assumes then assumes that starbucks.com will then allow you do to a zone transfer to fetch the entire zone to discover the names of all the other address records in starbucks.com. Clearly this is nonsense too. Your document proposes global address records with names with this form: unique_id.device_model.device_category.mic_loc.mac_loc.domain_name. For example: jkadjkhdsafhjlsadfjklkljdgajknsadf.Sungkyunkwan-1234.cleaning-robot.right-upper-corner.living-room.comcast.com. The host name of the cleaning robot keeps changing as it moves around the room, requiring continual updates and continual zone transfers to keep track of the name as it changes. Clearly this is infeasible. I would, however, love to get one of these new flying cleaning 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
Re: [DNSOP] additional special names Fwd: I-D Action: draft-chapin-additional-reserved-tlds-00.txt
On 26 Feb, 2014, at 06:34, Joe Abley wrote: > I still don’t see why we need a TLD, or a delegation/reservation under ARPA. > > There are many, many TLDs under which an application/protocol implementer can > reserve some namespace for their exclusive use at low cost ($10/year, say). > Why is this approach not preferred for a new application/protocol? It seems > far simpler. The issue is home gateway vendors who want to sell a $49 home gateway that “just works”, out of the box, without the customer having to go though some confusing registration process (that also costs 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 mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] additional special names Fwd: I-D Action: draft-chapin-additional-reserved-tlds-00.txt
On 24 Feb, 2014, at 19:37, Mark Andrews wrote: > There is a slight difference. There is no restriction on getting > names other than unwillingness or lack of education about how to > get a name. Good point. A document to help this education aspect would be good. > They can alway 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
Re: [DNSOP] additional special names Fwd: I-D Action: draft-chapin-additional-reserved-tlds-00.txt
On 29 Jan, 2014, at 07:47, Ralf Weber wrote: > Where shall this stop? How about .LOKALESNETZWERK (german for .LAN). How many > domains do we want to treat special? I know this draft only asks for 8, but > some of them are on ICANNs application list. Currently, with no established procedure for local-use names, the result is chaos. Since no DNS equivalent to RFC 1918 exists, people use whatever name they feel like. My hope is that if people are offered a short list of legitimate pseudo-TLDs for local-use names, the temptation to use some other TLD not on that list will be less. Today all NAT gateways I know of default to one of the RFC 1918 address ranges. If RFC 1918 did not exist, would NAT gateways not exist, or would they just hijack who-knows-what addresses? I suspect the latter. If we acknowledge and document the reality, the IETF can have a role in guiding it in a sane direction. If we pretend local-use names don’t exist, then the IETF has less relevance in the real world and the real world carries on without us. > I also don't think there are risks in delegation these other than the > applicants will get lots of traffic. No, the risk is that the applicants *won’t* get the traffic they want, because some user’s local DNS is answering those queries. If we have *some* pseudo-TLDs reserved for local-use names, there’s a stronger argument that local hijacking of other names is illegitimate. And yes, if you want .LOKALESNETZWERK, 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
Re: [DNSOP] additional special names Fwd: I-D Action: draft-chapin-additional-reserved-tlds-00.txt
On 28 Jan, 2014, at 13:56, Lyman Chapin wrote: > Hi Stuart - > > The draft was intended to capture existing observed high-volume uses of > non-delegated TLD names empirically, rather than trying to determine the > circumstances under which local use of a particular TLD name occurs (which > might be highly various, depending on the name). That’s a laudable contribution, thank you. I believe that with the considerable sleuthing abilities of the IETF community, we ought to be able to take this initial set of observed data and treat it as a call to action for the IETF 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.) Stuart Cheshire ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] additional special names Fwd: I-D Action: draft-chapin-additional-reserved-tlds-00.txt
On 28 Jan, 2014, at 07:52, Paul Hoffman wrote: > It does, but it doesn't call it out very well. It the middle of section 3, it > says that the list is “names that may not be used for top-level domains". That doesn’t describe what the labels are used for. It describes what they may *not* be used for. What they *are* used for remains unspecified. If the user types “www.host” into their web browser, the name should *not* be resolved in the global DNS. I get that. But what *should* happen with that name? Should it result in NXDOMAIN, like “www.invalid”? Should it result in 127.0.0.1 like “localhost” does? Resolved via mDNS, like “www.local”? Something else? I have no idea. If it’s the same as one of the other existing special-use TLDs, then an argument needs to be made as to why we need another reserved special-use TLD that duplicates the functionality of an existing one. These names are not supposed to be vanity names. The special-use names are there to trigger special behavior by software, and as such we probably don’t need more than one way to trigger each particular special behavior. The current use of various de facto reserved names like “.onion” results from there being no formal IETF mechanism for documenting and discussing such uses. The goal of RFC 6761 was to remedy this omission, and give people who feel they need such names a process to apply for such names and initiate discussion about whether such use is appropriate. That way the IETF community can be involved with these decisions about how names are used, instead of it happening outside the IETF with no IETF scrutiny or input. I think it would be fairly easy to produce a draft documenting what “.onion” is for, how it works, and why resolving those names via the conventional DNS is not appropriate. I’d love to see a draft like that from one of the people who understands the details. For some of the other names I don’t know what those documents would say. If people in the IETF community do know what those names are used for, having those people write and submit 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. Stuart Cheshire ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] additional special names Fwd: I-D Action: draft-chapin-additional-reserved-tlds-00.txt
eir authoritative DNS servers to act as authoritative for test names. 7. DNS Registries/Registrars MUST NOT grant requests to register test names in the normal way to any person or entity. Test names are reserved for use in private networks and fall outside the set of names available for allocation by registries/registrars. Attempting to allocate a test name as 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
