Subject: Should a nameserver know about itself?

From: Bruce Campbell <[email-masked]>
Date: Wed, 9 May 2001 16:33:11 +1000 (EST)

For those that aren't familar with our DNS operations, we manage in an
automated fashion the reverse delegations for the Asia Pacific Region.

We've assumed (in writing one of our automated delegation tests) that a
given nameserver is 'responding' if it knows about itself, ie, can supply,
when queried, an A/AAAA/A6 record and/or a PTR record for its own name/IP
address.

Unfortunately, we're running into a number of delegations that are failing
as the given nameservers fail both of the above tests, ie, the given
nameserver cannot supply any information about itself.

Is the assumption that a nameserver should have information about itself
correct?

-- 
  Bruce Campbell <[email-masked]>                +61-7-3367-0490
                      Systems Administrator                          APNIC

---

From: Randy Bush <[email-masked]>
Date: Wed, 09 May 2001 00:05:12 -0700

> Is the assumption that a nameserver should have information about itself

no.  

analogy: i have phone directories in my house, but i happen not to have one
for the town in which my house is situated.

randy

---

From: bert hubert <[email-masked]>
Date: Wed, 9 May 2001 09:31:01 +0200

> when queried, an A/AAAA/A6 record and/or a PTR record for its own name/IP

This is not necessarily the case and it is also not needed in the general
case. The PTR is never needed when resolving names, in any case.

If a query has reached your nameserver, someone obviously found out its
name and address. You would only need to supply details if they can't be had
anywhere else.

This would go if you were authoritative for EXAMPLE.COM, and you receive a
question for WWW.FRANCE.EXAMPLE.COM, and you list NS records for
FRANCE.EXAMPLE.COM, but their nameservers are themselves in the
FRANCE.EXAMPLE.COM domain.

However, as you delegate IN-ADDR.ARPA, this would only occur if you'd enter
your nameservers in an IN-ADDR.ARPA zone as well which you normally wouldn't
do. But you probably know this.

> Is the assumption that a nameserver should have information about itself

It is not. It is however very often the case that a nameserver is able to
supply an IP address when asked for an A of its name. Many authoritative
nameservers will happily recurse for you. Also, even servers which are not
willint to recurse for you will happily dish out data from the cache it
maintains for clients is *does* recurse for.

An example:

$ dig ns3.exodus.net @ns3.exodus.net
;; ANSWER SECTION:
ns3.exodus.net.		1d11h19m15s IN A  206.79.240.13
(some time later:)
;; ANSWER SECTION:
ns3.exodus.net.		1d11h17m10s IN A  206.79.240.13

ns3.exodus.net is not authoritative for exodus.net, and for example, does
not know the name for www.exodus.net. So if it knows its own name and IP
address, this is mostly due to good luck. If your nameserver is unable to
supply an A for its own name, you may wonder if other people ARE able to
supply one.

Perhaps you can supply the output of the fine tool 'dig' in the cases where
your delegations are failing. 

Good luck!

Regards,

bert hubert

-- 
http://www.PowerDNS.com      Versatile DNS Services  
Trilab                       The Technology People   
'SYN! .. SYN|ACK! .. ACK!' - the mating call of the internet

---

From: Nathan Jones <[email-masked]>
Date: Wed, 9 May 2001 17:39:49 +1000

>Is the assumption that a nameserver should have information about itself

I'm not aware of such a requirement, even though it sounds like a
good thing for a host to know.

Here's a scenario that I think is valid, in which a nameserver
wouldn't know about itself:

Foo use ns1 and ns2 for their own domain, but use dnshost1 and
dnshost2 for their customers.

foo.example.            IN  NS   ns1.foo.example.
foo.example.            IN  NS   ns2.foo.example.
ns1.foo.example.        IN  A    192.168.1.1
ns2.foo.example.        IN  A    192.168.1.2
dnshost1.foo.example.   IN  A    192.168.2.3
dnshost2.foo.example.   IN  A    192.168.2.4

Bar is a customer of Foo:

bar.example.       IN  NS   dnshost1.foo.example.
bar.example.       IN  NS   dnshost2.foo.example.

dnshost1 and dnshost2 are authoritative only nameservers
(no recursion).

When a delegation request is lodged for bar.example., your script
queries dnshost1 for it's own A record and gets a referral to either
the root servers or the example. servers, since it does not host
foo.example. and does not offer recursive resolution.

--
nathanj

---

From: [email-masked]
Date: Wed, 09 May 2001 17:43:43 +1000

> Is the assumption that a nameserver should have information about itself

	The assumption is incorrect.  The only time it has to be able to
	retrieve its own address is when it lives within a domain it
	serves.  It never needs to know its own name.

	Mark

--
Mark Andrews, Nominum Inc.
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

---

From: Bill Woodcock <[email-masked]>
Date: Wed, 9 May 2001 01:26:36 -0700 (PDT)

> for the town in which my house is situated.

So, as an ignorant layer-2/layer-3 person stretching to understand
this layer-5 DNS stuff, lemme see if I can render that as an example
rather than an analogy:

APNIC delegates 2.0.0.0/16 to Foo-ISP:

    $ORIGIN 2.in-addr.arpa.
    0 IN SOA 0.2.in-addr.arpa root.apnic.net n n n n n
    IN NS ns.apnic.net.
    $ORIGIN 0.2.in-addr.arpa.
    0 IN NS ns2.foo-isp.net.

ns2.foo-isp.net has a zone file for 0.0.2.in-addr.arpa:

    $ORIGIN 0.2.in-addr.arpa.
    0 IN SOA 0.0.2.in-addr.arpa root.foo-isp.net n n n n n
      IN NS ns2.foo-isp.net.
    $ORIGIN 0.0.2.in-addr.arpa.
    0 IN PTR host0.foo-isp.net.
    1 IN PTR host1.foo-isp.net.
    254 IN PTR host254.foo-isp.net.
    255 IN PTR host255.foo-isp.net.

However, ns2.foo-isp.net's IP address is 1.0.2.1, and it isn't
authoritative for either the 2.0.1.in-addr.arpa. zone or the
foo-isp.net. zone, those are both held by ns1.foo-isp.net, whose IP
address is 1.0.1.1:

    $ORIGIN net.
    foo-isp IN SOA foo-isp.net root.foo-isp.net n n n n n
            IN NS ns1.foo-isp.net.
    $ORIGIN foo-isp.net.
    ns1 IN A 1.0.1.1
    ns2 IN A 1.0.2.1

    $ORIGIN 0.1.in-addr.arpa.
    1 IN SOA 1.0.1.in-addr.arpa root.foo-isp.net n n n n n
      IN NS ns1.foo-isp.net.
    2 IN SOA 2.0.1.in-addr.arpa root.foo-isp.net n n n n n
      IN NS ns1.foo-isp.net.
    $ORIGIN 1.0.1.in-addr.arpa.
    1 IN PTR ns1.foo-isp.net.
    $ORIGIN 2.0.1.in-addr.arpa.
    1 IN PTR ns2.foo-isp.net.

So ns1.foo-isp.net would know about itself, but ns2.foo-isp.net
would not know anything at all about itself beyond the fact that
"ns2.foo-isp.net" was the data of an NS record in its zone file.
Both would be properly configured.

Is that right?

                                -Bill

---

From: Robert Elz <[email-masked]>
Date: Wed, 09 May 2001 18:51:15 +0700

Date:        Wed, 9 May 2001 16:33:11 +1000 (EST)
    From:        Bruce Campbell <[email-masked]>
    Message-ID:  <[email-masked]>

  | We've assumed (in writing one of our automated delegation tests) that a
  | given nameserver is 'responding' if it knows about itself,

I agree with all the other "that's wrong" replies.

The point of this reply is that a good test of whether a namesever is
'responding' or not is whether it can supply you with a list of NS
records for the root.

Though there are people who argue that not even that is needed.

The test I actually use is whether the nameserver correctly answers
queries about the zones that are about to be delegated to it.

That is, if someone asks for zone.example.com to be delegated to
ns3.example.net then I send ns3.example.com queries about zone.example.com
and get it to tell me the NS records, SOA record, etc.   If the
answers to that are correct (and agree with the other server(s) to
be delegated to, then the delegation happens).  (Note, I only ask it for
other records if I know they must exist - that is, if a server is within
the zone, then its A record has to be present).   If the server listed
is within the domain requested to be delegated, then I send the query
to its IP address from the form, otherwise I get its IP address from
a DNS lookup - if that fails, then there is missing glue elsewhere).
And note, while rare, it is entirely possible for an in-addr.arpa
delegation to require glue A records.

It really isn't important what other information the server would be
able to supply if asked, for this delegation, all that matters is that
it supply the information that you're being asked to refer to it, and that
it supply the same (identical) information as all of the servers that
are to be delegated the same zone - resolvers should be able to pick any
and get the same answer.

The only people this doesn't work with are a few DNS broker types who
somehow have formed the opinion that the delegation should happen first,
and that after it happens, then they will set up their servers to handle
the zone.   Those I treat as being the loony fringe, and they do things
my way, or they don't get delegations...

kre

---

From: Mans Nilsson <[email-masked]>
Date: Wed, 9 May 2001 14:43:35 +0200

Subject: Re: Should a nameserver know about itself? Date: Wed, May 09, 2001 at 06:51:15PM +0700 Quoting Robert Elz ([email-masked]):

	(I fully agree that the Sane Thing to test for is the domain 
	 that is about to be delegated)

> my way, or they don't get delegations...

Well written. They lose. SE does this, same method. After initial
confusion, most people running DNS agree that it is a Good Thing to
do. Some people don't. Running the risk of being whacked (as usually)
I'd dare say that those people probably should not be running DNS,
at least not charge for the service.

Yes, there are exceptions. But they are few and far between.

-- 
Måns Nilsson		Systems Specialist
+46 70 681 7204		KTHNOC
			MN1334-RIPE

I feel like I'm in a Toilet Bowl with a thumbtack in my forehead!!

---

From: Randy Bush <[email-masked]>
Date: Wed, 09 May 2001 07:04:11 -0700

> the zone.

i run the registrar/registry for a half dozen cctlds.  there are registrants
who keep insisting on this.  i have canned email in an elisp macro to tell
them they are welcome to insist all they wish.  they are also welcome to
register domains.  their choice.

randy

---

From: Mans Nilsson <[email-masked]>
Date: Wed, 9 May 2001 17:27:37 +0200

> register domains.  their choice.

Now we're talking! 

Yow!  Now I get to think about all the BAD THINGS I did to a BOWLING
BALL when I was in JUNIOR HIGH SCHOOL!

---

From: Cathy Murphy <[email-masked]>
Date: Wed, 9 May 2001 11:13:33 -0400 (EDT)

> delegation to require glue A records.

When would this ever happen?

-Cathy

---

From: "Cricket Liu" <[email-masked]>
Date: Wed, 9 May 2001 09:34:39 -0600

> When would this ever happen?

Maybe:

$ORIGIN 10.in-addr.arpa.
1    IN    NS    ns1.1
1    IN    NS    ns2.1

crickt

---

From: "Kenneth Porter" <[email-masked]>
Date: Wed, 09 May 2001 07:30:55 -0700

>my way, or they don't get delegations...

I'm struggling with two large ISP's to get my reverse delegation for my
dedicated access set up (one's done) and my biggest problem is finding
information or contacts so that I can get my zone set up in advance. I
end up doing it (at best) in parallel with the delegation because it's
so hard to find out what's needed up front. With one ISP, I was emailed
an HTML FAQ that should have been on their web site, and I only figured
out who to email by asking in their newsgroups.

So if you're going to establish this kind of requirement, *please* make
your requirements readily available and findable for us guys in the
trenches.

Ken
mailto:[email-masked]
http://www.sewingwitch.com/ken/
[If answering a mailing list posting, please don't cc me your reply. I'll take my answer on the list.]

---

From: Mats Dufberg <[email-masked]>
Date: Wed, 9 May 2001 17:49:48 +0200 (CEST)

> When would this ever happen?

If the name of the nameserver belongs to the delegated zone:

3.247.212.in-addr.arpa.   NS   nameserver.3.247.212.in-addr.arpa.
nameserver.3.247.212.in-addr.arpa. A 1.2.3.4

-----------------------------------------------------------------
Mats Dufberg                                     +46-8-545 857 06
[email-masked]                           fax: +46-8-545 857 29

---

From: Robert Elz <[email-masked]>
Date: Wed, 09 May 2001 23:04:13 +0700

Date:        Wed, 9 May 2001 11:13:33 -0400 (EDT)
    From:        Cathy Murphy <[email-masked]>
    Message-ID:  <[email-masked]>

  | When would this ever happen?

Cricket and Mats answered already.

The important thing to be aware of is that there aren't any
different types of domain based upon their names - all domains
are created equal, and remain equal.   Any domain can have any RR
in it.   Any time you're tempted to generalise based upon domain
name, you're almost invariably going to be wrong.

The only significance the various domain name trees have is how
one registers in them (what the various registrars will allow to
be registered there) and what lookups are conventionally directed
to them (as a first resort, a CNAME (or DNAME) can then point you
anywhere).

Technically, everything that applies to one domain applies to every domain
(with the root domain as the one and only special case).

kre

---

From: Cathy Murphy <[email-masked]>
Date: Wed, 9 May 2001 13:14:40 -0400 (EDT)

> nameserver.3.247.212.in-addr.arpa. A 1.2.3.4

Yes, I understand what a glue record is, but I don't see the likelihood of
ICANN/IANA creating nameservers in the in-addr.arpa domain. At least, to
date, it has not happened that I am aware. So, unless IANA does this, any
nameservers delegated in the in-addr.arpa zone would not require glue A
records. Theoretically possible? Yes. Rare? That implies that it happens.
In the meantime, I was wondering what a realistic example would be. [Not
trying to be argumentative, just covering the bases.]

-Cathy

---

From: Robert Elz <[email-masked]>
Date: Thu, 10 May 2001 01:12:09 +0700

Date:        Wed, 9 May 2001 13:14:40 -0400 (EDT)
    From:        Cathy Murphy <[email-masked]>
    Message-ID:  <[email-masked]>

  | Yes, I understand what a glue record is, but I don't see the likelihood of
  | ICANN/IANA creating nameservers in the in-addr.arpa domain.

ICANN/IANA has nothing at all to do with it.   If you're delegating
a domain to someone, they can ask for the nameservers to be anywhere
within the domain tree.   That includes inside their in-addr.arpa
tree if they want that.  As long as the name they specify has a A
record, and is running servers for the zone in question, and the owner
of the zone wants that server, then there should be no other issues
(the owner of the server has already demonstrated willingness by
setting up their server to handle the zone).

  | At least, to date, it has not happened that I am aware.

No, most people don't put A records in their in-addr.arpa domains, and
without that they can't have nameservers there either.   But there's
absolutely nothing to prevent it.   It certainly isn't waiting on any
IANA action - just someone who feels inclined to be different (and now
it has been discussed here, that might just happen tomorrow...)

  | Theoretically possible? Yes. Rare? That implies that it happens.
  | In the meantime, I was wondering what a realistic example would be. [Not
  | trying to be argumentative, just covering the bases.]

If you like, I'll get one of my ARIN handled in-addr.arpa domains
re-delegated to servers inside the domain, if you want to check whether
your procedures will handle this, and just to prove that it isn't
never done at all...

kre

---

From: Bill Manning <[email-masked]>
Date: Wed, 9 May 2001 11:18:01 -0700 (PDT)

% > If the name of the nameserver belongs to the delegated zone:
% > 
% > 3.247.212.in-addr.arpa.   NS   nameserver.3.247.212.in-addr.arpa.
% > nameserver.3.247.212.in-addr.arpa. A 1.2.3.4
% 
% Yes, I understand what a glue record is, but I don't see the likelihood of
% ICANN/IANA creating nameservers in the in-addr.arpa domain. At least, to
% date, it has not happened that I am aware. So, unless IANA does this, any
% nameservers delegated in the in-addr.arpa zone would not require glue A
% records. Theoretically possible? Yes. Rare? That implies that it happens.

	Well, it did happen in the past. It may happen in future.
	In fact, the "CNAME HACK" can be done w/ NS and A RRs.

% 
% -Cathy

--bill

---

From: Robert Elz <[email-masked]>
Date: Thu, 10 May 2001 02:09:30 +0700

Date:        Wed, 9 May 2001 11:18:01 -0700 (PDT)
    From:        Bill Manning <[email-masked]>
    Message-ID:  <[email-masked]>

  | 	In fact, the "CNAME HACK" can be done w/ NS and A RRs.

The CNAME HACK isn't relevant - that is just a method to get
a whole bunch of names which seem as if they have to go in one
zone file into different zones - it is only the data in the zone
that's affected, nothing related to NS's (which is good, as
NS's and CNAMES don't mix well at all).

And while I could delegate junk.cs.mu.oz.au to servers in some
in-addr.arpa zone, that would be unlikely to require glue (only
if the servers for the in-addr.arpa zone were inside junk.cs.mu.oz.au)

The likely case is nameservers for the in-addr.arpa inside the domain
being delegated.   And on other lists recently (and other times) one
DNS implementor has made it known that he recommends doing exactly that,
so much so, that his software will do it for you by default if you don't
tell it where else to put the servers (or that is how I understood it).
Whether that happens for in-addr.arpa domains or not I am not sure, but
if you believe the reasoning for doing this (which is largely to force
glue to be provided) then it probably should.

kre

---

From: Olaf Kolkman <[email-masked]>
Date: Wed, 09 May 2001 09:49:16 +0200

Hi Bruce,

 Bruce Campbell <[email-masked]> writes:
 * 
 * For those that aren't familar with our DNS operations, we manage in an
 * automated fashion the reverse delegations for the Asia Pacific Region.
 * 

I know :-)

 * Is the assumption that a nameserver should have information about itself
 * correct?
 * 

No, a nameserver can have a name or an address that is in a zone for
which it is not authoritative.  In other words the place where zone
data is published is independent from the zone data itself.

--Olaf

----------------------------------------------------- 
  Olaf M. Kolkman      |  RIPE NCC DISI project
     -----------       |      ---------------	   
  RIPE NCC             |  Phone:   +31 20 535 4444
  Singel 258           |  Fax:     +31 20 535 4445
  1016 AB Amsterdam    |  http://www.ripe.net/disi
  The Netherlands      |  [email-masked]

---

From: [email-masked]
Date: Wed, 09 May 2001 15:44:42 +0900

>Is the assumption that a nameserver should have information about itself

	if possible could you give us more specific goals/scenarios during
	domain/prefix registration?

	in many of IPv6 sites they operate IPv4-only machines to serve
	AAAA/IPv6 PTR records.  i'm wondering if this raises problem against
	your assumption, and curious about the exact scenario you have.

itojun

---

From: James Raftery <[email-masked]>
Date: Wed, 9 May 2001 15:00:54 +0100

> do. Some people don't. Running the risk of being whacked (as usually)

And for IE too. An authoritative nameserver is authoritative for a
finite set of zones. There is no reason to presume the auth. server's
own A RR is in one of the zones it's serving.

e.g.
ns1.isp.net and ns2.isp.net host isp.net
ns3.isp.net and ns4.isp.net host ISPs customers' zones, which would
naturally not include the isp.net zone.

If you're testing the quality of a delegation, you can only query about
the zone you're delegating. I could map out the algorithm the IE
delegation checker follows if you're interested.

Regards,
james
-- 
James Raftery (JBR54)
  "It's somewhere in the Red Hat district"  --  A network engineer's
   freudian slip when talking about Amsterdam's nightlife at RIPE 38.

---

From: Shane Kerr <[email-masked]>
Date: Thu, 10 May 2001 01:06:53 +0200 (CEST)

> name, you're almost invariably going to be wrong.

Okay, I'll bite.  What does it mean to have a PTR record in anything
other than the in-addr.arpa tree?  While in some ways all domains are
equal, can't we at least say that some domains are more equal than
others?  :P

--
Shane

---

From: "Cricket Liu" <[email-masked]>
Date: Wed, 9 May 2001 17:29:41 -0600

> > Any domain can have any RR in it.   Any time you're tempted to
> > generalise based upon domain name, you're almost invariably
> > going to be wrong.
> 

See RFC 2317, section 5.2.  It suggests that, since you're already
adding CNAME RRs to an in-addr.arpa zone, e.g.,

1.0.168.192.in-addr.arpa.    IN    CNAME    <something>

why not make that <something> a domain name in a zone the
delegate already owns, e.g.,

1.0.168.192.in-addr.arpa.    IN    CNAME    1.0.customer.example.

Then the customer adds

1.0.customer.example.    IN    PTR    foo.customer.example.

to his zone data file.  Ergo, a PTR RR in what's traditionally
considered a forward-mapping zone.

cricket

---

From: Bruce Campbell <[email-masked]>
Date: Thu, 10 May 2001 09:50:26 +1000 (EST)

> own A RR is in one of the zones it's serving.

Right.  Now that we've gotten that out of the way, can anyone suggest a
*reliable* test for verifying that a nameserver is responding ( which is
seperate from verifying that a nameserver is authoritatively serving a
given zone )

---

From: Jim Reid <[email-masked]>
Date: Wed, 09 May 2001 17:12:17 -0700

>>>>> "Shane" == Shane Kerr <[email-masked]> writes:

    Shane> Okay, I'll bite.  What does it mean to have a PTR record in
    Shane> anything other than the in-addr.arpa tree?

It just means there's a PTR record in a zone outside the in-addr.arpa
tree. Whether that has any significance or not depends on whether
something knows to look for that PTR record. For instance a server
might come across it by following a CNAME when resolving a query. This
is how some folk implement simplified RFC2317 style reverse lookups.
Take a look at 6.242.6.62.in-addr.arpa for example.

---

From: [email-masked]
Date: Thu, 10 May 2001 11:25:26 +1000

> seperate from verifying that a nameserver is authoritatively serving a

	Send it a non-recursive query.  A nameserver should always
	answer even if it is just a header containing refused,
	servfail or notimp.

	With this in mind the status opcode would be a good one to
	use.  It should always come back notimp/refused.

	Mark

---

From: Mats Dufberg <[email-masked]>
Date: Thu, 10 May 2001 10:48:32 +0200 (CEST)

On Thu, 10 May 2001, Jim Reid wrote:

>     Mark> 	Send it a non-recursive query.  A nameserver should
>     Mark> always answer even if it is just a header containing
>     Mark> refused, servfail or notimp.
>
> Yes, but there is one notorious DNS implementation that doesn't do
> that. It fails to return any answer -- not even a referral for . -- if
> it's asked for a name that it isn't authoritative for.

Then it isn't responding, in its true sense. Our control mechanisms of DNS
delegations should not try to handle all buggy servers. In that case the
error message will be "timeout" instead of "non-authoritative answer".

Mats

---

From: bert hubert <[email-masked]>
Date: Thu, 10 May 2001 10:30:03 +0200

> seperate from verifying that a nameserver is authoritatively serving a

You could send a query for the SOA of the domain, and see if it answers with
the AA flag set:

$ dig ds9a.nl soa @outpost.ds9a.nl

or to check automatically :

$ dig ds9a.nl soa @outpost.ds9a.nl | grep "^\;\; flags" | grep -q " aa "

Another check would be to ask for something in that domain that doesn't
exist, and see if you get an authoritative NXDOMAIN back.

Regards,

bert hubert

---

From: Jim Reid <[email-masked]>
Date: Thu, 10 May 2001 00:55:54 -0700

>>>>> "Mark" == Mark Andrews <[email-masked]> writes:

    >> Right.  Now that we've gotten that out of the way, can anyone
    >> suggest a *reliable* test for verifying that a nameserver is
    >> responding ( which is seperate from verifying that a nameserver
    >> is authoritatively serving a given zone )

---

From: Peter Koch <[email-masked]>
Date: Thu, 10 May 2001 11:07:22 +0200

> it's asked for a name that it isn't authoritative for.

That may even be helpful for the victim of a lame delegation, but anyway,
let's not go down this particular path. On the other hand, can we compile
a document (e.g. BCP) with technical/operational delegation prerequisites?
I remember that back in DNSIND times there were plans heading that direction.

The set of (non controversial) mandatory features to test may be small, but
still it might be helpful to have a "blessed" set of - optional - test
patterns.

Years ago, when I worked for a - then small - registry, we checked the
general nameserver setup before doing the delegation (correct 127.0.0.1
reverse mapping, root hints, forwarding etc.) in addition to a "sane"
zone configuration (NS and MX RRs, SOA timer, RNAME ...). At that time
pretty much everybody used "a" nameserver as server and resolver/forwarder,
so the checks were reasonable. Nowadays, even if you ignore the anti-registry-
djihad fraction, tests would have to accept a far broader range of setups.

-Peter

---

From: Peter Koch <[email-masked]>
Date: Thu, 10 May 2001 10:04:15 +0200

> other than the in-addr.arpa tree?  While in some ways all domains are

See RFC 1101 for examples of PTR RRs in "forward" name space.

> equal, can't we at least say that some domains are more equal than

"EU" comes to mind ...

-Peter

---

From: Robert Elz <[email-masked]>
Date: Thu, 10 May 2001 23:38:55 +0700

Date:        Thu, 10 May 2001 09:50:26 +1000 (EST)
    From:        Bruce Campbell <[email-masked]>
    Message-ID:  <[email-masked]>

  | Right.  Now that we've gotten that out of the way, can anyone suggest a
  | *reliable* test for verifying that a nameserver is responding ( which is
  | seperate from verifying that a nameserver is authoritatively serving a
  | given zone )

There have been some suggestions for that, but ... why???

If you know (either empirically, or by having been referred from another
server) that a nameserver is supposed to serve a particular zone, then
you send it a query about that zone.  If it sends you back some kind of
DNS response, then it has a DNS implementation.  If it sends you back
good data about the zone, then it is configured to handle the zone (so
you get two answers for the price of one...)

If you don't know any zone that a server is supposed to be serving, why
would you ever care if it has a DNS server on it or not?   (Unless it is
supposed to be your local back end resolver I suppose, but I doubt that is
the case you're concerned with).

That is, if you're never going to send it a query, why would you care what
it would say if you did?   What does it matter?

So, just check if it serves the zone that you're being asked to delegate.

If it does that, then you know (also, for free) that it must also have
a responding nameserver.   If it doesn't, you should be able to work
out from what happened whether the problem is no nameserver at all (you
get ICMP port unreachable, no response at all, TCP reset, ...) or perhaps
a firewall filtering you from the nameserver, which is effectively the same
thing, or a nameserver that just doesn't know the zone (a referral, a
NXDOMAIN, a non-auth answer, a list of NS records that doesn't include
itself, ...).   The only real point in distinguishing is to give a better
reason to supply for refusing to do the delegation.

kre

---

From: Sam Trenholme <[email-masked]>
Date: Thu, 10 May 2001 01:41:34 -0700 (PDT)

> it's asked for a name that it isn't authoritative for.

Fortunatly, his other suggestion about sending a status opcode will get a
"not implemented" response from the "nortorious implementation" in
question.

The only DNS server I know about that has version out there that don't
correctly handle the "status" opcode is my own implentation of a DNS
server.  It used to handle a status query like a normal query.  In fact,
Mark's posting made me realize that my implementation had this problem.
In light of his posting, I just released a new bugfix release because of
this issue.

- Sam

---

From: James Raftery <[email-masked]>
Date: Thu, 10 May 2001 10:17:07 +0100

> seperate from verifying that a nameserver is authoritatively serving a

They are two different tests, but they can both be implemented with a
query for the zone you're trying to delegate. If the server answers,
then it's responding. Then you perform a further check for aa bit, 
valid SOA RR or whatever you queried for.

tinydns, out-of-the-box, does not respond to queries for zones it is not
authoritative for. Unnecessarily seperating your tests for 
responsiveness and authority may be problematic because of this.

Regards,
james

---

From: Bruce Campbell <[email-masked]>
Date: Fri, 11 May 2001 10:24:27 +1000 (EST)

> There have been some suggestions for that, but ... why???

Part of it is how we *currently* deal with delegation requests.  We verify
each attribute (domain, nameserver) before verifying the whole request,
ie:

	domain: 220.219.218.in-addr.arpa   
		domain->validate() returns true if domain name is 'correct'
	nserver: ns1.example.com
	nserver: ns2.example.com
		nserver->validate() returns true if nameserver is
		considered to be 'responding'.

	( each attribute validate() method doesn't have the 'full'
	  delegation request on hand, so currently
          nserver->validate() can't directly test the domain on the given
          nameserver. )

So, our current implementation of nserver->validate() is flawed, because,
as has been pointed out, a nameserver doesn't *need* to know about itself,

( Personal opinion is that is *should* know about itself, as most of the
  cases we've seen where a nameserver doesn't know about itself have been
  broken in other ways )

> the case you're concerned with).

One of the future projects is an ongoing reverification of delegations
within our space.  The caching of nameserver good/bad results is
considered a good thing, and this caching was intended to be done in the
above nserver->validate method.

> So, just check if it serves the zone that you're being asked to delegate.

After we redo the code, this is what we'll be doing.  The
nserver->validate() check will get reduced to seeing if the data supplied
actually resolves as a hostname (or its a valid IPv{4,6} address).

> reason to supply for refusing to do the delegation.

Currently we reject on:

	non-authoritative
	SOA mismatches across supplied nameservers
	NS listing mismatches across supplied nameservers (both what they
		supply and whats in the actual zone file)

Unfortunately, we don't have any tests to reliably produce:

'*ERROR* Nameserver boggle.example.com appears to be running version bar
         of software foo.  This is broken as it does not correctly
         implement feeping-creaturism #34693.  Try again with better
         software.'

;)

---

From: Sam Trenholme <[email-masked]>
Date: Thu, 10 May 2001 21:26:07 -0700 (PDT)

>          implement feeping-creaturism #34693.  Try again with better

My particular DNS server has this feature, which is enabled by default.
When you send a MaraDNS name server this query:

erre-con-erre-cigarro.maradns.org. query txt class 1 (internet)

It sends back the version number of the server in question.  (The
answer that the maradns.org. name servers return is "MaraDNS version
number not available")

I know that some nameservers send me queries in this form:

version.bind. query txt class 3 (what class is class 3 anyway?)

Which may be script kiddies looking for older namservers to exploit, or
could be dns admins seeing what I run.

- Sam

---

From: Mats Dufberg <[email-masked]>
Date: Fri, 11 May 2001 09:11:42 +0200 (CEST)

>   cases we've seen where a nameserver doesn't know about itself have been

My experience is that there is no connection between having nameservers
designed not to know about its own name and broken configuration. It is
mostly big ISP's that have several nameservers for customers, of which
maybe some is also nameserver for their own domain. Telia is a big ISP in
Sweden. One of their domains are telia.com. They have several nameservers
under telia.com, of which dns3.telia.com, dns4.telia.com, dns5.telia.com
and others are not authoritative for telia.com. There are never any
problem with that design.

In our test of delegation we require that we can get an authoritative
answer of the request for an A record of the nameserver name. If the
resolver happens to give such an answer we accept that, or we explicitly
query the nameservers of the name.

Mats

---

From: Mans Nilsson <[email-masked]>
Date: Fri, 11 May 2001 10:22:31 +0200

> could be dns admins seeing what I run.

Unbeknownst to you, those folks at Nominum (and their predecessor) have
put the same feature into BIND. Unless explicitly configured not to,
BIND till answer with its version as a TXT record whwen queried like so:

dig @localhost version.bind CHAOS TXT

and the answer comes through:

;; ANSWER SECTION:
version.bind.           0       CH      TXT     "9.1.1rc4"

Class 3 is CHAOS, for MIT Chaosnet.

(Guess I better upgrade...;-) 

I wonder if I should put myself in ESCROW!!

---

From: Jim Reid <[email-masked]>
Date: Fri, 11 May 2001 02:01:59 -0700

>>>>> "Sam" == Sam Trenholme <[email-masked]> writes:

    Sam> what class is class 3 anyway?

CHAOS. It was a protocol suite that was mainly used by long-dead Lisp
machines. for years BIND has a compiled-in string which it supplies
when asked for a CHAOS TXT record or version.bind.

---

From: "Kenneth Porter" <[email-masked]>
Date: Fri, 11 May 2001 07:37:38 -0700

>		supply and whats in the actual zone file)

How tolerant are you of transient mismatches? One would expect them
during zone updates.

Ken
mailto:[email-masked]

---

From: Mats Dufberg <[email-masked]>
Date: Sat, 12 May 2001 22:07:56 +0200 (CEST)

> How tolerant are you of transient mismatches? One would expect them

Speaking of the SE TLD, we always reject updates where we find any
difference in SOA serial, SOA mail address, NS records or A records
corresponding to necessary glue records between any of the nameservers.

Mats

---

From: Bruce Campbell <[email-masked]>
Date: Mon, 14 May 2001 10:45:49 +1000 (EST)

( ok, this is diverging somewhat )

> > How tolerant are you of transient mismatches? One would expect them

During zone updates you would expect tansient mismatches, but why is the
zone being updated whilst the zone is being delegated ?  That implies that
the zone is not stable, and we dislike non-stable zones (tends to cause
excessive traffic back on our nameservers).

In an idealised world, we'd generate a caution back to the requestor, and
keep trying the nominated nameservers for the nominated domain until we're
happy, or an arbitary timeout (a day?) is exceeded.

> corresponding to necessary glue records between any of the nameservers.

We error out on SOA serial mismatch, and simply warn on any other SOA
mismatch (mail address, timeout values etc) due to some oddities in the
perl DNS module.

---

From: Mats Dufberg <[email-masked]>
Date: Mon, 14 May 2001 12:10:34 +0200 (CEST)

> mismatch (mail address, timeout values etc) due to some oddities in the

What oddities are you refering to?

Mats

---

From: "D. J. Bernstein" <[email-masked]>
Date: 29 May 2001 23:23:01 -0000

> glue to be provided) then it probably should.

Right. If you create a reverse zone in the simplest possible way with
tinydns, namely ./add-ns 3.2.1.in-addr.arpa 1.2.3.144, you get

   3.2.1.in-addr.arpa. NS a.ns.3.2.1.in-addr.arpa.
   a.ns.3.2.1.in-addr.arpa. A 1.2.3.144

so that glue is always provided.

Unfortunately, neither ARIN nor RIPE supports glue, despite the last
paragraph of RFC 1034 section 4.2.2, so reverse lookups on the Internet
are unnecessarily rickety.

---Dan

---

From: Shane Kerr <[email-masked]>
Date: Wed, 30 May 2001 11:03:36 +0200 (CEST)

On 29 May 2001, D. J. Bernstein wrote:

> paragraph of RFC 1034 section 4.2.2, so reverse lookups on the
> Internet are unnecessarily rickety.

Remember that registries are concerned with address to name mapping, and
this is a name to address mapping - one that is already performed
elsewhere.

The problem as I see it is that in order to provide glue records, the
RIR's need to track the A records similar to what you demonstrated.  
What this means is that when an in-addr.arpa zone changes (e.g. new
nameserver added, nameserver IP changes) the zone administrator has to
remember to update both their own zone files (or equivalent in the
tinydns case) as well as the records at the appropriate RIR.

One possible solution is for the RIR's to allow the recipients of
delegated space the option of maintaining glue information, so they can
decide for themselves whether they want the administrative overhead in
exchange for increased reliablity and response, reduced network and
server load, etc.  In reality it is likely there would be a lot of
garbage - perhaps even reducing the reliability of IN-ADDR.ARPA in
general rather than increasing it.

Would the RIR's then have to run automatic processes to verify their
glue records?  Would (should) they then simply use those all the time
rather than requiring users update them manually at all?  There are
large disadvantages to an automatic process like this.

IIRC, I asked for community input about this issue when I was at ARIN,
and received no feedback - my guess is that the Internet at large
doesn't consider it an important issue.

--
Shane

---

From: bert hubert <[email-masked]>
Date: Wed, 30 May 2001 11:54:42 +0200

> tinydns case) as well as the records at the appropriate RIR.

Automation is the key word here. 

> large disadvantages to an automatic process like this.

Well, it sets policy where it is often not expected. In an age where reverse
delegation is considered less and less important (many administrators do not
even know how it is set up - 'why doesn't it work out of the box'), we
should wonder if IN-ADDR.ARPA delegation should be made more difficult than
it currently is.

> doesn't consider it an important issue.

Well, 'The internet at large' often does not know what is broken. People
generally feel that 'stuff is not quite working as it should', without being
able to blame it on a single issue, like numerous compounded out-of-bailiwick
references causing 'rickety' dns service.

This ignorance about the reasons for bad 'surfing experience' leads to
little or no feedback - I did some experiments with a friend (Remco van
Mook) on three reputable networks (Surfnet, UUnet and Level(3)) and we found
that dns queries are very often answered late enough that the recursing
nameserver has already decided to move on to the next NS record.

Having a lot of out-of-bailiwick references then becomes a major issue in
delaying lookups. But imho, this is more important for forward lookups.

Regards,

bert hubert

---

From: Robert Elz <[email-masked]>
Date: Wed, 30 May 2001 19:44:22 +0700

Date:        Wed, 30 May 2001 11:03:36 +0200 (CEST)
    From:        Shane Kerr <[email-masked]>
    Message-ID:  <[email-masked]>

  | Remember that registries are concerned with address to name mapping, and
  | this is a name to address mapping - one that is already performed
  | elsewhere.

This has nothing to do with anything.   Anyone delegating pieces of the
DNS tree (whether for profit, as a public service, or just to other parts
of their own organisation) ought to be doing it properly.   And that
includes inserting glue records whenever they are required.

But ...

  | IIRC, I asked for community input about this issue when I was at ARIN,
  | and received no feedback - my guess is that the Internet at large
  | doesn't consider it an important issue.

this doesn't surprise me at all.

kre

---

From: Bruce Campbell <[email-masked]>
Date: Thu, 31 May 2001 09:44:33 +1000 (EST)

> includes inserting glue records whenever they are required.

Then (taking into account the RIR's previous experience with glue records
and the resounding lack of people caring about the reverse tree etc), what
would be the 'best' way of doing this?

The RIR's current procedures for obtaining delegation information are
simply 'range, nameservers' (in one form or another).  Asking the RIRs to
supply glue with the delegation implies an extra step, with accompanying
onus, being one of:

	Nameserver IPs collected at time of request, onus on
	client/requestor to ensure that they are kept up to date.

or

	RIR automagically keeps track of IP address changes applicable to
	nameservers referenced as glue, with onus on RIR to keep this
	magic running  (assume normal DNS refresh times are involved here,
	so a change to a glue nameserver would be reflected in the RIR's 
	glue a short (Listed-DNS-refresh-time+Listed-RIR-zone-rebuild-time)
	time later ).

or

	(current) RIR does not supply glue records, relying on the
	visibility of the forward tree for delegations to work.

Choose one, you can't have all three ;)

---

From: Bill Manning <[email-masked]>
Date: Wed, 30 May 2001 17:20:30 -0700 (PDT)

% Then (taking into account the RIR's previous experience with glue records
% and the resounding lack of people caring about the reverse tree etc), what
% would be the 'best' way of doing this?

	DataPoint:
	for 1q2001
	
	Brittle data indicates ~60% of the in-addr.arpa tree is not mappable.
	Mice&Men data indicates ~75% of the forward tree is not mappable.
	
	Which tree is more broken?

-- 
--bill

---

From: "D. J. Bernstein" <[email-masked]>
Date: 31 May 2001 00:36:07 -0000

> client/requestor to ensure that they are kept up to date.

Yes, that's how delegations work. RFC 1034: ``The administrators of both
zones should insure [sic] that the NS and glue RRs which mark both sides
of the cut are consistent _and remain so_.'' (Emphasis added.)

As for the frequency of changes: Yes, you have to be notified whenever
the server's IP address changes. On the other hand, you're already
dealing with changes in the NS names. Sensibly chosen in-zone NS names
(a.ns, b.ns) have the advantage of lasting forever. The overall effect
on the frequency of changes could be positive or negative.

---Dan

---

From: Robert Elz <[email-masked]>
Date: Thu, 31 May 2001 14:13:54 +0700

Date:        Thu, 31 May 2001 09:44:33 +1000 (EST)
    From:        Bruce Campbell <[email-masked]>
    Message-ID:  <[email-masked]>

  | Then (taking into account the RIR's previous experience with glue records
  | and the resounding lack of people caring about the reverse tree etc), what
  | would be the 'best' way of doing this?

  | 	Nameserver IPs collected at time of request, onus on
  | 	client/requestor to ensure that they are kept up to date.

That's the easy way of course.

  | 	RIR automagically keeps track of IP address changes applicable to
  | 	nameservers referenced as glue

That's the one I'd like.  In any random forward domain, that's probably
unsupportable.   In the in-addr.arpa tree, it is perhaps almost reasonable
to do that.

Recall we're only talking about necessary glue - not just any random A
record for any random nameserver that someone happens to dump on you.

If I request an in-addr.arpa delegation to munnari.oz.au and supply you
with munnari's current IP addresses, you should simply trash those
(ignore them - regardless of what I tell you, I really *don't* want you
listing A records for munnari in your servers, even if I don't know that
I don't want that, really, I don't...)

On the other hand, if I apply for in-addr.arpa delegation of 
1.168.192.in-addr.arpa and list ns.1.168.192.in-addr.arpa as the nameserver
and give you its A record, then that is necessary glue, and you have to
list it for the delegation to work.   Your only other option is to
refuse to do the delegation on the grounds that you don't like the
name of my nameserver - and that is not really acceptable.

Keeping track of those A records (since chances are that you'll only
see a handful, if that, a year) shouldn't be too hard - though for it
to work relies on the set of nameservers for the zone not all changing
addresses at the same time.  That ought to be an operational requirement
for any set of nameservers for a zone - but we know how seriously people
take those kinds of requirements...

kre

---

From: Robert Elz <[email-masked]>
Date: Thu, 31 May 2001 19:41:29 +0700

Date:        Thu, 31 May 2001 12:29:09 +0200 (CEST)
    From:        Shane Kerr <[email-masked]>
    Message-ID:  <[email-masked]>

  | But I suspect this is exactly what Bruce is suggesting!

My impression was that Bruce was imagining something different than what
is actually being suggested here.

  | Looking at the in-addr.new file from ARIN reveals that there are less
  | than 25000 unique servers, a nearly trivial number of lookups to perform
  | to get glue information.

If that's possible, then great - to make this work rationally with a
"classic BIND" all that's needed is to allow the server to handle recursive
queries when they come from magic box A (equipment run by the RIR), and
then have A issue queries for all of those 25000 server names, directed
at (all of the) relevant in-addr.arpa servers, and then from the answers it
gets, repeat the queries as soon as the TTLs have expired (any sooner
than that and the server will just answer from its cache, that isn't of
benefit to anyone).   That will prime the cache of the servers with all
of the glue records, and BIND will then return those as additional info
with the NS records.

That's fine, fairly easy, and is likely to be of some benefit.

But it has nothing at all to do with whether the registry will enter
necessary glue information when it is required - that glue must be manually
entered into the zone file - by definition, it is required only if there's
no way to obtain it using normal DNS methods, ie: you hit a circular
dependency, you can't get the A record for X without first finding the A
record for X...

  | A scan by each RIR, perhaps based on one of the TTL values in the SOA
  | record with a reasonable minimum refresh time (wouldn't want to query
  | NEC.COM every 2 hours, for instance) could probably achieve the goal of
  | inserting glue records, although not in the way that the
  | ns.x.y.z.in-addr.arpa A record fans want.  :)

Exactly (without counting myself as a fan of that scheme...).   The two
things are totally unrelated.

  | This would also have the side benefit of being a nice reference for
  | broken delegations, in case the Internet community wanted to pursue
  | more proactive means of improving in-addr.arpa delegation.

This is a long way from achieving that (it would find only the comparatively
few cases where a totally bogus name is listed as an NS).   To do more
than that, which I think would be valuable, would require going out to
actually query all of those servers for all of the delegated domains that
they're supposed to handle, and see if they're reporting sane answers or
not.  But that is a totally different discussion.

  | This is probably so for a large number of cases, but not true for ISP's
  | that have lots of disjoint IP space.

I have no idea at all how that ever became relevant to anything.   The
issue here relates to a single delegation, and how the RIRs handle that
request.

Whether it makes sense for an ISP to actually use this method to arrange
the delegation for 10000 in-addr.arpa domains that they handle is another
question entirely.  (Personally I don't think so, but that's a question
for each ISP to answer for itself).

The question isn't whether this is a sane way to delegate things, but that
given it is a legal way, why is it not being supported by the registries?

It is somewhat ironic that the in-addr.arpa registries won't insert glue
when it is needed, and the COM (etc) registries (or maybe it is the root)
insist on inserting glue when it isn't...

  | There is also the issue of educating administrators on this methodology,

There is no need.   No-one is proposing requiring anything like this
(I hope).   If people don't understand it, then they won't use it, and
that will harm no-one (IMO).

The only issue here is whether it is possible, not whether it should be
advocated.   Or at least, that's the only one worth discussing.

kre

---

From: Shane Kerr <[email-masked]>
Date: Thu, 31 May 2001 12:29:09 +0200 (CEST)

On Thu, 31 May 2001, Robert Elz wrote:

> That's the one I'd like.  In any random forward domain, that's
> probably unsupportable.  In the in-addr.arpa tree, it is perhaps
> almost reasonable to do that.
> 
> Recall we're only talking about necessary glue - not just any random
> A record for any random nameserver that someone happens to dump on
> you.
> 
> If I request an in-addr.arpa delegation to munnari.oz.au and supply
> you with munnari's current IP addresses, you should simply trash
> those (ignore them - regardless of what I tell you, I really *don't*
> want you listing A records for munnari in your servers, even if I
> don't know that I don't want that, really, I don't...)

But I suspect this is exactly what Bruce is suggesting!  And to be
honest, I think what most network administrators would expect.  Not that
I know most network administrators....

Looking at the in-addr.new file from ARIN reveals that there are less
than 25000 unique servers, a nearly trivial number of lookups to perform
to get glue information.

A scan by each RIR, perhaps based on one of the TTL values in the SOA
record with a reasonable minimum refresh time (wouldn't want to query
NEC.COM every 2 hours, for instance) could probably achieve the goal of
inserting glue records, although not in the way that the
ns.x.y.z.in-addr.arpa A record fans want.  :)

This would also have the side benefit of being a nice reference for
broken delegations, in case the Internet community wanted to pursue
more proactive means of improving in-addr.arpa delegation.

> 1.168.192.in-addr.arpa and list ns.1.168.192.in-addr.arpa as the
> nameserver and give you its A record, then that is necessary glue,
> and you have to list it for the delegation to work.  Your only other
> option is to refuse to do the delegation on the grounds that you
> don't like the name of my nameserver - and that is not really
> acceptable.
> 
> see a handful, if that, a year) shouldn't be too hard - though for
> it to work relies on the set of nameservers for the zone not all
> changing addresses at the same time.  That ought to be an
> operational requirement for any set of nameservers for a zone - but
> we know how seriously people take those kinds of requirements...

This is probably so for a large number of cases, but not true for ISP's
that have lots of disjoint IP space.  True, they won't have to update
the information very often once correct, but every time they buy a
smaller ISP they're going to have to worry about not only integrating
the different infrastructure into their own, but also now changing a set
of records in one or more RIR databases to use their preferred name
servers.

There is also the issue of educating administrators on this methodology,
which isn't the way that most forward delegation is carried out (e.g.
one of nominum.com's name servers is ns-ext.vix.com, which doesn't fit
in the "use only name servers in the domain to respond authoritatively
for that domain" model.

Does anyone who administers a lot of IP space have strong feelings on
this issue?

Shane

---

From: [email-masked]
Date: Fri, 01 Jun 2001 10:00:37 +1000

> in the "use only name servers in the domain to respond authoritatively

	As a model for good DNS delegation it is overkill.

	A just as robust model is "a nameserver should be a official
	(not stealth) server for the zone it lives in".  ns-ext.vix.com
	fits this model as it is a server for vix.com.

	This leads to NS chains of length 1.

	Mark

---

From: George Michaelson <[email-masked]>
Date: Fri, 01 Jun 2001 09:47:23 +1000

If there is a serious proposal of some merit for the wider community based
on the RIR hosting boxen and doing things with them, I am keen to narrow
down the spec, and get it proposed. There are opportunities for coordination
face to face in August (IETF) and before then on email.

Secondly, if there is some refinement of procedure for glue requirements
which can be defined and then equalized across the RIR and if appropriate
NIR/LIR, lets get that done too.

Cheers
	-George
--
George Michaelson       |  APNIC
Email: [email-masked]    |  PO Box 2131 Milton QLD 4064
Phone: +61 7 3367 0490  |  Australia
  Fax: +61 7 3367 0482  |  http://www.apnic.net