Re: [DNSOP] I-D Action: draft-bellis-dnsop-qdcount-is-one-01.txt
Hi, I noticed that Section 4 of the draft states: Firewalls that process DNS messages in order to eliminate unwanted traffic SHOULD treat messages with OPCODE = 0 and QDCOUNT > 1 as malformed traffic. See Section 4 of [RFC8906] for further guidance. However, I couldn't find the guidance in Section 4 of RFC 8906 being referred to. Most of that section is actually about misbehavior in firewalls in response to well-formed traffic, not correct behavior in response to malformed traffic. The most relevant text seems to be: Firewalls and load balancers should not drop DNS packets that they don't understand. They should either pass the packets or generate an appropriate error response. […] However, there may be times when a nameserver mishandles messages with a particular flag, EDNS option, EDNS version field, opcode, type or class field, or combination thereof to the point where the integrity of the nameserver is compromised. Firewalls should offer the ability to selectively reject messages using an appropriately constructed response based on all these fields while awaiting a fix from the nameserver vendor. Returning FORMERR or REFUSED are two potential error codes to return. If I understand correctly, the QDCOUNT is a field, not a flag, so it would not be included in the list of "a particular flag, EDNS option, EDNS version field, opcode, type or class field, or combination thereof" described here. Even if QDCOUNT were included in this list, I can't think of an example where QDCOUNT > 1 would compromise the integrity of a nameserver. One could also imagine a *valid*, non-malformed combination of query parameters that could result in the integrity of a nameserver being compromised, so this paragraph isn't solely about malformed traffic. So I'm having difficulty understanding how exactly to apply this section when reading it alongside the draft. If the intention of Section 4 of this draft is to allow firewalls to meddle with OPCODE = 0, QDCOUNT > 1 as a general, ongoing deployment posture rather than as a temporary workaround "while awaiting a fix from the nameserver vendor", it would seem to go a bit beyond the narrow guidance in Section 4 of RFC 8906. Also, I think the phrase "to eliminate unwanted traffic" is vague. How would a firewall eliminate unwanted traffic? May it drop OPCODE = 0, QDCOUNT > 1? May it synthesize a FORMERR response? If it synthesizes a FORMERR response, should those responses be rate-limited in case the sender's source address is spoofed? Thanks! Joe Abley wrote: > Hi all, > > This version mainly incorporates feedback from the room at the last meeting > and relate to document clarity; the advice is unchanged. > > > Joe > > > On 28 Sep 2023, at 15:21, internet-dra...@ietf.org wrote: > > > > Internet-Draft draft-bellis-dnsop-qdcount-is-one-01.txt is now available. > > It > > is a work item of the Domain Name System Operations (DNSOP) WG of the IETF. > > > > Title: In the DNS, QDCOUNT is (usually) One > > Authors: Ray Bellis > >Joe Abley > > Name:draft-bellis-dnsop-qdcount-is-one-01.txt > > Pages: 7 > > Dates: 2023-09-28 > > > > Abstract: > > > > This document clarifies the allowable values of the QDCOUNT parameter > > in DNS messages with OPCODE = 0 (QUERY) and specifies the required > > behaviour when values that are not allowed are encountered. > > > > The IETF datatracker status page for this Internet-Draft is: > > https://datatracker.ietf.org/doc/draft-bellis-dnsop-qdcount-is-one/ > > > > There is also an HTMLized version available at: > > https://datatracker.ietf.org/doc/html/draft-bellis-dnsop-qdcount-is-one-01 > > > > A diff from the previous version is available at: > > https://author-tools.ietf.org/iddiff?url2=draft-bellis-dnsop-qdcount-is-one-01 > > > > Internet-Drafts are also available by rsync at: > > rsync.ietf.org::internet-drafts > > > > > > _______ > > DNSOP mailing list > > DNSOP@ietf.org > > https://www.ietf.org/mailman/listinfo/dnsop > > ___ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop -- Robert Edmonds ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] what could we do with 15 unused bits of QDCOUNT?
Brian Dickson wrote: > Top-reply (since there are already a bunch of threaded replies that might > benefit from this): > Queries are small, and have room in the first packet for EDNS (and often the > resulting size will still be < 576). > Idea: > EDNS "signal" + bits -> tells server the client knows about the new meaning of > the 15 bits of QCOUNT, and is sending its client-side version of what those > bits are. > I.e. the bits are NOT changed from zero in the header in the query, only in > the > reply and only if the server understands this EDNS option. > IFF a server understands this EDNS parameter, it responds with the > corresponding EDNS parameter (possibly without bits, either same EDNS > parameter > or a sibling parameter), and sets the 15 bits per whatever the rules are. > Reason: > Putting bits in the header (when mutually understood and agreed upon) ensures > they are in the first portion of the response, even if the response gets > fragmented. E.g. for entropy, this is an important feature, to protect against > things like "fragmentation considered poisonous". So, 15 bits of extra entropy is not that much for such a substantial engineering effort. If getting entropy into the first response fragment in order to protect against off-path spoofing vulnerabilites is the problem to be solved, *and* you're willing to update both the client and the server implementations, *and* you're willing to negotiate a new message format definition between updated clients and servers, then you should just go ahead and put a cryptographically secure amount of entropy directly into the header. Expand the DNS header to add space for 256 bits of cryptographically secure entropy right after the 12 octet STD 13 DNS header and don't bother with re-defining the QDCOUNT field. Otherwise you're still left to wonder if all the various small bits of repurposed entropy in a DNS transaction add up to something that's cryptographically secure. Also, if you're willing to discount EDNS COOKIE because it might not be carried in the first response fragment, it seems like the ~15 bits added by UDP source port randomization should also be discounted, since the UDP query might have passed through a de-randomizing NAT box. So, that gives you 16 bits DNS ID entropy, plus 15 bits of "QDCOUNT" entropy, plus whatever is added by 0x20 (since both client and server have been updated with new code, they can also be mandated to support 0x20), which gives you 31 up to perhaps 50 bits of entropy, which still can't be considered cryptographically secure. Or, if the above is too use case specific, but there is a class of problems that is worthwhile to solve that can only be solved by getting data into the first response fragment, then for the amount of engineering and operational effort required it sounds like an "EDNS version 1" project and one of the requirements should be that the "EDNS1" data be carried between the 12 octet STD 13 DNS header and the question section. Of course, there would probably have to be an array of really compelling use cases to make such a project worthwhile as well as an opportunity for complexity reduction in order to get folks interested in undertaking such a project. -- Robert Edmonds ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] what could we do with 15 unused bits of QDCOUNT?
George Michaelson wrote: > if QDCOUNT is defined as [0|1] then we have 15 new bits of freedom in > the header. > > What would be interesting uses of the flow-label? Oh wait.. that's > right, nobody really knows at scale how to use flow-label either. > > I tend to "use it for 15 bits of signalling" because there are a lot > of things I wish were signalled from client to server. > > "I am new code" > "I am at least not ancient code" > "I'm the same as that other guy you saw over " > "I like TCP and want to do a persisting session" > "tell me if you are doing a|b|c|d" > "I like chocolate and want a pony" > > maybe the truth is, we've got 15 bits of zero in the header forever, amen. > > (I deliberately didn't put this in the draft- post from Ray so as not > to pollute an objective discussion of what it is or is not the value > proposition) > > clue-stick hits welcome. Avoid the stomach. > > -G With a maximum length QNAME inside a UDP query packet there are slightly under a couple thousand bits available for EDNS. Those bits at the end of the packet are easier to get to, ecosystem-wise, so if those use cases are worthwhile they should probably be done with EDNS. -- Robert Edmonds ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] draft-dulaunoy-dnsop-passive-dns-cof
Tim Wicinski wrote:
> All
>
> Draft-dulaunoy-dnsop-passive-dns-cof was originally submitted back in 2014,
> and
> has had 10 revisions since then.
>
> https://datatracker.ietf.org/doc/draft-dulaunoy-dnsop-passive-dns-cof/
>
> Note that the format is now fixed, and there are several implementations.
>
> We had asked DNSOP (in the poll we held)to help us assess the level of
> interest
> in it, and the responses largely put it moderately high ("Adopt, but not
> now"). It would be helpful to find out if this is still the case, as things
> have progressed since then: the format is now widely used, and so the format
> itself is basically fixed. As an example, the format is being used within the
> US government agencies for event logging and incident response[0].
>
>
> One of two things could happen:
>
> 1: DNSOP decides that they are really interested, adopts and improves the
> justification / operational / supporting text, and the draft gets published as
> an IETF RFC; or
>
>
> 2: DNSOP says "No thanks, but we don't actively object". In which case the ISE
> (and Warren!) has a much easier time explaining why it's being published as an
> RFC on the Independent stream. . We will also ask for a DNS Directorate
> review.
>
>
> Feedback Welcome
>
> tim
>
> [0]: Because the draft had expired, and the USG cannot (realistically) point
> at
> expired IDs, they had to copy and paste it into an internal document: https://
> www.whitehouse.gov/wp-content/uploads/2021/08/
> M-21-31-Improving-the-Federal-Governments-Investigative-and-Remediation-Capabilities-Related-to-Cybersecurity-Incidents.pdf
> Page 15 is the table where they defined the Passive DNS Log fields.
I originally developed one of the implementations named in this draft
[1] and if I recall correctly it did not occur to me that the API I was
developing should ever be standardized, let alone the underlying data
model being used to generate API responses, which I don't think this I-D
has ever touched on. E.g., the 'rdata' field may return a string or an
array of strings; if you have an array of length 1, does this mean a
resource record or a resource record set is being represented? Well, it
probably depends on which API endpoint on which implementation is being
called; but this spec is presented as a document format rather than as
specification for an entire API. I would guess there is substantially
more variation in the kinds of API endpoints that are supported by the
various passive DNS API implementations than there is in the output
formats generated by those endpoints which makes it less tractable to
come up with a consensus specification for the endpoints as well.
So, it seems a bit odd to me to try to put a particular narrowly scoped
idiosyncratic consensus format used by a few particular API services
through the RFC process. There are many kinds of databases, API
services, and formats that do not have RFC documents describing them.
For instance, the pcap savefile format is widely used and presumably a
lot of governments buy a lot of products that support the pcap format,
and as far as I can tell the canonical specification for that format is
a file in a particular Git repository [2] maintained by a group of open
source contributors. Why isn't that approach feasible for this
particular use case, which is much more of a niche use case than packet
capture in general?
[1] Some of the early API documentation is on the Wayback Machine:
https://web.archive.org/web/20130904190535/https://api.dnsdb.info/
[2] https://www.tcpdump.org/manpages/pcap-savefile.5.html,
https://github.com/the-tcpdump-group/libpcap/blob/master/pcap-savefile.manfile.in
--
Robert Edmonds
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [Ext] Coming soon: WG interim meeting on the definition of "lame delegation"
Edward Lewis wrote: > I’ve just come across this message (I have been out a bit recently)…sorry is > this is late. > > These are suggestions… > > For the situation where a (an active) nameserver is not configured to answer a > query it received (which is the case where my use of lame delegation comes > from), I’d suggest the following more accurate labels: > > “out of bailiwick query” - from the perspective of the server, the query is > something it can’t answer "In-bailiwick" vs. "out-of-bailiwick" refers to the relation of an NSDNAME in a delegation NS record to the name of the zone containing the delegation NS record. This can be objectively determined without ever sending a DNS query to the nameserver identified by the NSDNAME value. Or it can refer to an evaluation of RRset owner names in a nameserver's response message that a resolver performs to exclude poison (sometimes called "scrubbing" but I see this is such a slang term that it hasn't made it into "DNS Terminology"). But it seems weird to extend the bailiwick term to a situation where either incorrect delegation data exists in the DNS or a nameserver is misconfigured. -- Robert Edmonds ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] signing parent-side NS (was: Re: Updating RFC 7344 for cross-NS consistency)
Paul Vixie wrote: > Petr Špaček wrote on 2022-07-26 06:21: > > On 28. 06. 22 16:20, Bob Harold wrote: > > > But the parent NS set is not covered by DNSSEC, and thus could be > > spoofed?? > > > (Wish we could fix that!) > > > > I share your wish. > > > > Does anyone else want to contribute? > > only to fight such a change. > > > Can people here share their memories of why it is not signed? I wasn't > > doing DNS when this was designed and I think it would be good to > > understand the motivation before we start proposing crazy things. > > it exists in two places. only one can be authoritative. therefore only one > can be signed. as olafur said down-thread, RFC103x ought to have used > different rr types for delegation vs. apex nameserver list. now we live with > it. I don't agree that "only one can be authoritative. therefore only one can be signed." I don't see a prohibition against signing non-authoritative RRsets in general. RFC 4035 § 2.2 provides: For each authoritative RRset in a signed zone, there MUST be at least one RRSIG record… [Note: The above is not the same as saying that every RRSIG in a signed zone must only cover authoritative RRsets.] The NS RRset that appears at the zone apex name MUST be signed, but the NS RRsets that appear at delegation points (that is, the NS RRsets in the parent zone that delegate the name to the child zone's name servers) MUST NOT be signed. Glue address RRsets associated with delegations MUST NOT be signed. In other words, all authoritative RRsets in a signed zone must be signed, while non-authoritative NS records and glue address records in a signed zone must not be signed. This section does not say anything specific about the signing of non-authoritative RRsets in a signed zone that are not delegation NS records or glue address records. The reason delegation NS records and glue address records can't be signed is because it would violate a specific MUST NOT about those kinds of records, not because those records are non-authoritative. So I conclude that "authentic" and "authoritative" are not synonymous in the DNS(SEC) data model. "Authentic" and "authoritative" being distinct categories of RRsets is consistent with RFC 2181 § 5.4.1, which provides: When DNS security [RFC2065] is in use, and an authenticated reply has been received and verified, the data thus authenticated shall be considered more trustworthy than unauthenticated data of the same type. Thus it would be possible to distinguish the trustworthiness level of "[Authenticated] data from the authority section of a non-authoritative answer" from "[Unauthenticated] data from the authority section of a non-authoritative answer", and those two trustworthiness levels could themselves be distinguished from "authoritative data included in the answer section of an authoritative reply" and "data from the authority section of an authoritative answer". In practice I don't believe resolvers bother with the authenticated/unauthenticated distinction for individual trustworthiness levels and consider DNSSEC "secure" or "validated" to be a singular, penultimate trustworthiness level separate from the levels enumerated in 2181. The RRSIG "Signer's Name" field unambiguously identifies the zone that the covered RRset belongs to, and is covered by the signature calculation. So even if a parent zone and a child zone were signed by the same key, the RRSIG(NS) at the apex of the child zone is cryptographically distinguishable from the RRSIG(NS) with the same owner name at the delegation point in the parent zone. In practice the specific prohibition on signing delegation NS records and glue address records in 4035 § 2.2 probably enables a bunch of implementation simplifications (e.g. no need to key the resolver's RRset cache by zone name as well as owner name, no need to double up on the trustworthiness levels, etc.). So the historical reasons for why delegation NS and glue address records aren't signed is probably less relevant than the present day interoperability issues that such a change might cause. -- Robert Edmonds ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [EXT] Re: [Technical Errata Reported] RFC7686 (6761)
Peter van Dijk wrote:
> I don't think we should be prescribing extra code paths in
> authoritative servers in this document, and I think non-authoritative
> NXDOMAINs would be very confusing. In particular, resolvers would not
> believe them anyway.
>
> That all said, I can certainly see that other texts than my suggestion
> could make sense.
If the goal is to avoid mandating extra code paths in typical
authoritative servers, I would suggest something like the following
which narrowly answers only the questions asked in 6761 ("Are developers
of authoritative domain name servers expected to make their
implementations recognize these names as special and treat them
differently? If so, how?"):
Original Text
-
5. Authoritative DNS Servers: Authoritative servers MUST respond to
queries for .onion with NXDOMAIN.
Corrected Text
--
5. Authoritative DNS Servers: Authoritative servers SHOULD NOT
recognize .onion names as special and MUST NOT treat queries for
.onion names differently from other queries.
Splitting the "recognize ... treat" conjunction between "SHOULD NOT"
and "MUST NOT" would, for instance, allow an authoritative server to
log a warning message if an operator intentionally configured an
"onion." zone in the server.
A slight expansion of the text might read:
Corrected Text
--
5. Authoritative DNS Servers: Authoritative servers SHOULD NOT
recognize .onion names as special and MUST NOT treat queries for
.onion names differently from other queries. By default,
authoritative servers MUST NOT respond authoritatively to
queries for .onion names.
The "By default" qualifier covers the case of a non-default
configuration (such as being configured to serve the root zone) where an
authoritative server would need to respond authoritatively for .onion
names.
--
Robert Edmonds
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [Ext] Authoritative servers announcing capabilities
Paul Hoffman wrote: > On Sep 11, 2020, at 7:23 PM, John Levine wrote: > > > > In article <92ca6178-fe2d-407e-97fb-a9e44e264...@icann.org>, > > Paul Hoffman wrote: > >> On Sep 11, 2020, at 4:40 PM, Mark Andrews wrote: > >>> > >>> and why is it a RR type at all. > >> > >> So that the answer can be signed and thus validated. > > > > It looks to me like all of the servers for a particular zone would > > have to return the same AUTHINFO, which seems like a bad idea since > > they don't necessarily all have the same features. > > At this point, the only information we defined in the draft is for doing > client subnet. If there are server sets for a single zone where some do > client subnet, and others don't, then your concern is valid. Changing this to > an uncacheable, unverifiable EDNS option is easy. The draft is not limited to ECS. It creates an IANA registry and allows arbitrary "local use" values to be defined. It can already be used to specify different capabilities for each nameserver for a zone, because the draft also allows: Most zone typically have multiple authoritative servers. Thus, the AUTHINFO Rdata returned from different authoritative servers for the same zone might differ. If that's not correct, and all the nameservers must return the same AUTHINFO RR, then perhaps a better name would be "ZONEINFO", all the references to "server" changed to "zone", etc. -- Robert Edmonds ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Authoritative servers announcing capabilities
Paul Wouters wrote: > On Sep 11, 2020, at 20:48, Paul Vixie wrote: > > > > On Sat, Sep 12, 2020 at 09:40:11AM +1000, Mark Andrews wrote: > >> and why is it a RR type at all. An EDNS option or a opcode is better > >> suited > >> for this sort of thing. > > > > +1. > > An RR type can be signed and distributed differently and allow for preloading > of (distributed) caches which enhanced the decentralization of recursive DNS > servers. As described in -00, a cached and re-distributed AUTHINFO RR is useless unless you know what nameserver address it applies to, and if an AUTHINFO RR isn't trustworthy unless it's signed then the AUTHINFO RR would need to embed the nameserver address that it applies to so that that information can be signed and validated as well. -- Robert Edmonds ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Authoritative servers announcing capabilities
Paul Hoffman wrote: > The responses will be signed if the zone for which the server is > authoritative is signed, meaning that validating resolvers can get > authenticated information about the server if that would influence how they > treat responses from the server. How does the zone signer know the capabilities of the nameservers that will serve the zone and what does it do if the capabilities of those servers differ? It sounds like this is incompatible with offline signing. Must a primary nameserver exclude AUTHINFO RR's from outgoing AXFRs to secondary nameservers? Must secondary nameservers fail, filter, or replace an incoming AXFR if it contains an AUTHINFO RR? By making this an RR it seems like it would be easy to inadvertently serve an incorrect AUTHINFO RR. I think this should be an EDNS option rather than an RR and if integrity protection beyond that of plain DNS is needed, it can be combined with COOKIE, SIG(0), TSIG, DoT, etc. -- Robert Edmonds ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Question regarding RFC 8499
Joe Abley wrote:
> STD 13 assumes a model where there is a single authoritative nameserver which
> acts as a source of truth for zone data ("primary"), from which other
> nameservers retrieve data and also make it available ("secondary"). As such
> they describe the whole of a simple directed graph of zone transfers.
>
> In my experience, in common usage today, master and slave describe functions
> along a single edge of such a graph. A single piece of software might act as
> a master server on one edge, and a slave on another. As such those terms can
> be used to describe more complicated graphs than the particular topology
> imagined in STD 13.
It's not the case that you can only build simple directed graph XFR
topologies using the STD 13 model. RFC 1034 describes an "intermediate
secondary" which seems to be exactly what you described, a server that
performs both XFR-in and XFR-out.
Each secondary server is required to perform the following operations
against the master, but may also optionally perform these operations
against other secondary servers. This strategy can improve the transfer
process when the primary is unavailable due to host downtime or network
problems, or when a secondary server has better network access to an
"intermediate" secondary than to the primary.
--
Robert Edmonds
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Question regarding RFC 8499
Michael De Roover wrote: > Regarding the primary and secondary servers, it's a fair euphemism but this > among further fracturing of nomenclature in other projects makes this > definition very fragmented (master/slave is now primary/secondary, main, > parent/child, etc). This is something I find unnecessary and harmful, as it > creates confusion while merely redefining the same. "Primary" and "secondary" are not euphemisms or later re-definitions. They appear extensively throughout STD 13 and appear to be the preferred nomenclature, e.g. in the below description of zone transfers from RFC 1034. "Slave" does not appear anywhere in STD 13 to the best of my knowledge; the closest reference is to "non-master" servers. Mockapetris[Page 27] RFC 1034 Domain Concepts and FacilitiesNovember 1987 4.3.5. Zone maintenance and transfers Part of the job of a zone administrator is to maintain the zones at all of the name servers which are authoritative for the zone. When the inevitable changes are made, they must be distributed to all of the name servers. While this distribution can be accomplished using FTP or some other ad hoc procedure, the preferred method is the zone transfer part of the DNS protocol. The general model of automatic zone transfer or refreshing is that one of the name servers is the master or primary for the zone. Changes are coordinated at the primary, typically by editing a master file for the zone. After editing, the administrator signals the master server to load the new zone. The other non-master or secondary servers for the zone periodically check for changes (at a selectable interval) and obtain new zone copies when changes have been made. To detect changes, secondaries just check the SERIAL field of the SOA for the zone. In addition to whatever other changes are made, the SERIAL field in the SOA of the zone is always advanced whenever any change is made to the zone. The advancing can be a simple increment, or could be based on the write date and time of the master file, etc. The purpose is to make it possible to determine which of two copies of a zone is more recent by comparing serial numbers. Serial number advances and comparisons use sequence space arithmetic, so there is a theoretic limit on how fast a zone can be updated, basically that old copies must die out before the serial number covers half of its 32 bit range. In practice, the only concern is that the compare operation deals properly with comparisons around the boundary between the most positive and most negative 32 bit numbers. The periodic polling of the secondary servers is controlled by parameters in the SOA RR for the zone, which set the minimum acceptable polling intervals. The parameters are called REFRESH, RETRY, and EXPIRE. Whenever a new zone is loaded in a secondary, the secondary waits REFRESH seconds before checking with the primary for a new serial. If this check cannot be completed, new checks are started every RETRY seconds. The check is a simple query to the primary for the SOA RR of the zone. If the serial field in the secondary's zone copy is equal to the serial returned by the primary, then no changes have occurred, and the REFRESH interval wait is restarted. If the secondary finds it impossible to perform a serial check for the EXPIRE interval, it must assume that its copy of the zone is obsolete an discard it. When the poll shows that the zone has changed, then the secondary server must request a zone transfer via an AXFR request for the zone. The AXFR may cause an error, such as refused, but normally is answered by a sequence of response messages. The first and last messages must contain Mockapetris[Page 28] RFC 1034 Domain Concepts and FacilitiesNovember 1987 the data for the top authoritative node of the zone. Intermediate messages carry all of the other RRs from the zone, including both authoritative and non-authoritative RRs. The stream of messages allows the secondary to construct a copy of the zone. Because accuracy is essential, TCP or some other reliable protocol must be used for AXFR requests. Each secondary server is required to perform the following operations against the master, but may also optionally perform these operations against other secondary servers. This strategy can improve the transfer process when the primary is unavailable due to host downtime or network problems, or when a secondary server has better network access to an "intermediate" secondary than to the primary. -- Robert Edmonds ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Fwd: New Version Notification for draft-muks-dnsop-dns-thundering-herd-00.txt
Mukund Sivaraman wrote:
> On Thu, Jun 25, 2020 at 09:32:39AM -0700, internet-dra...@ietf.org wrote:
> >
> > A new version of I-D, draft-muks-dnsop-dns-thundering-herd-00.txt
> > has been successfully submitted by Mukund Sivaraman and posted to the
> > IETF repository.
> >
> > Name: draft-muks-dnsop-dns-thundering-herd
> > Revision: 00
> > Title: The DNS thundering herd problem
> > Document date: 2020-06-25
> > Group: Individual Submission
> > Pages: 6
> > URL:
> > https://www.ietf.org/internet-drafts/draft-muks-dnsop-dns-thundering-herd-00.txt
> > Status:
> > https://datatracker.ietf.org/doc/draft-muks-dnsop-dns-thundering-herd/
> > Htmlized:
> > https://tools.ietf.org/html/draft-muks-dnsop-dns-thundering-herd-00
> > Htmlized:
> > https://datatracker.ietf.org/doc/html/draft-muks-dnsop-dns-thundering-herd
> >
> >
> > Abstract:
> >This document describes an observed regular pattern of spikes in
> >queries that affects caching resolvers, and recommends software
> >mitigations for it.
>
> For whoever is interested, this is a description of a pattern of queries
> noticed at busy public resolvers that has led to issues in at least 4
> different sites in the last 2 months.
This seems like a description of a resolver implementation vulnerable to
the infamous VU#457875. Perhaps an update to the standards track RFC
5452 ("Measures for Making DNS More Resilient against Forged Answers")
would be more appropriate than a new document? That document mentions
the security problem caused by having multiple outstanding queries for
the same question but doesn't clearly state a requirement to
de-duplicate, perhaps because that mitigation was already very common in
resolver implementations at the time the document was published.
--
Robert Edmonds
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] my chromecast ultra would not start until i began answering 8.8.8.8
Paul Vixie wrote: > google, this is bogus as hell. my dhcp server gives you dns servers to use. > please don't make me route and answer 8.8.8.8 just to watch youtube. > > > [71] 2019-02-13 16:39:40.548137 [#68 vtnet0 4095] \ > > [24.104.150.186].56915 [8.8.8.8].53 \ > > dns QUERY,NOERROR,7357,rd \ > > 1 lh3.googleusercontent.com,IN,A 0 0 0 > > [71] 2019-02-13 16:39:40.548210 [#69 vtnet0 4095] \ > > [24.104.150.186].56915 [8.8.8.8].53 \ > > dns QUERY,NOERROR,49247,rd \ > > 1 lh3.googleusercontent.com,IN, 0 0 0 > > (no, this device i've paid for, will NOT be allowed to send you any > information, other than what i personally approve, which will never include > DNS traffic. if you don't like that deal, buy it back from me and i'll find > some other video appliance that doesn't twist my arm.) Are you looking for https://support.google.com/chromecast/contactflow ? -- Robert Edmonds ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] tdns, 'hello-dns' progress, feedback requested
bert hubert wrote: > 2) Try: > ping goes-via-embedded-nul.tdns.powerdns.org > ping goes-via-embedded-space.tdns.powerdns.org. > ping goes-via-embedded-dot.tdns.powerdns.org. > > None of these resolve when I try them, I wonder if that is because > implementations want CNAMEs to be 'host names', or if this a chain of > bugs. Not practically very relevant, but still. I think this is intentional behavior in the stub resolver, e.g. in glibc there's a function res_hnok used to enforce restrictions on hostnames. It looks like res_hnok in glibc got rewritten recently, too: https://sourceware.org/bugzilla/show_bug.cgi?id=22412 -- Robert Edmonds ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] New Version Notification for draft-sury-deprecate-obsolete-resource-records-00.txt
Ondřej Surý wrote: > It’s interesting that there’s some NULL RR Type usage in your zones, I > suppose that some experiments. Whatever the long gone original experiments that NULL was intended for that are alluded to in STD 13, NULL has some present day operational utility in that it's explicitly defined as carrying as much arbitrary data as can fit, and NULL RRs can be used with RFC 3597 generic syntax without squatting on a code point. It has no presentation format and is not allowed in master zone files so presumably it is also the easiest RR type to implement. -- Robert Edmonds ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] DNSOP Presentation "The Camel"
Paul Vixie wrote: > Joao Damas wrote: > > Camels are indeed great animals and they can be loaded until > > eventually one more insignificant straw breaks their back. I guess > > that is were Bert thinks the DNS is at now and I don’t completely > > disagree > > i was pretty horrified even before ECS. dnssec sentinels feels like friday > the 13th part 37. there were danger signs saying "don't go here, there's no > road, nothing to see, and no way back" and we ignored them. Speaking of being horrified, compare the growth rate on the graph on slide 2 in this presentation: https://indico.dns-oarc.net/event/28/session/11/contribution/55/material/slides/1.pdf With the growth rate on the graph in this article for the same time period: https://www.recode.net/2017/4/27/15413870/comcast-broadband-internet-pay-tv-subscribers-q1-2017 A hybrid resolution model that allows leaf queries for parts of the DNS to be resolved direct-to-authority at endpoints would be very helpful for some use cases (especially, CDNs) and could stall the insatiable growth in resolution capacity needed at centralized resolvers. Not to mention, such a model would provide a solid deprecation path for ECS. I also note most but not all of the stuff Bert is talking about in his slide deck are on the inter-server side of the protocol (resolver to authority). But there are also other DNS camels that have been slowly gestating in the browser world, e.g.: https://plus.google.com/+WilliamChanPanda/posts/FKot8mghkok https://bugzilla.mozilla.org/show_bug.cgi?id=1434852 -- Robert Edmonds ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] New Version Notification for draft-pwouters-powerbind-00.txt (fwd)
Paul Wouters wrote: > On Mon, 19 Mar 2018, Robert Edmonds wrote: > > > Viktor Dukhovni wrote: > > > The idea is to log the DNSKEY RRs observed at each zone apex. > > > Without the proposed flag, one would also have to log denial of > > > existence which would make the logs much too large. > > > > Can you expand on what you mean by "much too large"? There are already > > existing large scale passive DNS systems that log every RRset that they > > observe, and on relatively modest amounts of hardware. Is transparency > > for DNSSEC really all that less tractable than the "log every RRset" > > problem? > > Do these large scale passive DNS systems then host the data for (m)any > clients to fully download? If those "(m)any clients" were interested in being customers of the operator of the large scale passive DNS system, then yeah. https://www.farsightsecurity.com/faq/#q13 > There are also privacy aspects. if you need to audit/log every query, > you are uploading more personal identifiable information. Combined with > TTL=0 or really short RRSIG times, these can become trackers. DNSKEY and > DS records don't come with such short TTLs (or if they would it could > itself be seen as a sign of malicious behavior) so there is much less > of a one to one relationship between those queriers and answers. Who is uploading what to whom in this scenario? Suppose there were something like https://www.internic.net/domain/root.zone, but instead of being a daily point in time snapshot of the root zone in master file format, it were a log that captured each RRset and a publish date, going back for some small window of time, and it were (ugh) PGP signed so that you know it's authentic. Would that be enough for independent auditors to construct and publish their own append-only Merkle tree logs or whatever, so that folks who want to "trust, but verify" the DNSSEC responses from the root could do so without having to upload their query logs to anyone? If so, doesn't this generalize to TLDs as well? That is, I guess I'm saying if you need cooperation from the zone publisher anyway, why not just get them to publish what you need, out of band? (Sure, it doesn't work for the TLDs that don't want to publish their zones.) -- Robert Edmonds ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] New Version Notification for draft-pwouters-powerbind-00.txt (fwd)
Viktor Dukhovni wrote: > The idea is to log the DNSKEY RRs observed at each zone apex. > Without the proposed flag, one would also have to log denial of > existence which would make the logs much too large. Can you expand on what you mean by "much too large"? There are already existing large scale passive DNS systems that log every RRset that they observe, and on relatively modest amounts of hardware. Is transparency for DNSSEC really all that less tractable than the "log every RRset" problem? -- Robert Edmonds ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Terminology question: split DNS
Artyom Gavrichenkov wrote: > On Mon, Mar 19, 2018 at 5:47 PM, Paul Hoffman <paul.hoff...@vpnc.org> wrote: > > [..] the basic point is that the > >correspondence between a given FQDN (fully qualified domain name) and a > >given IPv4 address is no longer universal and stable over long periods." > > IP v. being whatever, 4 or 6, there's a bunch of reasons there's > virtually no correspondence between a given FQDN and a given IP > address nowadays. E.g. CDNs. There are many reasons that globally inconsistent DNS RRsets exist, e.g. load balancers, CDNs, split [horizon] DNS, etc. I think split horizon is a specific type of global inconsistency that doesn't necessarily encompass the other types. -- Robert Edmonds ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Please review in terminology-bis: QNAME
Stephane Bortzmeyer wrote: > On Mon, Dec 11, 2017 at 07:30:27AM -0800, > Paul Hoffman <paul.hoff...@vpnc.org> wrote > a message of 16 lines which said: > > > Some of the new terms added to the terminology-bis draft > > (https://datatracker.ietf.org/doc/draft-ietf-dnsop-terminology-bis/)since > > RFC 7719 can expose what some (but not all) people perceive as lack > > of clarity in RFC 1034/1035. This week, we hope you will look at the > > definition in the draft for "QNAME". > > As I mentioned in this errata > <https://www.rfc-editor.org/errata/eid4983>, I think RFC 2308 was > wrong in redefining QNAME. My personal preference would be to change > the second paragraph to "RFC 2308 proposed another definition, > different from the original one. Since it is actually a different > concept, it would be better to find another name for it. Here, QNAME > retains the original definition of RFC 1034." > > Otherwise, if the WG prefers, I can live with the current text :-( I agree with Stephane. The STD 13 definition of QNAME is extremely clear while the RFC 2308 re-definition seems rare enough that it tends to occur mainly in discussions about how to define QNAME :-\ -- Robert Edmonds ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Ask for advice of 3 new RRs for precise traffic scheduling
左鹏 wrote: > The "precise traffice scheduling" i mentioned is not only for performance > reason, but also for capacity reason. CDNs already have the ability to do precise traffic scheduling for both performance and capacity reasons, using the existing capabilities built into the DNS. > yes, more resolvers are good to improve user experience. > but also maybe we should notice each CDN node has different capacity.(it is > the real in practice). > a "weight-aware" rosolver can schedule clients to diffent nodes according to > weight pricisely. > or shall we do something only for authoritative server like defining the > weighted A/x? No, the DNS's existing capabilities provide more than enough power for CDNs for these use cases. > btw, any comments on the weightd CNAMEXs for multi-CDN? :) I don't have any direct experience of the multi-CDN use case. I would think the intra-CDN case for CDN node selection can be generalized to the multi-CDN case for CDN provider selection, though you probably have fewer owner names to work with. -- Robert Edmonds ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Ask for advice of 3 new RRs for precise traffic scheduling
bert hubert wrote: > On Wed, Dec 13, 2017 at 05:36:32PM +0800, zuop...@cnnic.cn wrote: > > so far as i know, many CDNs already use similar methods as you mentioned > > in PowerDNS 4.1.1 > > but i think only the Authoritative Server change is not enough, support > > on the recursive server is also very important . > > because the resolver determines the reponse to clients. > > This is true. A typical resolver will serve around 50,000 to 2,000,000 > users (although this is rare). This means that for 60 seconds, you shift > around 'a hundred thousand' potential users. > > In practice, this appears to be good enough from what I hear. > > Or let me put it another way, before we burden the DNS protocol with another > record type we have to add downgrade/workaround/DNSSEC support for, we > should have numbers that say it solves a problem. > > CDNs could maybe chime in. Hi, With my CDN hat on, I don't see any need to turn over scheduling decisions to resolvers. Extremely precise amounts of traffic can already be scheduled to individual CDN nodes because you have a large pool of owner names to work with, not a single owner name, and every (QNAME, QTYPE, resolver IP, client subnet [if present], anycast location that receives the query) tuple is an opportunity to make a unique scheduling choice. Generally, however, assignments to CDN nodes should be relatively sticky. You want to be shifting traffic for performance reasons, not capacity reasons. Or, put another way, we like existing resolver implementations just fine, we just wish there were a lot more resolver instances, and closer to clients :-) -- Robert Edmonds ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Clarifying referrals (#35)
Paul Vixie wrote: > Matthew Pounsett wrote: > > I haven't got the time this morning to search release notes, but I'm > > fairly sure that in 2012, when you wrote that article, current versions > > of BIND were already handing out REFUSED to indicate "I'm not > > authoritative for that." At the very least it began doing that not long > > after. > > the implication of REFUSED is that if someone else asked this question, we > might be able to answer. so if BIND is doing what you say, it's wrong. In theory, any authoritative nameserver could secretly also be a resolver that will answer from cache if the right client sends it the same question. Does that make it OK, then? The REFUSED RCODE is documented as: Refused - The name server refuses to perform the specified operation for policy reasons. For example, a name server may not wish to provide the information to the particular requester, or a name server may not wish to perform a particular operation (e.g., zone transfer) for particular data. In this case the server's policy would be that it doesn't perform a particular operation (i.e., QUERY) for particular data (i.e., data that it's not authoritative for). Where does the implication that REFUSED is only appropriate if the server might be able to answer if "someone else" asks the question come from? -- Robert Edmonds ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] DNSOP Call for Adoption - draft-tale-dnsop-serve-stale
tjw ietf wrote: > August is over and my self-imposed holiday is over, so it's time to get > busy again. We have this document marked as a candidate for adoption. > > This starts a formal Call for Adoption for draft-tale-dnsop-serve-stale > > The draft is available here: > https://datatracker.ietf.org/doc/draft-tale-dnsop-serve-stale/ > > Please review this draft to see if you think it is suitable for adoption by > DNSOP, and comments to the list, clearly stating your view. > > Please also indicate if you are willing to contribute text, review, etc. > > *If You have already stated your position for or against adoption, we are > counting those so you do not need to repeat yourself. * > > This call for adoption ends: 19 September 2017 > > Thanks, > tim wicinski > DNSOP co-chair Hi, I support the adoption of this document. Comments: This document is marked as updating 1034 and 1035 but it's not clear what text from those documents is being updated. E.g. compare to "NXDOMAIN: There Really Is Nothing Underneath" (RFC 8020) which explicitly documents its revisions in its Section 3. I think the claim in the introduction, "Notably, the original DNS specification does not say that data past its expiration cannot be used" should either be justified further or removed. The "should again be consulted" text from STD 13 could be read in isolation as permitting serve stale, but it's the weakest text out of these three TTL definitions given in STD 13: RFC 1034 §3.6: "The TTL describes how long a RR can be cached before it should be discarded. […] The meaning of the TTL field is a time limit on how long an RR can be kept in a cache." RFC 1035 §3.2.1: "a 32 bit […] integer that specifies the time interval that the resource record may be cached before the source of the information should again be consulted." RFC 1035 §4.1.3: "a 32 bit […] integer that specifies the time interval (in seconds) that the resource record may be cached before it should be discarded." That is, if "the original DNS specification does not say that data past its expiration cannot be used" is true, then this document doesn't need to update STD 13, and maybe it should only be an informational document. But if it's not true (and I don't think it is, based on the other two TTL definitions in STD 13), then a new TTL definition should be given that permits the serve stale mechanism. Also, just for fun, this text from RFC 882 exists (p.28 "Resolvers with cache management") and is even stronger than the text in STD 13: "When a resolver caches a returned resource record it must also remember the TTL field. The resolver must discard the record when the equivalent amount of time has passed." -- Robert Edmonds ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Status of "let localhost be localhost"?
Stuart Cheshire wrote: > [*] 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. As far as I can tell, "let 127.0.0.1 be loopback" is more stupid because RFC 1122 states that addresses of the form 127.0.0.0/8 MUST be used for loopback traffic, while the considerations for "let localhost be loopback" in RFC 6761 §6.3 use non-mandatory language. -- Robert Edmonds ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Status of "let localhost be localhost"?
Ted Lemon wrote:
> But we are arguing that "localhost" should be treated specially by every
> piece of software that looks at it, when its default meaning is "look up
> localhost in the DNS and connect to one of the addresses that you get in
> response."
RFC 6761 §6.3 already says that "localhost" should be treated specially
by pretty much every piece of software that looks at it. But especially:
2. Application software MAY recognize localhost names as special, or
MAY pass them to name resolution APIs as they would for other
domain names.
3. Name resolution APIs and libraries SHOULD recognize localhost
names as special and SHOULD always return the IP loopback address
for address queries and negative responses for all other query
types. Name resolution APIs SHOULD NOT send queries for
localhost names to their configured caching DNS server(s).
(In practice, "localhost" already does get treated specially, especially
by operating systems that place a "Name Service Switch" or similar
component in front of the DNS stub resolver. If you put
"http://localhost/; into your browser bar, you shouldn't see a DNS query
for "localhost" leave your machine.)
Doesn't "Application software MAY recognize localhost names as special"
already give more than enough permission for browser developers to treat
"localhost" (and any subdomain of "localhost") specially, for instance
by hardcoding the names to a loopback address, or filtering the result
from the system's name resolver to verify that only a loopback address
is used? Or only allowing the "Secure Context" flag to be set when the
localhost name resolves to a loopback address.
draft-west-let-localhost-be-localhost-03 upgrades the requirements in
RFC 6761 §6.3 to make them much stricter, for all applications,
converting SHOULDs to MUSTs, etc. So we're not arguing about whether
localhost "should" be treated specially, but whether it MUST be treated
specially, by all applications. Can the W3C not impose stricter
requirements on browser developers even if 6761 doesn't impose mandatory
treatment for "localhost"?
Maybe a smaller addition to RFC 6761 §6.3 would be sufficient for the
W3C? Something like:
Application software specifications MAY require that application
software recognize localhost names as special.
But that seems weird because it's arguably just a specific case of
requirement #2.
--
Robert Edmonds
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Fwd: New Version Notification for draft-pan-dnsop-edns-isp-location-02.txt
Hi, Dave Lawrence wrote: > Have you had any feedback from authority server implementers who are > interested in using this? As an authority server implementer at a CDN -- we have no interest in using anything like this. > I'm having a hard time picturing many CDNs wanting to switch, in no > small part because geo is not the only goal of mapping. The > < COUNTRY, AREA, ISP > tuple that is defined is insufficient. Yes, as has been made clear in previous discussion on this document. Even if it were sufficient, using only a <COUNTRY, AREA, ISP> tuple to direct traffic makes it incumbent on the resolver operator to accurately geolocate the client IP and faithfully transmit the result to the authoritative operator. If the resolver operator is an ISP, this proposal would give the ISP an enormous amount of counter- traffic engineering power by spoofing the COUNTRY/AREA fields. -- Robert Edmonds ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] EDNS0 clientID is a wider-internet question
Paul Vixie wrote: > Robert Edmonds wrote: > > Paul Vixie wrote: > ... > > > some of run our own rdns. some use vpn's. some use opendns or similar. > > > > The internet now has billions of users. With the possible exception of > > OpenDNS who have gone to admirable lengths to populate their knowledge > > base with device-specific configuration instructions [0], I don't think > > any of the choices you've listed are available to the "average enduser", > > who almost by definition lacks the specialized technical knowledge > > needed to select an alternative DNS resolution provider. > > italy's experience in blocking unlicensed online gambling sites proved > otherwise, as would would SOPA had it passed. any rDNS service that blocks > lookups in a way that does not align with a user's interests, will not be > used, other than to locate the nec'y bypass recipes. most of those recipes > do not require deep technical knowledge. > > a minute or so of searching turned up these: > > https://www.howtogeek.com/167533/the-ultimate-guide-to-changing-your-dns-server/ > > https://support.hidemyass.com/hc/en-us/articles/202720776-Changing-your-DNS-settings-on-Windows-Mac-Android-iOS-Linux > > also, there's an app for that: > > https://play.google.com/store/search?q=dns%20changer%20no%20root Yes, you and I are well aware that there are apps and howtos for changing DNS settings available online. If you can find, read, and execute one of those guides -- congrats, you're not an average user. -- Robert Edmonds ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] EDNS0 clientID is a wider-internet question
Paul Vixie wrote: > Paul Wouters wrote: > > On Tue, 25 Jul 2017, Paul Vixie wrote: > > > > > users believe that the recursive name server operator has aligned > > > interests, and for that reason one shouldn't say "it's easy to bypass" > > > but rather "end-user cooperation is required." > > > > So if 8.8.8.8 and your local ISP's nameserver do this to track you, what > > choice does an average enduser have? > > some of run our own rdns. some use vpn's. some use opendns or similar. The internet now has billions of users. With the possible exception of OpenDNS who have gone to admirable lengths to populate their knowledge base with device-specific configuration instructions [0], I don't think any of the choices you've listed are available to the "average enduser", who almost by definition lacks the specialized technical knowledge needed to select an alternative DNS resolution provider. [0] https://support.opendns.com/hc/en-us/categories/204012907-OpenDNS-Device-Configuration -- Robert Edmonds ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] EDNS0 clientID is a wider-internet question
RFC 7217 ("A Method for Generating Semantically Opaque Interface
Identifiers with IPv6 Stateless Address Autoconfiguration (SLAAC)") is
sort of relevant. From the introduction of that document, which
describes drawbacks of traditional IPv6 SLAAC addresses:
o Since the resulting Interface Identifiers are constant across
networks, the resulting IPv6 addresses can be leveraged to track
and correlate the activity of a host across multiple networks
(e.g., track and correlate the activities of a typical client
connecting to the public Internet from different locations), thus
negatively affecting the privacy of users.
That drawback translates pretty much directly to the 48-bit MAC
CLIENT-IDENTIFIER variant in draft-tale-dnsop-edns0-clientid.
For the dnsmasq use case, I would guess there's a CPE router/gateway
device involved, in which case the CPE device has a unique
device-specific value burned in (e.g., a WAN-facing MAC address, or
serial number) which could easily be hashed together with the client's
MAC address to produce a stable but opaque identifier specific to the
particular CPE device involved. (That is, if the client device travels
to a different network gatewayed by a CPE device implementing the same
scheme, the identifier generated would be different, because the CPE
device has a different WAN-facing MAC address.) So, the cloud would
still wind up executing the PII -> policy translation, but you take the
'P' out of 'PII', and don't need to store any extra state on the CPE
device.
Ted Lemon wrote:
> It would be nice if there were an RFC to point to that used a method that
> didn't include PII. For the use cases of which I am ware, there is no
> need to identify individual devices: only policies. What's lacking is a
> way to do this in the home router, so the PII winds up getting exported to
> the cloud not because that's necessary to accomplish the filtering but
> because it's the only available place where the translation from
> PII->policy can be done in practice. Unfortunately, solving _that_
> problem is definitely out of scope for DNSOP.
>
> On Thu, Jul 20, 2017 at 7:00 PM, George Michaelson <g...@algebras.org> wrote:
>
> > I probably will not carry the WG with me on this, but I find myself
> > thinking the PII aspect of client-ID makes it a wider-internet
> > question and we might have views as a WG, and promote questions as a
> > WG, but I think the "final call" on this is something which needs more
> > than WG approval.
> >
> > Its a big question. I'd actually welcome adoption on many levels, but
> > that isn't to pre-empt that it goes to WGLC. I think we need to
> > formalize the issues and take them out of the WG for review and
> > discussion.
> >
> > documenting current practice is ok btw, but .. PII.
> >
> > -G
> >
> > ___
> > DNSOP mailing list
> > DNSOP@ietf.org
> > https://www.ietf.org/mailman/listinfo/dnsop
> >
> ___
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop
--
Robert Edmonds
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [internet-dra...@ietf.org: New Version Notification for draft-edmonds-dnsop-capabilities-00.txt]
Mark Andrews wrote: > There are three things that made it hard to deploy new features. > > 1) Firewall vendor shipping firewalls with ridiculously strict rules >with zero evidence that they are needed. > > 2) Misimplementation of STD 13 and RFC 2671 by nameserver vendors. > > 3) Unknown EDNS option behaviour was not well defined by RFC 2671, >this is addressed in RFC 6891. > > 1 and 2 made it impossible to do a clean update from RFC 2671 to > RFC 6891 which tightened the unknown EDNS option behaviour. Proper > implementation of RFC 2671 would have allowed the EDNS version 1 > to be used to signal that RFC 6891 unknown option behaviour is > required. I'm more that willing to strip out any opinionated text in the draft about what makes it hard to deploy new DNS features. I agree that there is a lot of bad code out there, but my primary use case is for greenfield deployments where both client and server side have new code, and there is a need to detect the other side's capabilities. If you have old or bad code running in the client, server, or middlebox, you just don't get to use the new features. > I don't see how adding a capabilities option will help here when > the primary problem is bad code. There are cases where all you need is a feature flag, and in some cases, the ability to remember an advertised feature for subsequent queries. Currently there are 16 reserved bits between the DNS and EDNS headers that require standards action to use. The small number of bits available and the difficulty required to obtain one (the last allocation was over 10 years ago) means that an EDNS0 option is a more likely path for a feature flag, but that path wastes a minimum of 5 octets. There's a limited amount of space available in a UDP DNS query packet, maybe around ~200 octets for a query with a maximum length QNAME and a plausible set of EDNS0 options. The "DNS Features" capability in my proposal provides space for 256 feature bits at a cost of up to 32 octets. If we make that space a FCFS registry (and provide a handful of "Reserved for Local/Experimental Use" bits) it becomes easier to experiment with new features (using a new bit in an existing EDNS0 option is easier than implementing an entirely new EDNS0 option). -- Robert Edmonds ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Fwd: New Version Notification for draft-muks-dnsop-dns-opportunistic-refresh-00.txt
Stephen Morris wrote: > Hi > > We have submitted a new draft which attempts to formalize an idea that > has been kicking around for a couple of years, namely to use serial > number information from DNS responses to determine whether stale records > in a cache can be refreshed without the need for an upstream query. > > Please send comments and feedback to the list. > > Stephen Hi, I noticed this draft defines an EDNS0 option that communicates a single bit of information: FLAGS Flags field. Bit 7 of this field is the request/acknowledge flag. This bit MUST be clear in requests from the resolver to the authoritative server and MUST be set in responses from the authoritative server to the resolver. By flipping the bit in a response, answers from misbehaving authoritiative servers that just copy unknown EDNS0 options from query to response are not mistakenly treated as being from servers that understand opportunistic DNS refresh. Just an observation: this bit indicates client-side support in queries and server-side support in responses. This is the exact use case for the "DNS Features" capability in draft-edmonds-dnsop-capabilities [0]. And the capabilities option already detects and discards echoing, so no need to flip the bit between query and response. [0] https://tools.ietf.org/html/draft-edmonds-dnsop-capabilities-00#section-4.1 -- Robert Edmonds ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] [internet-dra...@ietf.org: New Version Notification for draft-edmonds-dnsop-capabilities-00.txt]
Hi, I've written a proposal for adding capability signaling to the DNS protocol that may be of interest to this group. The git repository is here: https://github.com/edmonds/draft-edmonds-dnsop-capabilities. - Forwarded message from internet-dra...@ietf.org - Date: Sun, 02 Jul 2017 13:42:39 -0700 From: internet-dra...@ietf.org To: Robert Edmonds <edmo...@mycre.ws> Subject: New Version Notification for draft-edmonds-dnsop-capabilities-00.txt A new version of I-D, draft-edmonds-dnsop-capabilities-00.txt has been successfully submitted by Robert Edmonds and posted to the IETF repository. Name: draft-edmonds-dnsop-capabilities Revision: 00 Title: Signaling DNS Capabilities Document date: 2017-07-02 Group: Individual Submission Pages: 9 URL: https://www.ietf.org/internet-drafts/draft-edmonds-dnsop-capabilities-00.txt Status: https://datatracker.ietf.org/doc/draft-edmonds-dnsop-capabilities/ Htmlized: https://tools.ietf.org/html/draft-edmonds-dnsop-capabilities-00 Htmlized: https://datatracker.ietf.org/doc/html/draft-edmonds-dnsop-capabilities-00 Abstract: This document defines an Extension Mechanisms for DNS (EDNS0) option that allows DNS clients and servers to signal support for DNS protocol capabilities. Clients and servers that support this option can take advantage of new DNS protocol features when completing a transaction, and by caching the set of capabilities advertised by a DNS server, a DNS client can utilize any mutually supported DNS protocol capability in subsequent queries. Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat - End forwarded message - -- Robert Edmonds ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] draft-tale-dnsop-serve-stale
Jared Mauch wrote: > IOn Mar 27, 2017, at 5:59 PM, P Vix <p...@redbarn.org> wrote: > > > > I agree to review and comment. Note that I am provisionally negative to the > > idea itself, and my review may reflect that. Vixie > > > I will note there are other implementations out there as well, such as in > unbound. serve-expired configuration directive is available there as well. Though, the algorithm described in this document is a much different algorithm than the one in Unbound. If I understand Unbound's serve-expired algorithm correctly, it always serves from cache if available (regardless of expiration status), and if what it served to the client happened to be expired, it triggers a post-response fetch to update the cache asynchronously. That can end up serving a lot more stale bread than is strictly necessary if your Unbound server only serves a few clients. (I guess Unbound could sort of be said to implement this draft, but with the client response timer hardcoded to 0 and the maximum stale timer hardcoded to ∞.) I support adoption of this document. -- Robert Edmonds ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Proposal for a new record type: SNI
John R Levine wrote:
> > http://www.bieberfever.com/ ("The Official Juston Bieber Fan Club") is
> > hosted by Akamai on 23.38.103.18.
> > According to DNSDB (IMO the best passive DNS service), there are 605
> > other sites *also* hosted on 23.38.103.18.
>
> > No doubt pervasive monitors (and others) will use passive DNS systems
> > to build a map of SNI DNS RRs, but I'd much much rather have the men
> > in black thinking that I'm visiting www.precisiondoor.net,
> > www.theman.in, or www.worldsleadingcruiselines.com than knowing my
> > dirty little secret love of the Bieb...
>
> I really don't get this. The bad guys we're worried about have to be
> sophisticated enough to do a packet capture and pick the SNI bits out of TLS
> handshakes. How plausible is it that those bad guys would say, oh, using a
> script to find the cert hashes that will reveal the specific site is too
> hard so never mind?
Isn't the server's certificate encrypted in TLS 1.3?
And even in previous versions of TLS, at least in the CDN world it's
somewhat common to put unrelated domains on the same SAN certificate.
--
Robert Edmonds
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Proposal for a new record type: SNI
Hi, Ben: In your draft, the reason for not using TXT is given as: 2.1.3. Using TXT We could encode this information in a TXT record, but that would violate the intended purpose of TXT records: to convey information to human readers. I'm not sure if it's true that TXT records are intended only for human consumption. TXT RRs contain "descriptive text" where "[t]he semantics of the text depends on the domain where it is found". If you define "where the domain is found" as, e.g., domains like _443._tcp._sni.www.example.com, then you get to define the semantics of what is described by the TXT record at that location. I think DKIM is an example of a protocol that uses this kind of scheme with TXT records. -- Robert Edmonds ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Proposal for a new record type: SNI
Ben Schwartz wrote: > Hi dnsop, > > I've written a draft proposal to improve the privacy of TLS connections, by > letting servers use the DNS to tell clients what SNI to send. > > https://tools.ietf.org/html/draft-schwartz-dns-sni-01 > > I've incorporated some helpful feedback [1] from the TLS WG, but now I > could use your help analyzing the DNS side. All comments welcome; this > draft will change based on your feedback. > > One particular issue that I could use advice on: should this be a new > record type, or should it reuse/repurpose an existing type like SRV or PTR? > > Thanks, > Ben > > [1] https://www.ietf.org/mail-archive/web/tls/current/msg22353.html Hi, Ben: I'm kind of curious: your examples are pretty HTTP-centric, and HTTP already has some pretty strong features for origins to persistently modify how clients perform TLS, i.e., HTTP Strict Transport Security and HTTP Public Key Pinning, along with preloading of those settings by the browser vendors. Why not follow that same model for the functionality in your draft? -- Robert Edmonds ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] ALT-TLD and (insecure) delgations.
Warren Kumari wrote:
> The largest outstanding issue is what to do about DNSSEC -- this is
> (potentially) a problem for any / all 6761 type names.
> The root is signed, so if a query leaks into the DNS (as they will),
> an (unaware) validating resolver will try resolve it, and will expect
> either a signed answer, or proof of an insecure delegation; without
> this things will look bogus, and so resolvers will SERVFAIL.
>
> Clearly, a signed answer isn't feasible, so that leaves 2 options - 1:
> simply note that validation will fail, and that SERVFAIL will be
> returned in many case (to me this seems "correct"), or 2: request that
> the IANA insert an insecure delegation in the root, pointing to a:
> AS112 or b: an empty zone on the root or c" something similar.
Hi, Warren:
I'm kind of confused. If a .ALT query leaks into the DNS, and there's
neither a secure or insecure delegation in the root, isn't the result a
signed NXDOMAIN, not a SERVFAIL?
; <<>> DiG 9.11.0-P1 <<>> +dnssec foo.alt
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 36917
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 0, AUTHORITY: 6, ADDITIONAL: 1
--
Robert Edmonds
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Fwd: New Version Notification for draft-bellis-dnsop-xpf-00.txt
Ray Bellis wrote: > Yes, that seems like a reasonable suggestion, although it would be a > shame to have to rev the doc if another IP version should even happen to > be introduced in the future... It can be rev'd in the same document that introduces a DNS address RR for that address family :-) -- Robert Edmonds ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Fwd: New Version Notification for draft-bellis-dnsop-xpf-00.txt
Ray Bellis wrote: > Spurred on by Warren's announcement of a Docker image that uses NGINX to > proxy TLS connections into DNS servers that don't natively support TLS, > I've just written up this short draft describing an EDNS0 option that > allows smart proxies to tell the backend server what the original client > IP address was. > > The master doc is at https://github.com/raybellis/draft-bellis-dnsop-xpf Hi, Ray: The values used by the "IP Version" field should be specified: IP Version: The IP protocol version number used by the client. Since the field is 4 bits long I would guess this field happens to be the same as the version field in the IP header [0], maybe with the restriction that the field can only take on the values 4 and 6? [0] http://www.iana.org/assignments/version-numbers/version-numbers.xhtml -- Robert Edmonds ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] DNSOP Call for Adoption draft-vixie-dns-rpz
Viktor Dukhovni wrote: > On Wed, Dec 21, 2016 at 12:39:55PM -0500, Matthew Pounsett wrote: > > > RPZ is not the ideal, but it works, and goes beyond being deployable–it is > > deployed. > > I am curious to understand how RPZ zone transfers are (intended to > be) secured. It sounds like the reason for standardizing RPZ is > to allow interoperable sharing of policies via replication of zone > data, and so an appropriate security mechanism would seem to be > desirable here to authenticate the transfer of data from the RPZ > master zone. Is there a related specification for that? Are you looking for RFC 2845, "Secret Key Transaction Authentication for DNS (TSIG)"? That authenticates the transaction but the contents of the zone is transferred in the clear. (I don't think there are any servers that implement DNS-over-TLS for zone transfers.) -- Robert Edmonds ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] A mention of draft-fujiwara-dnsop-resolver-update and draft-weaver-dnsext-comprehensive-resolver
Stephane Bortzmeyer wrote: > On Mon, Dec 05, 2016 at 01:44:29PM -0800, > David Conrad <d...@virtualized.org> wrote > a message of 53 lines which said: > > > It might be more helpful if you perhaps could explain why you're not > > convinced? > > 1) Glue is only for in-child nameservers. The majority of delegations > don't use glue. So, glue is only a part of the problem. I can easily believe that most delegation NS RRsets don't directly require glue address records. But it stands to reason that all glueless delegations must ultimately rely on other delegations with address glue in order to be resolved. > 2) The proper behaviour is for the child NS TTL to be used because it > is authoritative. This is what resolvers like Unbound do. If all > resolvers don't do it, we should change that, instead of allowing to > change the TTL in the parent. Sure, Unbound implements the trustworthiness ranking in RFC 2181 §5.4.1, like other implementations, so for a given zone the apex NS RRset will overwrite the delegation NS RRset. But it doesn't go out of its way to fetch authoritative data from the child to replace cached glue address records. (Unless you turn on Unbound's "harden-referral-path" option.) > 2bis) Section 2.1 of draft-vixie-dnsext-resimprove seems the way to go > (with the provisions of its section 2.2, to avoid ghost domains.) If I understand the complaint in the blog post you linked, the other issue that they want to avoid (which isn't mentioned at all AFAICS) is avoiding any extra RTTs to fill in glue records from the child. But if you don't mind possible extra RTTs there is the obvious solution of providing customers with nameserver names whose address records are not also glue address records. -- Robert Edmonds ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] New Version Notification for draft-dickinson-dnsop-dns-capture-format-00.txt
Paul Hoffman wrote: > On 1 Nov 2016, at 10:54, Philip Homburg wrote: > > > I find it hard to believe that after compression, the BSON encoded > > version of the DNS data would be a lot smaller than just the > > raw DNS data. > > Please note the use case in the draft: they don't want to burden the CPU of > the box with compressing with gzip, bzip, and so on. This draft compares lz4 vs gzip vs xz. If minimizing CPU usage is a concern, I'd be curious to see zstd (http://zstd.net/) added to the set of compressors being compared. I've found that zstd is often capable of beating gzip's compression ratio while consuming much less CPU. -- Robert Edmonds ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] status opcode?
Hi, What are status queries? Were they ever defined? Are they obsolete? -- Robert Edmonds ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Looking for IANA registry for --xn
Jim Reid wrote: > > On 7 Oct 2016, at 03:33, Phillip Hallam-Baker <ph...@hallambaker.com> wrote: > > > > Protocol matters. And just because IANA does 'assignments' that are not > > 'registrations' doesn't mean that is right or should continue. > > I’m sure the RIRs and the hundreds of millions of people who are using IP > addresses because of IANA ‘assignments’ will be delighted to hear that. Is the "IANA IPv4 Address Space Registry" not a registry? http://www.iana.org/assignments/ipv4-address-space/ipv4-address-space.xhtml http://www.iana.org/assignments/ipv6-address-space/ipv6-address-space.xhtml -- Robert Edmonds ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Looking for IANA registry for --xn
Donald Eastlake wrote: > Sure, you can consider the root zone to be the registry for TLDs but the > point is the xn-- labels are recommended to be interpreted specially at the > user interface at all levels... Nor would this say anything about "CCHH" prefixed labels in general. At the TLD level there seems to be an agreement at least(?) for new gTLDs to reserve all "CCHH" prefixes in delegated names other than xn--: SPECIFICATION 6 REGISTRY INTEROPERABILITY AND CONTINUITY SPECIFICATIONS 1. Standards Compliance 1.1. DNS. Registry Operator shall comply with relevant existing RFCs and those published in the future by the Internet Engineering Task Force (IETF), including all successor standards, modifications or additions thereto relating to the DNS and name server operations including without limitation RFCs 1034, 1035, 1123, 1982, 2181, 2182, 2671, 3226, 3596, 3597, 4343, and 5966. DNS labels may only include hyphens in the third and fourth position if they represent valid IDNs (as specified above) in their ASCII encoding (e.g., “xn--ndk061n”). https://newgtlds.icann.org/sites/default/files/agreements/agreement-approved-09jan14-en.htm -- Robert Edmonds ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Where in a CNAME chain is the QNAME?
Paul Hoffman wrote: > Oddly, "owner name" is correct here. From RFC 1035, Section 3.2.1 which > describes the format of resource records: Compare that section to the nearly identical §4.1.3, which replaces this sentence: All RRs have the same top level format shown below: with: The answer, authority, and additional sections all share the same format: a variable number of resource records, where the number of records is specified in the corresponding count field in the header. Each resource record has the following format: But, the "All RRs" part of §3.2.1 is still accurate, because an entry in the question section is not a RR. There are some other differences between §3.2.1 and §4.1.3, for instance §3 uses "owner name" while §4 uses "domain name" to describe the NAME field, and the infamous signed vs. unsigned definition of the TTL field. -- Robert Edmonds ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Mandated order of CNAME records in a CNAME chain?
Stephane Bortzmeyer wrote:
> On Thu, Sep 29, 2016 at 08:17:28AM +,
> Viktor Dukhovni <ietf-d...@dukhovni.org> wrote
> a message of 57 lines which said:
>
> > By the way, is it the case that CNAMEs in the answer section MUST
> > appear in their natural chaining order:
>
> Very good question but, IMHO, it is thread-stealing (hence changing
> the subject, and removing thread headers).
I think there was already a thread on this topic recently on this list
("Order of CNAME and A in Authoritative Reply" from August 2015). There
was some discussion over "adding" versus "appending" and it was pointed
out that a lot of existing code (e.g., the BSD stub resolver) was
written using the "add at the end" meaning.
--
Robert Edmonds
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Where in a CNAME chain is the QNAME?
Stephane Bortzmeyer wrote: > On Mon, Sep 26, 2016 at 09:04:54AM -0400, > Matt Larson <m...@kahlerlarson.org> wrote > a message of 41 lines which said: > > > I'd venture that more people familiar with the subject matter would > > define QNAME as the name in the question section of a DNS message. > > (That's my sense of the definition, FWIW.) > > What about adding this text to the Terminology section of the draft? > >"QNAME": it is defined in and >in , section 4.1.2, but, because target="RFC2308"/> provides a different definition, we repeat the >original one here: the QNAME is the owner name of the record in the >Question section. The QNAME is a domain name, but is it an owner name? There is no owned record data in the question section (and the entries in the question section are not RRs). -- Robert Edmonds ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Where in a CNAME chain is the QNAME?
Paul Hoffman wrote:
> On 26 Sep 2016, at 0:33, Peter van Dijk wrote:
>
> > 2308 does not “redefine” QNAME. It clarifies that the usage in 1034
> > 4.3.2 is the definition we use in RFCs. 1035 4.1(.2) does not conflict
> > with this; the QNAME there is just the initial QNAME.
>
> This seems like a very limited view of RFC 1034. RFC 1034 actually defines
> QNAME in Section 3.7.1:
>
> 3.7.1. Standard queries
>
> A standard query specifies a target domain name (QNAME), query type
> (QTYPE), and query class (QCLASS) and asks for RRs which match.
>
> Further, the usage in Section 4.3.2 does not say that the QNAME is the last
> name in the chain, just that the algorithm itself repeats with a new value
> for QNAME:
>
> If the data at the node is a CNAME, and QTYPE doesn't
> match CNAME, copy the CNAME RR into the answer section
> of the response, change QNAME to the canonical name in
> the CNAME RR, and go back to step 1.
If STD 13 were to be typeset like a technical book, "QNAME" in 1034
§4.3.2 would be styled using the book's typographical convention for a
variable name.
The exact same formulation in §4.3 ("change … to the canonical name in
the CNAME RR") is used again in the resolver algorithm in §5.3:
The following resolver algorithm assumes that all functions have been
converted to a general lookup function, and uses the following data
structures to represent the state of a request in progress in the
resolver:
SNAME the domain name we are searching for.
STYPE the QTYPE of the search request.
SCLASS the QCLASS of the search request.
[…]
5.3.3. Algorithm
The top level algorithm has four steps:
[…]
4. Analyze the response, either:
[…]
c. if the response shows a CNAME and that is not the
answer itself, cache the CNAME, change the SNAME to the
canonical name in the CNAME RR and go to step 1.
[…]
Since "SNAME" doesn't conflict with a term from another part of the
document set, it's clear that SNAME is being used as a variable name. So
the parallel use in §4.3.2 ("change QNAME to the canonical name") must
also be as a variable name, not a terminological (re)definition.
--
Robert Edmonds
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Where in a CNAME chain is the QNAME?
Viktor Dukhovni wrote: > On Fri, Sep 23, 2016 at 10:22:32AM +0200, Stephane Bortzmeyer wrote: > > > On Tue, Sep 20, 2016 at 06:13:50PM +0200, > > Stephane Bortzmeyer <bortzme...@nic.fr> wrote > > a message of 68 lines which said: > > > > > This issue was spotted by Peter van Dijk. It is about > > > draft-ietf-dnsop-nxdomain-cut-05, recently approved by IESG. The > > > problem is the definition of "QNAME" when there is a CNAME chain. > > > > OK, after reading the discussion, my opinion, as an author (but I'll > > of course defer the decision to the working group, the WG chairs, the > > RFC editor and the flying spaghetti monster): > > > > The re-definition of QNAME by RFC 2308 is awkward and does not match > > the general usage, or the previous definitions. Therefore, I prefer to > > keep the "common sense" usage "QNAME is the owner name of the record > > in the Question Section". Which means that, in my example, the QNAME > > is "www.afnic.fr" and the current text of > > draft-ietf-dnsop-nxdomain-cut-05 is correct. > > This would I believe cause problems if one then concludes that the > subtree below the QNAME is absent. How would one conclude that, when the document is careful to distinguish between the QNAME and the "denied name"? Abstract This document states clearly that when a DNS resolver receives a response with response code of NXDOMAIN, it means that the domain name which is thus denied AND ALL THE NAMES UNDER IT do not exist. […] "Denied name": the domain name whose existence has been denied by a response of rcode NXDOMAIN. In most cases, it is the QNAME but, because of [RFC6604], it is not always the case. […] Warning: if there is a chain of CNAME (or DNAME), the name which does not exist is the last of the chain ([RFC6604]) and not the QNAME. The NXDOMAIN stored in the cache is for the denied name, not always for the QNAME. […] -- Robert Edmonds ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] DNS-in-JSON draft
Paul Hoffman wrote: > Greetings again. I have updated my draft on describing DNS messages in JSON. > I still don't think that this WG needs to adopt this given that it is, as > far as I can tell, thinly implemented. I think it's probably about baked > enough for me to take it to the Independent Submissions editor to become an > Experimental RFC. If y'all have any comments on it, please send them along > and I'll incorporate before I move it along to RFChood. Hi, Paul: In section 3: A paired DNS query and response is represented as an object. Two optional members of this object are names "queryRecord" and "responseRecord", and each has a value that is an message object. This design was chosen (as compared to the more obvious array of two values) so that a paired DNS query and response could be differentiated from a stream of DNS messages whose length happens to be two. Why do you call these fields "queryRecord" and "responseRecord"? It seems to me that "queryMessage" and "responseMessage" would be more intuitive. In section 7: This document has no effect on IANA registries. Do you plan to register a media type for this format? There is some precedent: the "application/dns" media type was registered for the experimental format defined in RFC 2540 "Detached Domain Name System (DNS) Information". Nit: "Questing section" → "Question section" -- Robert Edmonds ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] my lone hum against draft-wkumari-dnsop-multiple-responses
Paul Wouters wrote: > The reason I hummed against this idea is that I think it is better to > teach validators to not strip dnssec signed additional data, and just > supply the data there. > > The current document as explained today seemed to limit itself already > to in baliwick or subzone data. Hi, I couldn't make it to IETF 96, but consider this a virtual hum against this idea also. > That seems a much simpler solution to the proposed problem. If I'm not mistaken, there's also no specification work required, either. (Besides, perhaps, specifying a RR that configures the behavior in the nameserver.) Nameservers are allowed to add “useful” RRs to the additional section, using local data. -- Robert Edmonds ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] The DNSOP WG has placed draft-wkumari-dnsop-multiple-responses in state "Candidate for WG Adoption"
IETF Secretariat wrote: > The DNSOP WG has placed draft-wkumari-dnsop-multiple-responses in state > Candidate for WG Adoption (entered by Tim Wicinski) > > The document is available at > https://datatracker.ietf.org/doc/draft-wkumari-dnsop-multiple-responses/ Hi, I've read the -03 version of this draft and previous mailing list discussion about prior versions of the draft and I don't support its adoption. There doesn't seem to be a strong (preferably data-driven) reasoning to justify the mechanism described in the draft, and in previous discussion [0] it's described as being, essentially, just an interesting optimization. [0] https://mailarchive.ietf.org/arch/msg/dnsop/NruMO-whi7UW7gzXF-gu9OrYTMg For keeping popular records in cache, pre-fetching (e.g. draft-wkumari-dnsop-hammer) would seem like a less disruptive technique since it can be implemented entirely by the recursive name server, and it can also be applied to unsigned records, of which there are still quite a few. Pre-fetching probably doesn't help unpopular records as much (if at all), but unpopular records (by definition) don't have as many users as popular records. About the draft itself: I wondered why signalling is necessary. • RFC 1034 §4.3.2 “Algorithm”, step 6: 6. Using local data only, attempt to add other RRs which may be useful to the additional section of the query. Exit. This would seem to let an authoritative nameserver add any records deemed “useful” to the additional section of a response. (The RFC says “query” instead of “response” here, but that is almost certainly an erratum.) • RFC 2181 §5.4.1 “Ranking data”: Unauthenticated RRs received and cached from the least trustworthy of those groupings, that is data from the additional data section, and data from the authority section of a non-authoritative answer, should not be cached in such a way that they would ever be returned as answers to a received query. They may be returned as additional information where appropriate. Ignoring this would allow the trustworthiness of relatively untrustworthy data to be increased without cause or excuse. When DNS security [RFC2065] is in use, and an authenticated reply has been received and verified, the data thus authenticated shall be considered more trustworthy than unauthenticated data of the same type. […] This is the prohibition on promoting additional section RRs to answer section RRs in the responses returned to clients. But the prohibition only applies to unauthenticated RRs. It actually sub-divides the “Additional information from an authoritative answer” rank into two sub-ranks based on DNSSEC status. Is there anywhere else in the DNS/DNSSEC specs that would prohibit that promotion, where the additional record is DNSSEC secure? Otherwise I would think that nameservers could populate the additional section with whatever they want, and security-aware recursive name servers could pick up secure RRs from the additional section, and cache them such that they would be returned in the answer section to clients, all without any signalling. So the EXTRA bit could be eliminated? • Section 8 “Use of Additional information” from the draft: When receiving additional records in the additional section, a resolver follows certain rules: 1. Additional records MUST be validated before being used. 2. Additional records SHOULD be annotated in the cache as having been received as Additional records. 3. Additional records SHOULD have lower priority in the cache than answers received because they were requested. This is to help evict Additional records from the cache first (to help prevent cache filling attacks). 4. Recursive resolvers MAY choose to ignore Additional records for any reason, including CPU or cache space concerns, phase of the moon, etc. It may choose to accept all, some or none of the Additional records. is very confusing to me. I think it doesn't apply to additional records that are the normal result of additional section processing? I think it is actually talking about “extra” records that are undergoing an upgrade. Basically, this whole idea seems to me like something that can already be implemented today, without any specification work other than the format of the EXTRA RR. But the EXTRA RR is just configuration information and you don't strictly need it until you want to distribute it interoperably. -- Robert Edmonds ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Working Group Last Call: draft-ietf-dnsop-nxdomain-cut
Brian Somers wrote: > Sorry I’m late to the party, and hopefully I’m misunderstanding, but…. using > tinydns as an authoritative server: Hi, Brian: You might enjoy these threads: http://thread.gmane.org/gmane.ietf.dnsop/13393 http://thread.gmane.org/gmane.ietf.dnsext/20301 http://cr-yp-to.996295.n3.nabble.com/Fixing-the-NXDOMAIN-NODATA-bug-in-tinydns-td17150.html -- Robert Edmonds ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] I-D Action: draft-ietf-dnsop-nxdomain-cut-01.txt
Paul Vixie wrote: > Ted Lemon wrote: > >>How deep do you expect the name tree to get? I rarely see anything > >>more than four levels deep, and three times through the loop isn't > >>a whole lot. > > > >Er, if on average you have to do three hash lookups instead of one, > >and hash lookups are the main expense to answering a query, then that > >would be 66% performance reduction on average on _every_ query. That's > >pretty significant. Am I missing something? Why does this sound like > >"not a whole lot" to you? > > i think if flattened hashing is an inefficient way to implement a dns > cache, then it should and will fall out of favour. in 2002 or so, for a > non-open-source project, we (vernon schryver and myself) implemented a > dns cache as a recursive hash table in the general style of bind4/bind8, > but with strong module boundaries, and arrays for sparse child-sets that > morphed into variable sized hash tables when density increased. this is > where resimprove-00's nxdomain treatment was first implemented, and it > worked well, and it the whole thing was extremely fast, as well as memory > efficient. > > so whenever i hear words like "that'll be slow for flat-hash dns caches" it > reminds me of the joke that begins "doctor, it hurts when i do $this" and > ends with "well, then don't do $this". OTOH, modern non-cryptographic hash functions (e.g., xxHash, CityHash, etc.) are extremely fast. If the cost of performing a few extra hashes and extra hash table lookups add significant expense to answering a query, then the rest of the system has been impressively well-optimized. -- Robert Edmonds ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] I-D Action: draft-ietf-dnsop-nxdomain-cut-01.txt
Stephane Bortzmeyer wrote: > On Thu, Mar 10, 2016 at 12:59:49PM -0800, > internet-dra...@ietf.org <internet-dra...@ietf.org> wrote > a message of 47 lines which said: > > > Title : NXDOMAIN really means there is nothing underneath > > Filename: draft-ietf-dnsop-nxdomain-cut-01.txt > ... > > A diff from the previous version is available at: > > https://www.ietf.org/rfcdiff?url2=draft-ietf-dnsop-nxdomain-cut-01 > > Main change: reorganisation of the text so that the normative section > 2 is written in a purely protocol-behaviour way, without any reference > to the implementation. Section 5 now discuss implementation. Hi, I agree with Ted Lemon's comments in this thread. Could the rule be relaxed so that the process of considering whether a cached NXDOMAIN in a parent zone is applicable to the name being looked up can be delayed until immediately prior to transmitting a query to an authoritative server? I.e., what would have traditionally been a cache miss can now be transformed into a cache hit at the last instant. That would move the O(number of labels) lookup from a hot path to a cold path, and there would be no need to argue about exactly how many nanoseconds the O(number of labels) lookup costs, because you were going to wait at least a few milliseconds on the network anyway. If you do it that way, however, a newly cached NXDOMAIN doesn't affect previous positively cached responses at all. This idea was brought up earlier and dismissed: Stephane Bortzmeyer wrote: > On Thu, Nov 12, 2015 at 06:13:04PM +, > Wessels, Duane <dwess...@verisign.com> wrote > a message of 57 lines which said: > > > Perhaps a recursive might be designed to negatively cache an entire > > zone (including TLD) but continue answering positively cached > > answers in the zone until they expire normally. > > Clever algorithm but I'm afraid it will make debugging more > difficult. Such a behaviour will be highly non-intuitive for the > user. (One of the motivations for NXDOMAIN cut is to make DNS behave > according to its data model, which is a tree.) (https://mailarchive.ietf.org/arch/msg/dnsop/JchUb-CvQVodkXJmxs1SR_0aIf8) But I'm not sure it should be dismissed so easily. The data model is a tree, yes, but caching up to the maximum TTL value allowed is permitted and widely expected, to the point that flushing the cache and trying again is often one of the first debugging steps performed. And debugging the DNS is already highly unintuitive and can already produce answers of... constrasting levels of coherence... especially when load-balancing is used for recursive service. -- Robert Edmonds ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] I-D Action: draft-ietf-dnsop-nxdomain-cut-01.txt
Robert Edmonds wrote: > 神明達哉 wrote: > > p.s. in my understanding Unbound adopts hash-based data structure for > > cached RRsets. If it still supports nxdomain-cut as described in > > Section 8, an argument against the proposal by referring to that type > > of implementation might sound less convincing. > > My understanding is that Unbound employs at least two hash-based data > structures, one for whole messages (msg-cache-* parameters) and one for > individual RRsets (rrset-cache-* parameters). > > It's also my understanding that Unbound already implements the > resimprove-00 §3 behavior when configured with "harden-below-nxdomain: > yes", but it defaults to off (only?) because "it is not an RFC". Actually, I was misremembering this. Unbound's harden-below-nxdomain behavior is much more conservative than resimprove, since it only considers NXDOMAINs that are DNSSEC-secure. But it still does use an "upwards" algorithm (successively strip labels off the QNAME) in a hash-based cache to find an applicable NXDOMAIN. -- Robert Edmonds ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] I-D Action: draft-ietf-dnsop-nxdomain-cut-01.txt
神明達哉 wrote: > p.s. in my understanding Unbound adopts hash-based data structure for > cached RRsets. If it still supports nxdomain-cut as described in > Section 8, an argument against the proposal by referring to that type > of implementation might sound less convincing. My understanding is that Unbound employs at least two hash-based data structures, one for whole messages (msg-cache-* parameters) and one for individual RRsets (rrset-cache-* parameters). It's also my understanding that Unbound already implements the resimprove-00 §3 behavior when configured with "harden-below-nxdomain: yes", but it defaults to off (only?) because "it is not an RFC". -- Robert Edmonds ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Erratra rejection
Hi, Dick Franks wrote: > On 11 March 2016 at 17:47, Robert Edmonds <edmo...@mycre.ws> wrote: > > > Dick Franks wrote: > > > There is no need to resort to doctrinal arguments about MUST/SHOULD, or > > > imagine that the RFC6844 tail can wag the RFC1035 dog. > > > > > > Mark A's objection really points a fundamental contradiction in RFC6844 > > > itself. > > > > Hi, Dick: > > > > Are you implying that 6844 violates 1035 in some way? > > > 6844 5.1.1 defines the tag field in a way which forbids the (arbitrary) > characters which MAY (but SHOULD NOT) be present according to the text in > 5.1. It's clear from the context that 6844 §5.1 is talking about the wire format, while §5.1.1 is talking about the presentation format. If the rules for the canonical presentation format are stricter than the rules for the wire format, then there exist wire RRs that cannot be represented using the canonical presentation format. Which, the verifier's notes in erratum 4061 claim, is OK, and not a contradiction. > This conflicts with the 1035 notion that master files contain text > representation of RRs. Any instance of a cacheable wire RR has a master file compatible text representation, thanks to the generic text encoding defined in RFC 3597. 1035 doesn't distinguish between canonical and generic text representation because the generic encoding hadn't been invented yet, of course. > I understand the > > reasoning in the erratum rejection: > > > > [...] > > > > The author believes SHOULD is correct here. The protocol on the wire > > will work just fine if someone breaks this advice. > > > > Yes, it might well break some zone file parsers. But those aren't on > > the wire and that type of incompatibility is exactly what I would > > expect from violating a SHOULD. > > > > [...] > > > > to be asserting that a valid wire format RR can have no valid canonical > > presentation format. > > > But CAA _does_ have a canonical presentation format, defined at 5.1.1. Sorry, I meant to say that the erratum rejection asserts that there can exist instances of valid on-the-wire RRs of known type that don't have a valid canonical presentation form. > The closest requirement I can find in 1035 is this: > > > > 5. MASTER FILES > > > > Master files are text files that contain RRs in text form. Since the > > contents of a zone can be expressed in the form of a list of RRs a > > master file is most often used to define a zone, though it can be used > > to list a cache's contents. > > > > So are you really suggesting flipping between canonical 6844 format and > 3597 \# format merely because the tag field happens to contain some > non-alphanumeric character or upper case letter? Yes. If a RR can't be presented canonically, how else would you do it? This is apparently exactly how BIND handles LOC records whose VERSION field is not 0, BTW: $ dig +norec @70.89.251.90 -t AXFR test.mycre.ws ; <<>> DiG 9.10.3 <<>> +norec @70.89.251.90 -t AXFR test.mycre.ws ; (1 server found) ;; global options: +cmd test.mycre.ws. 3600IN SOA mycre.ws. hostmaster.mycre.ws. 2016031104 7200 3600 604800 3600 test.mycre.ws. 3600IN NS bst.mycre.ws. loc.test.mycre.ws. 3600IN LOC \# 16 FFC0237FB02600C0237F loc2.test.mycre.ws. 3600IN LOC 42 21 28.764 N 71 0 51.617 W -10.00m 2000m 1m 10m test.mycre.ws. 3600IN SOA mycre.ws. hostmaster.mycre.ws. 2016031104 7200 3600 604800 3600 ;; Query time: 0 msec ;; SERVER: 70.89.251.90#53(70.89.251.90) ;; WHEN: Fri Mar 11 15:58:01 EST 2016 ;; XFR size: 5 records (messages 1, bytes 197) > > RFC6844 offers no justification for case folding, so > > > specifying exact matching would make the whole issue go away. > > > > I would hazard a guess that the "Matching of tag values is case > > insensitive" sentence is a requirement on applications that consume the > > RR, and not to DNS protocol comparisons like RRset data equality or > > DNSSEC canonical form. (Note the sentence "Applications that interpret > > CAA records..." a few lines up.) > > > > An unnecessary complication in my view, but maybe that is off-topic here. Well, speaking of unnecessary complications, maybe the practice of defining data RRTYPEs with canonical presentation formats that can only represent a subset of valid on-the-wire RRs ought to be explicitly banned going forward. -- Robert Edmonds ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Erratra rejection
Dick Franks wrote: > There is no need to resort to doctrinal arguments about MUST/SHOULD, or > imagine that the RFC6844 tail can wag the RFC1035 dog. > > Mark A's objection really points a fundamental contradiction in RFC6844 > itself. Hi, Dick: Are you implying that 6844 violates 1035 in some way? I understand the reasoning in the erratum rejection: [...] The author believes SHOULD is correct here. The protocol on the wire will work just fine if someone breaks this advice. Yes, it might well break some zone file parsers. But those aren't on the wire and that type of incompatibility is exactly what I would expect from violating a SHOULD. [...] to be asserting that a valid wire format RR can have no valid canonical presentation format. The closest requirement I can find in 1035 is this: 5. MASTER FILES Master files are text files that contain RRs in text form. Since the contents of a zone can be expressed in the form of a list of RRs a master file is most often used to define a zone, though it can be used to list a cache's contents. I.e., cacheable RRTYPEs (non- meta TYPEs) must be representable in master files. At the time 1035 was written, this would have implied a requirement that valid wire format RRs must have a valid canonical presentation format. But 3597 defined the generic "\#" encoding for RDATA appearing in master files, and explicitly allowed its use for representing known RRTYPEs: An implementation MAY also choose to represent some RRs of known type using the above generic representations for the type, class and/or RDATA, which carries the benefit of making the resulting master file portable to servers where these types are unknown. Using the generic representation for the RDATA of an RR of known type can also be useful in the case of an RR type where the text format varies depending on a version, protocol, or similar field (or several) embedded in the RDATA when such a field has a value for which no text format is known, e.g., a LOC RR [RFC1876] with a VERSION other than 0. Even though an RR of known type represented in the \# format is effectively treated as an unknown type for the purpose of parsing the RDATA text representation, all further processing by the server MUST treat it as a known type and take into account any applicable type- specific rules regarding compression, canonicalization, etc. > RFC6844: > > 5.1.1. Canonical Presentation Format > >The canonical presentation format of the CAA record is: > [snip] > >Tag: Is a non-zero sequence of US-ASCII letters and numbers in lower > case. > > [I assume "non-zero" really means "non-empty"] > > > is incompatible with the text in 5.1: > >Tag: The property identifier, a sequence of US-ASCII characters. > > Tag values MAY contain US-ASCII characters 'a' through 'z', 'A' > through 'Z', and the numbers 0 through 9. Tag values SHOULD NOT > contain any other characters. Matching of tag values is case > insensitive. > > Tag values submitted for registration by IANA MUST NOT contain any > characters other than the (lowercase) US-ASCII characters 'a' > through 'z' and the numbers 0 through 9. > > > which not only appears to imply the existence of two distinct species of > tag identifiers, but has the bizarre consequence that not all tag > identifiers are exactly representable using the canonical format prescribed > by section 5.1.1 > > The same form of words, or at least compatible words, should be used in > both places. RFC6844 offers no justification for case folding, so > specifying exact matching would make the whole issue go away. I would hazard a guess that the "Matching of tag values is case insensitive" sentence is a requirement on applications that consume the RR, and not to DNS protocol comparisons like RRset data equality or DNSSEC canonical form. (Note the sentence "Applications that interpret CAA records..." a few lines up.) -- Robert Edmonds ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] RFC 5155 §7.2.8
Hi, RFC 5155 says this: 7.2.8. Responding to Queries for NSEC3 Owner Names The owner names of NSEC3 RRs are not represented in the NSEC3 RR chain like other owner names. As a result, each NSEC3 owner name is covered by another NSEC3 RR, effectively negating the existence of the NSEC3 RR. This is a paradox, since the existence of an NSEC3 RR can be proven by its RRSIG RRSet. If the following conditions are all true: o the QNAME equals the owner name of an existing NSEC3 RR, and o no RR types exist at the QNAME, nor at any descendant of QNAME, then the response MUST be constructed as a Name Error response (Section 7.2.2). Or, in other words, the authoritative name server will act as if the owner name of the NSEC3 RR did not exist. Should the second condition on the RR type have an explicit "besides NSEC3" qualifier? Or am I missing something that implicitly excludes RR type NSEC3? Otherwise it seems to me that the second condition is always false. -- Robert Edmonds ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Name decompression strictness
Paul Vixie wrote: > On Saturday, January 09, 2016 11:26:16 AM Mukund Sivaraman wrote: > > > > If a DNS message is received on the wire, that has a compressed name in > > some RR's RDATA which it should not have (going by its type), is it fair > > to still accept it as a valid message and process it if the > > implementation is able to do so? i.e., can Postel's law be followed > > here, or must the implementation strictly reject such messages? > > > > i followed postel's law with regard to receipt of compressed names anywhere > in any RDATA that i knew the format of, in both BIND4 and BIND8. the result > was that implementations who wrongly compressed non-well-known RDATA's > (including BIND4 and BIND8) were able to break that rule without pain. > > it's my strongly held belief that postel's law is wrong for RDATA > interpretation, and that the first implementation to compress something they > should not have compressed, should feel pain. There is an analogous case with compression pointers themselves, which 1035 requires point to a "prior occurance [sic] of the same name". But BIND allowed pointers to point to later occurrences, and later implementations had to make the same allowance for compatibility reasons. -- Robert Edmonds ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Should we try to work on DNS over HTTP in dnsop?
Shane Kerr wrote:
> I have updated the DNS over HTTP review document that I sent some days
> ago. Thanks to Jinmei for reading it.
>
> As I mentioned before, if there is interest then my co-authors and I
> are happy to try to get the working group to adopt the document. If
> there is not interest, then we are happy to go forward with an
> individual submission.
>
> If I don't hear any positive support over the next week or two then
> that is a pretty clear sign that the working group has little
> interest. :)
Hi, Shane:
Given BCP 188 ("Pervasive Monitoring Is a Widespread Attack on Privacy"
and "The IETF Will Work to Mitigate Pervasive Monitoring"), I'm a bit
disappointed that "HTTPS" is spelled "HTTP(S)" in your document :-) If
you're going to go to the trouble of defining a new transport for DNS,
what's the rationale for allowing the transport to permit plaintext?
--
Robert Edmonds
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Question on RRtypes in RFC 4034 Section 6.2
Mark Andrews wrote: > In message <35c15c68-b6db-4970-b816-9295c123e...@dnss.ec>, > =?utf-8?Q?=F0=9F=94=92Roy_Arends?= writes: > > We'd end up adding stuff to a response in order to make it shorter. > > We'd end up changing a 0x00 to a 0x01 in the OPT record. > > > Is there a clear benefit (shorter responses)? Can you show me a few real > > world examples? > > Every DNSSEC answer would be potentially shorter. The signer field > can be compressed as can the domain names in all these types. > > hip ipseckey key lp nsec nxt rrsig sig talink nsap-ptr > dnskey cdnskey DNSSEC signer name fields are going to be fairly small for typical domains (barring outliers under .ip6.arpa). Isn't this a pretty trivial savings compared to the size of 1024 or 2048 bit RSA signatures? E.g., the response to "dig +norec +dnssec @sfba.sns-pb.isc.org www.isc.org -t A" returns a 1623 byte response (for me) containing 8 RRSIGs, and replacing the uncompressed instances of "isc.org" (9 bytes) in each RRSIG signer field with a two byte compression pointer saves (8*9 - 8*2) = 56 bytes. So that saves you ~3.5% off a 1.6 KB response. Why bother? You will get a far larger savings by just turning on minimal-responses and replacing RSA with ECDSA, no code changes required :-) -- Robert Edmonds ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Question on RRtypes in RFC 4034 Section 6.2
Paul Wouters wrote: > d) Does this need updating or an errata? It was already updated, in RFC 6840 §5.1. -- Robert Edmonds ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] are there recent studies of client side/ISP firewalls interfering with EDNS?
John Kristoff wrote: > After a DNS over TCP discussion a student of mine indicated that they > recently fixed a problem in their network where DNS messages over 512 > bytes were not being relayed. It appears the root cause has to do with > some defaults being set common gear that simply drops messages over 512 > bytes. For example: > > <http://www.cisco.com/web/about/security/intelligence/dns-bcp.html#5> > > !-- Enable a maximum message length to help defeat DNS > !-- amplification attacks. Note: This is the default > !-- configuration and value based on RFC 1035. > ! > message-length maximum 512 Ironically, elsewhere in that same document series: http://www.cisco.com/web/about/security/intelligence/dnssec.html Potential Networking Challenges with DNSSEC Deployment The networking-specific challenges from DNSSEC are largely the result of the differences mentioned previously: increased packet sizes, EDNS requirements and the more frequent use of TCP. Many firewall devices incorrectly limit DNS responses to 512 and prohibit DNS over TCP. [...] This is still wrong, though; "and" should be "or", as in "Many firewall devices incorrectly limit DNS responses to 512 *or* prohibit DNS over TCP." That document further states: Connectivity Over UDP and TCP port 53 Because most DNS traffic is sent over UDP port 53, any filtering of traffic that exists on the network is unlikely to impact future native DNS traffic that is traversing UDP port 53. However, if DNS traffic is not currently permitted to traverse TCP port 53, which is typically used for large DNS packets (that is, those greater than 512 bytes), any issues with DNS traffic over TCP port 53 will be exacerbated when DNSSEC packets begin arriving on the network, because many DNSSEC packets will be greater than 512 bytes due to the additional packet overhead of DNSSEC. If traffic using TCP port 53 is currently not permitted, or is being filtered to or from specific hosts or networks, then it may be necessary to account for new hosts and networks that could be sending DNSSEC traffic over TCP port 53. This seems to be implying that it's OK to block >512B UDP as long as you don't *also* block TCP/53 :-( -- Robert Edmonds ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Soon-to-come DNS over HTTP drafts
Shane Kerr wrote: > The other document describes our specific implementation, which sits > kind of in the middle of the the previous document, using DNS packets > sent in wire format via application/octet-stream. While of less general > interest, probably this is more important to standardize for > interoperability reasons. Why not register a media type for RFC 1035 §4 messages, rather than using application/octet-stream? (There is even already an "application/dns" media type, but it's not what you want.) -- Robert Edmonds ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Fw: New Version Notification for draft-yao-dnsop-root-cache-00.txt
Bob Harold wrote: > Reading these various ideas brings up a question in my mind. If a server > queries for the SOA of a zone and the serial number has not changed, can it > then assume that all of the entries in its cache for that zone should still > be valid now, and for the their original TTL value starting now? If the > values had changed, wouldn't the serial # also change? Seems like I must > be missing something here. No inferences like that can be drawn based on the SOA SERIAL field, because the serial number may have wrapped around to the same value that was observed previously. (Even if the time between queries is very small, there is still a finite window of time during which the zone publisher can fit as many zone updates into as needed -- at least conceptually.) -- Robert Edmonds ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Brian Haberman's No Record on draft-ietf-dnsop-root-loopback-04: (with COMMENT)
Joe Abley wrote: > On 30 Sep 2015, at 12:53, Paul Hoffman wrote: > > >I'll add the v4/v6 wording to the post-IESG-review draft unless there is > >objection in the WG. > > I like the v4/v6 wording, for what that's worth. > > >John Levine just answered your question about why the address might > >already be in use, which was something that was brought up in the early > >discussion of this draft in the WG. It means that you can't run both this > >and some other DNS-listening task on ::1, whereas you can run both on > >different addresses in 127/8. We'll cover that in the new wording. > > Since a single operator controls both ends, there's no need to use a > well-known port. If you can't bind to 127.0.0.1:53 because something else is > already listening there, use 127.0.0.1:12345. Hi, Joe: If I'm not mistaken, this would depend on the support in the recursive implementation for sending queries to non- well-known ports. Appendix B gives an example Unbound configuration which supports this (you append @ to the IP address), but AFAIK the example BIND configuration only supports querying the "static-stub" servers on the well-known port. -- Robert Edmonds ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] New Version Notification for draft-muks-dns-message-checksums-00.txt
Mukund Sivaraman wrote: > This is a new draft on DNS message checksums. I look forward to hearing > review comments. Hi, Mukund: 16 bits is an awful lot of space for the ALGORITHM field. Compare to the DNSSEC algorithm number field, which is only 8 bits. -- Robert Edmonds ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] New Version Notification for draft-muks-dns-message-checksums-00.txt
Mukund Sivaraman wrote: > Hi Robert > > On Mon, Sep 28, 2015 at 01:30:28PM -0400, Robert Edmonds wrote: > > 16 bits is an awful lot of space for the ALGORITHM field. Compare to > > the DNSSEC algorithm number field, which is only 8 bits. > > Do you suggest changing it to 8 bits too? If you keep an algorithm field, yes, I suggest changing it to 8 bits. It seems unlikely more than one or two algorithms would ever be implemented. Is algorithm agility really needed, though, given that there are ~65000 unused EDNS0 option codes? I am also curious why a cryptographic hash function (SHA-1) is needed for this. Is a fast non-cryptographic checksum not suitable (e.g., CRC-32C, which can be computed in hardware on x86 CPUs)? Also, there is a long deployment tail for new EDNS options. If it's urgent to deploy a countermeasure against off-path fragment spoofing, why not something like Unbound's "referral path hardening", or advertising a smaller EDNS buffer size which is much less likely to result in fragmentation? (E.g., I believe OpenDNS advertises a ~1.4 Kbyte EDNS buffer size.) Those countermeasures can be deployed unilaterally by the resolver, and on a shorter time scale than a new EDNS option. -- Robert Edmonds ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] draft-lewis-domain-names-00.txt
Stephane Bortzmeyer wrote: > If you want a nice example of a domain name which is not a DNS name, > add in your /etc/hosts (or equivalent for your OS): > > 104.20.1.85 > veryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryverylongname.example.com > > It is not a DNS name (first label is too long) but it works fine for > several applications which expect domain names: Those applications probably use the getaddrinfo() function for name lookup, and specifications for that function [0,1,2] don't specify a length limit for the 'nodename' parameter. [0] http://pubs.opengroup.org/onlinepubs/9699919799/functions/freeaddrinfo.html [1] http://tools.ietf.org/html/rfc3493#section-6 [2] https://msdn.microsoft.com/en-us/library/windows/desktop/ms738520(v=vs.85).aspx -- Robert Edmonds ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Order of CNAME and A in Authoritative Reply.
神明達哉 wrote: At Wed, 12 Aug 2015 07:23:59 -0400, Andrew Sullivan a...@anvilwalrusden.com wrote: So we are in agreement that glibc's stub resolver is acting really dumb here? I think that's overstating it. It appears that glibc implemented the protocol according to a widely-held but (at least mostly) undocumented feature of the protocol. I think my reading of the documents is more in line with your interpretation, but as you can see in the thread Mark thought add meant something obvious. Given the wide deployment of glibc, it's rather hard to call it wrong -- it's got a running code argument, after all. I think this is probably a gap in the specification. It's hardly the first one in the DNS. FWIW the stub resolver library in BSD variants derived from a very old version of BIND (ver 4?) has been behaving that way for more than (in my understanding) several decades: https://github.com/freebsd/freebsd/blob/master/lib/libc/net/gethostbydns.c it goes through the answer section in gethostanswer() as a one-pass operation, replacing the search name with CNAME target as it sees CNAMEs. I suspect it was implemented way before the first stub resolver of glibc, and I wouldn't even be surprised if the glibc implementation referred to the BSD behavior. The glibc resolver (libresolv plus the nss_dns module) is a stripped down fork of libbind. It looks like it was first imported into the glibc source tree in May 1993 from BIND 4.9.1 and synchronized periodically with subsequent BIND releases. The last merge was with BIND 8.2.3-T5B in July 2000. Compare https://github.com/freebsd/freebsd/blob/69d8a7bbb6/lib/libc/net/gethostbydns.c#L143 with https://sourceware.org/git/?p=glibc.git;a=blob;f=resolv/nss_dns/dns-host.c;h=357ac046932b4e991cd729363a97a3522313b7cc;hb=HEAD#l594 The BSD and glibc stub resolvers behave similarly because they're substantially the same code. -- Robert Edmonds ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] back to: Some distinctions and a request
manning wrote: There in lies the problem. These systems have no way to disambiguate a local v. global scope. It seems like the obvious solution is to ensure that these nodes do NOT have global scope, i.e. No connection to the Internets and no way to attempt DNS resolution. Or they need to ensure that DNS resolution occurs after every other “name lookup technology” which is not global in scope. I don't understand this point. Since Onion hidden service names are based on hashes derived from public keys surely they're globally scoped (barring hash collisions)? -- Robert Edmonds ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Character encoding of URI Target RDATA?
Tony Finch wrote: Robert Edmonds edmo...@mycre.ws wrote: What I'm asking is how the octet sequences provided by the URI RR RFC are decoded into the sequences of URI characters used by the URI RFC. Is there a generic way to do this, or does it depend on the specific protocol (e.g., HTTP), or is it left up to the application? Are you after RFC 20 as opposed to IBM ASCII or something? Yes, it appears that's one possible encoding of URI characters :-) -- Robert Edmonds ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Character encoding of URI Target RDATA?
Patrik Fältström wrote:
On 16 Jun 2015, at 22:45, Robert Edmonds wrote:
John Levine wrote:
Can you give an example of URI RDATA where it would make sense to
interpret it other than as ASCII?
This is the FTP example from the URI RR RFC, to which the UTF-8 byte order
mark has been gratuitously added:
Hmm...what RFC are you referring to? I can not find this in RFC 7553.
Sorry, it's not from an RFC. I took one of the examples from RFC 7553,
and modified it to show a pathological example for John's question.
The RFC says this:
This field holds the URI of the target, enclosed in double-quote
characters (''), where the URI is as specified in RFC 3986
[RFC3986]. Resolution of the URI is according to the definitions for
the Scheme of the URI.
I suppose to be perfectly clear we might either say percent encode
everything or we might say unencoded UTF-8 is allowed. They're
both unambigious, and I expect most parsers can handle both.
It would be very nice indeed if application developers did not have to
guess at the encoding of the bytes.
Earlier versions of the I-D did say explicitly that UTF-8 encoded characters
is how the Target is to be interpreted, but feedback gave that it is better
to just reuse the same specification as URIs. I.e. the interpretation is
according to RFC 3986 (which implies unclear where 3986 might be unclear).
I don't see anywhere in RFC 3986 where it says how to interpret an
arbitrary octet sequence as a URI. In fact, it repeatedly emphasizes
that the sequence of characters forming a URI is decoupled from possible
encodings of that sequence into octets.
RFC 3986 §2:
2. Characters
The URI syntax provides a method of encoding data, presumably for the
sake of identifying a resource, as a sequence of characters. The URI
characters are, in turn, frequently encoded as octets for transport
or presentation. This specification does not mandate any particular
character encoding for mapping between URI characters and the octets
used to store or transmit those characters. When a URI appears in a
protocol element, the character encoding is defined by that protocol;
without such a definition, a URI is assumed to be in the same
character encoding as the surrounding text.
The ABNF notation defines its terminal values to be non-negative
integers (codepoints) based on the US-ASCII coded character set
[ASCII]. Because a URI is a sequence of characters, we must invert
that relation in order to understand the URI syntax. Therefore, the
integer values used by the ABNF must be mapped back to their
corresponding characters via US-ASCII in order to complete the syntax
rules.
There are two encoding steps described here. The first is the
production of a URI from its components into URI characters, which
uses the percent-encoding scheme that everyone's familiar with to escape
URI components. These URI characters are ABNF terminal values. The
second encoding step is the conversion of these ABNF values into a
concrete octet stream. Only this second encoding step is relevant for
the URI DNS RR, because serialized URIs have already undergone
%-encoding.
Network ASCII is a very common encoding for ABNF terminal values, but
not the only possible encoding. RFC 5234 (ABNF):
2.3. Terminal Values
Rules resolve into a string of terminal values, sometimes called
characters. In ABNF, a character is merely a non-negative integer.
In certain contexts, a specific mapping (encoding) of values into a
character set (such as ASCII) will be specified.
[...]
2.4. External Encodings
External representations of terminal value characters will vary
according to constraints in the storage or transmission environment.
Hence, the same ABNF-based grammar may have multiple external
encodings, such as one for a 7-bit US-ASCII environment, another for
a binary octet environment, and still a different one when 16-bit
Unicode is used. Encoding details are beyond the scope of ABNF,
although Appendix B provides definitions for a 7-bit US-ASCII
environment as has been common to much of the Internet.
By separating external encoding from the syntax, it is intended that
alternate encoding environments can be used for the same syntax.
[...]
Appendix B. Core ABNF of ABNF
This appendix contains some basic rules that are in common use.
Basic rules are in uppercase. Note that these rules are only valid
for ABNF encoded in 7-bit ASCII or in characters sets that are a
superset of 7-bit ASCII.
[...]
B.2. Common Encoding
Externally, data are represented as network virtual ASCII (namely,
7-bit US-ASCII in an 8-bit field), with the high (8th) bit set to
zero. A string of values is in network byte order
Re: [DNSOP] Character encoding of URI Target RDATA?
Masataka Ohta wrote: Robert Edmonds wrote: What character encoding should be used when decoding the Target field of a URI RR? It depends on host part of URI, which decodes the URI. No, I'm not talking about the encoding of components within the URI into URI characters, I'm talking about the encoding of URI characters into octets. I.e., the second sentence of this paragraph, not the first: The URI syntax provides a method of encoding data, presumably for the sake of identifying a resource, as a sequence of characters. The URI characters are, in turn, frequently encoded as octets for transport or presentation. How non-ASCII characters in zone files of a name server are represented is a local issue to the name server. This is the *en*coding of characters in a zone file into wire data octets. (And, anyway, the zone file format is flexible enough that it can load arbitrary octets, via \DDD escapes.) How should a receiver decode the wire data octets? -- Robert Edmonds ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Character encoding of URI Target RDATA?
Masataka Ohta wrote: Robert Edmonds wrote: This is the *en*coding of characters in a zone file into wire data octets. I'm afraid you are totally confused. Actually, I don't really see how zone files are relevant to my question. How should a receiver decode the wire data octets? Into a zone file? Or? The URI RR RFC says that URI RRs store octet sequences that represent URIs, and says that URIs are specified in the URI RFC (3986). The URI RFC defines URIs in terms of codepoints that are based on the US-ASCII coded character set. What I'm asking is how the octet sequences provided by the URI RR RFC are decoded into the sequences of URI characters used by the URI RFC. Is there a generic way to do this, or does it depend on the specific protocol (e.g., HTTP), or is it left up to the application? -- Robert Edmonds ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Character encoding of URI Target RDATA?
John Levine wrote: What I'm asking is how the octet sequences provided by the URI RR RFC are decoded into the sequences of URI characters used by the URI RFC. Is there a generic way to do this, or does it depend on the specific protocol (e.g., HTTP), or is it left up to the application? As far as I can see, RFC 3986 defines URIs as sequences of ASCII characters. In the few places where they mention non-ASCII material, it says to represent them as percent encoded UTF-8, so it's still all ASCII. OK. That RFC seems to distance itself from mere octets. Can you give an example of URI RDATA where it would make sense to interpret it other than as ASCII? This is the FTP example from the URI RR RFC, to which the UTF-8 byte order mark has been gratuitously added: TYPE256 \# 36 000a0001efbbbf6674703a2f2f667470312e6578616d706c652e636f6d2f7075626c6963 or, equivalently, URI 10 1 \239\187\191ftp://ftp1.example.com/public; Attempting to decode it as ASCII simply does the wrong thing, but I don't see any reason that it's not a valid URI RR, and, knowing that it's encoded as UTF-8 w/ BOM, it can be successfully parsed into a URI (provided the Target field is handed off to the URI-parsing application as raw bytes, and not as a string with DNS zone file \DDD style escapes). I suppose to be perfectly clear we might either say percent encode everything or we might say unencoded UTF-8 is allowed. They're both unambigious, and I expect most parsers can handle both. It would be very nice indeed if application developers did not have to guess at the encoding of the bytes. -- Robert Edmonds ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Adoption and Working Group Last Call for draft-ietf-dnsop-dns-terminology/
Stephane Bortzmeyer wrote: On Mon, Apr 20, 2015 at 09:57:06AM -0700, Paul Hoffman paul.hoff...@vpnc.org wrote a message of 98 lines which said: Passive DNS -- A mechanism to collect large amounts of DNS data by storing queries and responses from recursive servers. Most passive DNS servcies collect only the responses, which is good for privacy. Some passive DNS services collect the query too. Given the privacy issue you mention, we should make people aware of that. Passive DNS -- A mechanism to collect large amounts of DNS data by storing responses from servers. Some of these systems also collect queries, which can raise privacy issues. When collecting below the recursive passive DNS data, both queries and responses can raise the same privacy issues, since the response usually contains a superset of the information in the query. Above the recursive (or inter-server in Florian Weimer's original paper), one could collect only responses, but unless queries are also collected and matched to the corresponding responses, the passive DNS system can be trivially poisoned by blindly spoofed responses. So, maybe query vs response is not the right distinction to make for can raise privacy issues. Maybe queries from recursive clients would be better than plain queries? -- Robert Edmonds ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] DNS terminology: Passive DNS
Stephane Bortzmeyer wrote: On Tue, Mar 17, 2015 at 10:56:44PM -0400, Robert Edmonds edmo...@mycre.ws wrote a message of 34 lines which said: Passive DNS Replication -- A mechanism to collect and store resource records by observing responses, usually those sent by authoritative servers. Passive DNS databases can be used to recover DNS records which were served in the past, and may allow certain kinds of inverse searches of the stored records. Sometimes shortened to passive DNS. My contribution to the painting of the bikeshed: I would drop usually those sent by authoritative servers because the responses can be sent by servers which are not authoritative for this specific zone (that's why DNSDB indicates the bailiwick of the response). Hi, Stephane: I was actually trying to draw a distinction between above the recursive and below the recursive collection, which is shown graphically in the slide 13 set in [0]. The work in [1] is an example of a system that collected both types of data. Maybe the following is better: Passive DNS Replication -- A mechanism to collect and store resource records by observing responses, usually those received by recursive servers. Passive DNS databases can be used to recover DNS records which were served in the past, and may allow certain kinds of inverse searches of the stored records. Sometimes shortened to passive DNS. Thanks! [0] http://www.enyo.de/fw/software/dnslogger/first2005-interactive.pdf [1] http://www.cc.gatech.edu/~ynadji3/docs/pubs/dnsnoise-dsn2014.pdf -- Robert Edmonds ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] DNS terminology: In-bailiwick response, Out-of-bailiwick response
Hi, Andrew: Andrew Sullivan wrote: On Wed, Mar 18, 2015 at 05:22:41PM -0700, Paul Hoffman wrote: I think response and reply don't need to be defined, but they do need to be used more carefully, and we didn't do that here, I think (but my co-authors might disagree with me). From looking at your concerns and the general use of bailiwick, I propose that it is records, not responses, that in- or out-of. What's tricky here is that the bailiwick-ness of something is only relevant given a response. So it seems to me that it's a question of records in a given response. I think Paul's proposed text doesn't _quite_ get us there, but it's close. I'll think some more. Do you think the simple way in RFC 5452 §6 is talking about the bailiwick-ness of records, or is it describing something different/stricter? Out-of-bailiwick -- A glue record in which the name server answering is not authoritative for an ancestor of the owner name of the record. Given the previous discussion about glue, that word seems especially fraught here. I note 6763 talks about verifying that any records (not just glue records) in a response are in-bailiwick. -- Robert Edmonds ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] DNS terminology: In-bailiwick response, Out-of-bailiwick response
Hi, draft-hoffman-dns-terminology-02 has the following definitions: In-bailiwick response -- A response in which the name server answering is authoritative for an ancestor of the owner name in the response. The term normally is used when discussing the relevancy of glue records. For example, the parent zone example.com might reply with glue records for ns.child.example.com. Because the child.example.com zone is a descendant of the example.com zone, the glue is in-bailiwick. Out-of-bailiwick response -- A response in which the name server answering is not authoritative for an ancestor of the owner name in the response. A few comments: * A zone can't send a reply; the authoritative server for a zone can. * Response isn't defined(!), nor is reply. I was (pedantically) thinking of an RFC 1035 §4 message with the QR bit set to 1 at first, but that doesn't fit well in the context of the owner name in the response, because a response message can contain RRs with different owner names, and records within a response message can be individually considered in-bailiwick or out-of-bailiwick. It would be good to clarify which owner name is being compared. * RFC 5452 §6, though it uses in-domain rather than in-bailiwick, uses the concept of deeming the authoritativeness of a record. RFC 3833 §2.3 refers to the long-standing defense of checking RRs in response messages for relevance to the original query. I think these two RFCs are alluding to the same or a similar bailiwick concept being defined here. Is in-bailiwick / out-of-bailiwick a property of the data in the DNS and how authoritative servers are configured to use it, or is it a determination (a deeming) by a recursive server that the data has this property? I favor the latter, because it is useful to have dedicated terminology for the process of determining a server's authority, but maybe a separate definition would be helpful: Bailiwick checking -- The process of determining whether a record in a response message should be considered in-bailiwick or out-of-bailiwick. -- Robert Edmonds ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] DNS terminology: Passive DNS
Hi, draft-hoffman-dns-terminology-02 has the following definition: Passive DNS -- A mechanism to collect large amounts of DNS data by storing queries and responses from many recursive resolvers. Passive DNS databases can be used to answer historical questions about DNS zones such as which records were available for them at what times in the past. I think this is referring to the concept originally described in Florian Weimer's Passive DNS Replication paper [0], which sort of combines the collection and retention aspects into a single term. Also, scale (large, many) may be an interesting property of a particular deployment, but it isn't really intrinsic to the definition of the term. Nor do all systems collect both queries and responses (some only collect responses). I would propose something like the following instead: Passive DNS Replication -- A mechanism to collect and store resource records by observing responses, usually those sent by authoritative servers. Passive DNS databases can be used to recover DNS records which were served in the past, and may allow certain kinds of inverse searches of the stored records. Sometimes shortened to passive DNS. [0] http://www.enyo.de/fw/software/dnslogger/first2005-paper.pdf -- Robert Edmonds ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] How to respond to ANY and RRSIG queries when you don't want to
Tony Finch wrote: If the response would be NOERROR / NODATA and the zone is not signed, synthesize a NULL RR and use that as the answer. It seems a little bit off to re-use the NULL RRtype, which has been reserved for experimental use, for this. There are at least some (marginal) uses of the type, e.g., the popular DNS tunneling tool iodine [0] will make use of NULL RRs. Which is perfectly OK, it's marked experimental, after all. This fact might be used by security monitors as a detection signature (e.g., [1] explicitly notes the use of NULL RRs by iodine), just like qtype=*. (Just noting this possibility, not passing judgment on whether such signatures are a good or bad idea.) NULL is hard to grep for in the commit messages, source code, and documentation of C/C++ based DNS software implementations, due to the obvious overlap with the C preprocessor macro of the same name, and the use of the word null in other DNS terminology (e.g., the null label of the root). I also note BIND appears to accept NULL RRs in zone files, even though RFC 1035 says NULL RRs are not allowed in master files. Knot 1.4 rejects NULL RRs in zones. (I tried searching for a later RFC that might mention NULL RRs but ran into the aforementioned terminology conflict.) Anyway, I recommend that the NULL RRtype be completely preserved for experimental uses and that a new RRtype be specifically allocated for the exclusive purpose of these synthetic responses, and that its definition require that it MUST NOT appear in zone files. Perhaps GNDN would be a good mnemonic, for the obvious [2] reference. [0] http://code.kryo.se/iodine/ [1] http://www.sans.org/reading-room/whitepapers/dns/detecting-dns-tunneling-34152 [2] http://en.wikipedia.org/wiki/Jefferies_tube -- Robert Edmonds ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Why no more meta-queries? (Was: More work for DNSOP :-)
Shumon Huque wrote: PS. regarding Paul Vixie's recent suggestion of adding an or A record set in the additional section for a corresponding A or query, I just learned today that Unbound already does this. Not sure if there are any DNS client APIs that can successfully make use of this info yet. Hi, Shumon: Do you mean that Unbound will accept such answers from servers, or that it will send such answers to clients, or both? I just tried querying an Unbound 1.5.2 server for a cached, signed pair of A/ records and I don't believe Unbound sends such answers to clients, at least not by default. -- Robert Edmonds ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Is there a concise and comprehensive definition of a zone file?
Edward Lewis wrote: Does such a thing exist (in one document)? Where I am going with this is - when one wants to automate looking at zone files today, there are many varied formats to consider. (Kind of like WhoIs.) With the inclusion of S-labels in some zone files I have seen, what was once simple parsing means loading in IDNA2008 libraries. And given the flashback I just related, it would be good to recommend how DNS records are shown in RFCs - for the sake of consistency between documents. IMHO, it would be good to (ahem) ‘clarify’ what is meant by a zone file. And how to write or document a DNS record. I’m been thinking that this is needed - or maybe I’ve overlooked a document that’s already in use. So I’m asking if anyone knows of a document? There's an interesting specification in the ICANN new GTLD agreements: http://newgtlds.icann.org/sites/default/files/agreements/agreement-approved-09jan14-en.htm (Search for master file format.) It's not concise or comprehensive; it's mostly a list of features of the master file format to not use. It looks like a wish list from those who've had to write custom parsers for the different ZFA file formats that the gTLD operators generate. Leaving aside the minor stuff like whether to use upper case or lower case, etc., if there were a canonical way to write a zone file, I'd recommend placing all RRs constituting an RRset together, without interleaving RRs from different RRsets, so that one doesn't need to scan the entire zone file before extracting RRsets. I can't think of an example from an RFC where RRs aren't shown like this, so at least there are aesthetic reasons to place them like this. (It seems like a case of unnecessary flexibility in the original spec.) -- Robert Edmonds ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
