Because it's time...
Start of forwarded message
From: internet-dra...@ietf.org
To: "Wes Hardaker"
Subject: New Version Notification for draft-hardaker-dnsop-must-not-sha1-00.txt
Date: Fri, 12 Aug 2022 08:48:21 -0700
A new versio
SIG records. Validating resolvers MUST treat
RRSIG records created from DNSKEY records using these algorithms as
insecure. If no other RRSIG records of accepted cryptographic
algorithms are available, the validating resolver MUST consider the
associated resourc
Roy Arends writes:
> What is missing is how validators/validating resolvers should behave
> when presented with SHA1.
Yep; see the response to Jim.
[the draft was a starting place, of course; I'm sure there will be more
text needed. "send text" is always an adequate
o fight the authors about
whether to kill sha1 or not :-P
--
Wes Hardaker
USC/ISI
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
t the expected table entries
and text should look like.
--
Wes Hardaker
USC/ISI
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
Because it's also time...
Start of forwarded message
From: internet-dra...@ietf.org
To: "Ondrej Sury" , "Paul Wouters" ,
"Wes Hardaker"
Subject: New Version Notification for draft-hardaker-dnsop-rfc8624-bis-00.txt
Da
ithm[s].
All fixed.
[and invited you to the github repo too]
--
Wes Hardaker
USC/ISI
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
I'll work it out with them about whether they want to be an
author in the first place. Paul has already agreed to be left.
--
Wes Hardaker
USC/ISI
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
Paul Wouters writes:
> I drop my objection to changing SHA1 status :)
I win I win!
--
Wes Hardaker
USC/ISI
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
Viktor Dukhovni writes:
> > There is a typo, "opt-opt" should be "opt-out".
>
>
> Thanks, this correction is valid. Indeed it should have been
> "opt-out".
Concur!
--
Wes Hardaker
USC/ISI
___
th right and wrong in many ways. I'm
avoiding the more complex aspects.
--
Wes Hardaker
USC/ISI
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
t to go through the process of registering? IE, if the burden
is high or they're simply lazy, they'll still end up squatting. So we
need an alt.alt that isn't registered at all? Do we make the burden so
low that it attracts hopefully everyone? Do we not have a registry so
this problem
alt won't be the perfect solution for them. And they'd prefer
something like .reg.alt where conflict doesn't occur. Sadly, we almost
need two .alt name spaces: one which is explicitly
not-registry-controlled, and one which is.
--
Wes Hardaker
USC/ISI
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
ot intending to be
negative here].
2. Those that deliberately want to collide because the nature of their
solution may be to "replace" the DNS because they detest centralization
based solutions, or think theirs is simply better, or
The "we" was referring to
hat, but I suspect that's going against
what the alternate name space proponents want: minimal upgrades to
existing software [right or wrong as that may be -- no judgment here].
--
Wes Hardaker
USC/ISI
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
the user input is valid before accepting a submit button.
Maybe. Maybe not. It feels like a hope, not an assured solution. Even
though it's the *right* thing to do.
--
Wes Hardaker
USC/ISI
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
simply "should we have a registry and how will
this work?" Based on the last week of mail, the general concept of "we
need a carve-out" (to use Paul's terminology) seems generally agreed
upon. It's just the details that aren't agreed to yet.
--
Wes Hardaker
USC/ISI
__
about whether the question should be
asked immediately, and what the nature of that question should be: I'm
all ears and will pass it on (at least in aggregated consensus form)
during future IAB discussions.
--
Wes Hardaker
USC/ISI
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
be/sh9Bbk_1bMQ?t=1365
[3] https://blog.apnic.net/2020/08/21/chromiums-impact-on-root-dns-traffic/
--
Wes Hardaker
USC/ISI
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
stracts (suggested 1 page text + 1 page references) from people who
are interested presenting at the workshop. Abstracts are due soon
after the start of the new year (2023-01-18), but as a reminder they
need not be lengthy. Co-chairs are John Heidemann and Wes Hardaker
(both at USC/ISI), with Goeff H
01-18), but as a reminder they
need not be lengthy. Co-chairs are John Heidemann and Wes Hardaker
(both at USC/ISI), with Goeff Huston (APNIC) and Giovane Moura (SIDN
Labs) on the Technical Program Committee.
For details about DINR2023, see https://ant.isi.edu/events/dinr2023/
. (For informa
ooking at *only* the qdcount field for all traffic
arriving at b.root-servers.net yesterday for any packets where qdcount
was greater than 1 was precisely zero.
--
Wes Hardaker
USC/ISI
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
, reads just the same as ( qtype)
--
Wes Hardaker
USC/ISI
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
t are designed to be
more specific about the actual nature of the problem being observed by a
recursive resolver.
--
Wes Hardaker
USC/ISI
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
enerating the error code
and this isn't understandable when proxied.
--
Wes Hardaker
USC/ISI
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
conversations then I believe understandably will go
up from where it is now.
--
Wes Hardaker
USC/ISI
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
range wording choices.
But... I've said my voice, so feel free to reply but I tend not to
follow up unless I have new things to add (and I doubt I will further).
--
Wes Hardaker
USC/ISI
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
Paul Vixie writes:
> if we need more terms let's invent. but this term has established meaning.
There I fixed it for you:
If we need more terms let's invent. But this term has established meaning*s*.
--
Wes Hardaker
USC/ISI
___
DNSOP
oint of view of the error-generator. I typically don't rehash
my past statements unless I have something to add [and I don't - my
original statements still stand]. The consensus seemed to be at the
time "it's not broken, so we
USC/ISI is renumbering both its IPv4 and IPv6 addresses for
b.root-servers.net on 2023-11-27. Our new IPv4 address will be
170.247.170.2 and our new IPv6 address will be 2801:1b8:10::b.
USC/ISI will continue to support root service over our current IPv4 and
IPv6 addresses for at least one year (un
be the
tide is shifting, as it seems like more are in favor of defining new
terms now than the previous discussion round.
--
Wes Hardaker
USC/ISI
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
Katherine Chen writes:
> The word "lame" is also problematic in the US:
As someone who grew up in the US and was frequently called "lame" during
jr-high / middle-school age even though I didn't have a hurt leg, I have
to agree: it's a problem in the
o the number of
error reports that should be sent anywhere as I have concerns that
this could be too easily misused and caching may not be a completely
sufficient mitigation.
--
Wes Hardaker
USC/ISI
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
SYNC record and any records it is referring
to). IE, the CSYNC records could be equal but the NS records need to
be checked for equivalence at each server too.
--
Wes Hardaker
USC/ISI
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
bject to the
largest debate]
--
Wes Hardaker
USC/ISI
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
irement in it. Maybe
"The SVCB and associated TLSA records MUST be validated by DNSSEC." And
this is one of those cases where the MUST feels right as it
significantly degrades the security of the protocol if only a SHOULD is
used. As such, I'd drop the
s a part]. Whether this
is the right solution or not will depend on feedback from many voices.
--
Wes Hardaker
USC/ISI
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
lag is
encoded. Extensibility != easy deployability. It *can* but it
shouldn't be assumed that all future simple on the wire changes of any
type won't require major code overhauls to handle it.
--
Wes Hardaker
USC/ISI
___
DNSOP mailing
maximum
contributions are preferred. Co-chairs are John Heidemann and Wes
Hardaker (both at USC/ISI), with Allison Mankin (Salesforce) and Moritz
Müller (SIDN Labs) on the Technical Program Committee. If you wish to
attend but not present, please submit a paragraph stating you wish to
attend only and provide
.
- draft-hardaker-dnsop-rfc8624-bis
- draft-hardaker-dnsop-must-not-sha1
- draft-hardaker-dnsop-must-not-ecc-gost
(These are early drafts so there are certainly things to discuss about
them. We look forward to those discussions.)
--
Wes Hardaker
USC/ISI
be "table 3" in the text and under the table.
Fixed
> And the header for each page has a placeholder "title" instead of the
> actual title.
Yep, now:
title: "DNSSEC Cryptographic Algorithm Recommendation Update Process"
abbrev: "DNSSEC Algorithms Update Process"
--
Wes Hardaker
USC/ISI
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
(royal) do then we
should publish it.
> Appendix C has a reference to draft-hardaker-dnsop-must-not-sha1
> instead of this draft.
Yep, noted by a few people. Fixed in future versions, thanks.
--
Wes Hardaker
USC/ISI
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
ude lower than the EC and SHA256
based algorithms.
To see trends, you can click on labels on the graph to remove them from
the graph to zoom in on the nearly flat lines at the bottom.
ZSK counts are similar (oddly 7 is slightly higher and 5 is slig
oftware in the DNS(SEC) landscape takes a
really really long time. So the trade off of when to say "stop using
this" vs "all software has already stopped using it" has a really really
long gap in the middle. There is no perfect.
--
Wes Hardaker
USC/ISI
Mark Andrews writes:
> If we go ahead with this these two sentences
[... snip ...]
That seems like a good suggestion considering the direction of the
conversation. Both drafts changed accordingly, thanks for the text.
--
Wes Hardaker
USC/
th
these recommendations implemented]
--
Wes Hardaker
USC/ISI
___
DNSOP mailing list -- dnsop@ietf.org
To unsubscribe send an email to dnsop-le...@ietf.org
et be a solid consensus about SHA1 though new values for the ECC-GOST
recommendations seems more agreed to]
--
Wes Hardaker
USC/ISI
___
DNSOP mailing list -- dnsop@ietf.org
To unsubscribe send an email to dnsop-le...@ietf.org
well.
--
Wes Hardaker
USC/ISI
___
DNSOP mailing list -- dnsop@ietf.org
To unsubscribe send an email to dnsop-le...@ietf.org
"Salz, Rich" writes:
> I'm not a member of this group, but I just saw the notice about this
> draft in the internet-drafts mailing list.
Thanks Rich, those are all valuable comments.
--
Wes Hardaker
USC/ISI
___
DNSOP mailing l
date it), so I'm going to go around you"?
Fro #3: Again, what is my next step or recourse? I'm not sure here what
I'd do with that new bit of information. Similarly, the parallel
missing code is "I'm doing DNS load balancing so if you ask again in 5
minutes you'll g
ch
space to the first-come/first-served and experimental policies make that
much sense. I think we'd prefer people write a specification for behaviour.
--
Wes Hardaker
USC/ISI
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
ix A.
--
Editorial: Missing diff summaries for new versions.
+ Response: very true. Sigh. I'm (Wes) horrible at remembering to
write those, and I never put them in my drafts in the first place.
With the advent of online diffs I don't find them as
s.com. nobody.invalid. ( 1 ; serial 3600 ; refresh (1
hour) 1200 ; retry (20 minutes) 604800 ; expire (1 week) 10800 ;
minimum (3 hours) )
;; ADDITIONAL SECTION: explanation.invalid. 10800 IN TXT "No tracking"
--
Wes Hardaker
USC/ISI
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
ri/draft-wkumari-dnsop-extended-error/pull/5.patch]
* [https://github.com/wkumari/draft-wkumari-dnsop-extended-error/pull/5.diff]
--
Wes Hardaker
USC/ISI
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
a
nameserver the power to instruct a resolver to not try at another
nameserver gives them the power to make my zone unavailable. This
completely changes the current trust model. Please remove the retry
flag from the document.
+ The R bit has been removed in the latest flag, due
e
information. If you'd provide text to clarify your thinking, we'd
gladly include it.
--
Wes Hardaker
USC/ISI
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
nicate with the chairs about the timing of a LC.
--
Wes Hardaker
USC/ISI
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
because it was hampering
real-implementations)
--
Wes Hardaker
USC/ISI
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
observer would not
>otherwise have access to, such as account numbers.
I like that. I've put it in, thanks!
--
Wes Hardaker
USC/ISI
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
e to
see what you come up with. As with all loaves of bread, do you slice
them cross-wise, length-wise or diagonally?
[I reminded my daughter the other day that when she was young I made
her sandwich in the morning for school and cut it in half using a
lightning bolt like cut because she was a fan
/SOA/etc). In the IPV6 space, it's even more
interesting that 51.6% of IPv6 clients were asking about A records, and
only 37% about !
--
Wes Hardaker
USC/ISI
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
Vittorio Bertola writes:
> > Il 10 agosto 2019 20:57 Wes Hardaker ha scritto:
> >
> > 4) Now that this has had multiple implementations (though they'll need
> > to change after the packet format and code changes [that they
> > requested]), this is likel
There are many places where the document uses flippant language that
could confuse readers who don't understand English idioms. Although
they are somewhat humorous, these could lead to confusion and should
be removed.
+ Response: I've removed the ones I found, and may remo
Paul Hoffman writes:
> On Sep 9, 2019, at 9:05 PM, Wes Hardaker wrote:
> >
> > Paul Hoffman writes:
> >
> > Hi Paul,
> >
> > Thanks for the comments and good suggestions. Responses below inside my
> > todo list of action:
> >
> >
emental information (URLs being the other
common suggestion). Publishing this first (as is) doesn't get in
the way of a future RFCs extending this specification.
--
Wes Hardaker
USC/ISI
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
d multiple people have pointed that one out
at this point... you folks have good eyes)
--
Wes Hardaker
USC/ISI
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
Loganaden Velvindron writes:
> On Wed, Sep 11, 2019 at 7:42 AM Wes Hardaker wrote:
> >
> > Loganaden Velvindron writes:
> >
> > Hi Loganaden,
> >
> > Thanks for the comments about the EDE draft. I've marked up your
> > comments with respons
Paul Hoffman writes:
> On Sep 11, 2019, at 4:02 PM, Wes Hardaker wrote:
> >
> > Tim Wicinski writes:
> >
> >> it sounds to me that a discussion on assumptions with EDEs and RCODES
> >> would be useful in the security considerations section as well.
&g
Loganaden Velvindron writes:
> I'm ok with the latest revision.
Awesome, thanks!
> Just a small request: John Todd from quad9 sent his feedback, so it's
> fair to credit him in the next revision of the draft.
Yep, fixed. Thanks for that.
--
W
C) Document how to handle each one independently (or as an override if
needed to a global policy)
D) Your option here
So really, this first comes down to how important is it we handle this
case set before it goes out the door?
--
Wes Hardaker
USC/ISI
___
DNSO
display it to users. I guess the usual warnings to not
click on potentially unsafe links apply.
+ Yeah, it really would be remiss to leave out that point. There may
be nothing we can do, but the whole point of a security
considerat
ed from
different sources. Can you check the new text of them to see if
they are more understandable now?
--
Wes Hardaker
USC/ISI
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
change the processing of RCODEs in messages based on extended error
codes.
--
Wes Hardaker
USC/ISI
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
D/Prohibited, I would have thought.
+ Response: I created an "Invalid Data" error code to handle this.
Does this work for you?
--
Wes Hardaker
USC/ISI
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
- Blocked 3.17. Extended DNS Error
Code 16 - Censored
somewhat confusing, it seems that the resolver returning the answer is
reporting second-hand status from an upstream server, but the language
leaves me unsure. Perhaps this can be stated more clea
ne below in my tracking
notes below.
14.7 DONE Mats Dufberg
~~
Error codes 1 and 2, respectively, says "unsupported algorithm" in the
headline but "unknown algorithm" in the description. It should be
consistent, and I think unsupported makes most s
ot; is
at the delegation (referring server), not the targeted server.
+ Response: good catch and I like (and have put in) you replacements.
I've never liked the "lame" name either, as I don't think it's
descriptive
. I think it's covered by your other sentence though?
(which I've just replaced the previous sentence with)
--
Wes Hardaker
USC/ISI
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
#x27;t useful in standards
documents? IMHO, they're used all the time (the IMAP RFC is one of my
favorites that is full of example usages). In the previous example you
brought up above, I agree that we shouldn't be determining commonality
of possibilities. But I think examples in general
Vittorio Bertola writes:
> > Il 28 settembre 2019 01:41 Wes Hardaker ha scritto:
> >
> > + Response: Those three codes were supplied in a previous comment
> > round and they are supposed to indicate policies being applied from
> > different sources.
more
> than one EDE option, and thereby communicate multiple errors? Such as
> perhaps the above hypothetical with some RRSIGs expired, and some not
> yet vlid.
Yes, the draft discusses including multiple EDE reports.
--
Wes Hardaker
USC/ISI
_
the above text is better and still uses
strong language and indicates precedence goes to other specs.
--
Wes Hardaker
USC/ISI
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
Viktor Dukhovni writes:
> > On Sep 30, 2019, at 7:06 PM, Wes Hardaker wrote:
> >
> >> Which raises another question: Can an OPT RR legitimately carry more
> >> than one EDE option, and thereby communicate multiple errors? Such as
> >> perhaps the abov
at would be discouraged. Should we warn implementers
> of the issues, but still not forbid acting on them?
Well, I think the new text tries to do this, no? Specifically, we're
now saying "follow other specs", but we don't specifically prohibit
not-acting if there are no
internet-dra...@ietf.org writes:
> A New Internet-Draft is available from the on-line Internet-Drafts
> directories. This draft is a work item of the Domain Name System
> Operations WG of the IETF.
This version addresses, I believe, all comments from the WG LC.
--
Wes Hardake
3? Are either of these errors that
> anyone has seen in the wild? (If so I would love to know how that came to
> pass!)
It was suggested to be added, so I did. It does make some sense... but
no, I've never seen it in the wild either.
--
Wes Hardaker
USC/ISI
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
h can be zero length) /
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
10: / EXTRA-TEXT (can be zero length).../
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
--
Wes Hardaker
USC/ISI
___
DNSOP mailing list
be changed to “2 + the length of the
> EXTRA-TEXT field… .” I also changed “EXTRA-TEXT section” to
> “EXTRA-TEXT field,” since the draft call these items “fields.”
Thanks. Fixed!
--
Wes Hardaker
USC/ISI
___
DNSOP mailing list
DNSOP@ietf.org
be nothing we can do, but the whole point of a security
> > consideration is to properly disclose any known threats/issues.
>
> I do not see text mentioning this.
I think we're miscommunicating. Can you propose concrete text changes?
--
Wes Hardaker
USC/ISI
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
Viktor Dukhovni writes:
> > On Nov 13, 2019, at 12:56 PM, Wes Hardaker wrote:
> >
> > I added this text to the next version:
> >
> > When the response grows beyond the requestor's UDP payload
> > size , servers SHOULD truncate message
r configs as well)
12. For B.3 (bind 9.14 with mirror): it's worth adding a note that by
using the mirror implementation you're actually using less upstreams
because it won't include the ICANN xfr (or localroot) sources.
13. B.3 say
ntations. It additionally
> >provides secured AXFR transfers, which helps defeat issues with
> >unsigned glue records being potentially modified in transit (see
> >Section 2).
>
> I'm hesitant to do this because the text you give here is different
>
it as well:
https://datatracker.ietf.org/doc/draft-hardaker-dnsop-drop/
--
Wes Hardaker
USC/ISI
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
e TC bit is unacceptable too.
We need to come to a decision about this, and that will require everyone
with an opinion to chime in.
--
Wes Hardaker
USC/ISI
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
Wes Hardaker writes:
> > I think our simplest and most appealing option would be to treat EDE
> > exactly like any existing EDNS Option (i.e. set the TC bit).
>
> For the record, I'm just fine with this. People that *want* a separate
> signal should speak up please a
not even try for adoption). But thanks, your voice matches what
looks to be the rest to the norm.
--
Wes Hardaker
USC/ISI
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
d since an EDNS0 option received by the original client will
be perceived only to have come from the resolver or forwarder sending
it.
--
Wes Hardaker
USC/ISI
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
ot; was intentional. (if it is intentional,
clarification text would certainly be good)
--
Wes Hardaker
USC/ISI
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
put is was designed to indicate you
should somehow describe where you got the information from. But we're
not prescribing how, since that's implementation dependent. Any
suggested text you'd prefer?
--
Wes Hardaker
USC/ISI
___
DNSOP mailing
when
trying to contact sub-zones, but falling back to the old zone when none
of the "new" glue were working (aka, DoSed by changes). I could also
see someone else make the opposite change. I could see some
implementations deciding to stop service (it sure makes users notice
faster).
1 - 100 of 394 matches
Mail list logo
