Subject: Re: Bogus nic.fr behavior

From: Jerry Scharf <[email-masked]>
Date: Wed, 07 Feb 2001 09:29:39 -0800

We have a couple things overlaying here, and I think it's worth splitting them 
out.

Dan, I think I agree with you on the TCP issue, but I have an operational 
question for your server. If I turn off TCP, then put in a record that is too 
long to be answered in 512 wire bytes, what happens? If you could demonstrate 
to me that you fail to load the zone in that case, then I would consider 
granting a waiver. If you don't do this, I think there is an operational issue 
for the zone operator that makes me want to not grant a waiver. There is no 
way for me to test that the domain will attempt to send longer answers in the 
future and fail, so you need to demonstrate to me that it can't happen. 
(Personally, I wouldn't turn off TCP for anything. Since my goal is to make 
sure everyone who wants to talk to foo can, I want to cover the case where 
some client decided to just use TCP to me or fail. I don't care whether it's 
right, just that I get them the answers.)

I really don't know why a authoritative server needs to answer for 127.0.0.1. 
I haven't seen anyone really defend this.  Answering for the roots in case of 
an errant query seems reasonable to me, but it should be best effort and 
should only require correctness. I see no reason for currency to be enforced, 
just no non-functional addresses. The "do this script" thing asssumes that 
scrips never break and that the testing coincide with the script cycle, both 
of which are questionable.

Finally, there is the issue of testing and testing waivers. There has been a 
great deal of discussion about protecting clueless people from themselves for 
the good of the Internet. If you delegate foo and it doesn't work, foo and the 
clients of foo are harmed. The pain is localized the the participating 
parties, so the degree to which this should have limits, IMO. Having tests 
that forces people get thier nameservers right is a good thing. What I'm 
hearing underneath all this is that nic.fr has no policy/ability to grant 
technical waivers for anything, or does not believe that there any need to. 
What would be needed to develop a wiaver policy for nic.fr? I would add the 
clause that there is the right to publicly riducle the person/group if they 
screw up after being given a waiver. :-)

Dan clearly knows DNS well, and if the zone in question wants to operate on 
correct terms but not to the letter of the nic.fr testing, why should that not 
be allowed. It's not for the "I'm too lazy to do DNS right crowd", it's for 
the "I'm clueful and want my server to run this legal way" group.

jerry

---

From: Robert Elz <[email-masked]>
Date: Thu, 08 Feb 2001 14:27:29 +0700

Date:        Wed, 07 Feb 2001 09:29:39 -0800
    From:        Jerry Scharf <[email-masked]>
    Message-ID:  <[email-masked]>

  | If you delegate foo and it doesn't work, foo and the 
  | clients of foo are harmed. The pain is localized the the participating 
  | parties,

You mean if I send in hundreds of delegation requests (for domains I
administer I mean, not hijacking or similar) naming your servers as
authoritative for the zones (and perhaps giving bogus glue records
for your servers as well), you're going to be quite content with that
when the registry doesn't bother to check, and simply lists the data
that was sent to them.

Or, if they do check, should then then listen to me when I claim
"I know what I am doing, I have been administering the DNS longer
than you have, put in the records I want, they will do what I think
is correct" ?

Really?

kre

---

From: Harald Alvestrand <[email-masked]>
Date: Thu, 08 Feb 2001 10:14:44 +0100

>than you have, put in the records I want, they will do what I think

I actually had to use quite forceful language with one of the newer 
registars to convince them that my authoritiative server, which was not a 
server for any (other) domain under their registration, was a "valid 
nameserver".

It seems they had adopted an opinion that the only valid nameservers were 
those listed as NS already in the .com zone....or something.

incompetence is not limited to the registrant side of that relationship...

--
Harald Tveit Alvestrand, [email-masked]
+47 41 44 29 94
Personal email: [email-masked]

---

From: Robert Elz <[email-masked]>
Date: Thu, 08 Feb 2001 16:39:32 +0700

Date:        Thu, 08 Feb 2001 10:14:44 +0100
    From:        Harald Alvestrand <[email-masked]>
    Message-ID:  <[email-masked]>

  | incompetence is not limited to the registrant side of that relationship...

No, of course not.   In fact, while one would hope that the people who
run the root would have something of a clue, it seems not.

Someone apparently made a typo in specifying the glue record for one
of the TLDs hosted by a fairly major server in AU - gave the address of
a different server instead.   Not checked apparently, and sitting there
now in the root servers giving out bad information...

That wouldn't be so bad of itself, everyone makes mistakes from time
to time - but it seems impossible to get anyone in any way responsible
for the root servers to do anything about it - neither going through
the proper channels, nor attempting some back door approaches (via
a few people who have tried their best, and thanks to them).

And just in case someone from the root servers is watching, the address
that needs fixing if for yarrina.connect.com.au - it should end in "17"
not "33" (just check with any of the AU servers - or with that server
itself, using either of the possible addresses).

And for the future, stick nothing in the root zone file without
verifying it with the authoritative servers for the information to
be inserted (which should be a rule to apply to all zones).

kre

ps: if this sounds a bit like my reply to Jerry suggested could be
done to his servers, well, now you know where the inspiration came from...

---

From: "D. J. Bernstein" <[email-masked]>
Date: 7 Feb 2001 18:09:05 -0000

Jerry Scharf, former Executive Director of ISC, writes:
> Having tests that forces people get thier nameservers right is a good thing.

Especially when the tests prohibit the perfectly valid default behavior
of DNS software that competes with yours, eh?

> Answering for the roots in case of an errant query seems reasonable to me,

Refusing to answer is also reasonable.

By the way, BIND 9 will also fail the nic.fr check, because nic.fr looks
for the root NS records in the _answer_ section of the packet. If your
reaction is ``well, they should check the other sections too,'' you are
missing the point. THEY SHOULD NOT EVEN BE ASKING THE QUESTION.

> If I turn off TCP, then put in a record that is too 
> long to be answered in 512 wire bytes, what happens?

If you have an answer that doesn't fit into 65535 bytes, what happens?
If you use a new record type that most BIND installations don't support,
what happens? If you use IP addresses in MX records, what happens? If
you mistype an IP address, what happens?

> fail to load the zone

Bad design.

---Dan

---

From: "Matt Crawford" <[email-masked]>
Date: Wed, 07 Feb 2001 11:38:41 -0600

> long to be answered in 512 wire bytes, what happens?

Not just a record, but any RRset, yes?

---

From: Jerry Scharf <[email-masked]>
Date: Thu, 08 Feb 2001 07:39:39 -0800

> than you have, put in the records I want, they will do what I think

That in an unbeleivabe distortion of the original post. You are describing a 
clueless move, and I agree with making sure that servers listed are not lame. 
We are talking here about subtle interpretations of the DNS specifications and 
I think in those cases we do need to have some latitude to let people have 
rope.

jerry