Re: [DNSOP] I-D Action: draft-ietf-dnsop-aname-01.txt

[Richard Gibson]

Comments on the latest ANAME draft:

In Section 3.1, "records retrieved during ANAME <> resolution" looks 
like a typo. Should "<>" be ""?


Also in Section 3.1, the first five paragraphs could be more explicit 
about resolving and adding address records instead of specifically A 
and/or  (other than as examples).


Also in Section 3.1, the final paragraph will result in universal 
SERVFAIL responses if an ANAME target is in a misconfigured signed zone, 
even if the zone containing the ANAME is _not_ signed (and a 
corresponding traffic spike from ANAME-ignorant resolvers).


In Section 4, "resolution fails" should be better defined. Specifically, 
may resolvers use server-provided records if their own query results in 
NODATA or NXDOMAIN?


I think zone transfer considerations merit their own section, rather 
than being buried in and mixed with DNSSEC in 3.3. And because of those 
considerations, I consider it a mistake to prohibit secondary servers 
from resolving ANAME targets when there are address records at the same 
node as is required by Section 3.2. Behavior in error cases, including 
those stemming from ANAME-ignorant participants, seems to be much more 
preferable if such address records are treated as fallback data occluded 
during healthy operation:


1. *ANAME-ignorant primary, ANAME-aware secondary*: The secondary will
   have access to fallback data from the zone, but will only include it
   in responses when its own ANAME target resolution fails. The
   secondary can thus provide better answers to ANAME-ignorant clients
   when responses for the ANAME target are tailored.
2. *ANAME-aware primary, ANAME-ignorant secondary*: Including expanded
   records in the transferred zone data results in stretching ANAME
   TTLs and failing to update anything until secondary refresh, but
   /not/ including them would almost completely suppress ANAME
   functionality. I think the tradeoffs here need further analysis;
   more on that below.
3. *Address-including zone, address-lacking target*: An ALIAS-aware
   server will be able to locally resolve answers from the target name
   for address types that it has (e.g., A), while still providing
   nonempty answers from the zone for those it lacks (e.g., ). At
   least Oracle [Dyn] customers actually prefer such behavior, as I
   mentioned in
   https://www.ietf.org/mail-archive/web/dnsop/current/msg20061.html .
   But note that it requires authoritative servers to override NODATA
   responses to ANAME target resolution, changing the last two
   paragraphs of Section 3.1.
4. *Address-ignorant primary, address-aware secondary*: Assuming that a
   new address record has been defined that the primary does not know
   of, the secondary will be able to include locally-resolved data for
   it, whether or not zone data includes the new type. In cases where
   the zone data just hasn't been updated, this behavior is better than
   assuming it has been pre-expanded to an empty set.
5. *Address-aware primary, address-ignorant secondary*: Assuming that a
   new address record has been defined which the primary knows of but
   the secondary does not, the transferred zone data should include
   pre-expanded answers of the type so the secondary has them available
   for its responses (since it doesn't know to look them up on its
   own). This informs the question from case 2 above, but does not
   completely resolve it (see below).
6. And layering DNSSEC on top of the above (i.e., assuming the
   ANAME-containing zone is signed), *ANAME-aware secondary without a
   zone-signing private key*: I agree that there is no reason for a
   secondary to respond with data that it cannot sign, but it should
   still include signed (fallback) data that ANAME-aware clients will
   attempt to override with local resolution. But how is the XFR server
   to know if the XFR client can add valid signatures?

Regarding zone transfers in which the secondary server is ignorant of 
ANAME altogether, or the inclusion of a new address type, it seems clear 
that primary servers capable of pre-expansion should do so. But in my 
mental model, there's a distinction between static in-zone fallback data 
and data that was resolved upstream (the latter subject to TTL 
decrementing and local refreshes, the former not), and ANAME-aware zone 
transfers should preserve the distinction even though resolution 
responses won't. There's also the practical matter of zone serial, which 
controls zone transfers but SHOULD NOT be updated by changes in non-zone 
data like ALIAS target answers.


With all that in mind, I think ANAME will need to update the definition 
of AXFR and IXFR, and IXFR in particular is likely to give ANAME a hard 
time:


   @ SOA serial= ; PROBLEM 1!
  ; Use of an already-known serial (since static zone contents
   have not changed).
  ; This may confuse ANAME-ignorant servers into ignoring the
   XFR altogether.
   @     SOA serial= ; PROBLEM 2!
      ; 

Re: [DNSOP] WGLC for draft-ietf-dnsop-let-localhost-be-localhost-02

[Paul Vixie]

as a general principle, any time you have to reach outside of a 
connectivity boundary in order to learn how to reach inside of a 
connectivity boundary, it's a sign of bad design.


needing to talk to a root name server in order to reach a cctld name 
server so that you can talk to people inside your own country, is an 
example of this -- and adding root name servers in that country, or on 
the loopback interface, is a workaround for a bad design, and does not 
make the design good.


the same is true for needing to reach outside your own virtual cloud, or 
your laptop, or your house or office or campus or enterprise, to find 
the "delegation data" that will let you talk to inside servers in order 
to get the information you need to talk to other inside servers. many of 
us use "stub zones" to work around this bad design, but DNS itself is 
crippled by many things, and this is one of them.


needing to talk to an rdns server to figure out that localhost means ::1 
(or 127.0.0.1 on the legacy internet) is also a bad design.


a hard transition, where all RDNS servers stop answering for localhost 
as soon as possible, is what would be in my opinion the best way to 
escape the long-armed clutches of bad design.


however, RDNS operators might be worried about complaints from their end 
users, and may want to either work through a gentle transition, or more 
likely, leave all the "tough love" for their successors to implement, 
and simply never remove this, because it's not causing them any 
problems, whereas removing it definitely could cause them problems.


vixie

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] WGLC for draft-ietf-dnsop-let-localhost-be-localhost-02

[Ted Lemon]

On Jan 22, 2018, at 12:43 PM, Bob Harold  wrote:
> Do we need to make sure stub resolvers get updated before we update DNS, to 
> avoid breaking things?

I support it too.   One observation, Bob—my recollection is that when we 
discussed this previously, we concluded that it's probably better, if a 
resolver is broken, for it to fail than succeed.   IOW, at the time I didn't 
hear a lot of voices saying "we have to hold off on deploying this."

This is not to say that it's a bad question.   Do you have any thoughts about 
what the answer should be?   In particular, use cases where breaking the 
resolver would be worse than not breaking it?   Given the way the discussion 
went earlier, that would probably be the thing to bring up, if you can think of 
a case where this is something we ought to be working hard to avoid.


___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] WGLC for draft-ietf-dnsop-let-localhost-be-localhost-02

[Bob Harold]

On Mon, Jan 22, 2018 at 11:18 AM, Suzanne Woolf 
wrote:

> Hi all,
>
> This is the opening of the Working Group Last Call for "Let 'localhost' be
> localhost” (https://www.ietf.org/id/draft-ietf-dnsop-let-
> localhost-be-localhost-02.txt).
>
> We’ll end it in two weeks, on February 5, 2018.
>
> Please focus feedback on: Is this draft ready to go to the IESG for
> approval as an RFC? If not, can you suggest specific changes it needs?
>
> The chairs need to see both positive and negative feedback, so please
> speak up.
>
>
> Thanks,
> Suzanne & Tim
>
>
I support this.
My concerns:
Do we need to make sure stub resolvers get updated before we update DNS, to
avoid breaking things?
Do we know what current stub resolvers do?

I notice that Google DNS returns NXDOMAIN, but OpenDNS returns 127.0.0.1

-- 
Bob Harold
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

[DNSOP] WGLC for draft-ietf-dnsop-let-localhost-be-localhost-02

[Suzanne Woolf]

Hi all,

This is the opening of the Working Group Last Call for "Let 'localhost' be 
localhost” 
(https://www.ietf.org/id/draft-ietf-dnsop-let-localhost-be-localhost-02.txt).

We’ll end it in two weeks, on February 5, 2018.

Please focus feedback on: Is this draft ready to go to the IESG for approval as 
an RFC? If not, can you suggest specific changes it needs?

The chairs need to see both positive and negative feedback, so please speak up.


Thanks,
Suzanne & Tim


___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop