>
> >
> > _______
> > 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
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
s 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
back 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
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 dat
ation 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 g
e 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
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",
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
_
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
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
ategy 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
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
r 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
en 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
icitly 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 E
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
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 w
eady
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
___
ers, 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
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
he 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
c 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
ticular 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
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
;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
ications 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
ing the COUNTRY/AREA fields.
--
Robert Edmonds
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
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 hav
inition 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
-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
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
___
" 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
__
: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 th
er 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
___
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.
--
Rob
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
ents 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
, 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
ss family :-)
--
Robert Edmonds
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
ld 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-nu
elated 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-
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 add
s 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
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
/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
agreements/agreement-approved-09jan14-en.htm
--
Robert Edmonds
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
t; 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 de
s 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
> 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 se
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 ter
e 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
gistries.
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" → "Questio
nfigures 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
t interoperably.
--
Robert Edmonds
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
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
ographic 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
um 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... constrast
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 impl
en-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
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.
&
e 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 reco
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
owed 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
sive 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
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
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
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 :-(
--
Robe
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
bserved 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
DN
ken, 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
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 E
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 changin
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).
=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
collisions)?
--
Robert Edmonds
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
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
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
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
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
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
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
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
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
should be considered in-bailiwick or
out-of-bailiwick.
--
Robert Edmonds
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
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
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
, at least not by default.
--
Robert Edmonds
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
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
89 matches
Mail list logo
