>The only use case you describe (firewall configuration) is >questionable. This is just a single use case, there can be a number of implementations for IPv4 to IPv6 and vice versa resolution. As I have faced the problem during development of writing automation service, thus i discuss this use case to support the requiremnet of the proposed resource record.
>Most firewall configuration interfaces allow you to use >domain names instead of IP addresses. So, if I want to allow port 443 >to www.example.com (which has IPv4 and IP v6 addresses), I can. Note >that many firewall administrators don't use this because, rightly or >wrongly, they don't trust the DNS. They'll have the same issue with >your proposal. using a firewall based on domain names can be simply bypassed by accessing websites through IP address. We have experienced this scenario here in Pakistan when the Government restrict access to youtube, but people were still able to access it through the IP address. Second, there are some firewalls such as Cisco and Kaspersky that handle this situation when someone configure a firewall rule based on domain name, it automatically resolves the IPv4 and IPv6 addresses for that domain and update the firewall rules so that it cannot be bypassed through accessing a server through IP based. But, these are highly expensive firewalls and normally not affordable for every organization. >By the way, that's why you _need_ to write something in the Security >Considerations, probably mentioning DNSSEC. Yes agreed, I will discuss it in that perspective. On Mon, Nov 27, 2017 at 10:58 PM, <dnsop-requ...@ietf.org> wrote: > Send DNSOP mailing list submissions to > dnsop@ietf.org > > To subscribe or unsubscribe via the World Wide Web, visit > https://www.ietf.org/mailman/listinfo/dnsop > or, via email, send a message with subject or body 'help' to > dnsop-requ...@ietf.org > > You can reach the person managing the list at > dnsop-ow...@ietf.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of DNSOP digest..." > > > Today's Topics: > > 1. Re: IVIPTR: New RR for DNS (Stephane Bortzmeyer) > 2. Re: IVIPTR: New RR for DNS (Stephane Bortzmeyer) > 3. Re: Terminology: "primary master" (Joe Abley) > 4. Re: Terminology: "primary master" (Tony Finch) > 5. I-D Action: draft-ietf-dnsop-terminology-bis-08.txt > (internet-dra...@ietf.org) > 6. Re: I-D Action: draft-ietf-dnsop-terminology-bis-08.txt > (Paul Hoffman) > 7. Re: [v6ops] New Version Notification for > draft-palet-sunset4-ipv6-ready-dns-00.txt (Gert Doering) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Mon, 27 Nov 2017 15:27:39 +0100 > From: Stephane Bortzmeyer <bortzme...@nic.fr> > To: Tony Finch <d...@dotat.at> > Cc: bert hubert <bert.hub...@powerdns.com>, Tariq Saraj > <tariqsa...@gmail.com>, dnsop@ietf.org > Subject: Re: [DNSOP] IVIPTR: New RR for DNS > Message-ID: <20171127142739.3a3w6yv5wsje5...@nic.fr> > Content-Type: text/plain; charset=us-ascii > > On Mon, Nov 27, 2017 at 01:38:08PM +0000, > Tony Finch <d...@dotat.at> wrote > a message of 24 lines which said: > > > Why not > > Section 1 of the draft explains "why not" but I disagree with their > assessment. I think the PTR way is indeed the right one. > > > > ------------------------------ > > Message: 2 > Date: Mon, 27 Nov 2017 15:45:15 +0100 > From: Stephane Bortzmeyer <bortzme...@nic.fr> > To: Tariq Saraj <tariqsa...@gmail.com> > Cc: dnsop@ietf.org > Subject: Re: [DNSOP] IVIPTR: New RR for DNS > Message-ID: <20171127144515.4ol63kkaptnwm...@nic.fr> > Content-Type: text/plain; charset=us-ascii > > On Sat, Nov 25, 2017 at 10:41:13PM +0500, > Tariq Saraj <tariqsa...@gmail.com> wrote > a message of 60 lines which said: > > > Please provide your valuable feedback on the newly uploaded draft. > > draft-tariq-dnsop-iviptr-00 > > <https://datatracker.ietf.org/doc/draft-tariq-dnsop-iviptr/> > > *IVIPTR: Resource Record for DNS* > > The only use case you describe (firewall configuration) is > questionable. Most firewall configuration interfaces allow you to use > domain names instead of IP addresses. So, if I want to allow port 443 > to www.example.com (which has IPv4 and IP v6 addresses), I can. Note > that many firewall administrators don't use this because, rightly or > wrongly, they don't trust the DNS. They'll have the same issue with > your proposal. > > By the way, that's why you _need_ to write something in the Security > Considerations, probably mentioning DNSSEC. > > Otherwise, I'm not convinced by your argument against using PTR. If > people don't configure PTRs to get the effect you want, it may be because: > > * they don't want to (so they don't need your proposal) > * they're lazy or incompetent (so they'll ignore your proposal) > > > > ------------------------------ > > Message: 3 > Date: Mon, 27 Nov 2017 11:34:11 -0500 > From: Joe Abley <jab...@hopcount.ca> > To: Tony Finch <d...@dotat.at> > Cc: "dnsop@ietf.org" <dnsop@ietf.org>, Havard Eidnes <h...@uninett.no> > Subject: Re: [DNSOP] Terminology: "primary master" > Message-ID: <180576ec-bc7c-47e1-b3f1-87062260c...@hopcount.ca> > Content-Type: text/plain; charset=us-ascii > > Hi Tony, > > On Nov 27, 2017, at 08:22, Tony Finch <d...@dotat.at> wrote: > > > Joe Abley <jab...@hopcount.ca> wrote: > >>> On Nov 23, 2017, at 12:44, Tony Finch <d...@dotat.at> wrote: > >>> > >>> It's quite difficult to have multiple masters and DNSSEC and coherent > >>> copies of the zone from all masters - i.e. more effort than just > spinning > >>> up parallel instances of BIND or Knot in automatic signing mode. > >> > >> Note that I wasn't talking about multiple signers; I was talking about > >> (from the perspective of one particular slave) having multiple masters > >> available to serve precisely the same zone. > > > > A primary master is wrt a zone not a server - a zone's primary master is > > a server that's authoritative for a zone and which does not get the zone > > contents via axfr/ixfr, but instead from a master file and/or UPDATE (or > > a non-standard mechanism such as directly from a database). > > That's an alluringly clear definition, but I'm not sure it matches common > understanding of the term, which I think has more to do with "single source > of truth" than with the specifics of what transport is used to provision > zone data in a server. > > For example, > > W <------- A -------> X > > Suppose A is a source of truth for a particular zone, and that W and X > obtain zone data from A. Are you saying that if the mechanism represented > by the arrows is [AI]XFR then A is a primary master and W and X are not, > whereas if that mechanism is something else (perhaps it's rsync, with W, A > and X all configured to be masters from local zone files) then W, A and X > are all primary masters? > > If A is not a nameserver but instead is a database, and the arrows > represent database replication, then W and X are primary masters but A is > not? > > > Joe > > > ------------------------------ > > Message: 4 > Date: Mon, 27 Nov 2017 17:15:17 +0000 > From: Tony Finch <d...@dotat.at> > To: Joe Abley <jab...@hopcount.ca> > Cc: "dnsop@ietf.org" <dnsop@ietf.org>, Havard Eidnes <h...@uninett.no> > Subject: Re: [DNSOP] Terminology: "primary master" > Message-ID: <alpine.deb.2.11.1711271640260.4...@grey.csi.cam.ac.uk> > Content-Type: TEXT/PLAIN; charset=US-ASCII > > Joe Abley <jab...@hopcount.ca> wrote: > > > > A primary master is wrt a zone not a server - a zone's primary master > is > > > a server that's authoritative for a zone and which does not get the > zone > > > contents via axfr/ixfr, but instead from a master file and/or UPDATE > (or > > > a non-standard mechanism such as directly from a database). > > > > That's an alluringly clear definition, but I'm not sure it matches > > common understanding of the term, which I think has more to do with > > "single source of truth" than with the specifics of what transport is > > used to provision zone data in a server. > > Hmm, I think I sort-of agree, but with caveats... > > I prefer to make a clear distinction between the standard DNS as specified > in the RFCs versus any funky non-standard stuff that people might do with > the DNS. > > The standard DNS protocols are closely fitted to a particular distributed > architecture, in which a zone has a single source of truth that we call > the primary master. You can, of course, implement a similar architecture > using non-standard protocols, but if you do you should take care to make > it clear how you are diverging from the standard - and be careful about > how you use standard DNS terminology when talking about your non-standard > system. > > > For example, > > > > W <------- A -------> X > > > > Suppose A is a source of truth for a particular zone, and that W and X > > obtain zone data from A. Are you saying that if the mechanism > > represented by the arrows is [AI]XFR then A is a primary master and W > > and X are not, whereas if that mechanism is something else (perhaps it's > > rsync, with W, A and X all configured to be masters from local zone > > files) then W, A and X are all primary masters? > > In this case I would say A is a primary master and W and X are secondaries > that use rsync instead of standard zone transfers. > > The part of the standard architecture that you have replaced is the zone > transfer mechanism, so the primary master is architecturally unaffected, > so it's OK to use the same name. > > (But you can't call rsync "ixfr" even though it is incrementally > transferring zones, because that would be unreasonably confusing.) > > > If A is not a nameserver but instead is a database, and the arrows > > represent database replication, then W and X are primary masters but A > > is not? > > In this case I would be very proud of my high-availability multi-master > system. > > Tony. > -- > f.anthony.n.finch <d...@dotat.at> http://dotat.at/ - I xn--zr8h > punycode > Shannon, Rockall, Malin, Hebrides, Bailey: North or northwest 5 to 7, > occasionally gale 8 except in Shannon. Rough or very rough, occasionally > moderate. Squally showers. Good. > > > > ------------------------------ > > Message: 5 > Date: Mon, 27 Nov 2017 09:49:17 -0800 > From: internet-dra...@ietf.org > To: <i-d-annou...@ietf.org> > Cc: dnsop@ietf.org > Subject: [DNSOP] I-D Action: draft-ietf-dnsop-terminology-bis-08.txt > Message-ID: <151180495773.30942.2986792598977230...@ietfa.amsl.com> > Content-Type: text/plain; charset="utf-8" > > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the Domain Name System Operations WG of the > IETF. > > Title : DNS Terminology > Authors : Paul Hoffman > Andrew Sullivan > Kazunori Fujiwara > Filename : draft-ietf-dnsop-terminology-bis-08.txt > Pages : 44 > Date : 2017-11-27 > > Abstract: > The DNS is defined in literally dozens of different RFCs. The > terminology used by implementers and developers of DNS protocols, and > by operators of DNS systems, has sometimes changed in the decades > since the DNS was first defined. This document gives current > definitions for many of the terms used in the DNS in a single > document. > > This document will be the successor to RFC 7719, and thus will > obsolete RFC 7719. It will also update RFC 2308. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-dnsop-terminology-bis/ > > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-ietf-dnsop-terminology-bis-08 > https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-terminology-bis-08 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-ietf-dnsop-terminology-bis-08 > > > Please note that it may take a couple of minutes from the time of > submission > until the htmlized version and diff are available at tools.ietf.org. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > > > ------------------------------ > > Message: 6 > Date: Mon, 27 Nov 2017 09:53:32 -0800 > From: "Paul Hoffman" <paul.hoff...@vpnc.org> > To: dnsop@ietf.org > Subject: Re: [DNSOP] I-D Action: > draft-ietf-dnsop-terminology-bis-08.txt > Message-ID: <7262e5e9-d844-4cba-b406-c38b57440...@vpnc.org> > Content-Type: text/plain; format=flowed > > This draft closes out a bunch of issues. (As a reminder, we're tracking > issues both here on the list and on the GitHub repo: > https://github.com/DNSOP/draft-ietf-dnsop-terminology-bis). > > We will be opening new issues in the coming weeks with the intention to > be ready for WG Last Call by mid-January. > > --Paul Hoffman > > On 27 Nov 2017, at 9:49, internet-dra...@ietf.org wrote: > > > A New Internet-Draft is available from the on-line Internet-Drafts > > directories. > > This draft is a work item of the Domain Name System Operations WG of > > the IETF. > > > > Title : DNS Terminology > > Authors : Paul Hoffman > > Andrew Sullivan > > Kazunori Fujiwara > > Filename : draft-ietf-dnsop-terminology-bis-08.txt > > Pages : 44 > > Date : 2017-11-27 > > > > Abstract: > > The DNS is defined in literally dozens of different RFCs. The > > terminology used by implementers and developers of DNS protocols, > > and > > by operators of DNS systems, has sometimes changed in the decades > > since the DNS was first defined. This document gives current > > definitions for many of the terms used in the DNS in a single > > document. > > > > This document will be the successor to RFC 7719, and thus will > > obsolete RFC 7719. It will also update RFC 2308. > > > > > > The IETF datatracker status page for this draft is: > > https://datatracker.ietf.org/doc/draft-ietf-dnsop-terminology-bis/ > > > > There are also htmlized versions available at: > > https://tools.ietf.org/html/draft-ietf-dnsop-terminology-bis-08 > > https://datatracker.ietf.org/doc/html/draft-ietf-dnsop- > terminology-bis-08 > > > > A diff from the previous version is available at: > > https://www.ietf.org/rfcdiff?url2=draft-ietf-dnsop-terminology-bis-08 > > > > > > Please note that it may take a couple of minutes from the time of > > submission > > until the htmlized version and diff are available at tools.ietf.org. > > > > Internet-Drafts are also available by anonymous FTP at: > > ftp://ftp.ietf.org/internet-drafts/ > > > > ------------------------------ > > Message: 7 > Date: Mon, 27 Nov 2017 18:58:46 +0100 > From: Gert Doering <g...@space.net> > To: Tony Finch <d...@dotat.at> > Cc: Joe Abley <jab...@hopcount.ca>, "v6...@ietf.org WG" > <v6...@ietf.org>, 6...@ietf.org, Daniel Karrenberg > <dan...@karrenberg.net>, dnsop@ietf.org, suns...@ietf.org > Subject: Re: [DNSOP] [v6ops] New Version Notification for > draft-palet-sunset4-ipv6-ready-dns-00.txt > Message-ID: <20171127175846.gh45...@space.net> > Content-Type: text/plain; charset=us-ascii > > Hi, > > On Mon, Nov 27, 2017 at 12:28:16PM +0000, Tony Finch wrote: > > The 31 TLDs with no v6 nameservers: > [..] > > > mil. > > Yay. Like, IPv6 mandate, and all that. > > Gert Doering > -- NetMaster > -- > have you enabled IPv6 on something today...? > > SpaceNet AG Vorstand: Sebastian v. Bomhard > Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann > D-80807 Muenchen HRB: 136055 (AG Muenchen) > Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 > > > > ------------------------------ > > Subject: Digest Footer > > _______________________________________________ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop > > > ------------------------------ > > End of DNSOP Digest, Vol 132, Issue 53 > ************************************** > -- Regards Tariq Saraj Riphah Institute of Systems Engineering, Islamabad
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
