[dnsext] Clarification on RFC 2181

RFC 2181, section 5.4.1 makes it clear that the NS from a child is 
"more trustworthy" than a NS from the parent. I have some issues with this 
notion of "trust", since both parent and child must be trusted regardless. 
But leaving that aside, it seems that problems can arise if glue A records
expire before NS records.

Example:

example.com 432000 NS ns.example.com
ns.example.com 1000 A 1.2.3.4

Suppose a resolver has fetched these records from the child zone.
Now suppose that administrator changes the zone to

example.com 432000 NS ns1.example.com
ns1.example.com 1000 A 1.2.3.4

and updates the parent and child zone files.

When the original A record expires from the resolver cache, the original NS 
record will remain for some time, but there is no hope of resolving it. 
The resolver will go to the parent, and receive the new NS and A record, 
but since the child NS has priority by RFC 2181, the NS will not be replaced, 
and there will be a blackout until the original NS record expires.

Section 5.4 does state 
"The challenge for the server is to determine which of the data sets is
 correct, if one is, and retain that, while ignoring the other."

It seems to me that to avoid problems newly fetched data from the Parent 

Re: [dnsext] Clarification on RFC 2181

Re: [dnsext] Clarification on RFC 2181

> From: "George Barwood" <george.barwood <at> blueyonder.co.uk>
> Date: Thu, 2 Jul 2009 16:49:03 +0100

> ..., it seems that problems can arise if glue A records expire before NS
> records.
> 
> Example:
> 
> example.com 432000 NS ns.example.com
> ns.example.com 1000 A 1.2.3.4
> 
> Suppose a resolver has fetched these records from the child zone.
> Now suppose that administrator changes the zone to
> 
> example.com 432000 NS ns1.example.com
> ns1.example.com 1000 A 1.2.3.4
> 
> and updates the parent and child zone files.
> 
> When the original A record expires from the resolver cache, the original
> NS record will remain for some time, but there is no hope of resolving
> it.  The resolver will go to the parent,

why?  the resolver already has a zone cut, it has no reason to iterate
through the parent until the zone cut (NS+A) in its cache expires.

>                                           and receive the new NS and A
> record, 

as above, it won't be receiving any such new NS+A until it has a reason
to iterate through the parent again, which means, until after the current
in-cache NS+A expires.

> but since the child NS has priority by RFC 2181, the NS will not
> be replaced, and there will be a blackout until the original NS record
> expires.
> 
> Section 5.4 does state 
> "The challenge for the server is to determine which of the data sets is
>  correct, if one is, and retain that, while ignoring the other."
> 
> It seems to me that to avoid problems newly fetched data from the Parent 
> should replace old child data, but this seems contrary to 5.4.1.
> 
> So I'm feeling somewhat conflicted/confused - help!

for this question to be sequitur, you'd have to assume that the recursive
server was going to periodically revalidate its cached delegation points.

--
to unsubscribe send a message to namedroppers-request <at> ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/namedroppers/>

Re: [dnsext] Clarification on RFC 2181

Re: [dnsext] Clarification on RFC 2181

Re: [dnsext] Clarification on RFC 2181

----- Original Message ----- 
From: "Paul Vixie" <vixie <at> isc.org>
To: <namedroppers <at> ops.ietf.org>
Sent: Thursday, July 02, 2009 5:18 PM
Subject: Re: [dnsext] Clarification on RFC 2181 


>> From: "George Barwood" <george.barwood <at> blueyonder.co.uk>
>> Date: Thu, 2 Jul 2009 16:49:03 +0100
> 
>> ..., it seems that problems can arise if glue A records expire before NS
>> records.
>> 
>> Example:
>> 
>> example.com 432000 NS ns.example.com
>> ns.example.com 1000 A 1.2.3.4
>> 
>> Suppose a resolver has fetched these records from the child zone.
>> Now suppose that administrator changes the zone to
>> 
>> example.com 432000 NS ns1.example.com
>> ns1.example.com 1000 A 1.2.3.4
>> 
>> and updates the parent and child zone files.
>> 
>> When the original A record expires from the resolver cache, the original
>> NS record will remain for some time, but there is no hope of resolving
>> it.  The resolver will go to the parent,
> 
> why?  the resolver already has a zone cut, it has no reason to iterate
> through the parent until the zone cut (NS+A) in its cache expires.

Because the A record has expired. The NS record ( TTL 432000 )
will expire later than the A record (TTL 1000 ), and that is a potential problem.

>>                                           and receive the new NS and A
>> record, 
> 
> as above, it won't be receiving any such new NS+A until it has a reason
> to iterate through the parent again, which means, until after the current
> in-cache NS+A expires.
> 
>> but since the child NS has priority by RFC 2181, the NS will not
>> be replaced, and there will be a blackout until the original NS record
>> expires.
>> 
>> Section 5.4 does state 
>> "The challenge for the server is to determine which of the data sets is
>>  correct, if one is, and retain that, while ignoring the other."
>> 
>> It seems to me that to avoid problems newly fetched data from the Parent 
>> should replace old child data, but this seems contrary to 5.4.1.
>> 
>> So I'm feeling somewhat conflicted/confused - help!
> 
> for this question to be sequitur, you'd have to assume that the recursive
> server was going to periodically revalidate its cached delegation points.
> 
> --
> to unsubscribe send a message to namedroppers-request <at> ops.ietf.org with
> the word 'unsubscribe' in a single line as the message text body.
> archive: <http://ops.ietf.org/lists/namedroppers/>
>¶‹§²æìr¸›zǧu©ž²Æ zÚ'jg®Šiz»+z«ž²Ú)²'­~ŠàÂ+a¶°¢·nžË›±Êâmè§jȧ‚W¥Šwš²Ø^™ë,j­{[¡Üš­Èb½èm¶Ÿÿ¢›"z×è®åŠËlþv¦yÚ覗«

Re: [dnsext] Clarification on RFC 2181

On Thu, 2 Jul 2009, George Barwood wrote:

> RFC 2181, section 5.4.1 makes it clear that the NS from a child is
> "more trustworthy" than a NS from the parent. I have some issues with this
> notion of "trust", since both parent and child must be trusted regardless.
> But leaving that aside, it seems that problems can arise if glue A records
> expire before NS records.
>
> Example:
>
> example.com 432000 NS ns.example.com
> ns.example.com 1000 A 1.2.3.4
>
> Suppose a resolver has fetched these records from the child zone.
> Now suppose that administrator changes the zone to
>
> example.com 432000 NS ns1.example.com
> ns1.example.com 1000 A 1.2.3.4
>
> and updates the parent and child zone files.

Operator error, there is nothing that the protocol can do to prevent
mistakes like this cause problems.

DNS has number of timing windows that have to be respected or
things cani/will go wrong, in this case:
ns.example.com should not have been removed until after all instances
of the prior NS set had expired from caches.

 	Olafur

--
to unsubscribe send a message to namedroppers-request <at> ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/namedroppers/>

Re: [dnsext] Clarification on RFC 2181

On Thu, Jul 2, 2009 at 6:41 PM, George
Barwood<george.barwood <at> blueyonder.co.uk> wrote:
> So asking for the old record will never succeed.
> The old NS RRset is useless, no good, unstuck, hopeless, dead and buried.

You'll find that all 'heavy duty' resolvers have code to deal with
'useless rrsets' to make sure parents are (re-)consulted, but not too
often.

    Bert

--
to unsubscribe send a message to namedroppers-request <at> ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/namedroppers/>

Re: [dnsext] Clarification on RFC 2181

I-D Action:draft-ietf-dnsext-dnsproxy-06.txt

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the DNS Extensions Working Group of the IETF.

	Title           : DNS Proxy Implementation Guidelines
	Author(s)       : R. Bellis
	Filename        : draft-ietf-dnsext-dnsproxy-06.txt
	Pages           : 14
	Date            : 2009-07-02

This document provides guidelines for the implementation of DNS
proxies, as found in broadband gateways and other similar network
devices.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-dnsext-dnsproxy-06.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

_______________________________________________
I-D-Announce mailing list
I-D-Announce <at> ietf.org
https://www.ietf.org/mailman/listinfo/i-d-announce
Internet-Draft directories: http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt