On 20 Feb 2024, at 11:55, jab...@strandkip.nl wrote:
> That is some good, arcane DNS knowledge right there, Niall, I like it!
8-)
> [...]
> Perhaps it's worth making it even more clear that this is just a provision
> for AXFR responses by specifying the QTYPE? Something like:
>
> DNS Zone Tr
On 15 Feb 2024, at 15:57, Suzanne Woolf wrote:
> The qdcount draft is brief and straightforward
and very welcome.
I think it would help, for completeness, and the better
to support the inexperienced reader of the DNS scriptures,
to include mention of RFC5936 (AXFR) in the "brief summary
of the g
On 12 Apr 2023, at 20:33, Patrik Fältström wrote:
> And if you use anycast, where some of the servers in the anycast cloud
> respond and some do not?
On 12 Apr 2023, at 20:37, Joe Abley wrote:
> This is not a distinction that matters
This, and independently of whether
> you consider lameness
On 10 Apr 2023, at 20:42, Mats Dufberg wrote:
Delegation is an entity consisting of a set of name servers and, in
some cases, glue address records. One part of the delegation is to
provide the path to the child zone content.
While this may be a convenient way to consider things in an
administ
On 12 Feb 2020, at 16:48, Paul Hoffman wrote:
Good call. Would it make both parts clearer if the introduction
instead said:
Because the information returned in this protocol only applies to
recursive
resolvers, servers that are acting as both authoritative servers
and recursive
reso
On 24 Jul 2018, at 9:44, Stephane Bortzmeyer wrote:
> Some work for draft-ietf-dnsop-terminology-ter? Define spoofing,
> poisoning and hijacking?
I think it's arguable either way whether to go for a -ter edition or to bring
out a companion document with its scope restricted to abuses, attacks, a
in a "naming system" without a single common root.
I'ld be surprised, because of what I understood of how the development of 7719
was approached, to learn that 7719bis can be permitted to revise a foundational
document such as 1034. I may be mistaken in this.
Best regards,
Ni
"Bailiwick"
would give sufficient clarity without unduly constraining the style of
future authors.
I hope this helps.
Best wishes for Christmas and the New Year, and apologies for being
late for Hannukah.
Niall O'Reilly
signature.asc
Description: OpenPGP digital signature
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
On 19 Dec 2017, at 10:08, Martin Hoffmann wrote:
> Except that "child zone" should probably be "subordinate zones" or
> something similar to also include (great)*grandchildren.
If "ancestor" were acceptable, then the natural counterpart would be
se a
domain name are printed or read left to right, from the most specific
(lowest, farthest from the root) to the least specific (highest, closest
to the root).
Best regards,
Niall O'Reilly
signature.asc
Description: OpenPGP digital signature
_
On 28 Nov 2016, at 20:00, Edward Lewis wrote:
> Please don't use the word random, not even in quotes, in this context.
+1
A good word might be "arbitrary" (NL: willekeurig).
Niall
signature.asc
Description: OpenPGP digital signature
___
DNSOP m
On Thu, 05 Nov 2015 13:26:22 +,
Ray Bellis wrote:
>
> IMHO, if a clarification is needed, it's that a client that depends on
> the order of the RRsets in an answer MUST NOT do so.
Wouldn't it be a simpler clarification to say that a client MUST NOT
depend on the order of the RRsets in an
On Tue, 13 Oct 2015 22:20:50 +0100,
Tony Finch wrote:
>
> The first-last convention has the minor advantage of accommodating
> non-CIDR delegations
or perversely-fragmented CIDR ones such as /26, 2x/26, /26, with
a single organization responsible for the middle pair of /26,
and otherwise no
t;
> Well, effectively maybe not. If a resolver "sticks" on the child,
> then the delegation won't move regardless.
ISTM that in such a case, the resolver is ignoring the
updated/(re)moved delegation, rather than that the delegation hasn't
moved.
Niall O'Reilly
t;
> Well, effectively maybe not. If a resolver "sticks" on the child,
> then the delegation won't move regardless.
ISTM that in such a case, the resolver is ignoring the
updated/(re)moved delegation, rather than that the delegation hasn't
moved.
Niall O'Reilly
n do so here, I'll follow up in my response to the
questionnaire mentioned by Sandoche
(Message-ID: <54fea0bf.4010...@afnic.fr>) at
https://fr.surveymonkey.com/r/zonemaster.
Best regards,
Niall O'Reilly
___
DNSOP mailin
ink that placing the definition of glue in the scope of "the
message" rather than in that of the zone data is likely to lead to
confusion.
Best regards,
Niall O'Reilly
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
ant" or "clumsy"; "long-winded" or "concise") isn't what's
needed here.
I suggest any one of "presented", "declared", or "specified".
ATB
Niall O'Reilly
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
> Yes, that is how I understand it. Can someone else confirm or deny?
Gladly. Confirmed for practical purposes in the majority of cases.
Best regards,
Niall O'Reilly
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
xt of the patent:
>
> http://www.google.com/patents/US8874790
This was filed in 2011.
By that time, I expect that there must have been a considerable body
of prior art.
Niall O'Reilly
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
chitecture providing distributed maintenance, resilience,
and loose coherency for this database; and
- a simple query-response protocol (as mentioned in the current
draft) implementing this architecture.
IHTH
Niall O'Reilly
___
DNSOP
top node of the zone down to leaf nodes or
nodes above cuts around the bottom edge of the zone."
Best regards,
Niall O'Reilly
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
that, according to RFC1178, "dk" is an undesirable choice of
hostname. Careful, but admittedly not exhaustive, searching in the
Scriptures hasn't led me to discover any reason to accept that it's
"not a hostname".
Best regards,
Niall O'Reilly
___
two
labels for a hostname is introduced.
I'll be glad to learn that I've missed something.
> i am never cheerful about things that work differently depending on
> what OS, what libraries, what browser, what ISP, or what search lists
> and/or what dns content is "more lo
At Thu, 08 Jan 2015 23:23:36 +1100,
Mark Andrews wrote:
>
> It is after 15 Jul 85. "dk" is no longer a hostname. There is
> just a node in the DNS tree with a A record attached which has no
> defined meaning.
>
> Mark
Thanks, Mark.
RFC 1034 (November 1987, but I'm sure you know that) uses
At Sun, 04 Jan 2015 14:15:17 -0800,
Paul Vixie wrote:
>
> also noting, dotless domains exist. dotless hostnames (for mail, web,
> etc) by def'n do not.
I don't understand.
Such a definition seems to be cheerfully violated in the case of
http://dk/
Best regard
esponding valid ZSK.
Perfectly clear; thanks.
Best regards,
Niall O'Reilly
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
ove and would appreciate
clarification.
The noun clause which is apparently intended as the object of the
infinitive "to ensure" contains two finite verbs. Perhaps a
sub-ordinating conjunction has been omitted?
Best regards,
Niall O'Reilly
___
> On 1 Dec 2013, at 21:44, Paul Hoffman wrote:
>
> padding (sending random queries from time to time)
a better word might be "chaff"
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
On 23 Oct 2012, at 14:29, Miek Gieben wrote:
> The paragraph is a *suggestion* in a *bcp*.
I don't see what point you're trying to make with this remark.
Indeed, if the suggestion is not congruent with current practice,
it seems to me that it very much ought not to belon
Alex Bligh wrote:
--On 22 January 2010 09:13:22 -0800 Paul Hoffman
wrote:
- Regular rolling can give you a false sense of security about your
rolling process
How can you have any sense of security about your rolling process if you
don't exercise it?
Why do people think the opposite of
Alfred � wrote:
Another point:
The draft is speaking abut "DNAME _in_ the root".
According to my surficial knowledge, DNAME RRs 'live'
at the _apex_ of the zone that shall be redirected, not
at the delegation point -- or did I miss something?
Within each zone, there may be at most one DNAME RR,
n. This doesn't help your argument.
Best regards,
Niall O'Reilly
University College Dublin IT Services
PGP key ID: AE995ED9 (see www.pgp.net)
Fingerprint: 23DC C6DE 8874 2432 2BE0 3905 7987 E48D AE99 5ED9
PGP.sig
Descrip
he at will).
Best regards,
Niall O'Reilly
University College Dublin IT Services
PGP key ID: AE995ED9 (see www.pgp.net)
Fingerprint: 23DC C6DE 8874 2432 2BE0 3905 7987 E48D AE99 5ED9
PGP.sig
Description: This is a digitally sign
On 3 Dec 2007, at 20:44, Mohsen Souissi wrote:
I have read the I-D as well and I second Joe's point of view and
his arguments [...]
+1
On 4 Dec 2007, at 05:16, [EMAIL PROTECTED] wrote:
Full IPv4 utilization and increasing use of IPv6 is completely
orthonginal to DNS label exaustio
owed to apply a domain name when
organizations or persons that do not provider the corresponding
contents and just want to sell the domain name for profit.
Surely this is about naming policy or registry policy,
and out of scope for DNSOP ?
Best regards,
On 20 Dec 2006, at 17:39, Paul Vixie wrote:
the attached paper was published last year but i've not got around to
writing an I-D for it nor releasing the software that implements
it. i
have shared it privately with a number of folks, and it's in fairly
wide
use among the folks ISC trades
37 matches
Mail list logo
