behavior, even if bad guys are hopping all over
the IP address space. Take a look, tell me if I'm nuts:
http://www.ietf.org/id/draft-levine-iprangepub-00.txt
Regards,
John Levine, jo...@iecc.com, Primary Perpetrator of The Internet for Dummies,
Please consider the environment before reading this e-mail
,
John Levine, jo...@iecc.com, Primary Perpetrator of The Internet for Dummies,
Please consider the environment before reading this e-mail. http://jl.ly
PS: If you were planning to say that all DNSBLs stink, don't. We know
they do, but the alternative stinks worse
I've come across a configuration in the wild where a given zone
'z' contains both
a.z.NS some.name.server.
*and*
sub.a.z. NSsome.other.name.server.
You're right, it's a mistake, but it is not my impression that
registries make many semantic checks on the DNS records that their
clients
of 24 hr TTL.
A 2010 paper by Alexiou et al. models the Kaminsky DNS poisoning
attack and the port randomizing fix, which is interesting but not what
I'm looking for. (They conclude that the attack is real, and the fix
works OK.)
Anything else I should be looking at?
--
Regards,
John Levine, jo
. If we're going
to hack on our DNS software, I'd rather work on that.
--
Regards,
John Levine, jo...@iecc.com, Primary Perpetrator of The Internet for Dummies,
Please consider the environment before reading this e-mail. http://jl.ly
___
DNSOP mailing list
And with IPv6 I would expect most homes *will* get dynamic forward zones.
More likely no forward zones, since they serve no useful purpose.
IPv6 *is* a game changer and people are still rooted in IPv4 think.
Agreed. Why do you think that a host that is not a server and will
never be contacted
Agreed. Why do you think that a host that is not a server and will
never be contacted by (non-malicious) other hosts needs a name?
Because servers out there won't allowing it access without a name.
I know this is stupid but they exist.
Given a choice between rolling out complex and fragile
Finally, the syntax for the descriptions in draft-levine-dnsextlang
will not always yield friendly JSON members (for instance because of
white space). So, we need at least to specify a derivation algorithm
(s/\s+/_/ ?)
Better I think to adjust dnsextlang to be closer to the needs of
We would like to draw your attention to a new draft.
It looks like it should work, assuming that your cache uses the
existing logic to remember queries in progress so it doesn't hammer a
record that's already in the process of being refetched.
My main observation is that I have no idea what the
I don't see the real-world benefit of this.
Fine: you don't need implement it. There are enterprise environments where the
round-trip times are more
significant to them than they seem to you in your enterprise environment.
I'm still trying to figure out how I could tell whether prefetch makes
If yes, message cache elements are prefetched before they expire
to keep the cache up to date. Default is no. Turning it on
gives about 10 percent more traffic and load on the machine, but
popular items do not expire from the cache.
My question earlier still stands: does
So, we got some good review and feedback on this from Tony Finch, anyone else?
I read the draft, and as a spec it looks fine to me. Once there are a
few empty.as112.arpa servers, you can send any branch of the DNS to
oblivion by pointing a DNAME at them. I have 2 1/2 questions:
* Anyone can
This new internet-draft is another request for additions to the RFC 6761
special names registry, this time motivated by an
interest in reserving the names most commonly found in recent analysis of TLDs
in private name spaces.
Several of these names including MAIL, HOME, CORP, and EXCHANGE have
I believe that with the considerable sleuthing abilities of the IETF
community, we ought to be able to take this initial set of observed data
and treat it as a call to action for the IETF community, for someone to
step forward and tell us *why* those names are in use, are leaking out
to the root
This is a useless discussion. Recriminations do not change the past.
True, but effectively what you're saying is that this special-use
registry could be used by anyone who's prepared to [squat|use a TLD
without registering it] in the right ways to get around the ICANN
allocation procedures. I
Not really, because what you get by squatting on a TLD is nothing like
what you get if you rent it from ICANN. Squats are all local
(mis-)use, with names only leaking onto the public Internet by
accident.
That actually depends on what you're doing with the name. In the case
of the names
How like LOCAL is ONION?
Neither is a zone in the DNS or a domain in the DNS namespace, and both refer
to names for which a
protocol other than DNS should be used for resolution.
(I realise the protocol for LOCAL is DNS-like, but it's not DNS, right?)
The protocol for .ONION is DNS-like, too.
The largest problem for IETF and DNS innovation is that the consensus in
IETF seems to be that innovation of DNS is not possible unless it
involves reuse of the TXT resource record.
Yes, sort of. The consensus in one part of the IETF is that adding
new RR types is too hard due to DNS server
Perhaps all that is missing is some guidance that says �you shouldn�t hijack
namespaces that you don�t control, even for non-DNS applications; register a
domain instead�.
That's a relatively high bar for all the residential broadband users
who buy a router at Best Buy (Future Shop to you), plug
That's a relatively high bar for all the residential broadband users
who buy a router at Best Buy (Future Shop to you), plug it in, and set
up the router via the configuration page at http://router.home.
And why wasn't that http://router.netgear.com; or
http://router.linksys.com;.
I dunno,
The problem occurs when common operating systems start shipping validating
resolvers, then users will not be able to browse to http://router.home to
configure their device.
Since the device and the browser will not be online when you do the
initial configuration, it seems to me that if you use a
Thanks, this is the kind of data I was looking for. The draft seems to assume
that the server will give an error, not no response.
I'd think no response would be pretty much mandatory these days to
avoid being a DDoS reflector.
This is also consistent with rants I've seen about EDNS0, in
It might be worth actively pushing the CDN folks to go the SRV direction.
Even if ENAME were a good idea, which is
not clear to me, it's an idea that would require significant infrastructure
changes, whereas SRV records appear to be
functional now, with no DNS software changes.
As I
What? A CNAME, redirection purely within DNS, rewrites an email
address?
Yes, of course.
See RFC 1123, section 5.2.2.
R's,
John
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
I've been talking privately with some knowledgable httpbis folks about
having a special joint
session at IETF 90 where we can focus on this topic and hopefully come to a
mutual understanding of
the problems and opportunities. Would people be interested in attending such
a meeting?
I'd
So, I have 2 drafts that I'd really appreciate feedback on - one of
the is the .alt TLD document (which many of y'all have already read):
http://tools.ietf.org/html/draft-wkumari-dnsop-alt-tld-01
This brings the delightful semi-anarchy of Usenet to the DNS, which is
not necessarily a bad thing.
Reactions have been, um, mixed. Some folk say it;s a no-brainer,
others seriously dislike the idea.
As I understand it, this changes DNS caches so that for the root zone
its behavior is somewhere between a cache and a secondary master. It
slurps up a copy of the root zone by AXFR or rsync or
As I understand it, this changes DNS caches so that for the root zone
its behavior is somewhere between a cache and a secondary master.
The cache remains precisely a cache.
I understand that it's still a cache in the DNS hierarchy, but in
operation, it's much more like a secondary master.
Many years ago Joe Abley and I suggested to create a special name for exactly
this purpose
a name that was guaranteed to never exist in the DNS thus the first lookup
would always return NXDOMAIN thus the A+ lookups would never take place.
http://tools.ietf.org/html/draft-jabley-sink-arpa-03
Not everyone who consumes our documents (or the results of them) is
going to tell us about their experiences.
I'm adding DNSSEC to the zones I host, and I've already found it
useful. Ship it, please.
R's,
John
___
DNSOP mailing list
DNSOP@ietf.org
In article alpine.lsu.2.00.1407231447050.13...@hermes-1.csi.cam.ac.uk you
write:
Kevin Darcy k...@chrysler.com wrote:
Potentially dumb question: what does this magic meaning MX target (.)
offer, that a target resolving to a null address (0.0.0.0 and/or ::0) does
not? No protocol or code
(1) Master-only. The master observes an ANAME record at the apex of a zone
it loads and uses it to periodically refresh the relevant records in the
zone (as if you had a cron job running dig | magic | nsupdate).
I have implemented something like this, with master file syntax
foo IN A
Not sure why Paul Vixie wants to relegate my IPv6 address to third class
citizen that's
not good enough to be a peer on the Internet for port 25. I'd ask him, but his
mail server
refuses my email due to my ISPs lack of reverse IPv6 :p
I'm all for anti-spam heuristics, but checking the reverse
but, separately from that, if PTR's have high and low uses, we should
document that, so that NYT (or whomever) ...
Can whoever mentioned the NY Times offer more clues about what they're
rejecting? My cable connection happens to have IPv6 with no rDNS, and
I can't even find a v6 address at the
Re-reading it today, it seems to me the text was altogether milquetoast.
I agree. The points that Vixie notes are entirely true, and it's hard
to imagine a good reason not to document them for the benefit of
people who want to, you know, interoperate.
R's,
John
stupid thing I've been wondering: Is there a reason not to use wildcard
PTRs?
$ORIGIN 6.7.6.2.7.6.7.0.1.0.0.2.ip6.arpa.
* 604800 IN PTR home-ipv6-customer.isp.net.
This turns out to be a Well Known Bad Idea (WKBI).
Most PTR checks look up the name to be sure
I think Evan was proposing that home-ipv6-customer.isp.net would also exist,
so a PTR check that looked for
*existence* would succeed, but one that looked for *matching* would fail for
most of those addresses.
Do we know whether typical PTR checks look for existence or matching?
The ones I
Most PTR checks look up the name to be sure there's a matching forward
( in this case) record, and ignore them if there isn't.
I see. Too bad. Is it any more feasible to adjust expectations for v6 in
this respect than it was when we were talking about not providing PTR for
v6 in the first
In article a9c0d68d-ca96-4720-b70e-35ecb32ca...@gmail.com you write:
Hi,
It's that time again: we need a jabber scribe and a note-taker for Tuesday's
meeting.
If you still need a note taker, I can do it.
___
DNSOP mailing list
DNSOP@ietf.org
And isn't there some danger that this parallel root becomes an
attractive target for those who want things to be different than
what's in the official root? That is, in effect, isn't this a plain
old alternative root?
I would assume the plan is that the clients use DNSSEC to validate
the
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.
Yes, I think the WG should adopt it. It has some editorial issues, and perhaps
should explain why it doesn't allow, e.g., root on the same LAN rather than only
The idea is that this will be an IETF consensus document, if possible, but we
are not yet asking for
adoption in the DNSOP WG, and we might not even later. For now, we'd like to
hear what additional terms
should be added, what clarifications to the terms we already have would be
helpful, and so
History: some registries still think that DNSSEC is a new experiment
and don't want to spend the effort to support it until it is real.
perhaps the apparent need for negative trust anchors has bolstered the
sense that DNSSEC is still experimental. or perhaps it's the fact that
after 19 years of
To begin with, in general I think this document is on the right path
and something very close to it should be published. It's
narrowly-focussed,
Agreed. Let's do these special case TLDLTs (top level domain like
things) one at a time unless there's a group with identical technical
and usage
In article 20150309110803.4516.qm...@cr.yp.to you write:
My qmail software is very widely deployed (on roughly 1 million SMTP
server IP addresses) and, by default, relies upon ANY queries in a way
that is guaranteed to work by the mandatory DNS standards.
All the qmail installations I know
What about adding a definition of public suffix? I suggest the text
from
https://code.google.com/p/guava-libraries/wiki/InternetDomainNameExplained:
Public suffix: A domain under which people can register subdomains,
and on which cookies should not be set. [with good examples
afterwards]
This
I have a minor nit for consideration: the examples should also include IPv6
loopback ::1 as well.
I'm with Paul -- every host handles 127/8 loopback addresses and
there's no need to use anything else for purely internal
communication.
Note that this has no effect on whether anything else in your
Looking for a few folks to do a close read. Send notes to the list, and
I'll make necessary revisions. If it's baked, I think there's consensus.
I read through it. It's basically fine but of course here are a few
suggestions.
I'd redo sec 1.2 to make it clearer what the serious problems are.
I took a look at it. The good news is that what it says is fine, but
the bad news is that it's been poked and twiddled so many times that it's
rather hard to follow.
I'd suggest reorganizing it like this :
Abstract
Disclaimer: Some people think this is an awful idea, they may well be
right,
master files are ASCII files.
Maybe they are supposed to be. But what got my goat recently was trying
to parse a zone file that had UTF-8 in it. There are zone master files
that are not purely ASCII in the wild.
Indeed. I have no idea what they mean. Since the DNS is a mostly
8-bit clean
Beyond that, does it end up being a cheap way to avoid the ICANN
process of creating a new gTLD. For example, I am not aware that
anything prevents the ToR project from applying to ICANN for the
.onion gTLD.
ICANN has a whole bunch of rules that mandate that once you've paid
the $185,000, you
Besides Paul's valid what if it's 100,000?, how does an engineer
distinguish between 100x people and 100x organized bots?
I dunno. How do we know that the traffic for .corp and .home is from
people rather than botnets?
If there is a group of people using an identifier as you describe, then
I'd
... and this is some of the point of the .ALT pseudo-TLD -- if you
want to use a TLD that does not get resolved in the DNS, make your
namespace look like YYY.ALT. This *will* leak into the DNS, but should
be dropped (NXD) at the first resolver (helping with privacy and
general pollution issues).
In article 0ee18e9e-e7d2-42e3-aee8-9a43c4032...@nominum.com you write:
On May 14, 2015, at 1:03 AM, David Conrad d...@virtualized.org wrote:
What qualitative difference do you see between those uses of numbers and the
use of TLDs like CORP?
Lack of scarcity.
+1
R's,
John
The distinction I'm making suggests why corp and onion seem different. They
are, in this
fundamental resolution nature.
I was under the impression that part of the problem with .corp was
that there were a lot of SSL certificates floating around. The
CAs are supposed to have stopped issuing
need therefore not to delegate it. But in the former case, one needs
a pretty good argument why we need anything stronger than ICANN's
policy statement that the names are blocked indefinitely -- certainly,
one needs a better argument than I don't trust ICANN, because it's
already got the policy
Good point, I was only thinking of recursive answers, and I don't think I see
SOAs there all the time. We can add
that NODATA responses for authoritative responses include the SOA.
A very short survey reveals that unbound and 8.8.8.8 return SOA, bind
doesn't. So it's not all the time, but it's
4. It's been pointed out that the maintenance of the special use names
registry is complicated by the fact that people used to be able to
assume the root zone was relatively stable, and this assumption has
become less defensible. (ICANN is not currently accepting new
applications for TLDs,
I think I used zone cuts to mean something it's not, I meant
establish separation lines in DNS that parties (like browsers, or
anyone using PSL) can use to make security decisions about what is an
'open' domain hierarchy with mutually distrusting participants versus
what is a 'shared' domain where
In article CAHw9_i+xnC=fivajrws4dllihuy+vyof_j7wxzfpdl3myk1...@mail.gmail.com
you write:
On Wed, May 20, 2015 at 1:55 PM, Joe Abley jab...@hopcount.ca wrote:
On 20 May 2015, at 13:12, Tim Wicinski wrote:
The draft can be found here:
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.
I think we should adopt it. I'm willing to review.
Since we're looking at it at the
In a side conversation about preventing badness it was suggested to turn
the conversation towards accommodating correct behavior. What would it
take for someone to pick an identifier space and get it acknowledged?
Write the software and get people to use it. Once again, this is
homesteading,
I agree that if you had a registry that had no unique entry, there'd
be no problem. But if you have to be prepared for identifier
collisions anyway, what use is the registry?
It tells you where to find out about foo.alt if you want to use that
particular un-DNS hack. Other than that, not much.
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
Maybe those features are actually desirable. The real issue is expectations.
For the vast
majority of uses dotless names are simply not an option as there are way too
many built-in
expectations in pretty much every piece of software that deals with domain
names.
On the other hand, have the
+many to what Warren says.
We do our best work when we do engineering, not rule-making. Let's
engineer a solution here that's more appealing than squatting. For my
money, alt-TLD looks about right.
I agree. On the other hand, since we are not the tsars of the
Internet, it is fairly likely
I guess my question here is, what would prevent House Finch Feathers OY from
applying
for the DNS(IN) string ONION from ICANN because they want that as a TLD in the
IN
class?
At the moment, nothing.
Remember, we also have a draft about .HOME and .CORP and .MAIL. ICANN
says they're not
They SHOULD choose a label that they expect to be unique and, ideally,
descriptive.
Is something that in reality won't happen, ...
Sure it will, for the same reason that the alt.* newsgroups worked and
continue to work.
Remember, this isn't the DNS. The way you stake a claim to alt.foo is
to
I think reserving a DNS-like namespace anchor of ALT is unnecessary; as
I mentioned in my comments about the ONION draft, you have a choice of
anywhere in the namespace to place that anchor, and there are an
enormous number existing places in the DNS where you can reserve a name
without
Unfortunately, I do not think this is good advice. Domain registrations have
to
be renewed, ...
There are domain registrations that don't have to be renewed, but I
still agree with your advice. We don't want to tell people to balance
a long term design on a short term foundation.
R's,
John
I believe the delegation of HOME/CORP/MAIL provides with more benefit than
risks, there
will be more companies/homes and mail users happy because their names resolve
from
everywhere, they can validate with DNSSEC, they can opt who can connect to
their
networks and no longer require domain hacks
I'm curious about one of those TLDs: MAIL. Besides dotless mail, which seems
to hit
the root at very high rate (lack of negative caching) and shouldn't be ever
allowed to
exist, and a few meaningful labels like local.mail*, I can't recall the
reasoning for
being concerned with
In article 20150728141250.27476.46586.idtrac...@ietfa.amsl.com you write:
The IESG has received a request from the Domain Name System Operations WG
(dnsop) to consider the following document:
- 'Decreasing Access Time to Root Servers by Running One on Loopback'
I believe that the registry we have currently defined doesn't do a great job
of capturing the actual needs here.
Agreed. It seems to me that there are two somewhat separate things going on
here.
One is the .ONION issue. It's a domain name string that has a
coordinated use that is
If we want to avoid future instances of squatting, it behooves us to
avoid applying too much process friction onto documents of this type.
Well, there's the problem. Personally, I entirely agree with you, and
I would prefer we err on the side of caution to prevent collsions
between special
With all due respect, this is a classic mistake that geeks make: thinking
that there can be some objective criterion or
set of criteria that would make decisions simple. ...
As I've said several times, I believe there are objective criteria that would
cover the majority of cases. ...
Perhaps
That was exactly the draft I was thinking about David. But it does not
address Paul's quest for one RFC per mapping, as
.alt has no registry.
I do think the path forward is one cutout (my opinion only)
The absence of a registry is a feature. Or if there is an IANA
registry, it should be
For clarity, I believe ICANN has placed the delegation of .CORP on hold
indefinitely.
I do not believe ICANN has stated that .CORP will not be delegated. Part of
the
reason for this discussion is due to this fact.
Since the new gTLD program still has five active applications for
.CORP, each of
Over in the dbound working group we have some proposals that would use yet
another
underscore prefixed name to avoid name collisions. (It's not a substitute for a
new RRTYPE; they need the prefix whether the data is TXT or a new type.) In
the mail world we have _domainkey and _dmarc and likely
>It can mean only one thing, that bar.example does not exist. How could
>it be different?
My name server (running NSD) appears to disagree with you. This is real data,
feel
free to poke at it yourself.
$ dig @sdn.iecc.com bogus.www.examp1e.com a
; <<>> DiG 9.8.3-P1 <<>> @sdn.iecc.com
>why not just go ahead and register the names through
>http://www.iana.org/form/ports-services? Don't be intimidated by all
>of the references on the application form
If people think that's OK, I'll send in registrations for _domainkey and all.
R's,
John
In article <5648026d.9040...@gmail.com> you write:
>
>Dave
>
>I would sign up as chair if there is enough interest to resurrect this.
I brought it up, I'm willing to work on it.
R's,
John
___
DNSOP mailing list
DNSOP@ietf.org
>I think this is OK as an individual and as co-chair.
In view of the other discussion we've had, _domainkey doesn't belong in ports
and services
since it's not something you use as _blah._proto.name in a SRV or NAPTR lookup.
>
>tim
>
>
>On 11/13/15 3:04 PM, John Levine wrote
>>From my previous recollection of this, ISTR there was a suggestion that
>your draft only directly register "single-label" names, but with "_tcp",
>"_udp" et al listed in the registry as a link to RFC 6335?
It seems to me that this needs three columns, like this:
NameReference Type
>Is there a document that says not to put such a record into the root,
>however? If not, why should DNSOP say anything about this? It seems
>like a job for SSAC to me.
IANA has a variety of policies which appear to me to say that the only
things that they will put into the root are NS, DS, and
>carried out by João Damas to evaluate the behaviour of many different
>code bases to a root zone that contained DNAME. The context of that work
>was the potential solution to use DNAME in the root zone to provision
>variant IDN TLDs (see ICANN board resolution 10 adopted on 12 March
>2010),
>In the past, when organizations found themselves in the same situation that
>ICANN seems to find itself in here
>(at least as outlined by yourself, below)
>they have done what ICANN has done and is trying to do now, which is to pass
>the document on to a neutral third
>party for �safe keeping�.
draft-pfrc-2181-handling-zone-cuts-00 (isn�t this the basis for the dbound
work?)
Nope. One of the few things we seem to agree on in the dbound group
is that we're not basing anything on zone cuts.
There may be other reasons to update this part of 2181, but dbound
isn't one.
R's,
John
>Done.
>
>This will be the third or fourth try for the document. Perhaps there is
>now enough community interest to make it happen?
The more I look at this, the more of a mess I find. It's not like it
would have been all up to you. RFC 6335 came out five years after the
first version of your
ples are of
>this sort, although John Levine might point out that they haven't made
>this permanent.
Well, since I've been dragged in here ...
The ICANN new TLD process had a step that looked at DNS Stability (see
pages 2-11 - 2-15 of the applicant guidebook), but the text in the AGB
ma
>This is a language quibble. I said ICANN had no mechanisms for
>specifying how a domain should be handled, and I would think a SHOULD
>specification is exactly that in formal language.
ICANN has vast sets of rules about how GTLDs are handled at the server
end. They have rules about DNSSEC and
>It should be easy enough to create a local alias address for the purpose
>though. "ifconfig lo inet6 add ::2 alias", salt to taste.
Uh, no. The *only* loopback address is ::1. The rest of ::/8 is reserved.
If you have a loopback software interface, you could set up a link
local address
>> Uh, no. The *only* loopback address is ::1. The rest of ::/8 is
>> reserved.
>
>Anything is a loopback address if you alias it on your loopback interface.
>
>::2 was only intended as an example (that's why I said "salt to taste"),
>but it was not a particularly well-chosen one.
On your
>There seems to be wide disagreement about what is the v6 loopback
>address: some of these addresses exist on some v6 systems but not
>others, or so we were told. If there is a v6 loopback address that is
>universally deployed (as 127/8 is for v4), we can add it, although it
>won't actually
> 2. Start the authoritative server with the root zone on a loopback
> address. This would typically be 127.0.0.1 in IPv4 or ::1 in
> IPv6.
>
>Why does the document say that the address should not be in use?
In many systems a local DNS cache or forwarder listens on 127.0.0.1
and
ICANN's published the final version of JAS' namespace collision report. The
first version came out a year ago but parts of it were redacted because they
stumbled across a horrible bug in some Microsoft software and wanted to give
MS time to fix it. The final version isn't very different other
It occurs to me that there's a difference between local and localhost
on the one hand and onion on the other. With local and localhost, you
still something like an A or record with an an IP address that
you can use in the normal way to open a connection.
With onion you get a rather
>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.
Yes, it's worth working on, and I'm willing to contribute the text to
replace the
For instance, some authoritative name servers embedded in load
balancers reply properly to A queries but send REFUSED to NS queries.
>> If my policy is not to tell you about NS records, that's my policy.
>> It may be a stupid policy that causes downstream problems, but it's my
>>
>> NEW
>>For instance, some authoritative name servers embedded in load
>>balancers reply properly to A queries but send REFUSED to NS queries.
>>This behaviour violates the DNS protocol (see Section ??? of [RFC??],
>>and improvements to the DNS are impeded if we accept such
1 - 100 of 462 matches
Mail list logo
