David Conrad <drc@virtualized.org> writes:
I believe the root server operators have stated (the equivalent of) that
it is not their job to make editorial decisions on what the root zone
contains. They distribute what the ICANN/NTIA/Verisign gestalt
publishes.
yes. for one example, see:
http://www.icann.org/en/announcements/announcement-04jan08.htm
other rootops who have spoken about this have said similar/compatible things.
Just to clarify, since I'm responsible for that particular red herring,
I had at the time forgotten that the TLD zone don't actually *live* in
the root -- I know; silly me, right? -- and that the root wouldn't be
affected by the sort of things that previously-2LD now TLD operators
might want to do with their monocomponent names...
which as someone pointed out, a 3-digit RFC forbids for security reasons
anyway.
Cheers,
-- jra
The NTIA issued a new notice to ICANN on Tuesday emphasizing it's desire for
"functional separation" of IANA
http://www.ntia.doc.gov/frnotices/2011/FR_IANA_FurtherNOI_06102011.pdf>
FurtherNOI_06102011.pdf<http://www.ntia.doc.gov/frnotices/2011/FR_IANA_FurtherNOI_06102011.pdf>
Larry Strickling spoke about it at the INET New York the same day
http://bit.ly/inetnyarchive
He also mentioned an extra hurdle- "in the global public interest" - for
new gTLDs, surely inspired by .xxx
j
Jay Ashworth <jra@baylink.com> writes:
... and that the root wouldn't be affected by the sort of things that
previously-2LD now TLD operators might want to do with their
monocomponent names...
someone asked me privately a related question which is, if there's a .SONY
and someone's web browser looks up http://sony/ and a root name server gets
a query for SONY./IN/AAAA then what will happen? the answer is happily that
the result will be a delegation (no AAAA RR in the answer section even if
the root name server knows one for some reason). the answer section will be
empty, the authority section will have a SONY/IN/NS RRset in it, and the
additional section will have the nec'y IN/AAAA and IN/A RRsets for those NSs.
this is sometimes called "the BIND9 behaviour" in contrast to BIND8/BIND4
which would have answered the question if they knew the answer, even if they
also knew that the qname had been delegated. BIND9 changed this, and NSD
does it the same way. RFC 1034/1035 is pretty clear about this, so to be
this should not be called "the BIND9 behaviour" but rather simply "correct".
which as someone pointed out, a 3-digit RFC forbids for security reasons
anyway.
three digit? i was thinking of <http://www.ietf.org/rfc/rfc1535.txt> which
was written as air cover for me when i added the "ndots:NNN" behaviour to
BIND4's stub resolver. and, looking at firefox on my workstation just now:
[58] 2011-06-19 23:27:49.906040 [#4 em1 0] \
[24.104.150.12].24003 [24.104.150.2].53 \
dns QUERY,NOERROR,57397,rd \
1 sony.vix.com,IN,A 0 0 0
[58] 2011-06-19 23:27:49.909895 [#5 em1 0] \
[24.104.150.12].26356 [24.104.150.2].53 \
dns QUERY,NOERROR,57398,rd \
1 sony.vix.com,IN,AAAA 0 0 0
[50] 2011-06-19 23:27:49.910489 [#6 em1 0] \
[24.104.150.12].23228 [24.104.150.2].53 \
dns QUERY,NOERROR,57399,rd \
1 sony,IN,A 0 0 0
[50] 2011-06-19 23:27:49.930022 [#7 em1 0] \
[24.104.150.12].37238 [24.104.150.2].53 \
dns QUERY,NOERROR,57400,rd \
1 sony,IN,AAAA 0 0 0
[58] 2011-06-19 23:27:49.931059 [#8 em1 0] \
[24.104.150.12].17401 [24.104.150.2].53 \
dns QUERY,NOERROR,33742,rd \
1 www.sony.com,IN,A 0 0 0
[124] 2011-06-19 23:27:50.112451 [#9 em1 0] \
[24.104.150.2].53 [24.104.150.12].17401 \
dns QUERY,NOERROR,33742,qr|rd|ra \
1 www.sony.com,IN,A \
1 www.sony.com,IN,A,600,72.52.6.10 \
2 sony.com,IN,NS,172800,pdns1.cscdns.net \
sony.com,IN,NS,172800,pdns2.cscdns.net 0
...i see that the browser's stub is indeed looking at the search list first
when there are no dots in the name. that's correct behaviour by the RFC
and also anecdotally since if i had an internal web server here called
sony.vix.com i would want my web browser to assume that that was the one i
wanted when i typed "http://sony/"\. having it go outside my network and
hit a TLD first would be a dangerous information leak. (this also shows
DNS's lack of a formal presentation layer as clearly as anything ever
could.)
inevitably there will be folks who register .FOOBAR and advertise it as
"http://foobar/" on a billboard and then get burned by all of the local
"foobar.this.tld" and "foobar.that.tld" names that will get reached
instead of their TLD. i say inevitable; i don't know a way to avoid it
since there will be a lot of money and a lot of people involved.
My point is that there is a relatively small group of root operators and I
consider them generally clueful and likely to comply with RFCs other than
through accidental violation.
OTOH, I can easily see $COMPANY deciding that $RFC is not in their
best interests and find the http://microsoft construct not at all unlikely.
I realize that no responsible software vendor would ever deliberately
do something insecure or contrary to a security-oriented RFC, but,
history has shown that not all software vendors are responsible.
Now imagine the number of corporate IT departments that can't
even spell RFC, but, they run web servers and DNS servers...
Yeah, under the coming circumstances, the expectation that said 3-digit
RFC will remain anything more than a novel collection of bits on an
FTP server somewhere is, well, optimistic at best.
Owen
And here is where it all comes off the rails.
Done anyone here know *why* Interstate-grade highways are designed to the
standards they are? Those standards have evolved markedly over the last
50 years or so, to the point were at today. And those things cost a
megabuck a mile, or more. Why?
Let's not always see the same hands.
Of course: it's because if those engineers get things wrong: people die.
Well, guess what, folks?
That's true for us, now, too. I don't think it's even melodramatic to
say that we have a pretty good handle on exactly what things are bad to
do when furthering the design of the Internet at large, and that if we
*do those things*... Really Bad Things will happen.
I have said for nearly 30 years now that The Internet Is An Engineering
Construct, and that should and must restrain us from doing stupid things
to and with it, regardless of how much money they'll make someone.
When you combine that with someone's famous observation that the Internet
is man's only technological achievement where a single character
typographical error in a server on the other side of the world that you
don't even know exists can take your entire network down (which, these
days, may mean "put your company out of business"), well, then...
we would seem to be hooved not merely to roll our eyes and say "well,
the suits will play, and they write the checks".
That doesn't happen in the paved road business because (are you ready
for this?) *the Government sets the standards*. I don't think I'm the
first person to say -- even on NANOG -- that we'd better get our shit
together before they start doing it for us...
but we'd better get our shit together, before they start doing it for us.
We now return you to Silly Sunday.
Cheers,
-- jra
Which just means we need to write yet another RFC saying that
resolvers shouldn't lookup simple host names in the DNS. Simple
host names should be qualified against a search list. Resolver can
still lookup simple names against /etc/hosts which covers localhost.
Mark
I think it's probably worse than that, since a lot of the companies who might
be foolish enough to try that *are companies that make stuff that's on your
LAN*... and what are you going to name the *one* Apple server that's on your
LAN in your internal DNS?
Of course; you're gonna call it "apple".
Cheers,
-- jra
And it only gets better from there... how many places have various "cutesy"
naming schemes that might include one or more trademarks (or whatever) that
someone might want as a TLD? A naming scheme involving fruit would cover
your "apple" example, but I'd bet that someone, somewhere, names their
servers after fast food restaurants or brands of shoe... and I'm confident
in predicting that there are plenty of cartoon characters that some company
or another will want to turn into a TLD.
- Matt
(Mark:)
Which just means we need to write yet another RFC saying that
resolvers shouldn't lookup simple host names in the DNS. Simple
host names should be qualified against a search list.
I don't see the problem. I'm happily running with a empty search
list for the last 25 year or so.
jaap
In message <201106200739.p5K7dxHJ071146@bartok.nlnetlabs.nl>, Jaap Akkerhuis wr
ites:
(Mark:)
Which just means we need to write yet another RFC saying that
resolvers shouldn't lookup simple host names in the DNS. Simple
host names should be qualified against a search list.
I don't see the problem. I'm happily running with a empty search
list for the last 25 year or so.
Which is your choice. Lots of others want search lists. I've seen
requests for 20+ elements.
Which is your choice. Lots of others want search lists. I've seen
requests for 20+ elements.
So they get what they ask for: Ambiguity in resolving the name space.
jaap
In message <201106200951.p5K9pmsW051234@bartok.nlnetlabs.nl>, Jaap Akkerhuis wr
ites:
Which is your choice. Lots of others want search lists. I've seen
requests for 20+ elements.
So they get what they ask for: Ambiguity in resolving the name space.jaap
There is no ambiguity if tld operators don't unilaterally add address
records causing simple hostnames to resolve. Simple hostnames as,
global identifiers, were supposed to cease to work in 1984.
Mark
Simple hostnames as, global identifiers, were supposed to cease
to work in 1984.
Can you point out where that is stated?
jaap
In message <201106201034.p5KAYZ2e008023@bartok.nlnetlabs.nl>, Jaap Akkerhuis wr
ites:
Simple hostnames as, global identifiers, were supposed to cease
to work in 1984.
Can you point out where that is stated?jaap
RFC 897.
Matthew Palmer <mpalmer@hezmatt.org> writes:
And it only gets better from there... how many places have various "cutesy"
naming schemes that might include one or more trademarks (or whatever) that
someone might want as a TLD?
As it happens, I have a set of routers that are named { craftsman,
makita, dewalt, black-and-decker, jet } etc. A couple of notably
small ones are named "dremel" and "proxxon". Likewise, our VM hosting
machines are named after container shipping lines. Trademarks and
candidates for dropping $185k on a TLD all.
In my experience this sort of naming scheme is the rule rather than
the exception.
-r
Simple hostnames as, global identifiers, were supposed to cease
to work in 1984.
Can you point out where that is stated?jaap
RFC 897.
I see where it says that all of the hosts that existed in 1984 were
supposed to change their names to something with at least two
components, as part of the transition to the DNS. I think we can
assume that process is now complete.
I don't see where it says that new DNS names can't have a single
component. A page and line reference would be helpful.
R's,
John
>> So they get what they ask for: Ambiguity in resolving the name space.
> There is no ambiguity if tld operators don't unilaterally add address
> records causing simple hostnames to resolve.EDU.COM.
See RFC 1535. Yes, a mistake was made implementing search lists.
A RFC was issued to say don't do search lists this way.
B.T.W. EDU.COM makes the point that TLD shouldn't make simple
hostnames operational as doing so deliberately add ambiguity or do
you want to issue a RFC that bans search lists?
Mark
Personally, I think search lists are a mistake and don't use them. If you do use them, then you are accepting a certain amount of ambiguity. Naked TLDs will increase that ambiguity and would recommend against their use, however there is no Internet Police to enforce such things (ICANN certainly isn't since ccTLDs can do whatever they like). I have significant doubt that an RFC will magically solve this problem (for any value of "this").
Regards,
-drc