Subject: [DNSOP] Always registering the IP address of the name servers during a delegation?

From: Stephane Bortzmeyer <[email-masked]>
Date: Fri, 9 Nov 2007 14:58:11 +0100

The ICANN Anti-Phishing Working Group has put forward a set of best
practice recommendations for ICANN registrars, currently a draft:

http://gnso.icann.org/mailing-lists/archives/registrars/msg05187.html

One item is of relevance to us. They state:

> Name servers should be specified as both FQDN *and* as IP addresses;
> do not allow FQDN's alone.

[The rationale is to detect and limit Fast Flux.]

I thought that there was a wide agreement in the TLD community that it
was bad practice to keep IP addresses of name servers, except when it
was necessary for the glue?

_______________________________________________
DNSOP mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/dnsop

---

From: John Crain <[email-masked]>
Date: Fri, 9 Nov 2007 20:08:02 -0800

Hi Stephane,

Just to Clarify, APWG is not an ICANN working group.

Their site is .... http://www.apwg.org

John L. Crain

---

From: John Crain <[email-masked]>
Date: Fri, 9 Nov 2007 20:08:02 -0800

Hi Stephane,

John L. Crain

---

From: Kevin Darcy <[email-masked]>
Date: Fri, 09 Nov 2007 19:34:55 -0500

> was necessary for the glue?
The document is not clear. The text to which you refer appears in a 
section on data validation, where the measures enumerated are only for 
the purpose of detecting "suspicious" domain registrations. But, the 
subsections directly underneath that text read:
"(i) This can reduce the use of fast flux name servers
(ii) Tying FQDN to specific IP's will ensure illegitimate domains can 
not [sic] be associated with botnets [lack of punctuation here leads to 
syntactic ambiguity - kcd] ensuring the timely removal of illegitimate 
content"

both of which contemplate some sort of "tying" between names and 
addresses which is not clearly spelled out in the document. (Glue? Not 
glue?)

I reserve judgment until the document is clarified.

- Kevin

---

From: Kevin Darcy <[email-masked]>
Date: Fri, 09 Nov 2007 19:34:55 -0500

- Kevin

---

From: Joe Abley <[email-masked]>
Date: Mon, 12 Nov 2007 17:31:12 -0500

> was necessary for the glue?

Is this not also codified in the EPP specification? I thought there  
was language to the effect that you MUST specify one or more addresses  
for host objects which are subordinate to the registry apex, but that  
you MUST NOT specify addresses for hosts which are not.

I went hunting through RFCs to try and find text to quote, but came up  
empty (although admittedly I only skimmed through the text). Perhaps I  
was looking in the wrong place? Or am I just confused?

Joe

---

From: Joe Abley <[email-masked]>
Date: Mon, 12 Nov 2007 17:31:12 -0500

Joe

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Tue, 13 Nov 2007 17:31:38 -0200

On Mon, Nov 12, 2007 at 05:31:12PM -0500,
 Joe Abley <[email-masked]> wrote 
 a message of 20 lines which said:

> Is this not also codified in the EPP specification?

RFC 4932, section 2.5

   When
   a host object is provisioned for use as a DNS name server, IP
   addresses SHOULD be required only as needed to generate DNS glue
   records.

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Tue, 13 Nov 2007 17:31:38 -0200

RFC 4932, section 2.5

   When

---

From: Edward Lewis <[email-masked]>
Date: Tue, 27 Nov 2007 11:47:41 -0500

>was necessary for the glue?

I can't speak for "wide agreement" but generally, reducing the amount 
of unnecessary data is a good thing.  The problem is that what is 
deemed necessary changes over time.

At 5:31 PM -0500 11/12/07, Joe Abley wrote:

>Is this not also codified in the EPP specification? I thought there was
>language to the effect that you MUST specify one or more addresses for
>host objects which are subordinate to the registry apex, but that you
>MUST NOT specify addresses for hosts which are not.

RFC 4932, Section 2.5 may be what you want.

#   When a host object is provisioned for use as a DNS name server, IP
#   addresses SHOULD be required only as needed to generate DNS glue
#   records.

I'd add two caveats - not all TLDs do EPP.  And that SHOULD was borne 
in an environment in which registry operations were the central 
theme, not defending against malicious network behavior.

>was looking in the wrong place? Or am I just confused?

Confused, certainly.  We know you Joe.

I don't mean to say that we want to collect the IP addresses as the 
ICANN APWG draft suggests.  I am just saying that it shouldn't be 
shot down *only* because collecting the IP addresses has heretofore 
been something we don't cotton to.

(Oh, heretofore = up to now; cotton to = we approve of.)
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                                +1-571-434-5468
NeuStar

Think glocally.  Act confused.

---

From: Edward Lewis <[email-masked]>
Date: Tue, 27 Nov 2007 11:47:41 -0500

---

From: Andrew Sullivan <[email-masked]>
Date: Tue, 27 Nov 2007 12:07:57 -0500

> deemed necessary changes over time.

Note that in a registry, there's an ordering problem, too.  Consider
this case

1.  Register example.org with some name servers.

2.  Register ns1.example.org.  It's not yet a name server, so you
    don't need an IP address, because no glue is strictly needed.

3.  Update example.org, and add ns1.example.org as a nameserver. 

The problem is that in (3), _ex hypothesi_ you didn't collect the IP
address in (2), so you'll have a delegation that can't be used (since
you can't get to the name server without the IP address). 

Since this is a general problem when in-zone hosts are created in a
registry, there are good reasons always to collect and store IP
addresses for host objects (or whatever analogous thing you use in
your protocol) that are in-zone.  

-- 
Andrew Sullivan                         204-4141 Yonge Street
Afilias Canada                        Toronto, Ontario Canada
<[email-masked]>                              M2P 2A8
jabber: [email-masked]                 +1 416 646 3304 x4110

---

From: Andrew Sullivan <[email-masked]>
Date: Tue, 27 Nov 2007 12:07:57 -0500

---

From: [email-masked]
Date: Tue, 27 Nov 2007 17:59:02 +0000

> your protocol) that are in-zone.  

	so WHO is the "owner" of that IP data, the zone admin
	for "example.org" or the machine admin for "ns1.example.org"?

	historically, the HOST has had an independent admin, precisely
	because they control the IP's used by the machine, not the zone
	admin.

--bill

---

From: [email-masked]
Date: Tue, 27 Nov 2007 17:59:02 +0000

--bill

---

From: Edward Lewis <[email-masked]>
Date: Tue, 27 Nov 2007 13:18:04 -0500

>	for "example.org" or the machine admin for "ns1.example.org"?

The zone admin for sure.  It is the registration of the domain name 
that is specifying the address records of the name servers.

The reason I say "for sure" comes from an experience of Harald 
Alvestrand.  (I can't find a URL referencing the problem.)  Some 
years ago one of his slave servers was in a domain whose registration 
expired and was taken up by a different registrant.  Had he 
registered the IP address of the slave he intended to be using, it 
would have been easier to debug why every Nth query seemed to get 
answered incorrectly.

>	because they control the IP's used by the machine, not the zone

Historically, we didn't worry about domain name registrations changing hands.

---

From: Edward Lewis <[email-masked]>
Date: Tue, 27 Nov 2007 13:18:04 -0500

---

From: [email-masked]
Date: Tue, 27 Nov 2007 18:25:21 +0000

> that is specifying the address records of the name servers.

	then we have a small issue...  you as zone admin, can't 
	dictate which IP's i must use on my machines, since you don't
	control my connectivity.  as zone admin, your job is to 
	provide accurate mapping betwn lable and address ... the
	extent of your influence is over the lables used, not their
	IP addresses.

> Historically, we didn't worry about domain name registrations changing 
	
	Historically, we did worry. We also worried about changes in
	topology.

---

From: [email-masked]
Date: Tue, 27 Nov 2007 18:25:21 +0000

---

From: Edward Lewis <[email-masked]>
Date: Tue, 27 Nov 2007 14:05:55 -0500

>	extent of your influence is over the lables used, not their

Since we are getting into pronouns, let's clarify what the roles are. 
At least these are what I think we are talking about.

Zone admin = the registrant of the domain owning the NS set.
You ("I" above) = the dude that has the root password to a machine 
that is mentioned in the NS set.

(As opposed to zone admin being the registry that the data is going in to.)

It is the prerogative of you to do what it takes to get your machine 
to function correctly.  It's the prerogative of the zone admin to 
include (or not) your machine in the NS set.

A zone admin ought to be aware of what the state of the slave servers 
are.  (That's my main point.)  There are minor tweaks, like IP 
addresses, and then there are major tweaks, like letting the domain 
lapse.  A responsible zone admin would be up to date on what the 
slave server admins are up to.  So, in this case, when the slave 
server changes IP addresses, this goes to the zone admin, who would 
then have to update the IP addresses registered.

Now being that I work for a TLD, I should say that I'm not 
enthusiastic about collecting these IP addresses.  I like it as it 
is, collect only what needed for the glue.  I mean, no one has said 
yet what the purpose of collecting the addresses for non-glue 
machines would be used for - certainly not to be put into DNS. 
Reporting such IP addresses is more work, it's unclear what they are 
used for, but if there's a benefit...

>	Historically, we did worry. We also worried about changes in

There's nothing stopping you from worrying more and more.
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                                +1-571-434-5468
NeuStar

---

From: Edward Lewis <[email-masked]>
Date: Tue, 27 Nov 2007 14:05:55 -0500

---

From: [email-masked]
Date: Tue, 27 Nov 2007 20:57:13 +0000

> then have to update the IP addresses registered.

	a concrete example:

	i have a zone, example.org and chose the following
	nameservers:

		moe.rice.edu
		ns.isi.edu
		PDC.example.org

	as the admin of PDC.example.org, I know what IP addresses
	are assigned and can change them on whim.  However, It is
	the Height of Arrogance to presume I can tell the rice.edu
	or isi.edu people what IP addresses to use on their machines.
	as the admin for example.org, I clearly have the right to 
	choose/select nameservers for my delegation that meet my
	needs.  Now the poor .org admin - he has to beleive me when
	i tell him what nameservers will be authoritative for example.org.
	and its prolly prudent for him to contact the admins of 
	ns.isi.edu and moe.rice.edu to collect the correct IP addresses
	for those nodes...  If I was the poor sod responsible for .org,
	I would not really beleive that the moron holding example.org
	had done his homework and actually -KNEW- what the IP addresses
	were for these nodes or was in a position to keep that data
	current.  but that would be me.

---

From: [email-masked]
Date: Tue, 27 Nov 2007 20:57:13 +0000

a concrete example:

		moe.rice.edu
		ns.isi.edu
		PDC.example.org

---

From: David Conrad <[email-masked]>
Date: Tue, 27 Nov 2007 13:03:59 -0800

Bill,

> or isi.edu people what IP addresses to use on their machines.

Presumably (assuming we're talking about professionally run infrastructure),
there is an agreement between the zone administrator and the providers of
secondary services.  The IP addresses in use for the secondary service
should be part of that agreement.

Regards,
-drc

---

From: David Conrad <[email-masked]>
Date: Tue, 27 Nov 2007 13:03:59 -0800

Bill,

Regards,
-drc

---

From: Edward Lewis <[email-masked]>
Date: Tue, 27 Nov 2007 16:19:50 -0500

At 8:57 PM +0000 11/27/07, [email-masked] wrote:

>	as the admin of PDC.example.org ... however, it is

The issue isn't between (say) moe.rice.edu and (say) ns.isi.edu, the 
issue is between example.org and (say) moe.rice.edu.

>	needs.  Now the poor .org admin - he has to believe me when

.org doesn't need to believe example.org's claim.  How does .org 
suffer if example.org mis-lists its servers?  How does example.org 
suffer?

>	I would not really believe that the moron holding example.org

I think the missing link here is knowing what is done with the 
collected IP addresses.  In the following scenario there's no risk if 
the addresses are incorrect.

   .org won't list the ns.isi.edu address in DNS, it won't be part of
   the operational fabric.  But let's say someone is debugging a phishing
   attack (as this stemmed from an APWG thing) and they note that
   example.org is being served up by 127.0.3.12.  They ask .org what IP
   addresses were reported for example.org and they find that the address
   being heard isn't one of the listed ones.  At this point it would be
   wrong to conclude that the address is rogue, but it merits questioning
   to see if it's the case that example.org just didn't make an needed
   update (whether aware or not) or the address is indeed rogue.

>should be part of that agreement.

That too.

---

From: Edward Lewis <[email-masked]>
Date: Tue, 27 Nov 2007 16:19:50 -0500

That too.

---

From: [email-masked]
Date: Tue, 27 Nov 2007 21:42:29 +0000

> issue is between example.org and (say) moe.rice.edu.

	w/ you so far.

> suffer if example.org mis-lists its servers?  How does example.org 

	suffering is subjective.  I expect you may be suffering this 
	exchange with the patience of Job.

	.org gets a request from a legit client - in this case, example.org
	to add a list of nameservers, some of which in in zone and some
	are not.  

> the addresses are incorrect.

	risk is also subjective.

>   update (whether aware or not) or the address is indeed rogue.

	but its not example.orgs call if ns.isi.edu changed its ip
	address to 127.0.3.12... is it?  that would be the call of the
	admin for ns.isi.edu.

	and if there were no contact information on that nameserver in
	the form of a HOST record in the whois or comments (w/ glue) in
	the DNS, then debugging an apparent problem is going to be much
	harder.  one could ask if its a service that the .org registry
	is willing to offer on behalf of its clients and the Internet
	community,

---

From: [email-masked]
Date: Tue, 27 Nov 2007 21:42:29 +0000

w/ you so far.

	risk is also subjective.

---

From: [email-masked]
Date: Tue, 27 Nov 2007 21:46:59 +0000

> should be part of that agreement.

	there may be some debate as to how much information is subject
	to contractual binding.  I would hate to be bound to a multiyear
	contract w/ CSC for nameservice that tied me to one of their old
	IP blocks.  Net 10 is used in so many more places these days.

--bill

---

From: [email-masked]
Date: Tue, 27 Nov 2007 21:46:59 +0000

--bill

---

From: Edward Lewis <[email-masked]>
Date: Tue, 27 Nov 2007 17:12:41 -0500

>	address to 127.0.3.12... is it?  that would be the call of the

Yeah - but - it is example.org's call to de-list ns.isi.edu because 
of the change.  I mean, what if ns.isi.edu changes it's name to 
ns1.isi.edu, or becomes IPv6 only (and there's no way for 
example.org's admin to reach it anymore)?  Or changes the admin to 
some organization you don't want to deal with?

Anyway, this is a red herring.  The issue isn't about example.org 
crimping ns.isi.edu's style, it's about example.org maintaining more 
information about its delegation.  When the change happens at 
ns.isi.edu, the correct next step is to have example.org change the 
IP it registers.

>	is willing to offer on behalf of its clients and the Internet

My assumption is that debugging requires getting on the phone and 
getting a live support person somewhere or maybe even a legal request 
for information.  (Being without a law degree, I can't correctly 
spell "subpeona.")  The time is long gone when I can look something 
up on-line and feel I have a reasonable handle on debugging a 
situation.  I suspect that these extra IP addresses might at best be 
in WhoIs, but more likely just filed away somewhere internally as 
they have no operational (packet-flowing) value.

Frankly though, I don't see this information collection happening 
unless there is some strong motivation given.

---

From: Edward Lewis <[email-masked]>
Date: Tue, 27 Nov 2007 17:12:41 -0500

---

From: Brian Dickson <[email-masked]>
Date: Tue, 27 Nov 2007 18:46:53 -0500

> 	or isi.edu people what IP addresses to use on their machines.
Kind of, and maybe.

Basically, glue is necessary only because NS records are allowed to be 
FQDNs instead of just IP addresses. (This is so that fewer NS records 
need to be updated when a nameserver changes IP address(es).)

And that glue is needed only, strictly speaking, when the NS FQDN is a 
subordinate of the (parent) zone.
(Any NS whose FQDN isn't subordinate, is "out of zone data", and 
shouldn't be kept as glue in the zone.)

Sometimes the glue isn't really necessary, if the FQDN of the NS is 
served by zone whose own NS records don't need glue, e.g. are served by 
entirely out-of-zone name servers.
(But that leads potentially to a name-server race condition, which 
operators should know to avoid. Having example.net use ns.example.org as 
its NS, and having example.org use ns.example.net as *its* NS, is bad form.)

In the example above, moe.rice.edu and ns.isi.edu are outside of the 
'.org' zone, and their IP should neither be accepted nor kept.
If, on the other hand, the nameservers were PDC.example.org, and 
FOO.other-example.org, then:
- the IP for FOO may already exist, if it is a nameserver for 
other-example.org
- even if FOO is not a nameserver for other-example.org, it might be in 
future.

So, capturing its IP *might* make sense. But, even if it exists, it 
isn't authoritative, so likely won't (or shouldn't) be used.
Which means, unless it comes to pass that other-example.org uses 
FOO.other-example.org as their nameserver, the presence or absence of 
quote-glue-unquote for FOO is irrelevant and annoying.

And if/when other-example.org adds FOO as their nameserver, they really 
do need to provide the IP, at which time the registrar should require 
the IP, and the registry operator should accept it as authoritative.

(Whether the things pointed to by the NS records are serving the zone is 
a whole other kettle of fish. Lame fish at that.)

Brian

---

From: Brian Dickson <[email-masked]>
Date: Tue, 27 Nov 2007 18:46:53 -0500

Kind of, and maybe.

Brian

---

From: Edward Lewis <[email-masked]>
Date: Wed, 28 Nov 2007 07:09:14 -0500

The issue of collecting IP address for name servers in the context of 
the APWG draft is not about glue.  The issue is not glue but actions 
taken to thwart malicious activity.

>subordinate of the (parent) zone.

"Strictly speaking" is incorrect in the above sentence, "generally 
speaking" is more appropriate.

>Sometimes the glue isn't really necessary, if the FQDN of the NS is served
>by zone whose own NS records don't need glue, e.g. are served by entirely
>out-of-zone name servers.

And that is what I suggest s/strictly/generally/, it seems we 
understand this so I don't think we need any lectures on glue here. 
Especially as that is not the focus of the suggestion to collect IP 
addresses.

>So, capturing its IP *might* make sense. But, even if it exists, it isn't
>authoritative, so likely won't (or shouldn't) be used.

What I think is happening in this thread is that a suggestion has 
been made in a registry forum (ICANN/APWG) that has a brush with DNS 
and we have tried to make it a DNS matter.  It's not a DNS matter, 
it's the collection of data related to DNS that is not intended to be 
in the DNS, no more so that the telephone number of the billing 
contact for the name.
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                                +1-571-434-5468
NeuStar

---

From: Edward Lewis <[email-masked]>
Date: Wed, 28 Nov 2007 07:09:14 -0500

---

From: Frederico A C Neves <[email-masked]>
Date: Wed, 28 Nov 2007 11:07:14 -0200

Bill,

> 	i have a zone, example.org and chose the following

Responsible registry admins would KISS, this is the view of what I
think one of them should do.

> 	the Height of Arrogance to presume I can tell the rice.edu

So at delegation time it'll mandate you to inform the glue record and
will check it for authority on example.org.

> 	for those nodes...  If I was the poor sod responsible for

It'll just use plain old A resolution for these two names, will query
them for authority on example.org.

> 	current.  but that would be me.

Responsible registry admins in your example would just collect glue
for PDC.example.org and will not accept delegation or a change on it
if any of the 3 DNS authority checks failed.

For the .org registry admin there is no need to collect or know who is
the admin and what are the addresses of moe.rice.edu and ns.isi.edu,
let the plain old DNS does its magic.

Fred

ps, btw this simple and functional policy is valid for any zone,
including the root !

---

From: Frederico A C Neves <[email-masked]>
Date: Wed, 28 Nov 2007 11:07:14 -0200

Bill,

Fred