scribed anywhere in the document, or the "chunks" need a scheme
allowing them to be divided into multiple RRsets that can be retrieved
in independent queries.
Separately, I also agree with John Levine's comments regarding RFCs
8552, 8553, and the underscore registry.
--
Robert Ed
s any record in a
zone file that is not properly part of that zone, including
nameserver records of delegated sub-zones (NS records), address
records that accompany those NS records (A, , etc), and any
other stray data that might appear." (Quoted from [RFC2181]
data) then I suspect you'd want to do something like append a
checksum to the JSON payload and Base64 encode the whole thing.
--
Robert Edmonds
___
DNSOP mailing list -- dnsop@ietf.org
To unsubscribe send an email to dnsop-le...@ietf.org
Paul Hoffman wrote:
> On Feb 1, 2025, at 15:49, Robert Edmonds wrote:
> > If comments aren't allowed, what about parens, embedded newlines, \DDD
> > and \X escapes, etc.?
>
> None of that; I'll add more prohibitions. Thanks again for asking good
> questions!
is?
> >
> >["DUJ", [["add", "yourname.example", "MX", "10",
> > "mx1.provider.example"]]]
>
> The latter, according to the example in Section 5.3 in RFC 1035.
Hm, I'm not following why SOA record data wo
ostmaster.yourname.example 2024112101 7200 3600
604800 60"]]]
What about this?
["DUJ", [["add", "yourname.example", "SOA",
"(\n yourname.example. ; MNAME\n hostmaster.yourname.example. ; RNAME\n
2024112101 ; SERIAL\n 2
ess that problem (various kinds of reordering at different
points in the stack, etc.), makes operational recommendations and
encourages implementers to adopt those recommendations as good defaults,
but I don't think it makes sense to try to enforce a new, normative
protocol requirement like this on DNS servers or applications.
--
Robert Edmonds
___
DNSOP mailing list -- dnsop@ietf.org
To unsubscribe send an email to dnsop-le...@ietf.org
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
t 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 complexi
st 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 EDN
PI 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
sage 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 dele
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 histor
rs 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
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 "Z
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
___
t 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
his 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
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
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
ibc 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
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.
--
Rob
rld, 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
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
___
t [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
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 eno
ience 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
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
tion (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
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
;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
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
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 f
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
duser",
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
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
s. 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
__
" 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
__
17 13:42:39 -0700
From: internet-dra...@ietf.org
To: Robert Edmonds
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.
ts.
(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
y, 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
efine 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
ify 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
operator would understand what "MBZ: 0x" means without re-training,
and if you're re-training operators you may as well point them to this
document.
--
Robert Edmonds
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
RY, 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
address family :-)
--
Robert Edmonds
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
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-num
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
r
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 glu
und 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
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
ot allow NULL RRs in zone
files besides the lack of a defined presentation format?)
--
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
uot; 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
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).
--
Robe
AME 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 vari
IN. 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
; SERVER: 192.168.43.1#53(192.168.43.1)
> ;; WHEN: Tue Sep 20 18:11:06 CEST 2016
> ;; MSG SIZE rcvd: 100
>
> Is the QNAME "www.afnic.fr" or "lb01-1.nic.fr" ("the data field of the
> last CNAME")???
"www.afnic.fr", because that is the domain name in the question section.
--
Robert Edmonds
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
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&q
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
y need it until you want to distribute
it 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
ction 4. Architectural considerations
> >
> >"Maintaining a globally-unique public namespace that supports different
> >name resolution protocols is hence an architectural requirement..."
> >
> >Adrien
> >
> >
> >>
> >>--Paul H
.
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
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 s
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
;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
Hi,
Dick Franks wrote:
> On 11 March 2016 at 17:47, Robert Edmonds 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.
> > >
&
ng, 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 ca
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
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
vasive 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 f
.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
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
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 :-(
ndardize 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
___
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 li
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 co
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
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
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/ms7
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 simil
ly they're globally scoped
(barring hash collisions)?
--
Robert Edmonds
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
WINS, or any other system for
lookup of registered names. However, a globally scoped naming
system, such as DNS fully qualified domain names, is necessary for
URIs intended to have global scope. URI producers should use names
that conform to the DNS
main name ends with the
root label, this leads to a printed form which ends in a dot. [...]
So, I take the octet sequence \# 13 03616263076578616D706C6500 and the
character string "abc.example." to be two different representations of
the domain name whose lis
Tony Finch wrote:
> Robert Edmonds 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 specif
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
ng" 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
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.
> > Ho
Masataka Ohta wrote:
> Robert Edmonds wrote:
>
> > What character encoding should be used when decoding the Target field of
> > a URI RR?
>
> It depends on part of URI, which decodes the URI.
No, I'm not talking about the encoding of components within the URI int
them) and that there's no "surrounding text" in a DNS wire
format message that can inform the decoder either.
Thanks!
--
Robert Edmonds
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
ng 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
lue, 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
t 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
Stephane Bortzmeyer wrote:
> On Tue, Mar 17, 2015 at 10:56:44PM -0400,
> Robert Edmonds wrote
> a message of 34 lines which said:
>
> >Passive DNS Replication -- A mechanism to collect and store resource
> >records by observing responses, usually tho
se" 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
1 - 100 of 105 matches
Mail list logo
